Re: [R] Weird Behavior of mean
It is probably a bit late in most existing languages to change behaviors all over the code. Languages like C often allowed many kinds of shortcuts that happened to work because 0 was false and 1 and most other things were true. Similarly, pointers were used in a Boolean way as in the way they copied a null-terminated string between p and q with code like: while(*p++ = *q++); That is quite compact and could do horrible things if the region being copied was not null terminated. Strictly speaking, the equivalent code written in languages that removed the increment operator as well as access to pointers can either be much longer or be replaced by a function call so you don't see how it is done. What the above does is a bit subtle for beginners and you have to ask where the comparison is. Heck, the while loop has no body, and does not need one as the work is done as a side effect. The above takes the pointer called q that starts at the beginning of a string and retrieves what it is pointing at as a single character. It then moves the pointer forward one unit. It then looks at where p is pointing and copies what it saved there and finally increments p to point to the next available location. But, before that, the value it copied into p is either a letter like A or B, or various other ASCII sequences OR it is all zeroes as in NULL. The latter, viewed as an integer, is 0, or false. Anything else is true. So, the while loop continues copying and moving forward until it copies a null. Too bad it is so compact and cute when a better design might have been more like this: while((*p++ = *q++) != NULL); Or perhaps an explicit conversion from character to integer that is compared to zero. It seems sometimes that you have two ways to go. You can abandon an old language and make a new one in which many older styles become not allowed. Or, you create some linter program that at least warns you of possible bad code. In some ways, R was designed differently enough from C. But, it retain s some features that some people wonder about. As I mentioned earlier, Python brags about how flexible their truthy/falsy can be. True. -Original Message- From: R-help On Behalf Of Bert Gunter Sent: Friday, December 13, 2024 6:32 PM To: Ben Bolker Cc: [email protected] Subject: Re: [R] Weird Behavior of mean Sounds reasonable, but I leave it to wiser heads than me to decide. My only point is that whatever is done be accurately documented. At present, that does not appear to be the case. ... and yes, "accurate" documentation is not easy either. -- Bert On Fri, Dec 13, 2024 at 3:20 PM Ben Bolker wrote: > >Thanks, I had missed/forgotten the fact that there is also an > inconsistency between mean.default() and sd(). > >sd() calls var(), which evaluates if(na.rm) [i.e., it will try to > coerce `na.rm` to logical rather than testing isTRUE] > > IM(H?)O, it would be best for both mean.default() and sd() to use > if(isTRUE(as.logical(na.rm))) -- this converts NULL, numeric(0), zero > numeric values, etc. to FALSE, non-zero numeric values (including > complex numbers not equal to 0+0i) to TRUE ... fails on un-coerceable > stuff like functions, environments ... > > > ‘as.logical’ attempts to coerce its argument to be of logical > type. In numeric and complex vectors, zeros are ‘FALSE’ and > non-zero values are ‘TRUE’. For ‘factor’s, this uses the ‘levels’ > (labels). Like ‘as.vector’ it strips attributes including names. > Character strings ‘c("T", "TRUE", "True", "true")’ are regarded as > true, ‘c("F", "FALSE", "False", "false")’ as false, and all others > as ‘NA’. > > > On 2024-12-13 5:43 p.m., Bert Gunter wrote: > > Ivo, et al.: > > --IMHO only ... and with apologies for verbosity > > > > Defining, let alone enforcing, "consistent behavior" can be a > > philosophical conundrum: what one person deems "consistent" behavior > > for a function across different data structures and circumstances may > > not be the same as another's. While you may consider the issue clear > > here, a glance at the source code shows that may not necessarily be > > the case: mean() is an S3 generic, but sd() is derived from var() > > which is in turn based on cov(), for which NA handling is more > > complex. > > > > Anyway, for me, the only defensible standard should be is that the > > *documented* behavior for overloaded function names is that they > > should be accurately documented for each use case, whether or not the > > semantics conform to any particular paradigm of consistency. By this > > standard, I think mean() is behaving correctly, as its Help page says: > > > >
Re: [R] Weird Behavior of mean
Sounds reasonable, but I leave it to wiser heads than me to decide. My
only point is that whatever is done be accurately documented. At
present, that does not appear to be the case. ... and yes, "accurate"
documentation is not easy either.
-- Bert
On Fri, Dec 13, 2024 at 3:20 PM Ben Bolker wrote:
>
>Thanks, I had missed/forgotten the fact that there is also an
> inconsistency between mean.default() and sd().
>
>sd() calls var(), which evaluates if(na.rm) [i.e., it will try to
> coerce `na.rm` to logical rather than testing isTRUE]
>
> IM(H?)O, it would be best for both mean.default() and sd() to use
> if(isTRUE(as.logical(na.rm))) -- this converts NULL, numeric(0), zero
> numeric values, etc. to FALSE, non-zero numeric values (including
> complex numbers not equal to 0+0i) to TRUE ... fails on un-coerceable
> stuff like functions, environments ...
>
>
> ‘as.logical’ attempts to coerce its argument to be of logical
> type. In numeric and complex vectors, zeros are ‘FALSE’ and
> non-zero values are ‘TRUE’. For ‘factor’s, this uses the ‘levels’
> (labels). Like ‘as.vector’ it strips attributes including names.
> Character strings ‘c("T", "TRUE", "True", "true")’ are regarded as
> true, ‘c("F", "FALSE", "False", "false")’ as false, and all others
> as ‘NA’.
>
>
> On 2024-12-13 5:43 p.m., Bert Gunter wrote:
> > Ivo, et al.:
> > --IMHO only ... and with apologies for verbosity
> >
> > Defining, let alone enforcing, "consistent behavior" can be a
> > philosophical conundrum: what one person deems "consistent" behavior
> > for a function across different data structures and circumstances may
> > not be the same as another's. While you may consider the issue clear
> > here, a glance at the source code shows that may not necessarily be
> > the case: mean() is an S3 generic, but sd() is derived from var()
> > which is in turn based on cov(), for which NA handling is more
> > complex.
> >
> > Anyway, for me, the only defensible standard should be is that the
> > *documented* behavior for overloaded function names is that they
> > should be accurately documented for each use case, whether or not the
> > semantics conform to any particular paradigm of consistency. By this
> > standard, I think mean() is behaving correctly, as its Help page says:
> >
> > na.rm
> > a *logical* evaluating to TRUE or FALSE indicating whether NA values
> > should be stripped before the computation proceeds. [emphasis added]
> > Note: *not* a value that can be *coerced* to logical, but an actual
> > logical expression.
> >
> > But sd() is not, as its Help page says:
> > na.rm
> > logical. Should missing values be removed?
> > Note: So seemingly same as above, but as you noted, will work for
> > values that can be coerced to logical and not just actual logical
> > expressions.
> >
> > Cheers,
> > Bert
> >
> >
> >
> > On Fri, Dec 13, 2024 at 11:43 AM ivo welch wrote:
> >>
> >> isn't this still a little R buglet? I have overwritten T (even if my
> >> schuld [franconian], it is not that uncommon an error, because T is also a
> >> common abbreviation for the end of a time series; namespace pollution in R
> >> can be quite annoying, even though I understand that it is convenient in
> >> interactive mode). Nevertheless, I am passing into mean() a positive
> >> number for na.rm, and by definition, a positive number still means TRUE.
> >> besides, sd() and mean() should probably treat this similarly, anyway. I
> >> do see the argument that functions cannot be proof against redefinitions of
> >> all sorts of objects that they can use.more philosophically, some
> >> variables should not be overwritable, or at least trigger a warning.
> >>
> >> As Dante wrote, Abandon all hope ye who enter R.
> >>
> >> --
> >> Ivo Welch ([email protected])
> >>
> >> [[alternative HTML version deleted]]
> >>
> >> __
> >> [email protected] mailing list -- To UNSUBSCRIBE and more, see
> >> https://stat.ethz.ch/mailman/listinfo/r-help
> >> PLEASE do read the posting guide
> >> https://www.R-project.org/posting-guide.html
> >> and provide commented, minimal, self-contained, reproducible code.
> >
> > __
> > [email protected] mailing list -- To UNSUBSCRIBE and more, see
> > https://stat.ethz.ch/mailman/listinfo/r-help
> > PLEASE do read the posting guide
> > https://www.R-project.org/posting-guide.html
> > and provide commented, minimal, self-contained, reproducible code.
>
> --
> Dr. Benjamin Bolker
> Professor, Mathematics & Statistics and Biology, McMaster University
> Director, School of Computational Science and Engineering
> > E-mail is sent at my convenience; I don't expect replies outside of
> working hours.
>
> __
> [email protected] mailing list -- To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting gui
Re: [R] Weird Behavior of mean
My preference would be for anything that is defined as taking a
"logical" parameter to report an error if given anything else.
On Sat, 14 Dec 2024 at 12:21, Ben Bolker wrote:
>
>Thanks, I had missed/forgotten the fact that there is also an
> inconsistency between mean.default() and sd().
>
>sd() calls var(), which evaluates if(na.rm) [i.e., it will try to
> coerce `na.rm` to logical rather than testing isTRUE]
>
> IM(H?)O, it would be best for both mean.default() and sd() to use
> if(isTRUE(as.logical(na.rm))) -- this converts NULL, numeric(0), zero
> numeric values, etc. to FALSE, non-zero numeric values (including
> complex numbers not equal to 0+0i) to TRUE ... fails on un-coerceable
> stuff like functions, environments ...
>
>
> ‘as.logical’ attempts to coerce its argument to be of logical
> type. In numeric and complex vectors, zeros are ‘FALSE’ and
> non-zero values are ‘TRUE’. For ‘factor’s, this uses the ‘levels’
> (labels). Like ‘as.vector’ it strips attributes including names.
> Character strings ‘c("T", "TRUE", "True", "true")’ are regarded as
> true, ‘c("F", "FALSE", "False", "false")’ as false, and all others
> as ‘NA’.
>
>
> On 2024-12-13 5:43 p.m., Bert Gunter wrote:
> > Ivo, et al.:
> > --IMHO only ... and with apologies for verbosity
> >
> > Defining, let alone enforcing, "consistent behavior" can be a
> > philosophical conundrum: what one person deems "consistent" behavior
> > for a function across different data structures and circumstances may
> > not be the same as another's. While you may consider the issue clear
> > here, a glance at the source code shows that may not necessarily be
> > the case: mean() is an S3 generic, but sd() is derived from var()
> > which is in turn based on cov(), for which NA handling is more
> > complex.
> >
> > Anyway, for me, the only defensible standard should be is that the
> > *documented* behavior for overloaded function names is that they
> > should be accurately documented for each use case, whether or not the
> > semantics conform to any particular paradigm of consistency. By this
> > standard, I think mean() is behaving correctly, as its Help page says:
> >
> > na.rm
> > a *logical* evaluating to TRUE or FALSE indicating whether NA values
> > should be stripped before the computation proceeds. [emphasis added]
> > Note: *not* a value that can be *coerced* to logical, but an actual
> > logical expression.
> >
> > But sd() is not, as its Help page says:
> > na.rm
> > logical. Should missing values be removed?
> > Note: So seemingly same as above, but as you noted, will work for
> > values that can be coerced to logical and not just actual logical
> > expressions.
> >
> > Cheers,
> > Bert
> >
> >
> >
> > On Fri, Dec 13, 2024 at 11:43 AM ivo welch wrote:
> >>
> >> isn't this still a little R buglet? I have overwritten T (even if my
> >> schuld [franconian], it is not that uncommon an error, because T is also a
> >> common abbreviation for the end of a time series; namespace pollution in R
> >> can be quite annoying, even though I understand that it is convenient in
> >> interactive mode). Nevertheless, I am passing into mean() a positive
> >> number for na.rm, and by definition, a positive number still means TRUE.
> >> besides, sd() and mean() should probably treat this similarly, anyway. I
> >> do see the argument that functions cannot be proof against redefinitions of
> >> all sorts of objects that they can use.more philosophically, some
> >> variables should not be overwritable, or at least trigger a warning.
> >>
> >> As Dante wrote, Abandon all hope ye who enter R.
> >>
> >> --
> >> Ivo Welch ([email protected])
> >>
> >> [[alternative HTML version deleted]]
> >>
> >> __
> >> [email protected] mailing list -- To UNSUBSCRIBE and more, see
> >> https://stat.ethz.ch/mailman/listinfo/r-help
> >> PLEASE do read the posting guide
> >> https://www.R-project.org/posting-guide.html
> >> and provide commented, minimal, self-contained, reproducible code.
> >
> > __
> > [email protected] mailing list -- To UNSUBSCRIBE and more, see
> > https://stat.ethz.ch/mailman/listinfo/r-help
> > PLEASE do read the posting guide
> > https://www.R-project.org/posting-guide.html
> > and provide commented, minimal, self-contained, reproducible code.
>
> --
> Dr. Benjamin Bolker
> Professor, Mathematics & Statistics and Biology, McMaster University
> Director, School of Computational Science and Engineering
> > E-mail is sent at my convenience; I don't expect replies outside of
> working hours.
>
> __
> [email protected] mailing list -- To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide https://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.
_
Re: [R] Weird Behavior of mean
Thanks, I had missed/forgotten the fact that there is also an
inconsistency between mean.default() and sd().
sd() calls var(), which evaluates if(na.rm) [i.e., it will try to
coerce `na.rm` to logical rather than testing isTRUE]
IM(H?)O, it would be best for both mean.default() and sd() to use
if(isTRUE(as.logical(na.rm))) -- this converts NULL, numeric(0), zero
numeric values, etc. to FALSE, non-zero numeric values (including
complex numbers not equal to 0+0i) to TRUE ... fails on un-coerceable
stuff like functions, environments ...
‘as.logical’ attempts to coerce its argument to be of logical
type. In numeric and complex vectors, zeros are ‘FALSE’ and
non-zero values are ‘TRUE’. For ‘factor’s, this uses the ‘levels’
(labels). Like ‘as.vector’ it strips attributes including names.
Character strings ‘c("T", "TRUE", "True", "true")’ are regarded as
true, ‘c("F", "FALSE", "False", "false")’ as false, and all others
as ‘NA’.
On 2024-12-13 5:43 p.m., Bert Gunter wrote:
Ivo, et al.:
--IMHO only ... and with apologies for verbosity
Defining, let alone enforcing, "consistent behavior" can be a
philosophical conundrum: what one person deems "consistent" behavior
for a function across different data structures and circumstances may
not be the same as another's. While you may consider the issue clear
here, a glance at the source code shows that may not necessarily be
the case: mean() is an S3 generic, but sd() is derived from var()
which is in turn based on cov(), for which NA handling is more
complex.
Anyway, for me, the only defensible standard should be is that the
*documented* behavior for overloaded function names is that they
should be accurately documented for each use case, whether or not the
semantics conform to any particular paradigm of consistency. By this
standard, I think mean() is behaving correctly, as its Help page says:
na.rm
a *logical* evaluating to TRUE or FALSE indicating whether NA values
should be stripped before the computation proceeds. [emphasis added]
Note: *not* a value that can be *coerced* to logical, but an actual
logical expression.
But sd() is not, as its Help page says:
na.rm
logical. Should missing values be removed?
Note: So seemingly same as above, but as you noted, will work for
values that can be coerced to logical and not just actual logical
expressions.
Cheers,
Bert
On Fri, Dec 13, 2024 at 11:43 AM ivo welch wrote:
isn't this still a little R buglet? I have overwritten T (even if my
schuld [franconian], it is not that uncommon an error, because T is also a
common abbreviation for the end of a time series; namespace pollution in R
can be quite annoying, even though I understand that it is convenient in
interactive mode). Nevertheless, I am passing into mean() a positive
number for na.rm, and by definition, a positive number still means TRUE.
besides, sd() and mean() should probably treat this similarly, anyway. I
do see the argument that functions cannot be proof against redefinitions of
all sorts of objects that they can use.more philosophically, some
variables should not be overwritable, or at least trigger a warning.
As Dante wrote, Abandon all hope ye who enter R.
--
Ivo Welch ([email protected])
[[alternative HTML version deleted]]
__
[email protected] mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide https://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
__
[email protected] mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide https://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
> E-mail is sent at my convenience; I don't expect replies outside of
working hours.
__
[email protected] mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide https://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
Re: [R] Weird Behavior of mean
Ivo, et al.: --IMHO only ... and with apologies for verbosity Defining, let alone enforcing, "consistent behavior" can be a philosophical conundrum: what one person deems "consistent" behavior for a function across different data structures and circumstances may not be the same as another's. While you may consider the issue clear here, a glance at the source code shows that may not necessarily be the case: mean() is an S3 generic, but sd() is derived from var() which is in turn based on cov(), for which NA handling is more complex. Anyway, for me, the only defensible standard should be is that the *documented* behavior for overloaded function names is that they should be accurately documented for each use case, whether or not the semantics conform to any particular paradigm of consistency. By this standard, I think mean() is behaving correctly, as its Help page says: na.rm a *logical* evaluating to TRUE or FALSE indicating whether NA values should be stripped before the computation proceeds. [emphasis added] Note: *not* a value that can be *coerced* to logical, but an actual logical expression. But sd() is not, as its Help page says: na.rm logical. Should missing values be removed? Note: So seemingly same as above, but as you noted, will work for values that can be coerced to logical and not just actual logical expressions. Cheers, Bert On Fri, Dec 13, 2024 at 11:43 AM ivo welch wrote: > > isn't this still a little R buglet? I have overwritten T (even if my > schuld [franconian], it is not that uncommon an error, because T is also a > common abbreviation for the end of a time series; namespace pollution in R > can be quite annoying, even though I understand that it is convenient in > interactive mode). Nevertheless, I am passing into mean() a positive > number for na.rm, and by definition, a positive number still means TRUE. > besides, sd() and mean() should probably treat this similarly, anyway. I > do see the argument that functions cannot be proof against redefinitions of > all sorts of objects that they can use.more philosophically, some > variables should not be overwritable, or at least trigger a warning. > > As Dante wrote, Abandon all hope ye who enter R. > > -- > Ivo Welch ([email protected]) > > [[alternative HTML version deleted]] > > __ > [email protected] mailing list -- To UNSUBSCRIBE and more, see > https://stat.ethz.ch/mailman/listinfo/r-help > PLEASE do read the posting guide https://www.R-project.org/posting-guide.html > and provide commented, minimal, self-contained, reproducible code. __ [email protected] mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide https://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
Re: [R] Weird Behavior of mean
Ivo, To be a bit clearer, your problem was not with mean(0 but with any function which is expecting a Boolean setting of TRUE/FALSE and instead got a nonsense value of 20. This gets even weirder in languages which automagcally transform many other values to be considered true. Languages like C consider many non-zero values to be true, including 20 as an integer. A language like python accepts a very wide variety of things as truthy and the few that qualify as falsy are empty strings, and zero as well as other empties like an empty list, empty dictionary, empty set, empty range, or even a complex number with both a zero real and imaginary part. Some see such designs as saving lots of labor and others suggest it would be better and clearer programming practice to only accept explicit code that is guaranteed to produce a Boolean such as is_empty(list) or whatever. In this case, it is simply fairly poor design to alias T/F to TRUE/FALSE for convenience and then have people inadvertently reuse the variables and produce odd results. In languages which support constants that can be set and protected from change, fine. But in R, I never use T/F as the longer versions are clearer and less error prone. I don't blame you for being teed off at why things where not working when T was redefined. -Original Message- From: R-help On Behalf Of Ivo Welch Sent: Thursday, December 12, 2024 7:23 PM To: [email protected] Subject: [R] Weird Behavior of mean Is the following a strange behavior for `mean` vs. `sd` ? ``` $ R --vanilla. ## 4.4.2 > x=c(NA,1,2,3) > c( mean(x,na.rm=T), sd(x,na.rm=T) ) [1] 2 1 > T=20 ## bad idea for a parameter. T is also used for TRUE > c( mean(x,na.rm=T), sd(x,na.rm=T) ) [1] NA 1 > ``` This one was a baffler for me to track down for a few hours... __ [email protected] mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide https://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code. __ [email protected] mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide https://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
Re: [R] Weird Behavior of mean
This was documented in [1] forever ago. I would not miss it if a future version of R chose to remove those variables. [1] The R Inferno, 8.1.32 On December 13, 2024 11:21:13 AM PST, ivo welch wrote: >isn't this still a little R buglet? I have overwritten T (even if my >schuld [franconian], it is not that uncommon an error, because T is also a >common abbreviation for the end of a time series; namespace pollution in R >can be quite annoying, even though I understand that it is convenient in >interactive mode). Nevertheless, I am passing into mean() a positive >number for na.rm, and by definition, a positive number still means TRUE. > besides, sd() and mean() should probably treat this similarly, anyway. I >do see the argument that functions cannot be proof against redefinitions of >all sorts of objects that they can use.more philosophically, some >variables should not be overwritable, or at least trigger a warning. > >As Dante wrote, Abandon all hope ye who enter R. > >-- >Ivo Welch ([email protected]) > > [[alternative HTML version deleted]] > >__ >[email protected] mailing list -- To UNSUBSCRIBE and more, see >https://stat.ethz.ch/mailman/listinfo/r-help >PLEASE do read the posting guide https://www.R-project.org/posting-guide.html >and provide commented, minimal, self-contained, reproducible code. -- Sent from my phone. Please excuse my brevity. __ [email protected] mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide https://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
Re: [R] Weird Behavior of mean
This example is a little more subtle than that; the OP knows about name masking, but was expecting T to be coerced to logical, which would ordinarily be a reasonable expectation (IMO) ... On Fri, Dec 13, 2024 at 3:40 PM Jeff Newmiller via R-help wrote: > > This was documented in [1] forever ago. I would not miss it if a future > version of R chose to remove those variables. > > [1] The R Inferno, 8.1.32 > > On December 13, 2024 11:21:13 AM PST, ivo welch wrote: > >isn't this still a little R buglet? I have overwritten T (even if my > >schuld [franconian], it is not that uncommon an error, because T is also a > >common abbreviation for the end of a time series; namespace pollution in R > >can be quite annoying, even though I understand that it is convenient in > >interactive mode). Nevertheless, I am passing into mean() a positive > >number for na.rm, and by definition, a positive number still means TRUE. > > besides, sd() and mean() should probably treat this similarly, anyway. I > >do see the argument that functions cannot be proof against redefinitions of > >all sorts of objects that they can use.more philosophically, some > >variables should not be overwritable, or at least trigger a warning. > > > >As Dante wrote, Abandon all hope ye who enter R. > > > >-- > >Ivo Welch ([email protected]) > > > > [[alternative HTML version deleted]] > > > >__ > >[email protected] mailing list -- To UNSUBSCRIBE and more, see > >https://stat.ethz.ch/mailman/listinfo/r-help > >PLEASE do read the posting guide https://www.R-project.org/posting-guide.html > >and provide commented, minimal, self-contained, reproducible code. > > -- > Sent from my phone. Please excuse my brevity. > > __ > [email protected] mailing list -- To UNSUBSCRIBE and more, see > https://stat.ethz.ch/mailman/listinfo/r-help > PLEASE do read the posting guide https://www.R-project.org/posting-guide.html > and provide commented, minimal, self-contained, reproducible code. __ [email protected] mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide https://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
Re: [R] Weird Behavior of mean
isn't this still a little R buglet? I have overwritten T (even if my schuld [franconian], it is not that uncommon an error, because T is also a common abbreviation for the end of a time series; namespace pollution in R can be quite annoying, even though I understand that it is convenient in interactive mode). Nevertheless, I am passing into mean() a positive number for na.rm, and by definition, a positive number still means TRUE. besides, sd() and mean() should probably treat this similarly, anyway. I do see the argument that functions cannot be proof against redefinitions of all sorts of objects that they can use.more philosophically, some variables should not be overwritable, or at least trigger a warning. As Dante wrote, Abandon all hope ye who enter R. -- Ivo Welch ([email protected]) [[alternative HTML version deleted]] __ [email protected] mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide https://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
Re: [R] Weird Behavior of mean
> CALUM POLWART
> on Fri, 13 Dec 2024 08:56:15 + writes:
> I've not checked the code, but I think that result would
> happen if mean uses something like
> if (na.rm == TRUE) { # do something to remove the NA's }
> And as uses something like
> If (na.rm != FALSE) { # do something to remove the NA's }
> Or perhaps ever na.rm == T
Hey, "be careful you are insulting" (;-) R core code would *never* contain
stupid silly code
such as== TRUE
> fortunes :: fortune("TRUE.*TRUE", fixed=FALSE)
Ted Harding: But you can also do these with 'any' and 'all', e.g. any(v==TRUE).
Thomas Lumley: or any( (v==TRUE)==TRUE), or any( ((v==TRUE)==TRUE)==TRUE)...
Or, perhaps, any(v). Lewis Carroll wrote a nice piece
on this theme.
-- Ted Harding and Thomas Lumley (about implementing an 'or' of a logical
vector)
R-help (August 2004)
It uses if(isTRUE(na.rm))
and yes,
people using T for TRUE are "selber tschuld" (Swiss German for "your fault!")
Martin
> If you ever see posts from Bert on here with T and F, he
> is hard core thorough and uses full words for exactly this
> reason, someone can reassign F as True if they want and
> your code will melt!
> On Fri, 13 Dec 2024, 08:31 Ivo Welch,
> wrote:
>> Is the following a strange behavior for `mean` vs. `sd` ?
>>
>> ``` $ R --vanilla. ## 4.4.2 > x=c(NA,1,2,3) > c(
>> mean(x,na.rm=T), sd(x,na.rm=T) ) [1] 2 1 > T=20 ## bad
>> idea for a parameter. T is also used for TRUE > c(
>> mean(x,na.rm=T), sd(x,na.rm=T) ) [1] NA 1
>> >
>> ```
>>
>> This one was a baffler for me to track down for a few
>> hours...
>>
>> __
>> [email protected] mailing list -- To UNSUBSCRIBE and
>> more, see https://stat.ethz.ch/mailman/listinfo/r-help
>> PLEASE do read the posting guide
>> https://www.R-project.org/posting-guide.html and provide
>> commented, minimal, self-contained, reproducible code.
>>
> [[alternative HTML version deleted]]
> __
> [email protected] mailing list -- To UNSUBSCRIBE and
> more, see https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide
> https://www.R-project.org/posting-guide.html and provide
> commented, minimal, self-contained, reproducible code.
__
[email protected] mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide https://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
Re: [R] Weird Behavior of mean
I've not checked the code, but I think that result would happen if mean
uses something like
if (na.rm == TRUE) {
# do something to remove the NA's
}
And as uses something like
If (na.rm != FALSE) {
# do something to remove the NA's
}
Or perhaps ever na.rm == T
If you ever see posts from Bert on here with T and F, he is hard core
thorough and uses full words for exactly this reason, someone can reassign
F as True if they want and your code will melt!
On Fri, 13 Dec 2024, 08:31 Ivo Welch, wrote:
> Is the following a strange behavior for `mean` vs. `sd` ?
>
> ```
> $ R --vanilla. ## 4.4.2
> > x=c(NA,1,2,3)
> > c( mean(x,na.rm=T), sd(x,na.rm=T) )
> [1] 2 1
> > T=20 ## bad idea for a parameter. T is also used for TRUE
> > c( mean(x,na.rm=T), sd(x,na.rm=T) )
> [1] NA 1
> >
> ```
>
> This one was a baffler for me to track down for a few hours...
>
> __
> [email protected] mailing list -- To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide
> https://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.
>
[[alternative HTML version deleted]]
__
[email protected] mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide https://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
[R] Weird Behavior of mean
Is the following a strange behavior for `mean` vs. `sd` ? ``` $ R --vanilla. ## 4.4.2 > x=c(NA,1,2,3) > c( mean(x,na.rm=T), sd(x,na.rm=T) ) [1] 2 1 > T=20 ## bad idea for a parameter. T is also used for TRUE > c( mean(x,na.rm=T), sd(x,na.rm=T) ) [1] NA 1 > ``` This one was a baffler for me to track down for a few hours... __ [email protected] mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide https://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
