Skip to main content
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