Hi,
I've noticed that if variable names are not R standard, many modules do not work well. A user sent me a dataset with variables named "Direction (left=1,right=2)" and "Stimulus (1=?,2=+)" (I know it is crazy naming but that's the way people do ).
GAMLj fails in different parts with these variables, but also some JVM procedures fails, such as all the post-hoc tests in ANOVA/ANCOVA, Do you prefer each module to handle this variables separately or would you see a general solution (such as a make.names() as soon as the data are imported, or the like?
Variables names
Re: Variables names
> but also some JMV procedures fails, such as all the post-hoc tests in ANOVA/ANCOVA
ah! if you find these issues, make sure you report them to our github issues page.
but yes, names can be an issue. it comes down to the packages we use. it's easy enough to make our code handle special names, but there's other packages out there which don't handle special names correctly.
generally we:
1. ask the author of the naughty package about it
2. submit a PR fixing the issue in the upstream package
3. work around the issue by encoding the names in base 64
normally 1. doesn't work, but i've got 2. to work a few times. i've had patches accepted into lsmeans, afex, etc. but sometimes it's too much work, and it's easier to just work around it.
ravi should be the one answering here, because he has more experience with it, but let me see if i can find a good example in jmv. ah, here's one:
https://github.com/jamovi/jmv/blob/mast ... a.b.R#L133
in this instance it's the level names which is the issue. what ravi does is encodes them all to base 64, and then when he's reading the results back out from the object, he decodes them back to normal again:
https://github.com/jamovi/jmv/blob/mast ... a.b.R#L431
by encoding to and from base 64, you don't have to store/remember the original names.
toB64 and fromB64 are in jmvcore:
https://www.rdocumentation.org/packages ... pics/toB64
but if the package *is* OK with variables with spaces in them, you may find the composeTerm(), etc. functions useful:
https://www.rdocumentation.org/packages ... omposeTerm
jonathon
ah! if you find these issues, make sure you report them to our github issues page.
but yes, names can be an issue. it comes down to the packages we use. it's easy enough to make our code handle special names, but there's other packages out there which don't handle special names correctly.
generally we:
1. ask the author of the naughty package about it
2. submit a PR fixing the issue in the upstream package
3. work around the issue by encoding the names in base 64
normally 1. doesn't work, but i've got 2. to work a few times. i've had patches accepted into lsmeans, afex, etc. but sometimes it's too much work, and it's easier to just work around it.
ravi should be the one answering here, because he has more experience with it, but let me see if i can find a good example in jmv. ah, here's one:
https://github.com/jamovi/jmv/blob/mast ... a.b.R#L133
in this instance it's the level names which is the issue. what ravi does is encodes them all to base 64, and then when he's reading the results back out from the object, he decodes them back to normal again:
https://github.com/jamovi/jmv/blob/mast ... a.b.R#L431
by encoding to and from base 64, you don't have to store/remember the original names.
toB64 and fromB64 are in jmvcore:
https://www.rdocumentation.org/packages ... pics/toB64
but if the package *is* OK with variables with spaces in them, you may find the composeTerm(), etc. functions useful:
https://www.rdocumentation.org/packages ... omposeTerm
jonathon
- mcfanda@gmail.com
- Posts: 462
- Joined: Thu Mar 23, 2017 9:24 pm
Re: Variables names
great, perfect! I'll implement these suggestions in next version of the module
Re: Variables names
you've probably seen that a fix has been merged into emmeans, which should fix the issues you're having with GAMLj.
cheers
cheers
- mcfanda@gmail.com
- Posts: 462
- Joined: Thu Mar 23, 2017 9:24 pm
Re: Variables names
yes, I just need to fix the mixed formula and i'm done with this bug