问题描述
我发现h和k.h之间的q NULL值不同：
q)0x00 vs 0W
0x7fffffffffffffff
q)0x00 vs 0N
0x8000000000000000
q)0x00 vs 0Ni
0x80000000
q)0x00 vs 0Wi
0x7fffffff
q)0x00 vs 0Wh
0x7fff
q)0x00 vs 0Nh
0x8000
在q中，一切看起来都很熟悉，但是在k.h nh中，看起来很奇怪：
// nulls(n?) and infinities(w?)
#define nh ((I)0xFFFF8000)
#define wh ((I)0x7FFF)
#define ni ((I)0x80000000)
#define wi ((I)0x7FFFFFFF)
#define nj ((J)0x8000000000000000LL)
#define wj 0x7FFFFFFFFFFFFFFFLL
为什么(I)0xFFFF8000的值为nh？ -为什么他们不只是简单地输入(H)0x8000？
解决方法
我怀疑多余的位用于表示解释器或虚拟机中的空值，以将其与短值0x8000区分开。使用额外的位来存储非整数值可以充分利用16位来表示整数。这样避免了将0x8000位模式提升为32位值的麻烦，并使存储和处理短裤列表更加有效。
当您使用vs转换为二进制时，看起来它强制16位输出，从而掩盖了特殊位。但是，这不是特殊值的内部二进制表示形式，您可以使用0b作为第一个参数来看到它。例如：
q)0b vs 0W
0111111111111111111111111111111111111111111111111111111111111111b
我无权访问q提示符来尝试0Nh，但您可以尝试一下。
这都是推测性的，因为我对q实现没有任何专门知识，但是我已经构建了多个解释器和VM，这对我来说很有意义。