cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Choose Language Hide Translation Bar

interrogate Use Thousands Separator using JSL

What inspired this wish list request? 

It's not simple to ask a column whether the checkbox in the column info for Use Thousands Separator is checked.  You can set it as part of << set format.  You can currently find out how it's set via << get format but only if it's different from the overall Preference under Tables, Use Thousands Separator. If it matches the preference it's just not mentioned by << get format.  That had me baffled for a quite a while thinking there was just no way to get it.  So you have to check both things and you need to extract it out of the Format() expression returned by <<get format.  Not impossible but fiddly and potentially confusing when you don't see it returned at all. 

 

Are there reasons to care?  It impacts the character strings you get a list of when you use Summarize and group by a numeric column that is using thousands separators. I ran into this as a bug in some old code that wasn't expecting the possibility that data that was 1000 as a numeric value might show up in the Summarize results as "1000" for one user but for a different user as "1,000".  It is just more robust to deal with the numbers and not make assumptions about the string form so I'm not actually using interrogating the column to fix that but the whole experience makes me think it would be worth having a simple way to learn this setting. 

 

Another possibility could be wishing to turn this setting off for some particular scripting then turn it back on again and for that you do want to know what the original setting was.

 

What is the improvement you would like to see? 

A message for a column "<< Get Use Thousands Separator".   My request would be to return a simple 1/0 answer to how the checkbox is set for a given column, that is the thing that matches how the data is actually formatted. 

 

Why is this idea important? 

This is a small thing and not impossible to do today but could be worth a look.  I may make myself a function for this but JMP support suggested I make a wish list item after we boggled over why it was not coming back from <<get format() for a while.    This could be a lot more straightforward and similar to how the other checkbox in column info (lock) can be interrogated. 

 

 

4 Comments
hogi
Level XII

sounds closely related to Changed Settings in the Preferences -> fix the issue :
JSL code generated via get script, get format etc. depends on the settings in the preferences:
everything defined in the preferences is assumed to be "standard"  - and depending on the current settings in the preferences, another "standard" is "standard" - and another command will show up in the generated script - or won't show up in the script.

 

The idea: if this code is executed on the same system again, it will generate the same result.

On the other hand: when the code is generated on another system (with different settings in the preferences) - it can lead to significantly different behavior.

 

I don't know how to solve this.
A solution: always generate code with all current settings, don't remove the stuff which overlaps with the preferences.

But this will lead to extremely long code.

 

 

hogi
Level XII

For the issue with the Thousands separator, Heidi's suggestion will work :

a special message:

<< get thousands separator()

 

... instead of checking the thousands setting from 

<< get format() 

aka

<< get all format settings which differ from the settings in the preferences()

 

but what to do with the thousands of similar issues?

 

hardner
Level V

@hogi, yes that is exactly what my wish is for, a separate command to just get the current setting, something that returns 1/0 based on what the current state is without all the complication of whether it's different from the preferences.  I can see that there may well be various other settings in this same boat where separate commands could be added to interrogate the state separate from using <<get format to get "code that will reproduce it as things are right now".  Based on your comments another possibility could be a "verbose" option for <<getformat that would include "everything" it's capable of including?

hogi
Level XII

That's a wonderful idea
I added a comment to the other wish
https://community.jmp.com/t5/JMP-Wish-List/Changed-Settings-in-the-Preferences-fix-the-issue/idc-p/7... 

and suggested a verbose option for << get script as well