* vim-dev ML <[email protected]> [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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/ZAXduGEMQG/Tn5WN%40basil.wdw.
