Hi All,
I want to clone a column in the data table (make a new identical column in all but it’s name). Is there a more sleek (and robust) way of doing this or do I need to extract the values and all properties and assign them to the new column as such:
dt3 = Open( "$SAMPLE_DATA/Cars.jmp" );
// add a column property
dt3:Make << Set Property(
"Value Colors",
{"Acura" = -13977687, "Audi" = -3780931, "BMW" = -4222943, "Buick" = -
13596966, "Cadillac" = -2211217, "Chevrolet" = -10562780, "Chrysler" = -
13156647, "Daihatsu" = -2078390, "Dodge" = -13182413, "Eagle" = -9549600,
"Ford" = -2334147, "Geo" = -13772446, "Honda" = -9282864, "Hyundai" = -
6995852, "Infiniti" = -1524612, "Isuzu" = -9458080, "Jeep" = -14452073,
"Lexus" = -6391856, "Lincoln" = -2745505, "Mazda" = -10199751, "Mercedes" =
-7150697, "Mercury" = -10513726, "Mitsubishi" = -8381519, "Nissan" = -
3502441, "Oldsmobile" = -3615440, "Peugeot" = -13925307, "Plymouth" = -
11502354, "Pontiac" = -7449196, "Renault" = -9229791, "Saab" = -4074344,
"Saturn" = -13050224, "Subaru" = -12565885, "Suzuki" = -2068529, "Toyota" =
-4494272, "Volkswagen" = -11824110, "Volvo" = -8734293, "Yugo" = -13849421}
) << color cell by value;
// clone the column
clone_column = dt3:Make << Get script;
clone_column;
Here is a completed example of one way to prepend the data table pointer:
Eval(Parse("(dtxxx<<"||char(dt3:Make << Get script)||") << set name(\!"Clone\!");"));
thanks Dave@Pega-Analytics txnelson,
this is what i was looking for. i didn't expect duplicating a column to be so cumbersome.
the following is my final script:
Names Default To Here( 1 );
dt3 = Open( "$SAMPLE_DATA/Cars.jmp" , private);
// clone into the same table
Eval(Parse("(dt3<<"||char(dt3:Make << Get script)||") << set name(\!"Clone\!");"));
// proof that the column was cloned - check log
dt3:Clone << get script;
close (dt3, no save);
best,
ron
I'm really not sure what value there is in keeping column properties like value colors in a private table. If the data is all you care about (typically true for private tables), the simpler method below could be used.:
dt3 << New Column("Make Clone", Formula(dt3:Make))
That looks very sleek to me. Have you experienced any problems with robustness?
If you do not want to waste memory on a variable it can be simplified into a oneliner:
Eval(dt3:Make << Get script) << set name("Clone");
For cloning multiple columns , I would consider making a subset of these, rename the columns and update with the original data table.
Thanks MS,
i am surprised there is no jsl command for duplicating an existing column. in addition, if dt3 is not the active table it creates the new column in an other table.
You can make it more robust by editing the script variable prior to evaluation i.e. prepend "dt << " to the expression.
Here is a completed example of one way to prepend the data table pointer:
Eval(Parse("(dtxxx<<"||char(dt3:Make << Get script)||") << set name(\!"Clone\!");"));
thanks Dave@Pega-Analytics txnelson,
this is what i was looking for. i didn't expect duplicating a column to be so cumbersome.
the following is my final script:
Names Default To Here( 1 );
dt3 = Open( "$SAMPLE_DATA/Cars.jmp" , private);
// clone into the same table
Eval(Parse("(dt3<<"||char(dt3:Make << Get script)||") << set name(\!"Clone\!");"));
// proof that the column was cloned - check log
dt3:Clone << get script;
close (dt3, no save);
best,
ron
I'm really not sure what value there is in keeping column properties like value colors in a private table. If the data is all you care about (typically true for private tables), the simpler method below could be used.:
dt3 << New Column("Make Clone", Formula(dt3:Make))
Thanks MS,
It is true that colors are not very useful in a private table.
the thing is that I am writing an algorithm based on a heuristic process. this means that I need to have a script that would do what i would if i had to "read" the data lines one by one my self and interpret it (here is where i need the colors). on the other hand the script needs to be fast when running so i need to bounce back and fourth between tables I see and fast running ones (private). this transition between visual and private tables introduces robustness challenges while scripting across a few open tables.
ron
the robustness issue came when using private tables since the clone was sent to another table which was not private.