当前位置：文江博客话题详情

raku

2＆＃x27的Raku操作员补充算术？

发布于 2025-02-13 04:36:18 字数 249 浏览 0 评论 0 原文

我有时会使用它：

$ perl -e "printf \"%d\", ((~18446744073709551592)+1)"
24

我似乎无法与Raku一起做。我能得到的最好的是：

$ raku -e "say +^18446744073709551592"
-18446744073709551593

所以：我该如何让raku给我和perl相同的答案？

原文

I sometimes use this:

$ perl -e "printf \"%d\", ((~18446744073709551592)+1)"
24

I can't seem to do it with Raku. The best I could get is:

$ raku -e "say +^18446744073709551592"
-18446744073709551593

So: how can I make Raku give me the same answer as Perl ?

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

葬心 2025-02-20 04:36:18

必须与Liz的自定义OP（在下面的评论中）一起去。

sub prefix:<²^>(uint $a) { (+^ $a) + 1 }

say ²^ 18446744073709551592; # 24

野生猜测”² @zentrunix可以接受，也是Liz's Op的基础：

say (+^ my uint $ = 18446744073709551592) + 1; # 24

/它起作用！

\ o

我原来的“半教育的 +^表格，将其子数字作为“两个补充”，然后避免看起来像^2 。

²一条思维是关于特定整数的。我看到 184444444073709551592 接近 2 ** 64 。另一个是，除非您采取其他行动使它们做某事，否则整数在Perl中的精度有限，而在Raku中，除非您做某事以使它们有其他方式，否则它们是任意的精度。第三条思维来自阅读 prefix +^ 说“使用所需的任意多字符将数字转换为二进制”这意味着表示形式很重要。唔。如果我尝试 int 变量怎么办？溢出。（当然。） uint ？宾果游戏。

³我不知道此解决方案是否是正确的，原因是出于错误的原因。甚至更糟。关于Raku中的 uint 的一件事定义为对应于用于编译Raku代码的RAKU编译器支持的最大的本机无符号整数大小。（iirc。）实际上，这意味着Rakudo和任何基础平台的目标，我认为几乎在几乎所有情况下，这几乎可以肯定意味着C的 uint64_t 。我想 perl 具有一些相似的平台依赖性定义。因此，如果我的解决方案（如果是合理的解决方案），则可能仅适用于Raku编译器（实际上在今天意味着Rakudo）与 perl 二进制（实际上在今天，今天意味着P5P的 perl ）在某个平台上运行时。另请参阅下面的 @P6Steve的评论。

Gotta go with (my variant¹ of) Liz's custom op (in her comment below).

sub prefix:<²^>(uint $a) { (+^ $a) + 1 }

say ²^ 18446744073709551592; # 24

My original "semi-educated wild guess"² that turned out to be acceptable to @zentrunix and the basis for Liz's op:

say (+^ my uint $ = 18446744073709551592) + 1; # 24

\o/ It works!³

Footnotes

¹ I flipped the two character op because I wanted to follow the +^ form, have it sub-vocalize as "two's complement", and avoid it looking like ^2.

² One line of thinking was about the particular integer. I saw that 18446744073709551592 is close to 2**64. Another was that integers are limited precision in Perl unless you do something to make them otherwise, whereas in Raku they are arbitrary precision unless you do something to make them otherwise. A third line of thinking came from reading the doc for prefix +^ which says "converts the number to binary using as many bytes as needed" which I interpreted as meaning that the representation is somehow important. Hmm. What if I try an int variable? Overflow. (Of course.) uint? Bingo.

³ I've no idea if this solution is right for the wrong reasons. Or even worse. One thing that's concerning is that uint in Raku is defined to correspond to the largest native unsigned integer size supported by the Raku compiler used to compile the Raku code. (Iirc.) In practice today this means Rakudo and whatever underlying platform is being targeted, and I think that almost certainly means C's uint64_t in almost all cases. I imagine perl has some similar platform dependent definition. So my solution, if it is a reasonable one, is presumably only portable to the degree that the Raku compiler (which in practice today means Rakudo) agrees with the perl binary (which in practice today means P5P's perl) when run on some platform. See also @p6steve's comment below.

回复收藏 0 原文

兲鉂ぱ嘚淚 2025-02-20 04:36:18

'长途'答案：

raku -e 'put ( (18446744073709551592.base(2) - 0b1).comb.map({!$_.Int+0}).join.parse-base(2));'

或

raku -e 'say 18446744073709551592.base(2).comb.map({!$_.Int+0}).join.parse-base(2) + 1;'

示例输出： 24

上面的答案（应该？）实现了直接编码的“两个组合”。两者都不使用Raku的+^二式操作员。第一个从二进制表示中减去一个，然后反转。第二个首先反转，然后添加一个。这两个答案都没有真正正确的答案，但是获得了与perl5相同的答案（ 24 ）。

查看Raku文档页面，可以得出结论，正面数字的“二组合”是负数的，因此尚不清楚Perl（现在是Raku）的答案所代表的。希望上述内容有些有用。

https：//docs.raku.org/routine/++qircirmflex_accent_accent_accent

'Long-hand' answer:

raku -e 'put ( (18446744073709551592.base(2) - 0b1).comb.map({!$_.Int+0}).join.parse-base(2));'

raku -e 'say 18446744073709551592.base(2).comb.map({!$_.Int+0}).join.parse-base(2) + 1;'

Sample Output: 24

The answers above (should?) implement "Two's-Complement" encoding directly. Neither uses Raku's +^ twos-complement operator. The first one subtracts one from the binary representation, then inverts. The second one inverts first, then adds one. Neither answer feels truly correct, yet the same answer as Perl5 is obtained (24).

Looking at the Raku Docs page, one would conclude that the "twos-complement" of a positive number would be negative, hence it's not clear what the Perl (and now Raku) answers represent. Hopefully the foregoing is somewhat useful.

https://docs.raku.org/routine/+$CIRCUMFLEX_ACCENT

回复收藏 0 原文

~没有更多了~