Gabor Grothendieck wrote:
> ... and maybe not having a guarantee would simplify implementation?
+1 for: "The results of such statements are not defined.", or something
to that effect. (Erasmus had something to say here. :)
__
R-devel@r-project.org ma
t all its arguments are evaluated.
--
Sincerely
Andre GILLIBERT
*De :* R-devel de la part de peter
dalgaard
*Envoyé :* samedi 28 août 2021 09:26:03
*À :* Duncan Murdoch
*Cc :* r-devel@r-project.org
*Objet :* Re: [Rd] order of operations
ATTENTION: Cet e-mail provient d’une ad
Duncan Murdoch
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 ca
Yes, and were it not for 0 * NA == NA, you might skip evaluation of y if x
evaluates to zero. In Andre Gillibert's example:
1 | (alpha<-6)
there really is no reason to evaluate the assignment since (1 | any) is always
TRUE. Notwithstanding method dispatch, that is.
With general function call
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 ‘^
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 op
_
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
c: 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
t 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.
>
>
>
omputer 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: [
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 /
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 / Te
12 matches
Mail list logo
