雇われるだけの人生から目指せ独立、社会人2年目なゲーム脳SEのブログ。更新頻度=週2~3回。
×
[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。
仕事中に、同僚の先輩の方から、こんなメッセージが送られてきました。
お疲れ様。ちょっと質問です。
double d = 65.0;
sprintf(out, "%.01f", d);
としたら
out はどうなる?
以下、私とその方とのメッセージのやり取りです。
おそらくですが、%.01fという指定が出来ないはずです。
%9.1f・・・可能。全体で9桁、小数点以下は1桁まで。足りない分はスペース。" 123.1"
%.5f・・・可能。小数点以下5桁まで。"12345.67891"
%010f・・・可能。10桁未満なら足りない桁が左から0で埋められる。"0000000001"
↓こちら参照
http://www9.plala.or.jp/sgwr-t/c/sec05.html#s5-1
えーと、どういう要件ですか?
あれ?やっぱり?
いや、今汎用編集の小数点を含む数値のところでちょっと
気にかかるところがあって、現行ソース見直したら
これが出てきてさ。
複合計算ってとこで、小数点を含む数値の場合は、
10倍してから計算をして、そのご少数1桁にもどすっつって
さっき送った処理がかかれてんの。
小数点になんてもどってないよね?
なるほど、つまりもとの数値が小数点を含む場合は、
(このとき、含まれる小数点以下は1桁以内。1234.5はあるが、123.45はない)
10倍してからint型にして計算して、小数点1桁の数値に戻すってことですか。
(doubleによる精度落ちを防ぐため?)
・・・これじゃ戻りませんね。どう考えても。
よしんば%.01fという記法が正しかったとしても、
%fは引数文字列を小数として扱うものですから、
%fに12345を通しても結果は12345です。
%.1fに12345を通したら結果は12345.0ですし。
だよねー。
やっぱなぁ。なんか変だと思ったんだよなぁ。
さんきゅー。
いえいえ、久しぶりにC言語だったんで頭混乱しまくりですよ。
念のためにjavaのsystem.out.printf()メソッドで検証してみてはいかがですか?
(たしかCと動作がまったく同じだったはずです)
System.out.printf("%.01f", "12345");
ですぐに検証できるとおもいます。1234.5になっていたら感動。
おお!なるほど。
HelloWorldプロジェクトを新規作成しよう(笑)
結果でたらおせーてつかーさーい
エラーもでず、まんま出力。
65.0は65.0のまま。
よかったあああああああああああああ
大嘘ハッタリ言ってなくてよかったです。
まぁ、これで現行ソースに酷いバグがあることが判明しましたねww
うん。さんきゅう。
なーーんかこのシステム大丈夫か??
10倍したの結局元に戻さずになってるぞ・・・。
何の数値なんですか?それ。
お金だったら無茶苦茶面白いことになりますよーw
ああ、重量計算のとこだね。多分。
個数×重量の1~8の合計とか。そんくらいしか使ってないね。
ってことは、送られてきた重量データが10倍になって算出されるシステムwwwww
例:10kgの小包→出荷データではなぜか100kgに!
重量を元に車両の配分をやっていたり、重量を元にお金の請求を
やっていたりしたら、それはそれは楽しいことになりますね。
●●さん超英雄じゃないですか。
でも現行問題おきてねーってことは、
多分このあとの処理とか通るときに(データチェックとか)で
上書きされるかチェックして修正されるかで
正しく書きかえられてる気もする。
となると、汎用編集のとこで処理する必要ねーじゃねーか!!
予想:
システムを構築する
↓
データを流すとなぜか重量が10倍になるバグ発生
↓
原因不明、困った
↓
ええい面倒だ!汎用編集の後で10分の1にしてしまえ!
↓
現在に至る
(某国内大手箱売りベンダ)の人マジ自重しろって感じですね。
まいっちゃうね。コレ、、ホント。
ま、もう僕帰るわ。
明日また検討するってことで。
ありがとうー。
そしてお先に。
いかがでしたでしょうか。
先日、JRの自動改札がバグのせいで起動しないという事件がありましたが、
現在世の中で動いている情報システムなんて皆こんなもんだ
というのが分かったと思います。
ちなみに今私達が改修を手がけているシステム、
国内で業界1~2位を争う大手企業のシステムで、
1日あたりのデータ量は500万件にも及びます。
つまり、1日500万件分のデータが、
こんなつぎはぎだらけのオンボロシステムの上で処理されているわけです。
毎日乗っている電車や飛行機を制御するシステムも、
毎日食べているご飯を流通させるシステムも、
果ては銀行の預金管理をしたり税金の管理をするシステムも、
ひょっとしたらこんな調子なのかもしれないと考えると、恐ろしくなりませんか?
そのくせ、最近では何でもかんでもIT化だの何だのといって情報システム化する始末。
そのうち、とんでもない大事故が起きるんじゃないかと、
同業者ながらヒヤヒヤしながら見守っている毎日です。
まぁ、正直1回酷い大事故が起きてしまったほうが、
IT業界全体、ひいては日本全体に危機意識が伝わって、
この業界も良い方向に向かうのではないかと、不謹慎ながら考えたりしています。
PR
カレンダー
10 | 2024/11 | 12 |
日 | 月 | 火 | 水 | 木 | 金 | 土 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
ブログ内検索
最新記事
(10/12)
(10/09)
(10/09)
(10/08)
(10/05)
カテゴリー
プロフィール
HN:
akisute
性別:
男性
職業:
システムエンジニア
趣味:
ゲーム・東方・ニコ動。あと散歩。
推奨環境
横幅900px以上、Firefox 3, Safari 3, Opera 9.5, Chrome 0.2以上。IE7ギリギリ対応。IE6未対応。