レースクイーン情報

レースクイーンを各種ブログ(Blog)から一括検索します。

冒頭の台詞は単なる例示かもしれないけど、一度真剣に電気や水道などと情報やサービスの違いや共通点を考えてみるべきかなぁ、なんてそんなことを思ったりしている。

"電気や水道のように"って (ナレッジ！？情報共有 … 永遠の課題への挑戦)

"ユーティリティ・コンピューティング"のコンセプトというのは、私の知る限り、もっとも古いものは、 Multics プロジェクトですね。最近、オープンソース化されて話題になりましたけど。

Since it was designed to be a utility, such as electricity and telephone services, it had numerous features to provide high availability and security.

History of Multics (Multics)

ここでは、"電気や電話のように"とありますね。このサイトによると、コンセプトが提出されたのは、1969年のことだとか。Multics は、巨大なタイム・シェアリング・システムを構想していたわけですが。このプロジェクトのアンチ・テーゼとして開発されたのが、 Unix タイム・シェアリング・システムであるのも有名な話ですね。

この後、コンピューティングの歴史はむしろ分散化へと向かっていったわけでして、その極限が、"パーソナル・コンピュータ革命"、コンピュータの個人所有、というものでしょう。それを実現したのが、コンピュータの低価格化であったわけです。どうも、昨今の"ユーティリティ・コンピューティング"の話では、この点が過小に評価されすぎているきらいがありますね。

まあ、つまらない話ではありますが、結局、"設備"の所有形態として、集中か分散か、というのは、コストで決まるのではないでしょうかね。情報システムの所有コストが、発電設備のそれに匹敵するのであれば、より集中へと進むでしょうけど、現にそうではないわけでして。

発電設備が個人で所有できるほど低価格になったことは未だないのではないでしょうか。だからこそ、"分散型電源"というコンセプトが新しいのでしょう。

近年、技術革新や環境問題と相まって、電力を必要とする場所の近くに小型発電機を設置し発電する試みが行われています。この場合、発電機が電力を必要とする場所ごとに分散して設置されるので、ここで使われる発電機は「分散型電源」と呼ばれます。また、この分散型電源を用いてエネルギーを供給するシステムを、「分散型エネルギーシステム」と呼びます。

分散型エネルギーシステム 技術解説 (独立行政法人 新エネルギー・産業技術総合開発機構)

作者:ron

更新日:2008年11月20日 0時57分

このブログのホーム

確か、瀬戸大橋の総工費が1兆円くらいだったよな、と。

塩飽諸島の5つの島の間に架かる6つの橋梁と、それらを結ぶ高架橋により構成されており、橋梁部9,368 m、高架部を含めると13.1kmの延長を持つ。これは鉄道道路併用橋としては世界最長である。橋梁は吊り橋・斜張橋・トラス橋の3種類を併設。総事業費はおよそ1兆1338億円。

瀬戸大橋 Wikipedia

財団つくって、年利１％で運用すると、毎年 200 億円 使えますね。

２兆円はもっとも有効な使い方をして欲しい (５号館のつぶやき )

定額給付金の自主的返納？ (５号館のつぶやき)

日本の政治も末期的な感じですな。

作者:ron

更新日:2008年11月11日 22時32分

このブログのホーム

「goto文禁止令」の類の話かと。

中途半端に優秀なプログラマが「正しいプログラミングテクニック」だと妄信しがちな３つポイント

比較的簡単なので1番目の「変数のスコープ」だけ。

その変数はどのくらい「変数」なのか？

「変数」の最大のポイントは、「代入」にあると思います。

public class Test {

  public static void main(String[] args) {
    if (args.length > 0) {
      String x = args[0];
      new Foo().bar(x);
    }
  }

}

上のソースで変数 x （つまり args[0]） って、どのくらい代入操作されますかね？

マルチスレッドなのか？

はてなブックマーク コメント よりお題をいただきました。

import java.io.IOException;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

public class TestServlet
  extends javax.servlet.http.HttpServlet
  implements javax.servlet.Servlet {

  static final long serialVersionUID = 1L;
  static HttpServletRequest request_;

  public TestServlet() {
    super();
  }

  protected void doGet(
    HttpServletRequest request,
    HttpServletResponse response)
    throws ServletException, IOException {

    request_ = request;
    try {
      Thread.sleep(5000);
    } catch (InterruptedException e) {
    }
    response.getWriter().println(request_.getParameter("p0"));
  }
}

２つのブラウザから、以下のリクエストを連続して投げること（5秒以内）。

GET /ServletTest/TestServlet?p0=A
GET /ServletTest/TestServlet?p0=B

一時期、この手のバグが話題になっていましたね。

とはいえ、 Servlet のユーザから見ると、 HttpServletRequest が「定数」に見えるのも確かです。 Servlet コンテナから見ると、「変数」なわけですけどね。

これは Servlet の仕様でしょうね。もともと、「軽量さ」が Servlet の売りであったことを思えば、意図的なデザインでしょう。

そのコードはどの程度「再利用」されるか？

使い捨てにするコードなら、別に気にしなくて良いですよね。広汎に使われるとなると、「想定外」の使われ方をする可能性が増えますので、より「防衛的に」プログラミングする必要があるかと。

作者:ron

更新日:2008年10月29日 23時31分

このブログのホーム

基数変換誤差が問題となるのは、固定小数点だからなんですよね。浮動小数点演算では、計算値に対する精度が十分に大きければ、基数変換誤差を気にする必要はないわけでして。そう考えると、固定小数点と10進数演算は、常にセットで考えるものなのでしょう。2進固定小数点を見かけない理由でもあるわけですね。

さて、 Java の　固定小数点数 java.math.BigDecimal ではソースコードはこんな感じになります。

import java.math.*;

public class BigDecimalTest {

  public static void main(String[] args) {
    float fa = 0.4f;
    float fb = 0.3f;
    float fc = 0.1f;

    System.out.println(fa - fb - fc);

    final BigDecimal xa = new BigDecimal("0.4");
    final BigDecimal xb = new BigDecimal("0.3");
    final BigDecimal xc = new BigDecimal("0.1");
    final BigDecimal xd = xa.subtract(xb).subtract(xc);

    System.out.println(xd);
  }

}

実行結果：

-7.4505806E-9
0.0

確かに、うざったい感じですね。

精度、スケール、丸めの方向を java.math.MathContext 、および java.math.RoundingMode で細かく指定できるのは、良いと思いますけど。

忘れていましたが、 Microsoft .NET では、組み込み型で固定小数点がサポートされています。

ソースコードは以下のようになります。

using System;

namespace DecimalTest
{
    class Program
    {
        static void Main(string[] args)
        {
          float fa = 0.4f;
          float fb = 0.3f;
          float fc = 0.1f;

          Console.WriteLine(fa - fb - fc);

          decimal xa = 0.4m;
          decimal xb = 0.3m;
          decimal xc = 0.1m;

          Console.WriteLine(xa - xb - xc);

        }
    }
}

実行結果:

-7.450581E-09
0.0

精度は 128 ビットで固定されているようです。スケールを明示的に指定する方法はなさそうですね。丸めの方向も指定できなさそう。

組み込み型なのは良いのですが。 Java と良い点・悪い点が、ちょうど反対になっているのが面白いといいますか。

しかし、この .NET Framework　マニュアルの説明はわけわからないですね。どこかでも話題になっていましたが。

Decimal 値型は、多数の有効な整数桁と小数桁を必要とし、丸め誤差を使用しない財務計算に適しています。

10 進数は、符号、値の各桁の範囲が 0 から 9 までの数値、数値の整数部と小数部を分ける浮動小数点の位置を示すスケール ファクタで構成される浮動小数点値です。

Decimal 構造体 (System)

「整数部と小数部を分ける　．．． スケール ファクタ」があるわけですから、固定小数点と呼ぶべきなのではないでしょうか。浮動小数点とは呼ばないのではないかと思うのですけど。

A decimal number is a floating-point value that consists of a sign, a numeric value where each digit in the value ranges from 0 to 9, and a scaling factor that indicates the position of a floating decimal point that separates the integral and fractional parts of the numeric value.

Decimal Structure (System)

小数点の桁位置を変えられることを、 ”floating-point value”, "floating decimal point" と言っているのですかね。かえって判りにくいような。

作者:ron

更新日:2008年10月19日 7時9分

このブログのホーム

以下の記事を読んでの感想。

「COBOLは現役バリバリだ。"COBOLは化石"などと口にするのはITとエンタープライズシステムが何たるかをわかっていない証拠」

「30年システムに携わっているが，COBOLは規格として長期間安定し，ビジネスロジックの書きやすさにおいては右に出る言語はない」

「COBOLは現役バリバリ」，東京海上日動がシステム全面再構築でCOBOLを選んだワケ (ITPro)

COBOL を使う最大の理由といえば、10進固定小数点演算が言語組み込みでサポートされている点がまず思い浮かびました。

事務処理用及び管理分野用とされるCOBOLにおいては会計・経理処理などのように通貨を対象とした正確な数値計算が特に要求されるため、数値に対する10進数から2進数への基数変換時に計算誤差の発生しない2進化10進数による数値型（固定小数点数）を用いることができる。

COBOL (Wikipedia)

会計計算では、計算規則は、人間が手で計算することを前提に作られているはずですから、10進固定小数点で計算しなければ、計算結果は「正しく」ならないでしょうね。保険関係の計算を行なうのに COBOL を使うのは、合理的な選択に思えます。プログラミング言語の組み込み型に、10進固定小数点がなければ、プログラムを書くのは、かなりつらくなるでしょう。

他方、浮動小数点演算はどうかといえば、未だ FORTRAN がデファクト・スタンダードであったりします。

十数年前、C言語 が普及し始めた当時、C言語の浮動小数点演算機能について、確か以下のようなことが言われていたと思います。

1. 式を評価する際、浮動小数点数が double にキャストされる仕様がふざけている
2. 標準ライブラリの数学関数の引数がすべて double になっているのがふざけている
3. 複素数型がないのは馬鹿にしている

C言語 は、 FORTRAN より退化している、という評価がもっぱらであったかと思います。

以下の数を扱える。

• 整数（範囲は機種依存、4バイトであればその範囲）
• 単精度実数（整数部+小数部、指数表示可能、精度は機種依存）
• 倍精度実数（単精度の倍の精度を持つ）
• 複素数（単精度または倍精度の実数の組み合わせ。2つの数字を()でくくる）

  ．．．．．．

  組込み関数

  組込み関数は、同じ機能でも引数の型と関数の型によって名前が異なる。関数名の先頭がI〜Nのものが整数型、Dが倍精度実数型、Cが複素数型、それ以外が実数型である。

  FORTRAN (Wikipedia)

なお、 C言語 浮動小数点で批判が多かった、 「式がすべて double になる」は、その後改善されています。

ここで注意すべきは、式の中の float が自動的に double に変換されるのではないことである。これは C のもとの定義に比べて代わった点の一つになっている。しかし一般に <math.h> にあるような数学関数では倍精度が使われよう。 float を使う主な理由は、大きな配列の記憶容量を減らすことであり、またそうあることではないが、倍精度の算術がとくに高くつくような計算機で計算時間を短くする点にある。

B.W.カーニハン/D.M.リッチー著, 石田晴久訳, 『プログラミング言語C 第2版』, 共立出版, 1989, p.55

単精度を使う理由が効率の問題でしかない、というのは少し乱暴な話ですね。

Java言語では、このC言語の仕様を、ほぼそのまま受け継いでいます。

Conversions and Promotions (Java Language Specification Third Edition)

Math (Java 2 Platform SE 5.0)

で、やっぱり批判されていると。

Java's floating-point arithmetic is blighted by five gratuitous mistakes:

1. Linguistically legislated exact reproducibility is at best mere wishful thinking.
2. Of two traditional policies for mixed precision evaluation, Java chose the worse.
3. Infinities and NaNs unleashed without the protection of floating-point traps and flags mandated by IEEE Standards 754/854 belie Java's claim to robustness.
4. Every programmer's prospects for success are diminished by Java's refusal to grant access to capabilities built into over 95% of today's floating-point hardware.
5. Java has rejected even mildly disciplined infix operator overloading, without which extensions to arithmetic with everyday mathematical types like complex numbers, intervals, matrices, geometrical objects and arbitrarily high precision become extremely inconvenient.

   W. Kahan and Joseph D. Darcy, "How Java's Floating-Point Hurts Everyone Everywhere"¹

C言語のときからすると、要求のハードルは大分高くなっているようにも思えますけど。5番目は、10進固定小数点演算 java.math.BigDecimal についても当てはまりますね。

FORTRAN と COBOL というのは、コンピュータが「計算機」であった時代に生まれたプログラミング言語であるわけでして、数値計算に関しては、未だこれに代わる言語というのは存在していないように思いますね。C言語がプログラミング言語のメインストリームになってからは、数値計算というのはプログラミング言語の進化から忘れられた存在なのかもしれません。

1. http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf

作者:ron

更新日:2008年10月17日 2時47分

このブログのホーム

冒頭の台詞は単なる例示かもしれないけど、一度真剣に電気や水道などと情報やサービスの違いや共通点を考えてみるべきかなぁ、なんてそんなことを思ったりしている。

"電気や水道のように"って (ナレッジ！？情報共有 … 永遠の課題への挑戦)

"ユーティリティ・コンピューティング"のコンセプトというのは、私の知る限り、もっとも古いものは、 Multics プロジェクトですね。最近、オープンソース化されて話題になりましたけど。

Since it was designed to be a utility, such as electricity and telephone services, it had numerous features to provide high availability and security.

History of Multics (Multics)

ここでは、"電気や電話のように"とありますね。このサイトによると、コンセプトが提出されたのは、1969年のことだとか。Multics は、巨大なタイム・シェアリング・システムを構想していたわけですが。このプロジェクトのアンチ・テーゼとして開発されたのが、 Unix タイム・シェアリング・システムであるのも有名な話ですね。

この後、コンピューティングの歴史はむしろ分散化へと向かっていったわけでして、その極限が、"パーソナル・コンピュータ革命"、コンピュータの個人所有、というものでしょう。それを実現したのが、コンピュータの低価格化であったわけです。どうも、昨今の"ユーティリティ・コンピューティング"の話では、この点が過小に評価されすぎているきらいがありますね。

まあ、つまらない話ではありますが、結局、"設備"の所有形態として、集中か分散か、というのは、コストで決まるのではないでしょうかね。情報システムの所有コストが、発電設備のそれに匹敵するのであれば、より集中へと進むでしょうけど、現にそうではないわけでして。

発電設備が個人で所有できるほど低価格になったことは未だないのではないでしょうか。だからこそ、"分散型電源"というコンセプトが新しいのでしょう。

近年、技術革新や環境問題と相まって、電力を必要とする場所の近くに小型発電機を設置し発電する試みが行われています。この場合、発電機が電力を必要とする場所ごとに分散して設置されるので、ここで使われる発電機は「分散型電源」と呼ばれます。また、この分散型電源を用いてエネルギーを供給するシステムを、「分散型エネルギーシステム」と呼びます。

分散型エネルギーシステム 技術解説 (独立行政法人 新エネルギー・産業技術総合開発機構)

作者:ron

更新日:2008年11月20日 0時57分

このブログのホーム

確か、瀬戸大橋の総工費が1兆円くらいだったよな、と。

塩飽諸島の5つの島の間に架かる6つの橋梁と、それらを結ぶ高架橋により構成されており、橋梁部9,368 m、高架部を含めると13.1kmの延長を持つ。これは鉄道道路併用橋としては世界最長である。橋梁は吊り橋・斜張橋・トラス橋の3種類を併設。総事業費はおよそ1兆1338億円。

瀬戸大橋 Wikipedia

財団つくって、年利１％で運用すると、毎年 200 億円 使えますね。

２兆円はもっとも有効な使い方をして欲しい (５号館のつぶやき )

定額給付金の自主的返納？ (５号館のつぶやき)

日本の政治も末期的な感じですな。

作者:ron

更新日:2008年11月11日 22時32分

このブログのホーム

「goto文禁止令」の類の話かと。

中途半端に優秀なプログラマが「正しいプログラミングテクニック」だと妄信しがちな３つポイント

比較的簡単なので1番目の「変数のスコープ」だけ。

その変数はどのくらい「変数」なのか？

「変数」の最大のポイントは、「代入」にあると思います。

public class Test {

  public static void main(String[] args) {
    if (args.length > 0) {
      String x = args[0];
      new Foo().bar(x);
    }
  }

}

上のソースで変数 x （つまり args[0]） って、どのくらい代入操作されますかね？

マルチスレッドなのか？

はてなブックマーク コメント よりお題をいただきました。

import java.io.IOException;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

public class TestServlet
  extends javax.servlet.http.HttpServlet
  implements javax.servlet.Servlet {

  static final long serialVersionUID = 1L;
  static HttpServletRequest request_;

  public TestServlet() {
    super();
  }

  protected void doGet(
    HttpServletRequest request,
    HttpServletResponse response)
    throws ServletException, IOException {

    request_ = request;
    try {
      Thread.sleep(5000);
    } catch (InterruptedException e) {
    }
    response.getWriter().println(request_.getParameter("p0"));
  }
}

２つのブラウザから、以下のリクエストを連続して投げること（5秒以内）。

GET /ServletTest/TestServlet?p0=A
GET /ServletTest/TestServlet?p0=B

一時期、この手のバグが話題になっていましたね。

とはいえ、 Servlet のユーザから見ると、 HttpServletRequest が「定数」に見えるのも確かです。 Servlet コンテナから見ると、「変数」なわけですけどね。

これは Servlet の仕様でしょうね。もともと、「軽量さ」が Servlet の売りであったことを思えば、意図的なデザインでしょう。

そのコードはどの程度「再利用」されるか？

使い捨てにするコードなら、別に気にしなくて良いですよね。広汎に使われるとなると、「想定外」の使われ方をする可能性が増えますので、より「防衛的に」プログラミングする必要があるかと。

作者:ron

更新日:2008年10月29日 23時31分

このブログのホーム

基数変換誤差が問題となるのは、固定小数点だからなんですよね。浮動小数点演算では、計算値に対する精度が十分に大きければ、基数変換誤差を気にする必要はないわけでして。そう考えると、固定小数点と10進数演算は、常にセットで考えるものなのでしょう。2進固定小数点を見かけない理由でもあるわけですね。

さて、 Java の　固定小数点数 java.math.BigDecimal ではソースコードはこんな感じになります。

import java.math.*;

public class BigDecimalTest {

  public static void main(String[] args) {
    float fa = 0.4f;
    float fb = 0.3f;
    float fc = 0.1f;

    System.out.println(fa - fb - fc);

    final BigDecimal xa = new BigDecimal("0.4");
    final BigDecimal xb = new BigDecimal("0.3");
    final BigDecimal xc = new BigDecimal("0.1");
    final BigDecimal xd = xa.subtract(xb).subtract(xc);

    System.out.println(xd);
  }

}

実行結果：

-7.4505806E-9
0.0

確かに、うざったい感じですね。

精度、スケール、丸めの方向を java.math.MathContext 、および java.math.RoundingMode で細かく指定できるのは、良いと思いますけど。

忘れていましたが、 Microsoft .NET では、組み込み型で固定小数点がサポートされています。

ソースコードは以下のようになります。

using System;

namespace DecimalTest
{
    class Program
    {
        static void Main(string[] args)
        {
          float fa = 0.4f;
          float fb = 0.3f;
          float fc = 0.1f;

          Console.WriteLine(fa - fb - fc);

          decimal xa = 0.4m;
          decimal xb = 0.3m;
          decimal xc = 0.1m;

          Console.WriteLine(xa - xb - xc);

        }
    }
}

実行結果:

-7.450581E-09
0.0

精度は 128 ビットで固定されているようです。スケールを明示的に指定する方法はなさそうですね。丸めの方向も指定できなさそう。

組み込み型なのは良いのですが。 Java と良い点・悪い点が、ちょうど反対になっているのが面白いといいますか。

しかし、この .NET Framework　マニュアルの説明はわけわからないですね。どこかでも話題になっていましたが。

Decimal 値型は、多数の有効な整数桁と小数桁を必要とし、丸め誤差を使用しない財務計算に適しています。

10 進数は、符号、値の各桁の範囲が 0 から 9 までの数値、数値の整数部と小数部を分ける浮動小数点の位置を示すスケール ファクタで構成される浮動小数点値です。

Decimal 構造体 (System)

「整数部と小数部を分ける　．．． スケール ファクタ」があるわけですから、固定小数点と呼ぶべきなのではないでしょうか。浮動小数点とは呼ばないのではないかと思うのですけど。

A decimal number is a floating-point value that consists of a sign, a numeric value where each digit in the value ranges from 0 to 9, and a scaling factor that indicates the position of a floating decimal point that separates the integral and fractional parts of the numeric value.

Decimal Structure (System)

小数点の桁位置を変えられることを、 ”floating-point value”, "floating decimal point" と言っているのですかね。かえって判りにくいような。

作者:ron

更新日:2008年10月19日 7時9分

このブログのホーム

以下の記事を読んでの感想。

「COBOLは現役バリバリだ。"COBOLは化石"などと口にするのはITとエンタープライズシステムが何たるかをわかっていない証拠」

「30年システムに携わっているが，COBOLは規格として長期間安定し，ビジネスロジックの書きやすさにおいては右に出る言語はない」

「COBOLは現役バリバリ」，東京海上日動がシステム全面再構築でCOBOLを選んだワケ (ITPro)

COBOL を使う最大の理由といえば、10進固定小数点演算が言語組み込みでサポートされている点がまず思い浮かびました。

事務処理用及び管理分野用とされるCOBOLにおいては会計・経理処理などのように通貨を対象とした正確な数値計算が特に要求されるため、数値に対する10進数から2進数への基数変換時に計算誤差の発生しない2進化10進数による数値型（固定小数点数）を用いることができる。

COBOL (Wikipedia)

会計計算では、計算規則は、人間が手で計算することを前提に作られているはずですから、10進固定小数点で計算しなければ、計算結果は「正しく」ならないでしょうね。保険関係の計算を行なうのに COBOL を使うのは、合理的な選択に思えます。プログラミング言語の組み込み型に、10進固定小数点がなければ、プログラムを書くのは、かなりつらくなるでしょう。

他方、浮動小数点演算はどうかといえば、未だ FORTRAN がデファクト・スタンダードであったりします。

十数年前、C言語 が普及し始めた当時、C言語の浮動小数点演算機能について、確か以下のようなことが言われていたと思います。

1. 式を評価する際、浮動小数点数が double にキャストされる仕様がふざけている
2. 標準ライブラリの数学関数の引数がすべて double になっているのがふざけている
3. 複素数型がないのは馬鹿にしている

C言語 は、 FORTRAN より退化している、という評価がもっぱらであったかと思います。

以下の数を扱える。

• 整数（範囲は機種依存、4バイトであればその範囲）
• 単精度実数（整数部+小数部、指数表示可能、精度は機種依存）
• 倍精度実数（単精度の倍の精度を持つ）
• 複素数（単精度または倍精度の実数の組み合わせ。2つの数字を()でくくる）

  ．．．．．．

  組込み関数

  組込み関数は、同じ機能でも引数の型と関数の型によって名前が異なる。関数名の先頭がI〜Nのものが整数型、Dが倍精度実数型、Cが複素数型、それ以外が実数型である。

  FORTRAN (Wikipedia)

なお、 C言語 浮動小数点で批判が多かった、 「式がすべて double になる」は、その後改善されています。

ここで注意すべきは、式の中の float が自動的に double に変換されるのではないことである。これは C のもとの定義に比べて代わった点の一つになっている。しかし一般に <math.h> にあるような数学関数では倍精度が使われよう。 float を使う主な理由は、大きな配列の記憶容量を減らすことであり、またそうあることではないが、倍精度の算術がとくに高くつくような計算機で計算時間を短くする点にある。

B.W.カーニハン/D.M.リッチー著, 石田晴久訳, 『プログラミング言語C 第2版』, 共立出版, 1989, p.55

単精度を使う理由が効率の問題でしかない、というのは少し乱暴な話ですね。

Java言語では、このC言語の仕様を、ほぼそのまま受け継いでいます。

Conversions and Promotions (Java Language Specification Third Edition)

Math (Java 2 Platform SE 5.0)

で、やっぱり批判されていると。

Java's floating-point arithmetic is blighted by five gratuitous mistakes:

1. Linguistically legislated exact reproducibility is at best mere wishful thinking.
2. Of two traditional policies for mixed precision evaluation, Java chose the worse.
3. Infinities and NaNs unleashed without the protection of floating-point traps and flags mandated by IEEE Standards 754/854 belie Java's claim to robustness.
4. Every programmer's prospects for success are diminished by Java's refusal to grant access to capabilities built into over 95% of today's floating-point hardware.
5. Java has rejected even mildly disciplined infix operator overloading, without which extensions to arithmetic with everyday mathematical types like complex numbers, intervals, matrices, geometrical objects and arbitrarily high precision become extremely inconvenient.

   W. Kahan and Joseph D. Darcy, "How Java's Floating-Point Hurts Everyone Everywhere"¹

C言語のときからすると、要求のハードルは大分高くなっているようにも思えますけど。5番目は、10進固定小数点演算 java.math.BigDecimal についても当てはまりますね。

FORTRAN と COBOL というのは、コンピュータが「計算機」であった時代に生まれたプログラミング言語であるわけでして、数値計算に関しては、未だこれに代わる言語というのは存在していないように思いますね。C言語がプログラミング言語のメインストリームになってからは、数値計算というのはプログラミング言語の進化から忘れられた存在なのかもしれません。

1. http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf

作者:ron

更新日:2008年10月17日 2時47分

このブログのホーム