As part of the JuliaML org/initiative, I'm working on some experimental stuff in Transformations which may be of interest. The goal is that you can define functions using valid julia syntax and let it be parsed into a backend-agnostic call graph constructor. To simplify: you would create your "formula", which could be scalar or tensor operations, and that builds type(s) with generated constructors/methods in order to calculate values, derivatives, or whatever else. It would know which variables are inputs, constants, functions, or "learnable parameters".
My vision is that one could define a formula once, then optimize/learn the free parameters, or generate probabilistic samples etc, using Optim, TensorFlow, or any other "backends" that may be able to do something useful. It's very similar to the Plots approach, and I see no reason why it wouldn't work here. For demonstrations sake, I added a recipe for Mike Innes' Flow.jl, which may form the basis of the "parsing": using Transformations @flow y(x) = x + log(x) - sin(x^2) using Plots; plot(ans) As I said, this is experimental so I don't expect everyone to drop what they're doing and help out. However it would be great to have more people involved if you're interested. Best, Tom On Thu, Aug 18, 2016 at 9:39 AM, John Myles White <[email protected]> wrote: > Some of the recent work I've been doing to demo out automatic lifting for > tables makes me think that the syntax here doesn't matter too much (as long > as it's easy to manipulate inside a macro). 0.5 actually offers us the > chance to use substantially more interesting semantics than we have had in > the past. We could realistically hope to do something like this now: > > @model_matrix(y ~ x + log(x) - sin(x^2), data) > > --John > > > On Wednesday, August 17, 2016 at 3:34:46 PM UTC-7, Alex Arslan wrote: >> >> Agreed regarding Stata formulas. >> >> We could always go the way of SAS and use = to separate the response from >> predictors, though that could get a tricky and/or confusing due to the >> similarity with how keyword arguments are specified. Not to mention >> problematic behavior if used incorrectly... >> >> Milan Bouchet-Valat <[email protected]> >> August 17, 2016 at 7:32 AM >> I don't find it particularly clear that in Stata the response isn't >> visually separated from the dependent variables. ~ is really useful >> IMHO. >> >> As regards +, it's needed so that the formula is a valid Julia >> expression, which is good for consistency (even if formulas end up >> being written as strings). That convention also follows the Wilkinson & >> Rodgers notation, so there's a precedent in the literature other than >> R. >> >> >> Regards >> >> Matthieu <[email protected]> >> August 15, 2016 at 8:33 PM >> In stata one specifies a formula without ~ or + >> y x1 x2 >> It works pretty well in my experience. How about dropping ~ and +? >> >> Michael Krabbe Borregaard <[email protected]> >> May 18, 2016 at 6:04 AM >> One might argue that the mathematical symbol ⇒ means something entirely >> different from what is implied by the formula operator: that the left side >> leads to the right by material implication >> <https://en.wikipedia.org/wiki/Material_conditional> . Also, the >> intuitive interpretation of => (that the left side leads to the right) is >> wrong. >> >> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "julia-stats" group. >> To unsubscribe from this topic, visit https://groups.google.com/d/to >> pic/julia-stats/LdozV7o4zuM/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> Milan Bouchet-Valat <[email protected]> >> May 18, 2016 at 4:24 AM >> >> Le mardi 17 mai 2016 à 22:22 -0700, Alex Arslan a écrit : >> >> I definitely agree with Stefan on this. >> >> Milan, you mentioned that we should have a strong reason to break the >> convention if we choose to do so. I've always found R's use of `~` to >> be a bit unfortunate. It's a carryover from S, which introduced `~` >> for formulas before R was even a thing. But S is also the language >> that brought us `<-` for assignment, so I tend to be wary of its >> gifts. ;) At this point I think other languages that offer >> statistical modeling facilities are using `~` just because R does it. >> Julia has the opportunity to potentially set a new precedent as it >> gains traction for stats, so I think we should think carefully about >> the choices. >> >> Stefan's suggestion of `@model` opens the possibility for just about >> any kind of separator because it just becomes the `head` in the >> `Expr` that goes into the macro. But I think the syntax for pairs, >> i.e. `=>`, would make the most sense in terms of consistency with >> existing Julia structures because a model is essentially a pair; it's >> some combination of responses paired with some combination of >> predictors. >> >> As I said, I find => a good idea too. @model sounds a bit verbose to me >> (it should really be called @formula anyway), but maybe that's OK if in >> practice we can use @fit as a shorthand. >> >> Anyway, I don't really have strong feelings about this either. >> >> >> Regards >> >> >> Anyway, just thinking aloud. >> -Alex >> >> >> I don't have a strong feeling about `~` versus `=>` – although the >> R tradition of using `~` seems to at least give a hint about what's >> going on, which is kind of nice. But I do think that it would be >> good to get rid of the macro business for ~ and start spelling >> model specifications as `@model y ~ 1 + x + z` or `@model y => 1 + >> x + z` and returning some kind of Model type instead of using bare >> expression objects for this kind of thing. Expression objects >> already have a meaning in Julia code and it is not to specify >> statistical models – it is to represent Julia expression trees. The >> fact that those two meanings can usually be disambiguated easily >> doesn't mean they should be represented the same way. >> >> On Tue, Feb 2, 2016 at 10:15 AM, Milan Bouchet-Valat wrote: >> >> Le mardi 02 février 2016 à 15:30 +0100, Milan Bouchet-Valat a écrit : >> >> Using Pairs (and therefore =>) sounds like a good idea to me, as it >> conveys exactly the meaning of associating two parts of a formula >> together, in a structure designed for that. (Well, the direction of the >> arrow isn't very natural, but...) >> >> But maybe to make it nicer to read we could make the whole formula an >> expression, i.e.: >> :(y => 1 + x + z) >> >> instead of: >> :y => :(1 + x + z) >> >> >> That would make the syntax very close to what macros would allow to fit >> a model: >> @fit(LinearModel, y => 1 + x + z, data) >> >> (Such a macro, while not strictly necessary, could also allow saving >> the full call expression and the name of the dataset used when fitting >> the model, to print it to the user as R does.) >> >> >> Maybe more importantly, it would remove the requirement for the left >> hand-side of the formula to be a symbol. Indeed, some models (like PLS >> regression) accept several dependent variables, which could be written >> like this: >> :(y + z => 1 + x) >> >> Actually, scratch that, as the two features are orthogonal. >> :(y => 1 + x + z) and :y => :(1 + x + z) both have Symbol as the type >> for the LHS. The only difference is whether we have a Pair of >> expressions/symbols or a => call with two expression/symbol arguments. >> >> Yet it might be a bit nicer to write >> :(y + z => 1 + x) >> rather than >> :(y + z) => :(1 + x) >> >> >> >> My two cents >> >> >> Le lundi 01 février 2016 à 13:18 -0800, Douglas Bates a écrit : >> >> The current formula interface for packages like GLM and MixedModels >> emulates that of R in that a formula is written like >> >> y ~ 1 + x + z >> >> The difficulty with this form is that the ~ character is used >> elsewhere in Julia so somewhat nasty tricks need to be used to >> parse >> such an expression as a formula. >> >> One way to break away from this R-centric approach is to use a Pair >> to represent a formula. Because we don't want to evaluate the >> expressions in a formula at function call it would be necessary to >> use Pair(Symbol,Expr) or Pair(Expr,Expr) to represent a two-sided >> formula. The translation of the previous formula would be >> >> :y => :(1 + x + z) >> >> This requires a few extra keystrokes but is not a terrible burden >> and >> it would use a native Julia construct. It also serves to visually >> distinguish a formula in Julia from a formula in R so that we can >> make other changes in the formula language (e.g. require an >> explicit >> 1 for the intercept term) with less confusion for users. Because a >> formula in Julia looks different from a formula in R it is less >> confusing that other aspects of the formula syntax are different in >> Julia and in R. >> >> -- >> You received this message because you are subscribed to the Google >> Groups "julia-stats" group. >> To unsubscribe from this group and stop receiving emails from it, >> send an email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> >> -- >> You received this message because you are subscribed to the >> Google Groups "julia-stats" group. >> To unsubscribe from this group and stop receiving emails from it, >> send an email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> >> >> -- >> You received this message because you are subscribed to the Google >> Groups "julia-stats" group. >> To unsubscribe from this group and stop receiving emails from it, >> send an email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> >> >> -- > You received this message because you are subscribed to the Google Groups > "julia-stats" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "julia-stats" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
