Project

General

Profile

Actions

Bug #4169

closed

$calc and other $math identifiers

Added by Paul Janson about 6 years ago. Updated about 6 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Scripting
Target version:
Start date:
10/28/2018
Due date:
% Done:

0%

Estimated time:
Operative System:
All
Regression:
No

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

Actions #1

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.

Actions #2

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.

Actions #3

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.

Actions #4

Updated by Per Amundsen about 6 years ago

  • Status changed from Assigned to Resolved
Actions #5

Updated by Per Amundsen about 6 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF