mIRC Home    About    Download    Register    News    Help

Print Thread
$calc $base extensions #269925 16/02/22 11:34 PM
Joined: Jan 2004
Posts: 1,745
maroon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Jan 2004
Posts: 1,745
There may be some unintended consequences from enabling scifi notation for $calc and $base without there either being a switch or .prop to enable it. It might be appropriate for the exponential notation to be recognized only when an optional .prop is used.

Some scripts have used $calc(%string) as a quick way to strip trailing non-a-number from the end of a string. They don't use $abs(123xyz) or $int(123abc) because $int(123d21) $int(123e21) were not returning '123', but $calc did. But now, $calc would be mimic'ing the $int/$abs behavior of outputting '123000000000000000000000' except for not supporting 'd' along with 'e'. Yes I know it's possible to do it with $regsubex, but $regex functions would be slower in this usage, and lots of scripters are intimidated by regex stuff.

I've never had to intentionally look for and handle this kind of numeric notation string, and most of the time this notation is accompanied by the unstated caveat "warning this number is wildly inaccurate due to loss of precision", but I'm assuming something similar to the next would be how scripts are handling the e2 notation under the existing syntax.

//var %a $regsubex(123e2,e(\d+),*(10^\t)) | echo -a $calc(%a +1)

Something which might be unexpected for some scripts is how the scifi notation alters existing $base behavior. Currently, the base36 alphabet assigns the 0-35 values to 0-9a-z in all bases 2-36, with the exception that 0x is ignored for inbase=16. Now this inserts an exception when the inbase=10 string contains 'e' followed by a number, and it continues to do that when the portion preceding that contains characters not normally used in base10. For example, $base(fe2,10,10) changes from 1642 to 1500 and $base(fe0,10,10) becomes '15', because e<number> now changes to be $str(0,number), at least for integers.

Not that I'm wanting it, but I'm not sure how useful the handling of e2 notation is when $calc and $base don't output such strings.

Last edited by Khaled; 18/02/22 09:51 AM.
Re: $calc $base extensions [Re: maroon] #269926 17/02/22 12:53 AM
Joined: Dec 2002
Posts: 5,104
Khaled Offline
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,104
Thanks for your comments regarding e/E notation. I am going to revert these changes in the next beta as it does look like these may cause backward-compatibility issues.