Seeming error in isNumber()

[dont_want_to_be_here]

Maptool:
b90
Macro:
[h:f="1f"]
[h:d="3d"]
[h:s="5s"]
[h:die="3d2"]
[h:n="1234"]
[r,if(isNumber(f)):f+f]<br>
[r,if(isNumber(d)):d+d]<br>
[r,if(isNumber(s)):s+s]<br>
[r,if(isNumber(die)):die+die]<br>
[r,if(isNumber(n)):n+n]<br>
Output:
1f1f
3d3d


2468
User:
o_0

[wolph42]

isNumber also checks true for hexadecimal numbers:
0,1,2,3,4,5,6,7,8,9,a,b,c,d,e,f

1f (hex) == 31 (dec) and that is a number.

try
[isNumber("1g")]
it will return 0 (false).

[dont_want_to_be_here]

Well, yes, I thought of that, and should have presented a more thorough test, I offer sincere apologies. But it really doesn't work that way.
Firstly, the macro doesn't treat them as hexidecimal. It clearly adds them as strings.
Secondly, a single letter doesn't work. "d" returns false.
Thirdly, it is inconsistent, "1b" returns false.
Finally, "3d2" returns false, even though it is a perfectly valid hexidecimal. It doesn't seem to work with anything over 2 digits. And doesn't seem to work with most hexidecimal letters.

But really, it is all on the first point. If isNumber() can't be used to reliably determine if a variable will be treated as a string instead of a number, what is the point?

[aliasmask]

Here's a trick that may help. If you only want numbers with only digits in it.

Code: Select all

[H: value = "1d"]
[H: isNumber = 0]
[H, if(isNumber(value)), code: {
   [H: valCheck = replace(value,"^[0-9]","")]
   [H, if(value == valCheck): isNumber = 1]
};{}]
 

[dont_want_to_be_here]

Thankyou for that. It is a rare case that a player would accidentally type a single digit from 0 to 9 followed by either "d" or "f" and nothing further, but it is genuinely very nice to have an alternative.

But I feel that my point still stands. It is easy enough to test the functionality of isNumber():
[previous=0]
[h,while(1):abort(input("previous|"+previous+"|"+isNumber(previous)))]

isNumber() clearly is not compatible with hexadecimal notation except in 20 specific instances. And the default mathematics engine clearly is not compatible with hexadecimal notation. And Maptools generally seems to be associated with converting non-computerised activities into computerised ones, which implies that many of the subjects were developed in an environment where binary notation was irrelevant(notably, hexadecimal notation is incompatible with dice notation). So I really must insist that by all appearances this function is not behaving in an appropriate fashion.

So... is this a bug, or am I missing something?

[wolph42]

Yeah it's probly a bug.