[Rd] order of operations

Fri Aug 27 20:36:40 CEST 2021

Due to lazy evaluation, the order of operations can be pretty random in R. Actually, some operations may not be performed at all, sometimes.

The following program illustrates the issue:

test1=function(x,y) {}
test2=function(x,y) {x;y}
test3=function(x,y) {y;x}
alpha="hello"
test1(alpha <- 1, alpha <- 2)
print(alpha) # prints "hello"

test2(alpha <- 1, alpha <- 2)
print(alpha) # prints 2

test3(alpha <- 1, alpha <- 2)
print(alpha) # prints 1

Many internal functions unconditionally evaluate all their parameters before performing any operation, because they know that they will use all of them anyway. Theoretically, the order of evaluation could be well-specified for these internal functions, but I would recommend against doing that, because the functions could be changed in future, and not evaluate some of their parameters, or change the order of evaluation.

For instance, in R 4.0, the following code displays 6:
alpha<-42
1|(alpha<-6)
print(alpha)

But, I would not be shocked to see it display 42 in a future version of R.

Moreover, internal functions are usually wrapped in R code, that may evaluate parameters in random orders due to lazy evaluation.
See mean.default, for instance...

On R 4.0.3:
mean.default((alpha<-1),(alpha<-2),(alpha<-3))
print(alpha) # prints 2

Things are probably less tricky with a simple addition or multiplication, but I would not rely on that.

--
Sincerely
Andr� GILLIBERT
________________________________
De : R-devel <r-devel-bounces using r-project.org> de la part de Gabor Grothendieck <ggrothendieck using gmail.com>
Envoy� : vendredi 27 ao�t 2021 19:57:33
� : Avi Gross
Cc : r-devel using r-project.org
Objet : Re: [Rd] order of operations

ATTENTION: Cet e-mail provient d�une adresse mail ext�rieure au CHU de Rouen. Ne cliquez pas sur les liens ou n'ouvrez pas les pi�ces jointes � moins de conna�tre l'exp�diteur et de savoir que le contenu est s�r. En cas de doute, transf�rer le mail � � DSI, S�curit� � pour analyse. Merci de votre vigilance

It could be that the two sides of * are run in parallel in the future and maybe
not having a guarantee would simplify implementation?

On Fri, Aug 27, 2021 at 12:35 PM Avi Gross via R-devel
<r-devel using r-project.org> wrote:
>
> Does anyone have a case where this construct has a valid use?
>
> Didn't Python  add a := operator recently that might be intended more for
> such uses as compared to using the standard assignment operators? I wonder
> if that has explicit guarantees of what happens in such cases, but that is
> outside what this forum cares about. Just for the heck of it, I tried the
> example there:
>
>         >>> (x := 1) * (x := 2)
>         2
>         >>> x
>         2
>
> Back to R, ...
>
> The constructs can get arbitrarily complex as in:
>
> (x <- (x <- 0) + 1) * (x <- (x <-2) + 1)
>
> My impression is that when evaluation is left to right and also innermost
> parentheses before outer ones, then something like the above goes in stages.
> The first of two parenthetical expressions is evaluated first.
>
> (x <- (x <- 0) + 1)
>
> The inner parenthesis set x to zero then the outer one increments x to 1.
> The full sub-expression evaluates to 1 and that value is set aside for a
> later multiplication.
>
> But then the second parenthesis evaluates similarly, from inside out:
>
> (x <- (x <-2) + 1)
>
> It clearly resets x to 2 then increments it by 1 to 3 and returns a value of
> 3. That is multiplied by the first sub-expression to result in 3.
>
> So for simple addition, even though it is commutative, is there any reason
> any compiler or interpreter should not follow rules like the above?
> Obviously with something like matrices, some operations are not abelian and
> require more strict interpretation in the right order.
>
> And note the expressions like the above can run into more complex quandaries
> such as when you have a conditional with OR or AND parts that may be
> short-circuited and in some cases, a variable you expected to be set, may
> remain unset or ...
>
> This reminds me a bit of languages that allow pre/post increment/decrement
> operators like ++ and -- and questions about what order things happen.
> Ideally, anything in which a deterministic order is not guaranteed should be
> flagged by the language at compile time (or when interpreted) and refuse to
> go on.
>
> All I can say with computer languages and adding ever more features,
>         with greater power comes greater responsibility and often greater
> confusion.
>
>
> -----Original Message-----
> From: R-devel <r-devel-bounces using r-project.org> On Behalf Of Gabor
> Grothendieck
> Sent: Friday, August 27, 2021 11:32 AM
> To: Thierry Onkelinx <thierry.onkelinx using inbo.be>
> Cc: r-devel using r-project.org
> Subject: Re: [Rd] order of operations
>
> I agree and personally never do this but I would still like to know if it is
> guaranteed behavior or not.
>
> On Fri, Aug 27, 2021 at 11:28 AM Thierry Onkelinx <thierry.onkelinx using inbo.be>
> wrote:
>
> > IMHO this is just bad practice. Whether the result is guaranteed or
> > not, doesn't matter.
> >
> > ir. Thierry Onkelinx
> > Statisticus / Statistician
> >
> > Vlaamse Overheid / Government of Flanders INSTITUUT VOOR NATUUR- EN
> > BOSONDERZOEK / RESEARCH INSTITUTE FOR NATURE AND FOREST Team Biometrie
> > & Kwaliteitszorg / Team Biometrics & Quality Assurance
> > thierry.onkelinx using inbo.be Havenlaan 88 bus 73, 1000 Brussel www.inbo.be<http://www.inbo.be>
> >
> >
> > //////////////////////////////////////////////////////////////////////
> > ///////////////////// To call in the statistician after the experiment
> > is done may be no more than asking him to perform a post-mortem
> > examination: he may be able to say what the experiment died of. ~ Sir
> > Ronald Aylmer Fisher The plural of anecdote is not data. ~ Roger
> > Brinner The combination of some data and an aching desire for an
> > answer does not ensure that a reasonable answer can be extracted from
> > a given body of data.
> > ~ John Tukey
> >
> > //////////////////////////////////////////////////////////////////////
> > /////////////////////
> >
> > <https://www.inbo.be>
> >
> >
> > Op vr 27 aug. 2021 om 17:18 schreef Gabor Grothendieck <
> > ggrothendieck using gmail.com>:
> >
> >> Are there any guarantees of whether x will equal 1 or 2 after this is
> run?
> >>
> >> (x <- 1) * (x <- 2)
> >> ## [1] 2
> >> x
> >> ## [1] 2
> >>
> >> --
> >> Statistics & Software Consulting
> >> GKX Group, GKX Associates Inc.
> >> tel: 1-877-GKX-GROUP
> >> email: ggrothendieck at gmail.com
> >>
> >> ______________________________________________
> >> R-devel using r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-devel
> >>
> >
>
> --
> Statistics & Software Consulting
> GKX Group, GKX Associates Inc.
> tel: 1-877-GKX-GROUP
> email: ggrothendieck at gmail.com
>
>         [[alternative HTML version deleted]]
>
> ______________________________________________
> R-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> ______________________________________________
> R-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

--
Statistics & Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com

______________________________________________
R-devel using r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

	[[alternative HTML version deleted]]