Re: [Rd] order of operations

[Duncan Murdoch]

On 27/08/2021 3:06 p.m., Enrico Schumann wrote:

On Fri, 27 Aug 2021, Gabor Grothendieck writes:


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


At least the "R Language Definition" [1] says

   "The exponentiation operator ‘^’ and the left
assignment plus minus operators ‘<- - = <<-’
group right to left, all other operators group
left to right.  That is  [...]  1 - 1 - 1 is -1"

which would imply 2.


I think this is a different issue.  There's only one operator in 
question (the "*").  The question is whether x*y evaluates x first or y 
first (and I believe the answer is that there are no guarantees).  I'm 
fairly sure both are guaranteed to be evaluated, under the rules for 
group generics listed in ?groupGeneric, but I'm not certain the 
guarantee is honoured in all cases.


Duncan Murdoch

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

Re: [Rd] order of operations

[Enrico Schumann]

On Fri, 27 Aug 2021, Gabor Grothendieck writes:

> 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

At least the "R Language Definition" [1] says

  "The exponentiation operator ‘^’ and the left
   assignment plus minus operators ‘<- - = <<-’
   group right to left, all other operators group
   left to right.  That is  [...]  1 - 1 - 1 is -1"

which would imply 2.

[1] 
https://cran.r-project.org/doc/manuals/r-release/R-lang.html#Infix-and-prefix-operators

-- 
Enrico Schumann
Lucerne, Switzerland
http://enricoschumann.net

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

Re: [Rd] order of operations

[GILLIBERT, Andre]

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  de la part de Gabor Grothendieck 

Envoy� : vendredi 27 ao�t 2021 19:57:33
� : Avi Gross
Cc : r-devel@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
 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  On Behalf Of Gabor
> Grothendieck
> Sent: Friday, August 27, 2021 11:32 AM
> To: Thierry Onkelinx 
> 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 
> wrote:
>
> > IMHO this is just bad practice. Whether the result is guaranteed or
> > not, doesn't matter.
> >
> > ir. Thierry Onkelinx
> > Statisticus / Statistician
> >
> > Vlaamse Overheid / Governm

Re: [Rd] order of operations

[Avi Gross via R-devel]

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  
Sent: Friday, August 27, 2021 1:58 PM
To: Avi Gross 
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  
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  On Behalf Of Gabor 
> Grothendieck
> Sent: Friday, August 27, 2021 11:32 AM
> To: Thierry Onkelinx 
> 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 
> 
> 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
> >
> >
> > 
> > // //

Re: [Rd] order of operations

[Gabor Grothendieck]

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
 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  On Behalf Of Gabor
> Grothendieck
> Sent: Friday, August 27, 2021 11:32 AM
> To: Thierry Onkelinx 
> 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 
> 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
> >
> > //
> > /
> >
> > 
> >
> >
> > 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/

Re: [Rd] order of operations

[Avi Gross via R-devel]

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  On Behalf Of Gabor
Grothendieck
Sent: Friday, August 27, 2021 11:32 AM
To: Thierry Onkelinx 
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 
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
>
> //
> /
>
> 
>
>
> 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

Re: [Rd] order of operations

[Gabor Grothendieck]

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 
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
>
> ///
>
> 
>
>
> 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

Re: [Rd] order of operations

[Thierry Onkelinx via R-devel]

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
///




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
>

[[alternative HTML version deleted]]

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

[Rd] order of operations

[Gabor Grothendieck]

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

[Rd] R_CheckUserInterrupt

[GILLIBERT, Andre]

Dear R developers,


R makes some functions interruptible, thanks to a call to R_CheckUserInterrupt. 
Simple arithmetic operations can be interrupted avoiding freezes when using 
huge arrays (e.g. length > 1 billion).

But many operations, such as matrix multiplication, are not interruptible. I 
estimated that a multiplication of two 1�1 square matrices would freeze 
R for at least 7 days on my computer, unless I kill the process.


I found an old commit that deleted the calls to R_CheckUserInterrupt in many 
basic operations 
(https://github.com/wch/r-source/commit/b99cd362a65012335a853d954cbeb1c782e6ae37)


Why were they deleted ?


First hypothesis : this slowed down the code too much, because it was done 
suboptimally, with an integer division (high latency CPU operation) at each 
iteration.

Second hypothesis : this introduced bugs, such as memory leaks, in code that 
did not handle interruptions gracefully.


If the first hypothesis is correct, I can write much better code, with almost 
zero penalty, using R_ITERATE_CHECK (in R_ext/Itermacros.h) and a new macro I 
wrote: ITERATE_BY_REGION_CHECK.


That would make more operations interruptible and would even provide 
performances improvements in loops that were not optimized for ALTREPs.


Are you interested in patches?



PS: the slow integer division is actually not very slow with recent GCC 
versions, because this compiler is smart enough to replace it by a 
multiplication and a shift because the divisor is known at compile time. Older 
compilers may not be that smart.


--

Sincerely

Andr� GILLIBERT

[[alternative HTML version deleted]]

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