Amazing! :+1: Den 18/08/2016 15.39 skrev "John Myles White" <[email protected]>:
> 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.
