Yes, I agree there are defaults for many identifiers where the default for a not-used parameter makes since, like $sha1() assuming the string is text when the 2nd parm isn't given. But with a uniform return string across these bitwise identifiers, that's making the default setting different. Like $xor and $or defaulting to zero for the missing parm, and $and defaulting to -1 for it.
If you come across an identifier that you think should be using a different default value, let me know. However, if the behaviour has been in place for a long time, it normally cannot be changed since that would affect backward compatibility.
The 1 thing that can be used for this is - there are some scripts that need to strip text from the end of a number, and they use $abs or $int or $calc to do it. However $abs and $int evaluate $int(1d2stuff) as 100 in scifi notations, while $calc does not. However $calc doesn't strip off the fraction. However $xor(1d2stuff) $xor(1.2345stuff) is stripping off the fraction as well as not interpreting text as scifi notation.
This sounds like a different issue to your original post. The way numbers are parsed in commands, identifiers, and other features varies depending on the context and on the API or CRT function call being used. Some of these, for historical reasons, do parse scientific notation, others do not. Some of them will allow floating point values, others will not. And so on. If you think an identifier or feature should behave differently, suggest it. That said, unless there is a really good reason, I will rarely change the way a scripting feature has behaved for decades, as that would break backward compatibility.
