I recently ran into this issue with a very large customer. In earlier versions of JMP, they were using Contains to ID error codes from a numeric column in a fashion like this This is no longer available in JMP 17. Two questions: 1. Have you run into this issue? 2. How can this selection process be replicated with no more than the same number of clicks and as efficiently (the table may have 100M rows).

Here are some ideas. I've scripted these here but they can be done easily interactively. // Setup nrows = 1e6; dt = New Table( "Error Codes", <<Add Rows( nrows ), <<New Column( "Code", Numeric, Continuous, <<Format( "Fixed Dec", 12, 3 ), <<Set Values( J(1, nrows, Random Category(0.5, 1, -1) * Random Integer( 1e5, 1e6 ) / 1e3 ) ) ) ); // Keep Numeric: Data Filter switched to Nominal dt << Data Filter( Add Filter( columns( :Code ), Modeling Type( :Code, Nominal ), Display( :Code, N Items( 15 ), Find( Set Text( "999." ) ) ) ) ); // Change to Character: Unstructured Text and Row Selection :Code << Set Data Type( Character ) << Set Modeling Type( "Unstructured Text" ); dt << Row Selection( Select where( Contains( :Code, "999." ) ), Match case( 1 ), Dialog( Edit( Contains( Source Column( :Code ) ) ), Keep dialog open( 1 ) ) ); // Other: Split Main.Sub into two Numeric columns :Main and :Sub then use Row Selection or Data Filter on these

Thanks @SamGardner , this has already been shared with PM and development.

@DonMcCormack if you havent't yet, please share this with the product managers, let us know the customer, and you can reference this thread.

nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Contains no longer an option when selecting values from a numeric row

DonMcCormack

I recently ran into this issue with a very large customer. In earlier versions of JMP, they were using Contains to ID error codes from a numeric column in a fashion like this

Screenshot 2024-02-27 at 8.56.48 AM.png

This is no longer available in JMP 17. Two questions:

1. Have you run into this issue?

2. How can this selection process be replicated with no more than the same number of clicks and as efficiently (the table may have 100M rows).

Accepted answers

All comments

Jed_Campbell

Explore Outliers has a Nines tab, but that's a lot more clicks. What about mapping the script below to a keyboard shortcut? That could be even fewer clicks.

Try(
	col = (Current Data Table() << get selected columns())[1];
	Current Data Table() << Select Where( Contains( Char( col ), "9999" ) );
);

Chris_Kirchberg

@DonMcCormack , are they always 9999? If so, what about setting the column property missing value codes then using data filer under rows with the red triangle option for filter to select missing? Row selection in 17 for is missing does not seem to work. Assuming they want to avoid a script

Chris_Kirchberg

local data filter, distribution and other platforms will recognize it. But if their goal is to find the missing values and the missing value codes, then maybe column property and global data filter. A couple of extra clicks than before. 18 it is still an issue.

Explore missing respects missing value codes.

brady_brady

Does "equals" in the same dropdown no longer work? Same number of clicks, of course.

DonMcCormack

From what I've been told, they are looking for a specific string of numeric values. I suspect that the string starts with these values, but I didn't confirm that this was true. There may be more than one value (e.g., 9999 and -9999), I don't know how many more.

DonMcCormack

Equals will not work

DonMcCormack

This may have to be deployed to hundreds (thousands?) of users, some of whom are not scripters.

EvanMcCorkle

Why will Equals not work? It is not obvious from the original post why.

brady_brady

Well, can they change the col to character, use "contains", and then change it back to numeric when they're done?

It is a couple more clicks, but that really won't be the issue, because changing back and forth takes about the same time as actually doing the search on a tall table... the selection takes about 5 seconds to run on only about 10M rows, whether you're searching for "equals 999" on numeric data, or for "contains 999" over character data. So for 100M rows, I'd expect almost a minute... at which point the extra 2.5 seconds on each end to change data types is rendered trivial.

Aside from the fact that it is rarely a good idea to take existing functionality away from the user... am I missing something here?

EvanMcCorkle

I realize we aren't looking for a scripting solution but I wanted to mention that the new Where function will be at least as fast and usually faster than Select Where or Get Rows Where in JMP 18. This should be especially relevant for these very large tables.

Current Data Table() << Select Rows(Where(Contains(Char(:Column 1), "9999")))

DonMcCormack

The error codes contain more than just 9999 to differentiate the different types of errors. 9999.123, 9999.345, 9999.299, etc. All are types of 9999 errors.

DonMcCormack

We've given a large customer a tool that has been communicated with a large number of users and likely baked into a large number of scripts. The said customer has a history of being reluctant to moving to newer versions of JMP. Now we've taken the tool away and asked them to move to a new version of JMP. The obvious question is "What else is hiding?". It's not just taking away functionality it's communicating loudly and clearly when changes like this will happen, regardless of how minor those changes might seem.