Forums Developers $calc $base extensions

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.