JSL Feature or Bug?

[#1]

I have a function that relies on knowing whether a substring of a larger string represents a number or not, and I simply use the result of the Num() command -- if it returns a missing value I assume the substring does not represent a number.

However, a user pointed out a bug that had as the root-cause the fact that the Num() command is perfectly happy with any number preceded by the literal "R".

Is anyone aware of this as a feature or bug?  I tried looking in the scripting index but cannot think of a well-posed query for this.

Thanks!

Print( Num( "R404" ) );
Print( Num( "R123.456" ) );
Print( Num( "r99" ) );

/*
404
123.456
.
*/

[#2]

Currency, maybe. Lots of odd cases to watch out for...

num("$5")
5

num("1jan2000")

3029529600

num("5%")

0.05

asdate(num("1/1"))

01Jan2001

[#3]

I realize that there are many cases to look out for -- but specifically I only need to care about standard characters and "R" is the only example here.  In any other programming language this would be well documented or considered a bug (any behavior that is not explicitly listed in the documentation is a bug), but JMP is not at that level of documentation, so it's probably just a hidden feature.

[#4]

Currency does seem likely but I can't really tell if this is a feature, if it is it certainly needs better documentation in several different places.   If you already have an idea of what the number should look like though you might be better off writing your own validation function for that data, I find that prevents things like '1/1' from being interpreted as January 1st. Of course this gets harder if you are dealing with multiple languages..

num_validated = function({v}, {r=.},
	
	if( //Make sure anything with odd characters is missing
		is missing(regex(v,"^[0-9\.\,]+$")),
		r = .,
		
		//try to interpret everything else using 'num':
		r = num( v );
	);
	r;
);

show(
	num_validated("1"),
	num_validated("1.0"),
	num_validated("R1"),
	num_validated("1,000")
);

[#5]

I sent a note to JMP's doc and development teams. Thanks!

[#6]

Greetings all. It looks like some work has been done for this issue in the JMP 17 timeframe. Specifically, an additional argument has been added to Num() and Informat() to help you control what is considered a valid number. Any JMP 17 EA7 (or later) users can try this out now; others will need to wait until JMP 17 is available in Fall of 2022. Thanks for reporting this! We do monitor these forums and look to fix things like this when possible. 

[#7]

@Audrey_Shull 
I was having an issue with a column imported as character. 
I could not see anything not numerical by eye.
But when making it a numeric, most values disappeared. (with JMP 16.2 Pro)

But using JMP 17EA I could straight away transform from character to numeric without values disappearing.
So there was some progress there.

Hope that helps!

Ben