IBM大型機上APL2中有趣的bug⊥

在這種環境中，我們測量消耗服務單元數量的效率。我會轉換當前日期時間以毫秒來說明錯誤：IBM大型機上APL2中有趣的bug⊥

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或乘以1.0。

來源

2016-12-14 mappo

https://stackoverflow.blog/2011/07/its-ok-to-ask-and-answer-your-own-questions/ – mappo

我猜編譯器沒有特別優化 - 除非這是一個來自IBM的狡猾的賺錢訣竅...... :-) –

@mappo我認爲答案部分（「好吧，通過附加.0 ...」）應該放入適合QA格式的答案中。 –

出於好奇我嘗試同樣在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：那肯定是好的回答你自己的問題，分享知識 - 但要做到這一點，您還應該將答案發布爲「答案」，而不是問題的一部分。通過這樣做，您將能夠接受您自己的答案（，等待一天左右後），然後將結束該問題。

來源

2016-12-15 08:31:36 MBaas

我已經在IBM APL2 for Windows中完成了相同的基準測試，並且在那裏基本沒有差異。感謝PS - 如果只有管理員是有幫助的... – mappo

我想象以下是發生：（一人的猜測）

0 100 100 100 100 100 1000處於Dyalog一個16位的整數向量，在APL2

大概32

⊥通常會返回更寬左側或右側的參數類型的

⎕TS也是整數向量，16位或32位整數

答案是2.017011212181701E16，約。 20170112122036000顯然是一個64位（或更大）的浮點數。

APL2打賭，這個解碼操作將使用整數算術成功。它首先嚐試使用整數算術計算解碼，但由於算術溢出，操作失敗。 APL2然後再次嘗試使用浮點。時間的增加包括捕獲溢出，清理和再次執行。

將左參數更改爲0 100 100 100 100 100 1000.0導致解碼使用64位浮點算術，而不首先嚐試整數算術。

Dyalog可能不會打擾這一點，並進行浮點解碼。

有趣的是，上Dyalog，⎕DR0 100 100 100 100 100 1000⊥1是645，64位浮點

+/+和\和其他可具有與溢出類似的問題。

⎕DR+ /100000000分之21是323，32位整數

⎕DR+ /100000000分之22是645，64位浮點

這將是有啓發性使用GNU APL嘗試這些實例使用64位整數。

來源

2017-01-12 11:46:50 Lobachevsky

IBM大型機上APL2中有趣的bug⊥

回答

相關問題