## 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