Question

在这种环境下，我们衡量消费服务单位数的效率。我将当前的dateTime转换为毫秒来说明错误：

.0

这里发生了什么？好吧，通过将0.0附加到左参数中的任何术语，我们就告诉解释器进入浮点模式。没有它，它首先尝试用整数处理操作，注意它不起作用然后在浮点模式下重试。

可以在正确的参数上使用相同的技巧，或者添加1.0，或者乘以{{1}}。

Answer 1

出于好奇，我在Dyalog APL v15中尝试了同样的事情：

private List<Color> GetAllColors() {
        var list = new List<Color>();
        var colorType = typeof(Color);
        var propInfos = colorType.GetProperties(BindingFlags.Static | BindingFlags.DeclaredOnly | BindingFlags.Public);
        foreach (var propInfo in propInfos) {
            var color = Color.FromName(propInfo.Name);
            list.Add(color);
        }
        return list;
    }

那里几乎没有任何区别......

P.S：通过回答您自己的问题来分享知识肯定是可以的 - 但要做到这一点，您还应该将答案发布为＆＃34;答案＆＃34;而不是问题的一部分。通过这样做，您将能够接受自己的答案（等待一天左右），然后关闭问题。

Answer 2

我想以下情况正在发生:(一个人的猜测）

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上，⎕DR0100 100 100 100 100 1000⊥1是645,64位浮点

+ /和+ \和其他人可能有类似的溢出问题。

⎕DR+ / 21/100000000是323,32位整数

⎕DR+ / 22/100000000是645,64位浮点数

使用64位整数的GNU APL尝试这些示例是有益的。

关于⊥，IBM大型机上的APL2中有趣的错误

2 个答案: