Timeline for Produce a list of variable name in a for loop, then assign values to them
Current License: CC BY-SA 3.0
16 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
Aug 15, 2013 at 13:26 | history | edited | gung - Reinstate Monica | CC BY-SA 3.0 |
aligned code for readability
|
May 20, 2011 at 20:07 | comment | added | mpiktas | Ok this is bizarre, why the downvote? My answer clearly solves the problem (I've tested it), and I've given the arguments why this particular piece of code is acceptable. It does not involve any fancy hackery it is plain R. | |
May 20, 2011 at 3:33 | comment | added | mpiktas | @mdsumner, why is it a bad practice? | |
May 19, 2011 at 23:27 | comment | added | mdsumner | exactly, bad practice like using assign to create multiple single element variables should be discouraged | |
May 16, 2011 at 13:37 | comment | added | mpiktas | @mdsumner, your code produces named vector, when the OP wants variables with certain names in the global environment. | |
May 16, 2011 at 13:36 | comment | added | mpiktas |
@Joris, I use eval later in the code to evaluate the function :) Though I take care to use the correct environment.
|
|
May 16, 2011 at 13:25 | comment | added | mdsumner | elegant workspaces are nice too n <- 3; vals <- structure(rnorm(n), names = paste("a", 1:n, sep = "")) | |
May 16, 2011 at 13:25 | comment | added | Joris Meys |
@mpiktas : Your link is an example where the use of parse is the right choice. Note that you never used eval() there, you use parse (correctly) to convert a string to an expression object needed by the deriv() function. That's a whole other beast than the problem of OP. Nice piece of code by the way.
|
|
May 16, 2011 at 13:12 | comment | added | mpiktas |
@Joris, thanks for your explanations. I just felt a bit stupid, since I use parse extensively mainly for reasons given in this example. I do not think that besides automatic differentiation (which is not yet implemented fully) you can produce more elegant code. I would however be glad to be proven wrong.
|
|
May 16, 2011 at 13:06 | comment | added | Joris Meys | @mpiktas : I never said it's deficient. I just gave you the reason why in general a eval(parse()) construct is advised against by eg Thomas Lumley, member of the R core development team. (cfr the refernce of @Roman Lustrik) | |
May 16, 2011 at 12:53 | comment | added | mpiktas |
@Joris, ok this is clearly R and the code is not in a function :) In this case I used parse as a substitute for running a code which I created using string manipulation instead of writing the code by hand. I fail to see the deficiencies of parse in this scenario, since this is the way R is used, you write some code and then you run it.
|
|
May 16, 2011 at 12:40 | comment | added | Joris Meys | @mpiktas : it has to do with the fact that the underlying scoping rules can result in inpredictable results when used within a function. Also (as mentioned in the help files), R and S can give a different result due to the difference in scoping rules. It is also slower than other solutions. This will matter when you have to do this many times. And last but not least, in most cases there is a more elegant and easier solution than using eval(parse()). In this case that's working with lists or using assign. | |
May 16, 2011 at 12:31 | comment | added | mpiktas |
@Roman, I see that there are at least 3 people which do not like to use parse , yet nobody gave clear reason why. Is it slow? Prone to errors? Too sophisticated? I usually use it as analogue of source .
|
|
May 16, 2011 at 12:28 | comment | added | mpiktas |
@Roman, strange, I've started using parse after reading R help pages. I agree that sometimes it is an overkill, for example in formula management, but I found it very useful. Note that I cannot rethink the question as suggested in the fortune, since I did not ask it.
|
|
May 16, 2011 at 12:18 | comment | added | Roman Luštrik |
library(fortunes) fortune(106)
|
|
May 16, 2011 at 5:46 | history | answered | mpiktas | CC BY-SA 3.0 |