Page 1 of 1

How/why is jamovi indicating wrong factor levels for an Rj-created variable?

Posted: Wed Jun 07, 2023 2:09 am
by reason180
I have an analysis project in which I use Rj+ to add lots of new computed variable the the data. I never explicitly created "factor" variables, but jamovi appears to automatically convert non-numeric variables to factors. Curiously, jamovi often indicates wrong factor levels (for example, factor levels that belong to a different factor). Yet the same time, the correct factor levels (they should be "0" and "1") appear in the spreadsheet cells. See the illustration below. my question is, how/why is this possible, and how can I fix it? (Unfortunately, I haven't been able to reproduce this issue with a small data set and code set.)
Untitledfrdr.png
Untitledfrdr.png (71.76 KiB) Viewed 2372 times

Re: How/why is jamovi indication wrong factor levels for an Rj-created variable?

Posted: Wed Jun 07, 2023 4:06 am
by jonathon
> I never explicitly created "factor" variables, but jamovi appears to automatically convert non-numeric variables to factors

there's not a perfect correspondence between R types, and jamovi types, so treating these as factors seems reasonable.

> my question is, how/why is this possible, and how can I fix it?

yeah, the key to fixing bugs is being able to reproduce the issue. if you can find a way to do that, i expect we'll be able to push out a fix pretty quickly.

cheers

jonathon

Re: How/why is jamovi indication wrong factor levels for an Rj-created variable?

Posted: Thu Jun 08, 2023 12:52 pm
by reason180
So here's a reproducible corruption of the factor levels in jamovi 2.3.28 for Windows. It may or may not be exactly the same issue that I originally, because I had introduce an operation that I don't think I used initially.

In the attached omv file, a started with a three-row column of values ("red", "blue", "green") called Color. I then used Rj+ to create three additional columns (Animal, Number, Season) which are transformations of the Color column.

If you look the factor levels in jamovi, they are correct.

Now, in the spreadsheet, manually delete "blue" from the Color column. Now type-in "blue" to replace what was deleted.

You'll see that the factor levels for the Animal, Number, and Season are corrupted. Moreover, they appear to be permanently corrupted in that you can delete them and re-run the Rj code, but the corruption will remain.

Re: How/why is jamovi indication wrong factor levels for an Rj-created variable?

Posted: Thu Jun 08, 2023 4:42 pm
by reason180
I've now reproduced the bug in a slightly different way. In changing a value to NA nd then back to its original value: instead of doing it manually, I've done it with Rj+ code, with a similar results (corrupted factor levels). See the attachment.

Re: How/why is jamovi indication wrong factor levels for an Rj-created variable?

Posted: Thu Jun 08, 2023 5:12 pm
by reason180
I now see that the problem isn't specific to the use of NA. If I use Rj+ code to change "whale" to "armadillo" and then back again, there's still some corruption of some of the factor levels. See attached.

Re: How/why is jamovi indicating wrong factor levels for an Rj-created variable?

Posted: Fri Jun 09, 2023 2:11 am
by jonathon
awesome. thanks for taking the time to reproduce/provide/describe ... i'll take a look.

jonathon

Re: How/why is jamovi indicating wrong factor levels for an Rj-created variable?

Posted: Fri Jun 09, 2023 4:30 am
by jonathon
hmm ... this is a good one. the good news is, that there's no corruption to the data set, per se, only to the way the data set is displayed. if you save the file and reopen it, everything will be fine ... in fact, you can just hit F5, and it will refresh all good.

i've created an issue here: https://github.com/jamovi/jamovi/issues/1358

with thanks

jonathon

Re: How/why is jamovi indicating wrong factor levels for an Rj-created variable?

Posted: Fri Jun 09, 2023 3:43 pm
by reason180
It's good to know that the problem is with how the factor levels are displayed rather than with the data themselves.

Note. However, that saving and or using F5 does not necessarily correct the display. I provide details on the github issue thread.