Cool, workspace() seems very helpful. Yeah, I don't really understand exactly what that code would look like either, because I'm not the most familiar with time-series statistics. My point was that to work easily with flexible models that mix environmental variables with dataframe variables, it is convenient (though again not necessary) to have environment access.
On Saturday, July 25, 2015 at 7:34:44 AM UTC-4, Milan Bouchet-Valat wrote: > > Le samedi 25 juillet 2015 à 01:58 -0700, Brandon Taylor a écrit : > > Well a somewhat unique feature or R is automatic argument recycling, > > so that when doing operations on dataframes, it's a lot easier to > > incorporate data from outside of the dataframe into evaluation. Let's > > say you are doing a stepwise logisitic growth model, like dP/dt = > > r*P*(1 - P/K). Let's say that r a known single value in the global > > environment, K is going be predicted from some environmental > > variables within your dataframe, and P is going to be given as an > > initial condition and its evolution modeled. The R way of looking at > > this would be to set up an environment where the dataframe > > environment inherits from the global environment, and to evaluate > > within this environment regardless of calling environment. That means > > that within a sub sub function, you can use r to represent, maybe, a > > row number, and K, to represent, maybe, a column number, and that you > > can still evaluate an expression like r*P*(1 - P/K) with no problem. > > This is most useful when writing your own functions. For example, you > > could build some sort of time-series predictive package that could > > handle not only logisitic models, but other models, like the Lotka > > -Volterra models. Now, I'm not saying this is impossible to do in > > Julia: in fact, I'm quite sure it is. It's just less convenient. > Thanks for the example. I don't think I would use an environment for > that. Why not have the function take a data frame with the variables, a > nd constants as an argument? As I understand it, the only interest of > environments is that you don't have to make a difference between > variables in the data frame and variables in the global scope. But I > also find it confusing that you don't know where the data comes from, > and I've seen students make mistakes because of that. > > That said, I don't understand exactly what the code you describe would > look like, so I might be missing something. If you can provide a few > lines to illustrate a toy example, it could help. > > > The other nice things about environments are more trivial. For > > example, you might be doing a homework assignment with several > > problems. At the start of each problem, you could define a new > > environment. At the end of the problem, you could display the entire > > content of the problem's environment as a way to track down errors. > > When looking at an answer sheet, you could compare intermediate > > results and see where you went wrong. Again, not impossible to do > > with Julia; you would probably want to set up a dict for each > > problem, and do all operations within that dict. Which, I guess, is > > basically what is happening under the hood in a language with > > environments. > You should be able to do this by working inside modules in Julia. In > particular, workspace() looks exactly like what you're describing: once > you're done with one problem, call it to get a clean environment, > storing globals in the LastMain module. > > > Regards > > > I'll just nod in agreement with the fexpr stuff and pretend I > > understand. > > > > On Friday, July 24, 2015 at 4:11:37 PM UTC-4, Scott Jones wrote: > > > I should give you a hard time about arguing from authority ;-), but > > > I was there at the same time and knew KMP, so I wouldn't want to > > > argue too much with him either, and I am in agreement with you > > > about fexprs vs. macros, and the equivalent issues in Julia. > > > > > > On Friday, July 24, 2015 at 2:31:54 PM UTC-4, Stefan Karpinski > > > wrote: > > > > Lisp has already been down this path – fexprs were special forms > > > > with behavior similar to R's functions, and they were deprecated > > > > in the 1980s in favor of macros, https://en.wikipedia.org/wiki/Fe > > > > xpr#Mainstream_use_and_deprecation: > > > > > > > > > His central objection was that, in a Lisp dialect that allows > > > > > fexprs, static analysis cannot determine generally whether an > > > > > operator represents an ordinary function or a fexpr — > > > > > therefore, static analysis cannot determine whether or not the > > > > > operands will be evaluated. In particular, the compiler cannot > > > > > tell whether a subexpression can be safely optimized, since the > > > > > subexpression might be treated as unevaluated data at run-time. > > > > If Lispers think a feature is too dynamic and hard to understand, > > > > that's a danger sign. In general, I wouldn't want to argue too > > > > much with Kent Pitman :-) > > > > > > > > On the subject of Kent Pitman, here's a random bit of Lisp wisdom > > > > from this interview with him: > > > > > > > > > I like Lisp's willingness to represent itself. People often > > > > > explain this as its ability to represent itself, but I think > > > > > that's wrong. Most languages are capable of representing > > > > > themselves, but they simply don't have the will to. Lisp > > > > > programs are represented by lists and programmers are aware of > > > > > that. It wouldn't matter if it had been arrays. It does matter > > > > > that it's program structure that is represented, and not > > > > > character syntax, but beyond that the choice is pretty > > > > > arbitrary. It's not important that the representation be the > > > > > Right® choice. It's just important that it be a common, agreed > > > > > -upon choice so that there can be a rich community of program > > > > > -manipulating programs that "do trade" in this common > > > > > representation. > > > > This is probably the best quote about homoiconicity I've read > > > > anywhere and explains why the term is tricky to pin down. > > > > > > > > On Fri, Jul 24, 2015 at 2:21 PM, Brandon Taylor < > > > > brandon....@gmail.com> wrote: > > > > > Macros seem to have a bunch of limitations. They can't be > > > > > overloaded to take advantage of Julia's typing system. Their > > > > > functionality can somewhat mimic evaluation within a function > > > > > in its direct parent environment, but what if you want to write > > > > > functions within your macro, or macros inside your macro, etc? > > > > > Probably still possible to do many things, but it would invovle > > > > > passing expressions back in forth in confusing ways, where as > > > > > with environments, as long as an environment is kept attached > > > > > to every expression, they can be immediately evaluated in any > > > > > sub or subsub etc. environment. > > > > > > > > > >
