Effective java 第７章

項目 31 正確な答えが必要ならば ,float と double は避ける 浮動小数点は近似計算にすぎない 実数が取り得る値が無限にあるのに大して、浮動小数点で使用できるビットの数は有限であるため そもそも小数の表現の仕方には 固定小数点 浮動小数点 の２種類

浮動小数点は近似計算にすぎない

実数が取り得る値が無限にあるのに大して、浮動小数点で使用できるビットの数は有限であるため

そもそも小数の表現の仕方には

固定小数点

浮動小数点

の２種類

固定小数点 特徴 浮動小数点数に比べて表現できる値の範囲ははるかに狭い 情報落ちが起こらない 高速に演算できる コーデックなどで使われるらしい 丸め誤差や打ち切り誤差は免れない

特徴

浮動小数点数に比べて表現できる値の範囲ははるかに狭い

情報落ちが起こらない

高速に演算できる

コーデックなどで使われるらしい

丸め誤差や打ち切り誤差は免れない

浮動小数点 特徴 広範囲の値を表せることができる 整数形式ほど値を正確に表せない

特徴

広範囲の値を表せることができる

整数形式ほど値を正確に表せない

浮動少数点の形式 単精度浮動小数点形式 java だと float 型 倍精度浮動小数点形式 java だと double 型

単精度浮動小数点形式

java だと float 型

倍精度浮動小数点形式

java だと double 型

単精度浮動小数点形式 形式 指数部はイクセス 127 形式を使用 2^0 は この形式だと 127 になる 0 以下を表現するため 暗黙的に仮数部の２４ビット目は 1 がはいり 1.xxxx となる つまり 仮数部では 1.0 以上 2.0 未満しか表現できない yo

形式

指数部はイクセス 127 形式を使用

2^0 は この形式だと 127 になる

0 以下を表現するため

暗黙的に仮数部の２４ビット目は 1 がはいり 1.xxxx となる

つまり 仮数部では 1.0 以上 2.0 未満しか表現できない yo

有限精度演算の影響 計算順序が誤差に影響を与える可能性がある 例） 1.23e3 , 1.00e0 を考える １回の計算だけだと 1.23e3 + 0.001e3 = 1.23e3 になる １０回の計算だと？ 1.23e3 に 0.001e3 を 10 回足す －＞ 1.23e3 変わらない！！！ じゃ 計算順序を入れ替えると？ 1.00e0 同士を 10 回加算して , その結果を 1.23e3 と足すと？ 1.24e3 ！！！

計算順序が誤差に影響を与える可能性がある

例） 1.23e3 , 1.00e0 を考える

１回の計算だけだと 1.23e3 + 0.001e3 = 1.23e3 になる

１０回の計算だと？

1.23e3 に 0.001e3 を 10 回足す －＞ 1.23e3

変わらない！！！

じゃ 計算順序を入れ替えると？

1.00e0 同士を 10 回加算して , その結果を 1.23e3 と足すと？

1.24e3 ！！！

オーバーフロー、アンダーフローが発生する可能性がある 非常に大きい数値同士、小さい数値同士を乗算、除算すると起きる可能性がある。 最大値を超えた場合はオーバーフロー 絶対値の最小より小さい場合はアンダーフロー 情報落ちがおきる可能性がある 非常に小さな値と非常に大きな値との加算を行う

オーバーフロー、アンダーフローが発生する可能性がある

非常に大きい数値同士、小さい数値同士を乗算、除算すると起きる可能性がある。

最大値を超えた場合はオーバーフロー

絶対値の最小より小さい場合はアンダーフロー

情報落ちがおきる可能性がある

非常に小さな値と非常に大きな値との加算を行う

項目３２ 他の型が適切な場合には、文字列を避ける 文字列は他の値型に対する代替としては貧弱 データが本質的に本当に文字である場合だけ、文字列を使え！ データが数値なら int,float などの適切な値に変換すべし。 Yes/no なら boolean 型 列挙型に対する代替としては貧弱 集合型に対する代替としては貧弱 ってかこんなことするやついるのか？ ケイパビリティーに対する代替としては貧弱 key などを文字列にすると競合が起きる可能性がある yo そんなときは一意なキーを生成するメソッドを提供したほうがよい yo

文字列は他の値型に対する代替としては貧弱

データが本質的に本当に文字である場合だけ、文字列を使え！

データが数値なら int,float などの適切な値に変換すべし。

Yes/no なら boolean 型

列挙型に対する代替としては貧弱

集合型に対する代替としては貧弱

ってかこんなことするやついるのか？

ケイパビリティーに対する代替としては貧弱

key などを文字列にすると競合が起きる可能性がある yo

そんなときは一意なキーを生成するメソッドを提供したほうがよい yo

項目３３ 文字列結合パフォーマンスに用心する 文字列を結合するときは String? StringBuffer? StringBuilder? どれを使う？ 実際実行してみると、、、、

文字列を結合するときは

String? StringBuffer? StringBuilder? どれを使う？

実際実行してみると、、、、

項目３４ インターフェースでオブジェクトを参照する インターフェースに対してプログラミングする！ 言わずもがな！！！

インターフェースに対してプログラミングする！

言わずもがな！！！

項目 35 リフレクションよりインターフェースを選ぶ リフレクションの代価 コンパイル時の型検査の恩恵をすべて失う リフレクションによるアクセスを行うコードは、ぎこちなく冗長 パフォーマンスが悪くなる どのくらい悪くなるの？ リフレクションの利点 プログラムみたほうがよい。 まとめ リフレクションはオブジェクトのインスタンス化のためだけに使用し、コンパイ ル時にわかっているインターフェースやスーパークラスを使用してオブジェク トにアクセスすべし！！！

リフレクションの代価

コンパイル時の型検査の恩恵をすべて失う

リフレクションによるアクセスを行うコードは、ぎこちなく冗長

パフォーマンスが悪くなる

どのくらい悪くなるの？

リフレクションの利点

プログラムみたほうがよい。

まとめ

リフレクションはオブジェクトのインスタンス化のためだけに使用し、コンパイ

ル時にわかっているインターフェースやスーパークラスを使用してオブジェク

トにアクセスすべし！！！

37 注意して最適化する はやすぎる最適化 諸悪の根源！！ 速いプログラムよりも良いプログラムを書く etc

はやすぎる最適化

諸悪の根源！！

速いプログラムよりも良いプログラムを書く

etc