Running things in various forms of parallel opens up all kinds of issues. Currently, programs that use forms like "threads" often need to carefully protect any variables that can be changed using things like locks.
So what would they do in the scenario being discussed? Would they need to analyze the entire part of the program before splitting off parts and add code to protect not only from simultaneous access to the variable but set up a guarantee so that one of multiple threads would get to change it first and others freeze until it is their turn? Strikes me as a bit too complex given the scenario does not look like one that is likely to have serious uses. I understand the question is more academic and there are multiple reasonable answers with tradeoffs. And one answer is to make it totally deterministic even if that precludes any ability to speed things up. Another is to simply declare such use to be either illegal or unsupported. And, perhaps, there can be support for ways to do this kind of thing more safely. Clearly, the methods of parallelism vary from threads within a program running on the same processor that just interleave, to running on multiple processors and even multiple machines across the world. Darned if I know what issues would come up on quantum computers which have yet other aspects of the concept of parallelism. -----Original Message----- From: Gabor Grothendieck <ggrothendi...@gmail.com> Sent: Friday, August 27, 2021 1:58 PM To: Avi Gross <avigr...@verizon.net> Cc: r-devel@r-project.org Subject: Re: [Rd] order of operations 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@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-boun...@r-project.org> On Behalf Of Gabor > Grothendieck > Sent: Friday, August 27, 2021 11:32 AM > To: Thierry Onkelinx <thierry.onkel...@inbo.be> > Cc: r-devel@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.onkel...@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.onkel...@inbo.be Havenlaan 88 bus 73, 1000 Brussel > > 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 < > > ggrothendi...@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@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@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > ______________________________________________ > R-devel@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@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
