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
Updated by Per Amundsen about 6 years ago
- Category set to Scripting
- Status changed from New to Assigned
- Assignee set to Per Amundsen
Paul Janson wrote:
Crashes from too big number: //echo -a $calc(2^96 -1)
Happens also in /var command: //var %a 2 ^ 96
I fixed the crashes, the numbers seems to be too big for the .NET Math.Pow.
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
AdiIRC does indeed not extract only the numbers, I will look into that soon.
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
2^50 resolves to $calc(1125899906842620M -1), I don't know how to deal with that.
$calc handles alphanumerics differently if number embedded among the letters
//echo -a $calc(123deadbeef) is 123
//echo -a $calc(123deadbeef1) is 0
AdiIRC does indeed not extract only the numbers, I will look into that soon.
($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
I fixed this.
//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.
Scientific notations is not supported in any identifier atm.
$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)
I fixed all this.
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
I don't know how to fix this using the standard .NET Math.Round function.
Here is a beta build with the fixes https://adiirc.com/build/1540783833/AdiIRC.exe.
Updated by Paul Janson about 6 years ago
Scientific notations is not supported in any identifier atm.
I was trying to describe how 'combatible' behavior would be, which scripts running on both clients should beware of. The scientific notation here is a side-effect of whatever strings library was used, but is useless because $calc() doesn't recognize it, so it's probably fine to not code support for it elsewhere.
Updated by Per Amundsen about 6 years ago
Paul Janson wrote:
Scientific notations is not supported in any identifier atm.
I was trying to describe how 'combatible' behavior would be, which scripts running on both clients should beware of. The scientific notation here is a side-effect of whatever strings library was used, but is useless because $calc() doesn't recognize it, so it's probably fine to not code support for it elsewhere.
I will add it eventually, the goal is maximum compatibility.
Updated by Per Amundsen about 6 years ago
- Status changed from Assigned to Resolved
Updated by Per Amundsen about 6 years ago
- Status changed from Resolved to Closed