• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Effective Java 第7章
 

Effective Java 第7章

on

  • 2,525 views

 

Statistics

Views

Total Views
2,525
Views on SlideShare
2,521
Embed Views
4

Actions

Likes
0
Downloads
5
Comments
0

1 Embed 4

http://www.slideshare.net 4

Accessibility

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Effective Java 第7章 Effective Java 第7章 Presentation Transcript

    • Effective java 第7章
    • 項目 31  正確な答えが必要ならば ,float と double は避ける
      • 浮動小数点は近似計算にすぎない
        • 実数が取り得る値が無限にあるのに大して、浮動小数点で使用できるビットの数は有限であるため
      • そもそも小数の表現の仕方には
        • 固定小数点
        • 浮動小数点
        •  の2種類
    • 固定小数点
      • 特徴
        • 浮動小数点数に比べて表現できる値の範囲ははるかに狭い
        • 情報落ちが起こらない
        • 高速に演算できる
        • コーデックなどで使われるらしい
        • 丸め誤差や打ち切り誤差は免れない
    • 浮動小数点
      • 特徴
        • 広範囲の値を表せることができる
        • 整数形式ほど値を正確に表せない
    • 浮動少数点の形式
      • 単精度浮動小数点形式 
        • java だと float 型
      • 倍精度浮動小数点形式
        •   java だと double 型
    • 単精度浮動小数点形式
      • 形式
      • 指数部はイクセス 127 形式を使用
        • 2^0 は この形式だと  127 になる
        • 0 以下を表現するため
      • 暗黙的に仮数部の24ビット目は 1 がはいり 1.xxxx となる
        • つまり 仮数部では 1.0 以上 2.0 未満しか表現できない yo
    • 有限精度演算の影響
      • 計算順序が誤差に影響を与える可能性がある
        • 例)  1.23e3 , 1.00e0 を考える
          • 1回の計算だけだと  1.23e3 + 0.001e3 = 1.23e3 になる
          • 10回の計算だと?
            • 1.23e3  に  0.001e3 を 10 回足す ->  1.23e3
              • 変わらない!!!
          • じゃ 計算順序を入れ替えると?
            • 1.00e0 同士を 10 回加算して , その結果を 1.23e3 と足すと?
              • 1.24e3  !!!
      • オーバーフロー、アンダーフローが発生する可能性がある
        • 非常に大きい数値同士、小さい数値同士を乗算、除算すると起きる可能性がある。
          • 最大値を超えた場合はオーバーフロー
          • 絶対値の最小より小さい場合はアンダーフロー
      • 情報落ちがおきる可能性がある
        • 非常に小さな値と非常に大きな値との加算を行う
    • 項目32 他の型が適切な場合には、文字列を避ける
      • 文字列は他の値型に対する代替としては貧弱
        • データが本質的に本当に文字である場合だけ、文字列を使え!
        • データが数値なら int,float などの適切な値に変換すべし。
        • Yes/no なら  boolean 型
      • 列挙型に対する代替としては貧弱
      • 集合型に対する代替としては貧弱
        • ってかこんなことするやついるのか?
      • ケイパビリティーに対する代替としては貧弱
        • key などを文字列にすると競合が起きる可能性がある yo
        • そんなときは一意なキーを生成するメソッドを提供したほうがよい yo
    • 項目33 文字列結合パフォーマンスに用心する
      • 文字列を結合するときは
        • String? StringBuffer? StringBuilder? どれを使う?
        • 実際実行してみると、、、、
    • 項目34 インターフェースでオブジェクトを参照する
      • インターフェースに対してプログラミングする!
      • 言わずもがな!!!
    • 項目 35  リフレクションよりインターフェースを選ぶ
      • リフレクションの代価
        • コンパイル時の型検査の恩恵をすべて失う
        • リフレクションによるアクセスを行うコードは、ぎこちなく冗長
        • パフォーマンスが悪くなる
            • どのくらい悪くなるの?
      • リフレクションの利点
        • プログラムみたほうがよい。
      • まとめ
      • リフレクションはオブジェクトのインスタンス化のためだけに使用し、コンパイ
      • ル時にわかっているインターフェースやスーパークラスを使用してオブジェク
      • トにアクセスすべし!!!
    • 37  注意して最適化する
      • はやすぎる最適化
        • 諸悪の根源!!
      • 速いプログラムよりも良いプログラムを書く
      • etc