Re: [vim/vim] Decrementing 2**64 gives wrong result (Issue #12103)
[not sure if this got through, ignore if you already have seen it] Marvin Renich wrote: > * Bram Moolenaar [230304 15:47]: > > > > > ### Steps to reproduce > > > > > > Create a buffer with the number `18446744073709551616`. > > > Press `Ctrl-x` with the cursor on the number. > > > Number is changed to `18446744073709551614`. > > > > > > ### Expected behaviour > > > > > > Number is changed to `18446744073709551615` > > > > The problem is that 2 ** 64 does not fit in the variable being used. > > Getting the number from the text results in the maximum number that can > > be represented, which is 18446744073709551615. Then one is subtracted. > > > > I think the best we can do is keep a flag for the "overflow" and then > > not subtract one. That makes this corner case work, although it won't > > be fixed in the general case. Still better than doing nothing. > > I don't think this is the right fix. I think you should either document > that 64-bit arithmetic is being used, and load the original number as 0 > (the correct modulo-64 representation) and decrement gives -1 and > increment gives 1, or decide to use arbitrary-precision arithmetic and > give the correct answer for numbers larger than 2^64. > > Either of these two approaches give consistent results for numbers > larger than 2^64-1, whereas the fix you suggest only makes one > 'out-of-bounds' value work. I would prefer the current behavior to > applying the fix you are suggesting. > > I would be willing to write the arbitrary-precision code so that no > external library need be used, but I might not get to it right away. Interpreting a large number as zero is a terrible solution. I don't see how this can ever do what the user wants. Using arbitrary precision can work, but it would require a lot of changes in the code. Currently CTRL-A and CTRL-X use functions common to other commands, it would have to be split and quite a bit of code needs to be duplicated. Including handling of hex and octal numbers. I doubt this is used often enough to justify the work. -- A computer without Windows is like a fish without a bicycle. /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ /// \\\ \\\sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ /// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/20230307155658.8B0781C0354%40moolenaar.net.
Re: [vim/vim] Decrementing 2**64 gives wrong result (Issue #12103)
* Bram Moolenaar [230306 15:15]: > Marvin Renich wrote: > > After your change (I'm going by your description; I haven't built a new > > vim to test it), it seems you treat too-large numbers as one more than > > the largest representable number (2^64) for decrement but as 2^64-1 for > > increment, and similarly for too-small numbers. > > Not exactly. The number is rounded off to the nearest representable > number, but the addition or subtraction is not done. Ah, okay. This is an easily documentable and consistent behavior. I'm happy with it. > I would think that "2 ** 64" appears much more often than "2 ** 64 + 1". Perhaps, or perhaps someone was just testing edge conditions. > For the old behavior a bug was reported, which is an indication it is > not what users expect to happen. The rest of the discussion is > speculating what would be the least-worst solution. In cases like this > would rather go with an actual complaint than speculation. That's a perfectly reasonable approach. Thanks for listening to my arguments for a different solution and helping me understand the reasoning behind your solution. ...Marvin -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/ZAZQi%2BoZtgA6c5QD%40basil.wdw.
Re: [vim/vim] Decrementing 2**64 gives wrong result (Issue #12103)
* vim-dev ML [230305 16:16]: > Marvin Renich wrote: > > * Bram Moolenaar ***@***.***> [230304 15:47]: > > > > > > > ### Steps to reproduce > > > > > > > > Create a buffer with the number `18446744073709551616`. > > > > Press `Ctrl-x` with the cursor on the number. > > > > Number is changed to `18446744073709551614`. > > > > > > > > ### Expected behaviour > > > > > > > > Number is changed to `18446744073709551615` > > > > > > The problem is that 2 ** 64 does not fit in the variable being used. > > > Getting the number from the text results in the maximum number that can > > > be represented, which is 18446744073709551615. Then one is subtracted. > > > > > > I think the best we can do is keep a flag for the "overflow" and then > > > not subtract one. That makes this corner case work, although it won't > > > be fixed in the general case. Still better than doing nothing. > > > > I don't think this is the right fix. I think you should either document > > that 64-bit arithmetic is being used, and load the original number as 0 > > (the correct modulo-64 representation) and decrement gives -1 and > > increment gives 1, or decide to use arbitrary-precision arithmetic and > > give the correct answer for numbers larger than 2^64. > > > > Either of these two approaches give consistent results for numbers > > larger than 2^64-1, whereas the fix you suggest only makes one > > 'out-of-bounds' value work. I would prefer the current behavior to > > applying the fix you are suggesting. > > > > I would be willing to write the arbitrary-precision code so that no > > external library need be used, but I might not get to it right away. > > Interpreting a large number as zero is a terrible solution. I don't see > how this can ever do what the user wants. I don't see how decrementing 18446744073709551618 and getting 18446744073709551615 could be what the user wants, either. Incrementing 18446744073709551615 and getting -18446744073709551615 is also unexpected (for pure math) but correct (for 64-bit arithmetic). I'll agree that hooking up arbitrary precision may not be worth the effort. I think the best compromise is to have a consistent and documented behavior for numbers not representable by 64-bit signed ints. The behavior before you made this change appears to be to treat all positive, too-large numbers as the largest representable number (for both increment and decrement) and all negative, too-small numbers as the smallest representable number for both increment and decrement. After your change (I'm going by your description; I haven't built a new vim to test it), it seems you treat too-large numbers as one more than the largest representable number (2^64) for decrement but as 2^64-1 for increment, and similarly for too-small numbers. This moves the seemingly anomalous behavior by one (18446744073709551616 gives the correct result for decrement, but 18446744073709551617 gives a result that is off by one), at the expense of requiring more verbiage to explain, and treating increment and decrement of out-of-range values differently. I think the previous behavior is more consistent and easier to explain and justify. Either way has values which give very close, but wrong (for pure math) results. If arbitrary precision is not worth the effort, I would stick with the previous behavior and document it. ...Marvin -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/ZAXduGEMQG/Tn5WN%40basil.wdw.
Re: [vim/vim] Decrementing 2**64 gives wrong result (Issue #12103)
* Bram Moolenaar [230304 15:47]: > > > ### Steps to reproduce > > > > Create a buffer with the number `18446744073709551616`. > > Press `Ctrl-x` with the cursor on the number. > > Number is changed to `18446744073709551614`. > > > > ### Expected behaviour > > > > Number is changed to `18446744073709551615` > > The problem is that 2 ** 64 does not fit in the variable being used. > Getting the number from the text results in the maximum number that can > be represented, which is 18446744073709551615. Then one is subtracted. > > I think the best we can do is keep a flag for the "overflow" and then > not subtract one. That makes this corner case work, although it won't > be fixed in the general case. Still better than doing nothing. I don't think this is the right fix. I think you should either document that 64-bit arithmetic is being used, and load the original number as 0 (the correct modulo-64 representation) and decrement gives -1 and increment gives 1, or decide to use arbitrary-precision arithmetic and give the correct answer for numbers larger than 2^64. Either of these two approaches give consistent results for numbers larger than 2^64-1, whereas the fix you suggest only makes one 'out-of-bounds' value work. I would prefer the current behavior to applying the fix you are suggesting. I would be willing to write the arbitrary-precision code so that no external library need be used, but I might not get to it right away. ...Marvin -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/ZATMw7uo9w/xcfcs%40basil.wdw.
