IBMメインフレーム上のAPL2の面白いバグ

Question

この環境では、消費されたサービスユニットの数の効率を測定します。 私はバグを説明するためにミリ秒に現在のDateTimeに変換されます：

0 100 100 100 100 100 1000⊥⎕TS  ⍝ this statement consumes around 150 SUs 
0 100 100 100 100 100 1000.0⊥⎕TS  ⍝ this statement consumes around 5 SUs 

ここで何が起こっていますか？さて、左引数の中のいずれかに.0を付けることによって、私たちは通訳者にフロートモードに入るように指示します。それがなければ、最初に整数で操作を処理しようとしますが、動作していないことに気づき、フロートモードで再試行します。

右の引数で、または0.0を追加することによって、またはを掛けることによって、同じトリックを使用できます。

Answer 1

は、好奇心のうち、私はDyalog APL V15で同じことを試してみました：

 ]runtime '0 100 100 100 100 100 1000.0⊥⎕TS' '0 100 100 100 100 100 1000⊥⎕TS' -compare -repeat=500000 

    0 100 100 100 100 100 1000.0⊥⎕TS → 4.6E¯7 | 0% ⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕ 
    0 100 100 100 100 100 1000⊥⎕TS → 4.3E¯7 | -7% ⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕  

がほとんど何の違い...

PS：それはあなた自身の質問に答えることで知識を共有することは確かokです - それを行うには、回答を質問の一部ではなく「回答」として投稿する必要があります。そうすることで、自分の答えを受け入れることができます（、1日待ってから）。これで質問が終了します。私は、次の想像

Answer 2

が起こっている：（一人の男の推測）

0 100 100 100 100 100 1000はおそらく32 APL2

で、

Dyalogで16ビットの整数ベクトルである⊥通常は広いが返されます左または右の引数の型

⎕TSも整数ベクトルである、16または32ビット整数

の答えは、約、2.017011212181701E16あります。 20170112122036000は明らかに64ビット（またはそれ以上）の浮動小数点数です。

APL2は、このデコード操作が整数演算を使用して成功すると賭けています。最初に整数演算を使用してデコードを計算しようとしますが、算術オーバーフローのために演算が失敗します。その後、APL2は浮動小数点を使用して再試行します。タイミングの増加には、オーバーフロー、クリーンアップをトラップし、再度実行することが含まれます。

左の引数を0 100 100 100 100 100 1000.0に変更すると、整数演算を最初に試みることなく、64ビットの浮動小数点演算が使用されます。

おそらくダラログはこれを気にせず、浮動小数点のデコードを行います。

興味深いことに、Dyalogに、⎕DR0 100 100 100 100 100から1000⊥1は、645である64ビット浮動小数点

+/+および\等がオーバーフローと同様の問題を有していてもよいです。 ⎕DR+/100000000分の21

323は、32ビットの整数である

⎕DR+/100000000分の22は645、GNU APLを使用してこれらの例を試すことが有益であろう

64ビット浮動小数点数であります64ビットの整数を使用します。