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

improvements for Transform Column

☐ cool new feature
☐ could help many users!

☑ feels like a bug

☐ nice to have

☐ nobody needs it

 

What inspired this wish list request? 

In Jmp, there are 2 approaches to generate Transform Columns.

  1. 1) by talking to a data table:
    hogi_0-1696493389196.png
    - the transform column is generated with Table Scope - so, the Transform Column "lives" outside the context of the platform it is generated for.
    - there is a Replace option: either a pre-existing Transform Column is replaced (setting: 1) or the name of the new Transform Column is adjusted (setting: 0)
    hogi_1-1696493480422.png
    - The Transform Column is easily accessible, e.g. by using the
    return value of the command = handle for the generated transform column

  2. 2) by talking to a report
    hogi_2-1696494294072.png
    2b)  via
    platform << Transform Column()
    - this Transform column is generated in the scope of the platform - and will we deleted once the platform is closed
    -> very useful
    This is why this is the default approach how Transform Columns are used in Graph Builder, Summary and all the other platforms.

    - unfortunately, there is no replace option.
    If there is a Transform Column with the same name, the command is ignored (!) and the exiting Transform Column is used instead.

    -  unfortunately, Transform Columns which are generated by a platform are very hard to access:
    how to reference a Transform Column? 
    e.g. how to remove a Transform Column?

What is the improvement you would like to see? 

Although it works like designed, it definitely feels like a bug.

It's hard for a user to understand that there are several tasks doable via the GUI which are not accessible via JSL.

 

Please improve the functionality of Transform Columns which are generated in the context of a Platform:

  1. return a handle for the column - - analogous to the one of the first kind of Transform columns
  2. add a replace option - analogous to the one of the first kind of Transform columns

 

Why is this idea important? 

GraphBuilder has cool features to aggregate data via Summary Statistics - but important functions are missing, like CDF .

Transform Columns provide a possibility to close such gaps - but the limited functionality of Transform Columns in the context of a platform make it difficult.

 

Example:
If a user changes the selection in a Local Data Filter - how to update a Transform Column to account for the changes?

 

 

 

 

more wishes submitted by  hogi_2-1702196401638.png

4 Comments
hogi
Level XII

Jmp Support confirmed: TS-00056243

you cannot reference a transform column created in the platform context.  This means you cannot remove it nor replace it.  If you want to have a reference to a transform column, you must create the column in the data table context. 

 

This refers to a user who uses JSL.

His colleague who uses the Jmp graphical interface can do all these things - he can even rename the Transform Column.

What a disadvantage for "JSL" users.

hogi
Level XII

related wish for new formula columns:
Make New Formula Column return references to the newly created columns 

@mia_stephens , is it possible to fix the issue with transform columns & platform context

- such that a reference to the generated column is returned?


mia_stephens
Staff
Status changed to: Acknowledged

Hi @hogi, thank you for this detailed post. I believe I understand your requests. Our development team has some major initiatives in the current cycle, so this will be added to the queue for consideration.

 

Note that the virtual transform option in launch dialogs is intended to be more for exploratory purposes within a particular analysis context, so functionality is a bit more limited. Transforms via the formula editor are more fully featured. 

hogi
Level XII

understood.

fallback solution at the moment is indeed: generating transform column with table context.
the drawback: they "pollute" my table - and show up in all the other reports.

yes, compared to other wishes: definitely much lower prio  ; )