アカウント名:
パスワード:
バッチ処理は多かれ少なかれどの企業でも動いてると思うんだけど、このITジャーナリストの方はフリーランスで自分から近い世界でしかものを見たことないのかな?そう考えると、新しい時代に突入した感覚がある。
あとCOBOLも勘定系ではかなり現役なんだけど、これについては異論多そうなので黙っときます。
COBOL に関しては、・動くものに手を入れるな・動いているものが仕様だから、リプレイスなんてとても……・帳票など COBOL に最適化されていて、他に適した言語って？あたりが現役な理由かなぁ（あと開発当時なら、それが読める人が銀行にも結構いたんじゃないかな）
お金を扱う以上、今までとちょっと違う動きしますってそうそう許されないだろうし、パッケージに業務を合わせるのが特に難しい業界だと思っているとはいえクラウドとか規模拡大とかサービス拡充なんかのために、基幹リプレイスは体力あるところはやった方がいいとは思う
あと、金額を扱う以上COBOLのように10進法で計算するのはありがたい。JAVAでも10進法で定義する型はあるけど、利率計算なんぞさせると途中で2進数になるのか計算結果がずれる。計算がずれるから、プログラムで何とかするしかない時点で使い物にならない。それに別にCOBOLでもリアルタイムで動作するし、JAVAからでも実行できるんだからCOBOLなんて古臭いなんて言ってる方が古臭いし、いじったこともないんだろうなと思う。
BigDecimal でずれる？それってインスタンス化のときにちゃんと値を String で渡してても？
いや、それを「プログラムで何とかするしかない」と言ってるんだけど・・・普通の二進数計算みたいに、何もしなくても計算結果をちゃんと出せと。
いや、それは使い方を間違ってるだけ（new BigDecimal(double a) みたいなの？double 型使ってる時点ですでにずれてるから BigDecimal の罪ではない）だから、「プログラムで何とかするしかない」って話じゃないでしょ。BigDecimal同士の演算ならちゃんとしてくれるはず。
金融系のシステムだったからBigDecimal同士の四則演算をしていて、結果を小数点第二位のBigDecimalにいれたらずれていたんだけど・・・Decimal同士でも内部での計算中はfloat演算してるんかいと。十年ぐらい前だから、いまのJavaは平気なの？
書いた通り・仕様通りにプログラムが演算子を適用した結果じゃないの? > ずれの発生
自分も同じような計算して、ズレが出た記憶があります。15年くらい前かな、10兆円単位の金額を扱う案件の引き合いがあって、計算結果に自信が無いんで計算部分だけテストコード書いて試したら、どうも計算結果がズレる。特に小数点以下が怪しい感じ。任意の桁で切り捨て、切り上げ、四捨五入、五捨六入とかする必要もあって、なんだか面倒そう。結局スケジュールとか金額とか人員のアサインなんかの関係で、お断りしちゃったけど、もし受けちゃったらどうしようとドキドキでした。それから別業種に転職しちゃったんで、最近のJava動向とか知らないんですが、今時はJavaで行けちゃう感じなんですかね。
使えない仕様だってことでしょ「気を付ければ使える」なんてのは腐ってんだよ金銭計算の世界じゃ誤差出したくても出せねぇぐらいじゃないと
×: 気を付ければ使える○: リファレンスを読むという当然のことすらしてない者には使いこなせないなんだよなぁ。真にJavaが「使えない仕様」なのだとしたら、当該プロジェクトの開発言語としてそもそも選定すらされていまい誤算だったのは「プログラマーのレベルが想定以上に腐ってた」ってところだろうな# ここからは私見だが、この分野で対価を得るからには浮動小数や2進表現は# 知ってて然るべきだろうし、知る気がないのなら降りてくれとも思う
で、具体的にどんな実装したのよ?
注意して使えば使えるなんてのはちゃんと書けばバグなんか出ないっていうぐらいの理想論、根性論だよ
普通にプログラマ経験があればさすがに「異なる型を混ぜて計算するときは注意」、「浮動小数同士で計算すると丸め誤差が起きる」ってことぐらいは知ってるでしょ。
当然すべて有効桁2桁のDecimal型（当然途中に型指定のない数字はない）に合わせて、一気に掛け算割り算を行ったら、電卓の結果と異なりました。まあ私見通り、当然浮動小数は基本なので、どこかで丸め誤差でも起こってることはすぐに想像できたので、それを織り込んで計算させると丸め誤差分の結果と一致しました。
人間が直感的に計算する「10進型同士の計算でも気を使わないといけない」ってのが、使えない仕様だと言っている。
想像通り、BigDecimalのリファレンスをちゃんと読めてないだけのことだなぁ乗除算の結果が浮動小数で返ってくるのは、書いた通り・仕様通りの挙動でしかないそうならないための方法が用意されているのがBigDecimalなのにわざわざ丸め誤差補正を車輪の再発明して「使えない仕様」だの、「理想論、根性論」だの宣われてもそれ以前に「ちゃんと書く」行為自体がまず水準に達していない、としか言いようがない
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ研究家
ITジャーナリストも新しい時代に突入 (スコア:1)
バッチ処理は多かれ少なかれどの企業でも動いてると思うんだけど、このITジャーナリストの方はフリーランスで自分から近い世界でしかものを見たことないのかな?
そう考えると、新しい時代に突入した感覚がある。
あとCOBOLも勘定系ではかなり現役なんだけど、これについては異論多そうなので黙っときます。
Re: (スコア:0)
COBOL に関しては、
・動くものに手を入れるな
・動いているものが仕様だから、リプレイスなんてとても……
・帳票など COBOL に最適化されていて、他に適した言語って？
あたりが現役な理由かなぁ
（あと開発当時なら、それが読める人が銀行にも結構いたんじゃないかな）
お金を扱う以上、今までとちょっと違う動きしますってそうそう許されないだろうし、パッケージに業務を合わせるのが特に難しい業界だと思っている
とはいえクラウドとか規模拡大とかサービス拡充なんかのために、基幹リプレイスは体力あるところはやった方がいいとは思う
Re: (スコア:0)
あと、金額を扱う以上COBOLのように10進法で計算するのはありがたい。
JAVAでも10進法で定義する型はあるけど、利率計算なんぞさせると途中で2進数になるのか計算結果がずれる。
計算がずれるから、プログラムで何とかするしかない時点で使い物にならない。
それに別にCOBOLでもリアルタイムで動作するし、JAVAからでも実行できるんだから
COBOLなんて古臭いなんて言ってる方が古臭いし、いじったこともないんだろうなと思う。
Re: (スコア:1)
BigDecimal でずれる？
それってインスタンス化のときにちゃんと値を String で渡してても？
Re: (スコア:0)
いや、それを「プログラムで何とかするしかない」と言ってるんだけど・・・
普通の二進数計算みたいに、何もしなくても計算結果をちゃんと出せと。
Re:ITジャーナリストも新しい時代に突入 (スコア:1)
いや、それは使い方を間違ってるだけ（new BigDecimal(double a) みたいなの？double 型使ってる時点ですでにずれてるから BigDecimal の罪ではない）だから、
「プログラムで何とかするしかない」って話じゃないでしょ。
BigDecimal同士の演算ならちゃんとしてくれるはず。
Re: (スコア:0)
金融系のシステムだったからBigDecimal同士の四則演算をしていて、
結果を小数点第二位のBigDecimalにいれたらずれていたんだけど・・・
Decimal同士でも内部での計算中はfloat演算してるんかいと。
十年ぐらい前だから、いまのJavaは平気なの？
Re: (スコア:0)
書いた通り・仕様通りにプログラムが演算子を適用した結果じゃないの? > ずれの発生
Re: (スコア:0)
自分も同じような計算して、ズレが出た記憶があります。
15年くらい前かな、10兆円単位の金額を扱う案件の引き合いがあって、計算結果に自信が無いんで
計算部分だけテストコード書いて試したら、どうも計算結果がズレる。特に小数点以下が怪しい感じ。
任意の桁で切り捨て、切り上げ、四捨五入、五捨六入とかする必要もあって、なんだか面倒そう。
結局スケジュールとか金額とか人員のアサインなんかの関係で、お断りしちゃったけど、もし受けちゃったらどうしようとドキドキでした。
それから別業種に転職しちゃったんで、最近のJava動向とか知らないんですが、今時はJavaで行けちゃう感じなんですかね。
Re: (スコア:0)
使えない仕様だってことでしょ
「気を付ければ使える」なんてのは腐ってんだよ金銭計算の世界じゃ
誤差出したくても出せねぇぐらいじゃないと
Re: (スコア:0)
×: 気を付ければ使える
○: リファレンスを読むという当然のことすらしてない者には使いこなせない
なんだよなぁ。真にJavaが「使えない仕様」なのだとしたら、
当該プロジェクトの開発言語としてそもそも選定すらされていまい
誤算だったのは「プログラマーのレベルが想定以上に腐ってた」ってところだろうな
# ここからは私見だが、この分野で対価を得るからには浮動小数や2進表現は
# 知ってて然るべきだろうし、知る気がないのなら降りてくれとも思う
で、具体的にどんな実装したのよ?
Re: (スコア:0)
注意して使えば使えるなんてのは
ちゃんと書けばバグなんか出ないっていうぐらいの理想論、根性論だよ
Re: (スコア:0)
普通にプログラマ経験があればさすがに「異なる型を混ぜて計算するときは注意」、
「浮動小数同士で計算すると丸め誤差が起きる」ってことぐらいは知ってるでしょ。
当然すべて有効桁2桁のDecimal型（当然途中に型指定のない数字はない）に合わせて、
一気に掛け算割り算を行ったら、電卓の結果と異なりました。
まあ私見通り、当然浮動小数は基本なので、どこかで丸め誤差でも起こってることはすぐに想像できたので、
それを織り込んで計算させると丸め誤差分の結果と一致しました。
人間が直感的に計算する「10進型同士の計算でも気を使わないといけない」ってのが、
使えない仕様だと言っている。
Re: (スコア:0)
想像通り、BigDecimalのリファレンスをちゃんと読めてないだけのことだなぁ
乗除算の結果が浮動小数で返ってくるのは、書いた通り・仕様通りの挙動でしかない
そうならないための方法が用意されているのがBigDecimalなのに
わざわざ丸め誤差補正を車輪の再発明して「使えない仕様」だの、「理想論、根性論」だの宣われても
それ以前に「ちゃんと書く」行為自体がまず水準に達していない、としか言いようがない