Bug #4169
closed$calc and other $math identifiers
0%
Description
Crashes from too big number: //echo -a $calc(2^96 -1)
Happens also in /var command: //var %a 2 ^ 96
Handles non-numeric terms differently.
//echo -a add $calc(1 + x) vs $calc( x + 1) / sub $calc(1 - x) vs $calc( x - 1)
Returns
add 1 vs 1 / sub 1 vs -1
instead of
add 1 vs 0 / sub 1 vs 0
The accuracy for integers does not extend through 2^53, probably due to offering 28 digits in fractions. Above 2^53 returns different 'wrong' answers. If the valid range is going to be different, would help to have the new range documented.
//echo -a $calc(2^49 -1 ) correct
//echo -a $calc(2^50 -1 ) wrong
$calc handles alphanumerics differently if number embedded among the letters
//echo -a $calc(123deadbeef) is 123
//echo -a $calc(123deadbeef1) is 0
($calc is often used as a shortcut to strip non-numbers from the end of a string, because $int() and similar don't do the same for if they think it's scientific notation.)
//echo -a $abs(123X) should be 123
//echo -a $int(123e4) $abs(123e4) $ceil(123e4) $floor(123e4) should all be 1230000
but $calc should not handle scientific notation differently than other non-numerics as the above identifiers should.
$xor $or $and $not negatives/decimals:
//echo -a $not(1) s/b 4294967294
//echo -a $not($calc(2^31-1)) s/b 2147483648
//echo -a $not(4.1) s/b 4294967291
//echo -a $xor(8,1.1) fraction should be ignored, instead causes term treated as if zero
//echo -a $and(7,7.1) ditto
//echo -a $or(8,1.1) ditto
//echo -a $or(8,-8) s/b 4294967288
//echo -a $xor(8,-1) s/b 4294967287
//echo -a $and(-8,-9) s/b 4294967280
//echo -a $ord(111) $ord(112)
In spite of extra decimal places, this fails all 100 instead of failing most:
//var %i 1 , %list | while (%i isnum 1-100) { var %list %list $round(%i $+ .05 ,1) | inc %i } | echo -a round: %list