Интересная ошибка в APL2 на мэйнфрейме IBM относительно ⊥

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 к любому из условий в левом аргументе, мы говорим интерпретатору, чтобы он перешел в режим float. Без него он сначала пытается обработать операцию целыми числами, отмечает, что он не работает, а затем повторяет попытку в режиме float.

Тот же трюк может использоваться по правильному аргументу или путем добавления 0.0 или путем умножения на 1.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: это, конечно, хорошо, чтобы делиться знаниями, отвечая на свой вопрос - но для этого вы также должны опубликовать ответ как «Ответ», а не как часть вопроса. Таким образом, вы сможете принять свой собственный ответ (после ожидания дня или около того), который затем закроет вопрос.

Answer 2

я представляю следующее происходит: (догадка одного человека)

0 100 100 100 100 100 1000 представляет собой 16-битное целое вектор в Dyalog, вероятно, 32 в APL2

⊥ обычно возвращают шире левых или правых типов аргументов

⎕TS также является целым числом вектор, 16 или 32-битное целое

ответ 2.017011212181701E16, прибл. 20170112122036000 явно 64-битное (или большее) число с плавающей запятой.

APL2 делает ставку на то, что эта операция декодирования будет успешной с использованием целочисленной арифметики. Сначала он пытается вычислить декодирование с использованием целочисленной арифметики, но затем операция выходит из строя из-за арифметического переполнения. Затем APL2 снова пытается использовать с плавающей запятой. Увеличение времени включает в себя захват переполнения, очистки и повторное выполнение.

Изменение левого аргумента на 0 100 100 100 100 100 1000.0 заставляет декодировать использовать 64-битную арифметику с плавающей точкой без первой попытки целочисленной арифметики.

Dyalog, возможно, не беспокоится об этом и выполняет декодирование в плавающей запятой.

Интересно, что на Dyalog, ⎕DR 0 100 100 100 100 100 1000 ⊥ 1 645, 64 бит с плавающей точкой

+/+ и \ и другие могут иметь аналогичные проблемы с переливом.

⎕DR +/21/100000000 323, 32-битное целое

⎕DR +/22/100000000 645, 64 бит с плавающей точкой

Было бы полезно попробовать эти примеры с использованием GNU APL, которые использует 64-битные целые числа.