Re: [R] error when trying to install {rgdal} on Windows

[Martin Maechler]

[I have fixed your subject:  "text" is really on of the most
 unuseful subjects we've ever seen on this list ... ]

> Farzad Ghooshi on Sun, 28 Apr 2024 12:17:34 +0330 writes:

> Hi dear friend I use rgdal package for shape files.
> When installing the package, it gives me the following
> error, a picture of the error is attached.  What command
> should I run to fix this error?

Did you install the Rtools, in your case Rtools43

(If you'd use a current version of R, R 4.4.0  you'd needed
Rtools44 to install packages from source on Windows.

Note that we *DO NOT WANT* screen shot images, but rather simple
cut'n'paste plain text in this mailing list.

Best regards,
Martin

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] x[0]: Can '0' be made an allowed index in R?

[Martin Maechler]

> Ben Bolker 
> on Sun, 21 Apr 2024 10:23:50 -0400 writes:

> Also https://cran.r-project.org/package=Oarray (which is older and 
> hence possibly more stable)

also maintained and written by a careful and really good person.
I do recommend  Oarray  as well.

Martin

BB> On 2024-04-21 3:55 a.m., Hans W wrote:
>> As we all know, in R indices for vectors start with 1, i.e, x[0] is not a
>> correct expression. Some algorithms, e.g. in graph theory or 
combinatorics,
>> are much easier to formulate and code if 0 is an allowed index pointing 
to
>> the first element of the vector.
>> 
>> Some programming languages, for instance Julia (where the index for 
normal
>> vectors also starts with 1), provide libraries/packages that allow the 
user
>> to define an index range for its vectors, say 0:9 or 10:20 or even 
negative
>> indices.
>> 
>> Of course, this notation would only be feasible for certain specially
>> defined vectors. Is there a library that provides this functionality?
>> Or is there a simple trick to do this in R? The expression 'x[0]' must
>> be possible, does this mean the syntax of R has to be twisted somehow?
>> 
>> Thanks, Hans W.

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] Building Packages.

[Martin Maechler]

> Ben Bolker 
> on Wed, 20 Mar 2024 13:25:33 -0400 writes:

>Hmm, looks platform-specific.  Under Linux both RStudio
> and external R console return

> a0b52513622c41c11e3ef57c7a485767

> for digest::digest(install.packages)

Well, platform-specific maybe, notably probably the *RStudio*-version
matters (for once).

One one of our public compute-machines running Linux Fedora 38
  (I don't have RStudio installed on my desktop as I loathe it
   badly to see RStudio start up when I click at an *R script in
   the OS gui file browser ... !:!P:!)(*&))
 
I definitely see

> R.version.string
[1] "R version 4.3.3 Patched (2024-02-29 r86162)"
> RStudio.Version()$version
[1] ‘2023.12.1.402’
> install.packages
function (...) 
.rs.callAs(name, hook, original, ...)

> 

No need for any hashes to see that install.packages is not the
one from R.

---
Concluding from your, Ben's, finding I'd guess that Posit
finally decided to move away from this very unfriendly idea of
sneakily replacing a base R function ?

That would actually give raise to some applause..

Martin



> On 2024-03-20 1:20 p.m., Duncan Murdoch wrote:
>> On 20/03/2024 1:07 p.m., Duncan Murdoch wrote:
>>> On 20/03/2024 12:37 p.m., Ben Bolker wrote:
  Ivan, can you give more detail on this? I've heard
 this issue mentioned, but when I open RStudio and run
 find("install.packages") it returns
 "utils::install.packages", and running dump() from
 within RStudio console and from an external "R
 --vanilla" gives identical results.
 
  I thought at one point this might only refer to
 the GUI package-installation interface, but you seem to
 be saying it's the install.packages() function as well.
 
  Running an up-to-date RStudio on Linux, FWIW --
 maybe weirdness only happens on other OSs?
>>> 
>>> On MacOS, I see this:
>>> 
>>>   > install.packages function (...)  .rs.callAs(name,
>>> hook, original, ...)  
>>> 
>>> I get the same results as you from find().  I'm not sure
>>> what RStudio is doing to give a different value for the
>>> function than what find() sees.
>> 
>> Turns out that RStudio replaces the install.packages
>> object in the utils package.
>> 
>> Duncan Murdoch
>> 
>>> 
>>> Duncan Murdoch
>>> 
 
   Ben Bolker
 
 On 2024-03-20 12:13 p.m., Ivan Krylov via R-help wrote:
> В Wed, 20 Mar 2024 16:02:27 + Jorgen Harmse via
> R-help  пишет:
> 
>>> install.packages(tar,type='source',repos=NULL)
>> 
> Error in library(jhBase) : there is no package called
>> ‘jhBase’
>> 
> Execution halted
>> 
> Warning in install.packages(tar, type = "source", repos =
>> NULL) :
>> 
>  installation of package
>
>> 
‘/Users/jharmse/Library/CloudStorage/OneDrive-RokuInc/jhBase_1.0.1.tar.gz’
> had non-zero exit status
> 
> Using RStudio? It happens to override install.packages
> with a function that doesn't quite handle file
> paths. Try utils::install.packages(tar, type =
> "source", repos = NULL).
> 
 
 __
 R-help@r-project.org mailing list -- To UNSUBSCRIBE and
 more, see https://stat.ethz.ch/mailman/listinfo/r-help
 PLEASE do read the posting guide
 http://www.R-project.org/posting-guide.html and provide
 commented, minimal, self-contained, reproducible code.
>>> 
>> 

> __
> R-help@r-project.org mailing list -- To UNSUBSCRIBE and
> more, see https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide
> http://www.R-project.org/posting-guide.html and provide
> commented, minimal, self-contained, reproducible code.

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] Building Packages.

[Martin Maechler]

> "Duncan Murdoch on Wed, 20 Mar 2024 13:20:12 -0400 writes:

> On 20/03/2024 1:07 p.m., Duncan Murdoch wrote:
>> On 20/03/2024 12:37 p.m., Ben Bolker wrote:

>>> Ivan, can you give more detail on this? I've heard this
>>> issue mentioned, but when I open RStudio and run
>>> find("install.packages") it returns
>>> "utils::install.packages", and running dump() from
>>> within RStudio console and from an external "R
>>> --vanilla" gives identical results.
>>> 
>>> I thought at one point this might only refer to the GUI
>>> package-installation interface, but you seem to be
>>> saying it's the install.packages() function as well.
>>> 
>>> Running an up-to-date RStudio on Linux, FWIW -- maybe
>>> weirdness only happens on other OSs?
>> 
>> On MacOS, I see this:
>> 
>> > install.packages function (...)  .rs.callAs(name, hook,
>> original, ...)  
>> 
>> I get the same results as you from find().  I'm not sure
>> what RStudio is doing to give a different value for the
>> function than what find() sees.

> Turns out that RStudio replaces the install.packages
> object in the utils package.

> Duncan Murdoch

Yes, and this has been the case for several years now, and I
have mentioned this several times, too  (though some of it
possibly not in a public R-* mailing list).

And yes, that they modify the package environment
  as.environment("package:utils")
but leave the
  namespace  asNamespace("utils")
unchanged, makes it harder to see what's
going on (but also has less severe consequences; if they kept to
the otherwise universal *rule* that the namespace and package must have the 
same objects
apart from those only in the namespace,
people would not even have access to R's true install.packages()
but only see the RStudio fake^Hsubstitute..

We are still not happy with their decision. Also
help(install.packages) goes to R's documentation of R's
install.packages, so there's even more misleading of useRs.

Martin

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [ESS] Error installing on Mac

[Martin Maechler via ESS-help]

> Liz Hare via ESS-help 
> on Thu, 7 Mar 2024 09:49:12 -0500 writes:
> Liz Hare via ESS-help 
> on Thu, 7 Mar 2024 09:49:12 -0500 writes:

> Hi all,

> I'm updating ESS by installing from source. I uncommented the MacOS 
related lines from makeconfig, but I get this error:

I think you mean  ess/Makeconf, right?

In there, indeed it uses things like

PREFIX=/Applications/Emacs.app/Contents/Resources
EMACS=/Applications/Emacs.app/Contents/MacOS/Emacs

>> make
> /bin/sh: /Applications/Emacs.app/Contents/MacOS/Emacs: No such file or 
directory

and obviously your Emacs is not at the above 'EMACS=' location.
I have no make at disposal, but maybe a Mac user can help:

Where is your Emacs installing into?

> * VERSIONS **

> ESS 24.01.1
> ESSR 1.8
> sed: 1: "lisp/ess-custom.el": extra characters at the end of l command
> make: *** [version] Error 1

> This error appears to be related to the fact that the BSD sed on Mac is 
different than the GNU sed.

hmm.. our Makefile only uses pretty basic  'sed' calls; hence I'm not sure.
Also strange that the error messages end with "end of l command"
-- in the few sed uses in our Makefile/Makeconf  I only see
versions of  sed s/.../  or  sed "s| ...|p"  i.e., not  "l command"..

> I looked for a similar issue on GitHub but didn't find anything.

Would installing the whole bundle   Emacs+ESS+{more}
from Vincent Goulet's website, mentioned
at   https://ess.r-project.org/  i.e.
 https://ess.r-project.org/index.php?Section=download

be an option: For a few years now  it's been
as   https://emacs-modified.gitlab.io/  then for macOS
at   https://emacs-modified.gitlab.io/macos/

however that currently is not using the latest ESS version (but
something quite close to it).

Still agree that would be a workaround,  and we should try to
ensure that macOS users can install ESS from the sources.

I have started to recommend installing the 'ess' package


> Thanks,
> Liz
> __
> ESS-help@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/ess-help

__
ESS-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help

Re: [R] converting MATLAB -> R | element-wise operation

[Martin Maechler]

> Berwin A Turlach 
> on Wed, 28 Feb 2024 17:42:27 +0800 writes:

> On Tue, 27 Feb 2024 13:51:25 -0800 Jeff Newmiller via
> R-help  wrote:

>> The fundamental data type in Matlab is a matrix... they
>> don't have vectors, they have Nx1 matrices and 1xM
>> matrices.

> Also known as column vectors and row vectors.  :)
 
>> Vectors don't have any concept of "row" vs. "column".

> They do in (numerical) linear algebra.  And MATLAB was
> written by numerical analysts for numerical analysts. :-)
> So they distinguish between row and column vectors.

> GAUSS also distinguishes between row and column vectors.

There are *vectors* and they belong to a vector space and that's it.
(and yes, arrays of a given rank and dimensions also are
 elements of a vector space, and hence matrices are, and then
 indeed, a 3x1 matrix and a 1x3 matrix are *not* members of the
 same vector space -- even though the two vector spaces are
 isomorphic to each other)

The matlab induced --> applied linear algebra / math
"column- and row-vectors"  have been convenient because then
everything is a matrix (or scalar), and that fits well with a
product called "matlab" which is short for "matrix lab(oratory)".
BUT they are  mathematically confusing and therefore in my view
very undesirable terminology.

I'm very very strongly with Jeff that "the only" consistent
language would be to call them 1-row matrix and 1-column matrix,
because that's what they are, well defined and perfect within 
the well defined math realm of linear algebra.

Yes, matrix-vector calculus , scalar products, bilinear forms, ...
can be generalized in such ways that 1-row matrices and 1-column
matrices can be treated equivalently to vectors and vice versa
.. and that is sometimes convenient. 

Still, the "column-vector"  and "row-vector"  terms have
lead to much confusion in my view,
because really  Nx1  or  1xM  are dimensions of matrices and
*not* of any vectors  ..


> R (and S) does not distinguish between row and column
> vectors, and is in this aspect quite unique among the
> groups of vector-oriented programming languages (AFAICT).

I agree. And that's good -- because "vectors are vectors" aka
"a rank-1 array is a rank-1 array is a rank-1 array" (Richard O'Keefe)

> But treating every vector as a column vector, together
> with the recycling rule, allows for the easy coding of the
> matrix/vector calculations that one (mostly) comes across
> in statistical computing.  For the rare occasion when this
> is not true the sweep() command is provided, typically
> remembered once one was bitten by the lack of distinction
> between row and column vectors. :)

> Cheers,
>   Berwin

Martin

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] Packages sometimes don't update, but no error or warning is thrown

[Martin Maechler]

> Berwin A Turlach 
> on Wed, 14 Feb 2024 11:47:41 +0800 writes:
> Berwin A Turlach 
> on Wed, 14 Feb 2024 11:47:41 +0800 writes:

> G'day Philipp,

> On Tue, 13 Feb 2024 09:59:17 +0100 gernophil--- via R-help
>  wrote:

>> this question is related to this
>> (https://community.rstudio.com/t/packages-are-not-updating/166214/3),
>> [...]

>> To sum it up: If I am updating packages (be it via
>> Bioconductor or CRAN) some packages simply don’t update,
>> [...]

>> I would expect any kind of message that the package will
>> not be updated, since no newer binary is available or a
>> prompt, if I want to compile from source.

> RStudio is doing its own thing for some task, including
> 'install.packages()' (and for some reasons, at least on
> the platforms on which I use RStudio, RStudio calls
> 'install.packages()' and not 'update.packages()' when an
> update is requested via the GUI). See:

RStudio> install.packages
> function (...)  .rs.callAs(name, hook, original, ...)
> 

> compared to:

R> install.packages
> function (pkgs, lib, repos = getOption("repos"),
> contriburl = contrib.url(repos, type), method, available =
> NULL, destdir = NULL, dependencies = NA, type =
> getOption("pkgType"), configure.args =
> getOption("configure.args"), configure.vars =
> getOption("configure.vars"), clean = FALSE, Ncpus =
> getOption("Ncpus", 1L), verbose = getOption("verbose"),
> libs_only = FALSE, INSTALL_opts, quiet = FALSE,
> keep_outputs = FALSE, ...)  { [...]


> So if you use Install/Update in the Packages tab of
> RStudio and do not experience the behaviour you are
> expecting, it is something that you need to discuss with
> Posit, not with R. :)

>> However, the only message I get is: ``` trying URL
>> ''

> The package name has the version number encoded in it, so
> theoretical you should be able to tell at this point
> whether the package that is downloaded is the version that
> is already installed, hence no update will happen.

> Best wishes,

>   Berwin


Yes, thank's a lot, Berwin.

Indeed I've raised the fact that RStudio
hides R's own install.packages() from the user  and uses its
own, undocumented one ... this has been the case for quite a few years.
I found out during teaching --- one of the few times, I use
RStudio to use R... in another case where RStudio's
install.packages() behaved differently than R's.

I'm pretty sure this is reason for quite a bit of confusion...

Martin

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] Use of geometric mean .. in good data analysis

[Martin Maechler]

> Rich Shepard 
> on Mon, 22 Jan 2024 07:45:31 -0800 (PST) writes:

> A statistical question, not specific to R.  I'm asking for
> a pointer for a source of definitive descriptions of what
> types of data are best summarized by the arithmetic,
> geometric, and harmonic means.

In spite of  off-topic:

I think it is a good question, not really only about
geo-chemistry, but about statistics in applied sciences (and
engineering for that matter).

Something I sure good applied statisticians in the 1980's and
1990's would all know the answer of :

To use the geometric mean instead of the arithmetic mean
is basically  *equivalent* to  first log-transform the data
and then work with that transformed data:
Not just for computing average, but for more relevant modelling,
inference, etc.

John W Tukey (and several other of the grands of the time)
had the log transform among the  "First aid transformations":

If the data for a continuous variable must all be positive it is
also typically the case that the distribution is considerably
skewed to the right.
In such a case behave as a good human who sees another human in
health distress: apply First Aid -- do the things you learned to
do quickly without too much thought, because things must happen
fast ---to hopefully save the other's life.

Here: Do log transform all such variables with further ado,
and only afterwards start your (exploratory and more) data analysis.

Now,  mean(log(y)) = log(geometricmean(y)), 
where mean() is the arithmetic mean as in R
{mathematically; on the computer you need all.equal(), not '==' !!}

I.e., according to Tukey and all the other experienced applied
statisticians of the past, the geometric mean is the "best thing" 
to do for such positive right-skewed data   in the same sense
that the log-transform is the best "a priori" transformation for
such data -- with the one advantage even that you need to fiddle
with zeroes when log-transforming, whereas the geometric mean
works already for zeroes.

Martin


> As an aquatic ecologist I see regulators apply the
> geometric mean to geochemical concentrations rather than
> using the arithmetic mean. I want to know whether the
> geometric mean of a set of chemical concentrations (e.g.,
> in mg/L) is an appropriate representation of the expected
> value. If not, I want to explain this to non-technical
> decision-makers; if so, I want to understand why my
> assumption is wrong.

> TIA,

> Rich

> __
> R-help@r-project.org mailing list -- To UNSUBSCRIBE and
> more, see https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide
> http://www.R-project.org/posting-guide.html and provide
> commented, minimal, self-contained, reproducible code.

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [ESS] Following up, success! [was RE: [R-win] Difficulty installing R packages under Windows 11 / Cygwin]

[Martin Maechler via ESS-help]

> Robert Lerche via ESS-help 
> on Wed, 3 Jan 2024 22:58:00 + writes:

> Yes and thanks for responding.  That is I think exactly what's needed and 
I have taken a shot at implementing it.  [I'm glad my previous attached patch 
got filtered, I was a bit careless.]  Here's a summary of what I've done:
> ess-custom.el: extract prefix using cygpath, set to nil if error (i.e., 
no cygpath command indicates not in Cygwin)

Just to be sure: So all these changes in your patch are
guaranteed to *not* change the path / file-paths  anywhere
*unless* our emacs & ESS run on an Windows Cygwin  platform?

Martin

__
ESS-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help

Re: [R] Convert character date time to R date-time variable.

[Martin Maechler]

> Ebert,Timothy Aaron 
> on Thu, 7 Dec 2023 16:29:09 + writes:

> Look at the lubridate package in R.  Regards, Tim

Absolutely *un*needed here !! - as others mention in this
thread.

Very simple with base R:

  > strptime("2020-09-17_00:00:00", format = "%Y-%m-%d_%H:%M:%S")
  [1] "2020-09-17 CEST"
  > 

(in my time zone).
 
> -Original Message- From: R-help
>  On Behalf Of Sorkin, John
> Sent: Thursday, December 7, 2023 11:22 AM To:
> r-help@r-project.org (r-help@r-project.org)
>  Subject: [R] Convert character date
> time to R date-time variable.

> [External Email]

> Colleagues,

> I have a matrix of character data that represents date and
> time. The format of each element of the matrix is
> "2020-09-17_00:00:00" How can I convert the elements into
> a valid R date-time constant?

> Thank you, John



> John David Sorkin M.D., Ph.D.  Professor of Medicine,
> University of Maryland School of Medicine;

> Associate Director for Biostatistics and Informatics,
> Baltimore VA Medical Center Geriatrics Research,
> Education, and Clinical Center;

> PI Biostatistics and Informatics Core, University of
> Maryland School of Medicine Claude D. Pepper Older
> Americans Independence Center;

> Senior Statistician University of Maryland Center for
> Vascular Research;

> Division of Gerontology and Paliative Care, 10 North
> Greene Street GRECC (BT/18/GR) Baltimore, MD 21201-1524
> Cell phone 443-418-5382



> __
> R-help@r-project.org mailing list -- To UNSUBSCRIBE and
> more, see https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide
> http://www.r-project.org/posting-guide.html and provide
> commented, minimal, self-contained, reproducible code.

> __
> R-help@r-project.org mailing list -- To UNSUBSCRIBE and
> more, see https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide
> http://www.R-project.org/posting-guide.html and provide
> commented, minimal, self-contained, reproducible code.

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [ESS] [External] [R-win] Difficulty installing R packages under Windows 11 / Cygwin

[Martin Maechler via ESS-help]

As R core and ESS core  I still have never tried to install ESS under Windows.
Just last week installed not only R for Windows (binary from CRAN) +
Rtools43 (by Tomas, from CRAN) and was able to install my Rmpfr
package (C code + external lib) *from source* -- again
thanks to Tomas Kalibera's  excellent  Rtools.
However, for Emacs & ESS,  I have always used the Windows port of
Emacs+ESS+Auctex+..  by Vincent Goulet (Canada)
which now resides here  https://emacs-modified.gitlab.io/
For me it's absolutely crucial and nicely working, also allowing
M-x R-[Tab]   get a list of my dozen different R versions all
installed in our (Terminal Server) Windows version.

Martin

On Sat, Dec 2, 2023 at 9:42 PM Richard M. Heiberger via ESS-help
 wrote:
>
> my initial reaction is that you are trying to hard.  I haven't paid serious 
> attention to Windows since
> I switched to Mac about 10 years ago.
>
> What I recall is that all the unix utilities (sh, awk, grep, etc) that you 
> need are included in the
> Rtools collection.  Indeed they are exactly the cygwin utilities.  I know 
> that I stopped bothering
> with cygwin itself once I meade that realization.  Then, since all the unix 
> functions are distributed by
> R, you know that they are fully compatible.  I used the CRAN distibuted 
> Windows binary for R.
>
> Rich
>
> > On Dec 2, 2023, at 12:59, Sparapani, Rodney via ESS-help 
> >  wrote:
> >
> > Hi Robert:
> >
> > Would they allow dual-booting?  I’m not saying that you can’t get ESS
> > to work under Cygwin.  On the contrary, it did work at one time so
> > it certainly can be done.  However, that is not currently supported
> > so you are on your own.  But, perhaps there are others in the same
> > straight-jacket here on ess-help that might be willing to help?
> > Please speak up if so!
> >
> > In regards to WSL, that came out after I permanently switched
> > to macOS.  But, I think it is worth a try too.  Since you will be
> > running pure Linux binaries, then it might work out of the box.
> > And maybe there are more people here interested in WSL than
> > Cygwin.  Also, the more recent WSL 2 (released in 2019) sounds
> > like it is more compatible than WSL 1 (released in 2016).
> >
> > --
> > Rodney Sparapani, Associate Professor of Biostatistics, He/Him/His
> > Vice President, Wisconsin Chapter of the American Statistical Association
> > Institute for Health and Equity, Division of Biostatistics
> > Medical College of Wisconsin, Milwaukee Campus
> >
> > From: Robert Lerche 
> > Date: Saturday, December 2, 2023 at 11:40 AM
> > To: Sparapani, Rodney , Tomas Kalibera 
> > 
> > Subject: RE: [R-win] Difficulty installing R packages under Windows 11 / 
> > Cygwin
> > ATTENTION: This email originated from a sender outside of MCW. Use caution 
> > when clicking on links or opening attachments.
> > 
> > Thanks for your thoughtful reply.  Alas, I am using a company-provided 
> > laptop.  I would much prefer to run Linux as I do on my personal system but 
> > that is not in the cards.  I have plenty of access to Linux servers and of 
> > course I can run things there but it’s a bit inconvenient.
> >
> > I thought about using WSL (Windows Subsystem for Linux). I have some 
> > experience with early versions of that [which leads me to avoid it  ].
> >
> > It is my fate to cope with legacy junk on projects that were late when I 
> > joined. Ah well it’s a living.
> >
> > From: Sparapani, Rodney 
> > Sent: Saturday, December 2, 2023 9:28 AM
> > To: Robert Lerche ; Tomas Kalibera 
> > ; ess-help (ess-help@r-project.org) 
> > 
> > Subject: Re: [R-win] Difficulty installing R packages under Windows 11 / 
> > Cygwin
> >
> >
> > [EXTERNAL MESSAGE] Be mindful when clicking links or attachments
> > Hi Robert:
> >
> > There was a time when we supported ESS under Cygwin.
> > In other words, run elisp code assuming UNIX/Linux rather
> > than Windows even though Windows is the OS.  However,
> > that was a long time ago: at least 10 years since I last tried it.
> > Cygwin has largely fallen out of fashion since you can now so
> > easily install Ubuntu on typical hardware: something that
> > has markedly improved since 2013.  Therefore, I would not
> > expect Cygwin support to work out of the box since there
> > has been no recent testing.  Also, Windows is not very
> > popular with R users since there is no forking support
> > for the parallel package.  So switching to Linux is well
> > worth it.  I used to run Windows inside VirtualBox when
> > I needed to do PC stuff like Office and iTunes
> > (before switching to macOS and never looking back ;o)
> >
> > --
> > Rodney Sparapani, Associate Professor of Biostatistics, He/Him/His
> > Vice President, Wisconsin Chapter of the American Statistical Association
> > Institute for Health and Equity, Division of Biostatistics
> > Medical College of Wisconsin, Milwaukee Campus
> >
> > From: ESS-bugs 
> > mailto:mailman-boun...@stat.ethz.ch>> on 
> > behalf of Robert 

Re: [ESS] How can one tell rlang not to mess up R session in ESS ?

[Martin Maechler via ESS-help]

> Dirk Eddelbuettel via ESS-help 
> on Mon, 13 Nov 2023 10:00:26 -0600 writes:

> Casual searching at the rlang repo doesn't reveal anything so pardon me 
for
> asking here but what is a simple way to tell rlang to NOT do fancy pants
> color error backtraces?  At least under the theme I use ("nord", for 
Emacs)
> it basically nixes readability by leaving a 'dark on dark' default.

I've noticed the same ... and was very frustrated.
IIRC, I needed to restart R to get back to a usable *R* buffer.

Martin

> Thanks in advance for any pointers.

> Dirk

> -- 
> dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

__
ESS-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help

Re: [R] Dependency errors for package pracma

[Martin Maechler]

> Hans W 
> on Thu, 9 Nov 2023 12:22:52 +0100 writes:

> What really interests me:
> With all those strict checking procedures, how is it possible that the
> new 'Matrix' version got accepted on CRAN?

There > 2000 reverse dependencies for Matrix.

We have had some (in themselves small) inconsistency fixes some
of which make Matrix 'Matrices' more similar to base R matrices.

In any case we pre-tested all reverse dependencies and found 7 or 8
out of 22'000 CRAN+Bioc packages which needed to adapt to the
Matrix changes.  The package maintainer of the 7 packages were
told in advance that they should (very slightly) adapt their
code (sometimes only there *tests*) and mostly were even handed
out a *patch* to apply to the respective package for updating it.
One or two of these packages were updated on CRAN in time, the
other ~ 5 were not... this is  ~ 1 in 4000 packages.  So the
decision was made to release (from us pkg maintainers) and to
accept (from the CRAN team).

Also, to be fair, in our tests we did miss one package,
but then quickly told the maintainer, again providing him with a
complete patch file to update the package (working both with old
and new Matrix).

> I think this happened twice to me before, and it takes a lot of time
> to check package dependencies that turn out to be not dependent --
> more time than checking dependencies that are real.

With Matrix there is some extra effort, because it also exports
a C API (so other packages can have  'LinkingTo: Matrix') and
this time it was necessary for CRAN to additionally re-install
those linking-reverse-dependent packages .. on all platforms, in
time, etc. a somewhat brittle task all with a CRAN check system
that simultaneously runs other package installations and checks.

I think you were slightly unlucky in the timing of your package
checks/submission.

Best regards,
Martin

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] Concordance and Kendall's tau in copula

[Martin Maechler]

>>>>> Steven Yen 
>>>>> on Tue, 7 Nov 2023 09:09:33 +0800 writes:

> Dear
> I estimate a sample selection model using the Clayton copula and Burr 
> and Gaussian marginal. I need to derive ther Kendall'sw tau from the 
> concordance coefficient by integration. I came across a way to do that 
> in R long time ago but cannot find it again. Can somewone tell me what 
> to read and what to use? Thank you.

> Steven Yen


I think you can estimate your model relatively easily using our
package {copula}  and the function  fitMvdc()

   https://search.r-project.org/CRAN/refmans/copula/html/fitMvdc.html

MVDC := Multivariate Variate Distribution {built from} Copula

To solve the question you asked --- but would not need to answer if
using fitMvdc(),
you can use  e.g.,

> iTau(claytonCopula(), tau = 1.4)
[1] -7

or look up the formulas for tau() or its inverse 'iTau':

  > copClayton@tau
  function (theta) 
  {
  theta/(theta + 2)
  }

  > copClayton@iTau
  function (tau) 
  {
  2 * tau/(1 - tau)
  }

  > 

Best regards,
Martin

{and yes, consider getting our 'useR! Springer series book, as
 it's the only "real" book, I've been a coauthor.. 
https://copula.r-forge.r-project.org/book/ }

--
Martin Maechler
ETH Zurich  and  R Core team

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] strptime with +03:00 zone designator

[Martin Maechler]

> Richard O'Keefe 
> on Mon, 6 Nov 2023 18:37:34 +1300 writes:

> Thanks to all who replied.  On Mon, 6 Nov 2023 at 18:37,
> Richard O'Keefe  wrote:

>> OK, so the consensus is (1) One cannot make strptime
>> accept ISO8601-compliant zone designators (2) The
>> lubridate package can (3) Or one can hack away with
>> regex.  Lubridate it is, then.
>> 
>> But I do regard strptime's inability to process
>> ISO8601-compliant zone designators as a bug.

Did you try to submit it to R's bugzilla?

It's the first time I hear of this "Feature" of the ISO
standard, but then I'm not at all a timezone, and even less an
ISO standard expert.

Best,
Martin


>> On Mon, 6 Nov 2023 at 13:18, jim holtman
>>  wrote:
>> 
>>> try using 'lubridate'
>>> 
>>> > library(lubridate)Attaching package: ‘lubridate’
>>> 
>>> The following objects are masked from ‘package:base’:
>>> 
>>> date, intersect, setdiff, union > x <-
>>> "2017-02-28T13:35:00+03:00"> ymd_hms(x)[1] "2017-02-28
>>> 10:35:00 UTC"
>>> 
>>> >
>>> 
>>> 
>>> 
>>> Thanks
>>> 
>>> Jim Holtman *Data Munger Guru*
>>> 
>>> 
>>> *What is the problem that you are trying to solve?Tell
>>> me what you want to do, not how you want to do it.*
>>> 
>>> 
>>> On Sun, Nov 5, 2023 at 3:45 PM Richard O'Keefe
>>>  wrote:
>>> 
 I have some data that includes timestamps like this:
 2017-02-28T13:35:00+03:00 The documentation for
 strptime says that %z expects an offset like 0300.  I
 don't see any way in the documentation to get it to
 accept +hh:mm with a colon separator, and everything I
 tried gave me NA as the answer.
 
 Section 4.2.5.1 of ISO 8601:2004(E) allows both the
 absence of colons in +hh[mm] (basic format) and the
 presence of colons in +hh:mm (extended format).  Again
 in section 4.2.5.2 where a zone offset is combined with
 a time of day: if you have hh:mm:ss you are using
 extended format and the offset MUST have a colon; if
 you have hhmmss you are using basic format and the
 offset MUST NOT have a colon.  And again in section
 4.3.2 (complete representations of date and time of
 day).  If you use hyphens and colons in the date and
 time part you MUST have a colon in the zone designator.
 
 So I am dealing with timestamps in strict ISO 8601
 complete extended representation, and it is rather
 frustrating that strptime doesn't deal with it simply.
 
 The simplest thing would be for R's own version of
 strptime to allow an optional colon between the hour
 digits and the minute digits of a zone designator.
 
 I'm about to clone the data source and edit it to
 remove the colons, but is there something obvious I am
 missing?
 
 __
 R-help@r-project.org mailing list -- To UNSUBSCRIBE and
 more, see https://stat.ethz.ch/mailman/listinfo/r-help
 PLEASE do read the posting guide
 http://www.R-project.org/posting-guide.html and provide
 commented, minimal, self-contained, reproducible code.
 
>>> 

>   [[alternative HTML version deleted]]

> __
> R-help@r-project.org mailing list -- To UNSUBSCRIBE and
> more, see https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide
> http://www.R-project.org/posting-guide.html and provide
> commented, minimal, self-contained, reproducible code.

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] Dynamically create a (convenience) function in a package

[Martin Maechler]

> Iris Simmons 
> on Mon, 30 Oct 2023 06:37:04 -0400 writes:

> If you don't know the name of the attributes in advance,
> how can you know the function name to be able to call it?
> This seems like a very flawed approach.

> Also, I would discourage the use of eval(parse(text = )),
> it's almost always not the right way to do what you want
> to do. In your case,

> eval(bquote(function(x) attr(x, .(n

> would be better.

Indeed!  Thank you, Iris!

... as an old timer, I'd like to raise

  R> fortunes::fortune("eval(parse")

  Personally I have never regretted trying not to underestimate my own future
  stupidity.
 -- Greg Snow (explaining why eval(parse(...)) is often suboptimal, 
answering
a question triggered by the infamous fortune(106))
R-help (January 2007)

  R> fortunes::fortune(106)

  If the answer is parse() you should usually rethink the question.
 -- Thomas Lumley
R-help (February 2005)

  R> 


Best, Martin



> On Mon, Oct 30, 2023, 06:28 Sigbert Klinke
>  wrote:

>> Hi,
>> 
>> n a package, I have a data object with attributes, and I
>> want to dynamically create a convenience function to
>> access those attributes.  This way, instead of using
>> attr(x, "number"), I would like to use number(x).
>> 
>> 
>> 
>> Because I don't know in advance which attributes the data
>> object may have, I've used the following algorithm:
>> 
>> x <- structure(pi, number=exp(1))
>> 
>> a <- attributes(x)
>> 
>> for (n in names(a)) {
>> 
>> if (!exists(n, mode="function")) {
>> 
>> f <- eval(parse(text=sprintf("function(x) { attr(x, '%s')
>> } ", n)))
>> 
>> 
>> assign(n, f, envir=.GlobalEnv)
>> 
>> }
>> 
>> }
>> 
>> number(x)
>> 
>> However, I believe modifying the global environment with
>> this is not allowed by CRAN for a package. Is there a way
>> to implement such functionality?
>> 
>> Thanks Sigbert
>> 
>> --
>> https://hu.berlin/sk https://www.stat.de/faqs
>> https://hu.berlin/mmstat https://hu.berlin/mmstat-ar
>> 
>> __
>> R-help@r-project.org mailing list -- To UNSUBSCRIBE and
>> more, see https://stat.ethz.ch/mailman/listinfo/r-help
>> PLEASE do read the posting guide
>> http://www.R-project.org/posting-guide.html and provide
>> commented, minimal, self-contained, reproducible code.
>> 

>   [[alternative HTML version deleted]]

> __
> R-help@r-project.org mailing list -- To UNSUBSCRIBE and
> more, see https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide
> http://www.R-project.org/posting-guide.html and provide
> commented, minimal, self-contained, reproducible code.

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] The argument 'eps.Pvalue' of `printCoefmat()`

[Martin Maechler]

> Duncan Murdoch 
> on Sun, 29 Oct 2023 04:45:19 -0400 writes:

> On 29/10/2023 3:48 a.m., Shu Fai Cheung wrote:
>> Hi all,
>> 
>> Just a minor issue that I am not sure whether this is
>> considered a "bug." It is about the help page.
>> 
>> In the help page of printCoefmat(), for the argument
>> 'eps.Pvalue', the description is as below:
>> 
>> number, ..
>> 
>> I have to read the source to figure out that this
>> argument is to be used by format.pval().
>> 
>> Maybe the description of 'eps.Pvalue' can be revised to
>> refer users to the help page of format.pval()?

> That looks like an oversight by the author of the help
> page.  It's been there for at least 20 years!

> Duncan Murdoch

indeed "!"  -- my fault.

Note that at the R sprint 2023,  printCoefmat() has been one of
the small topics
 
https://contributor.r-project.org/r-project-sprint-2023/projects/tweak-printCoefmat/

on which we hoped to make progress -- also prompted by your (Shu
Fai) good question, on this list,
  https://stat.ethz.ch/pipermail/r-help/2023-July/477688.html

on how to improve the details of the  `zap.ind` setting.

Whereas the R sprint project lead to some investigations, but
unfortunately did not yet lead to improve the code generally
... even though we *did* try some changes, but IIRC they all had
their flaws and hence were not good enough to warrant a change
of code.

So, for now, we should at least change that part of the help
page -- finally!

Martin

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] running crossvalidation many times MSE for Lasso regression

[Martin Maechler]

> Jin Li 
> on Mon, 23 Oct 2023 15:42:14 +1100 writes:

> If you are interested in other validation methods (e.g., LOO or n-fold)
> with more predictive accuracy measures, the function, glmnetcv, in the 
spm2
> package can be directly used, and some reproducible examples are
> also available in ?glmnetcv.

... and once you open that can of w..:   the  glmnet package itself
contains a function  cv.glmnet()  which we (our students) use when teaching.

What's the advantage of the spm2 package ?
At least, the glmnet package is authored by the same who originated and
first published (as in "peer reviewed" ..) these algorithms.



> On Mon, Oct 23, 2023 at 10:59 AM Duncan Murdoch 
> wrote:

>> On 22/10/2023 7:01 p.m., Bert Gunter wrote:
>> > No error message shown Please include the error message so that it is
>> > not necessary to rerun your code. This might enable someone to see the
>> > problem without running the code (e.g. downloading packages, etc.)
>> 
>> And it's not necessarily true that someone else would see the same error
>> message.
>> 
>> Duncan Murdoch
>> 
>> >
>> > -- Bert
>> >
>> > On Sun, Oct 22, 2023 at 1:36 PM varin sacha via R-help
>> >  wrote:
>> >>
>> >> Dear R-experts,
>> >>
>> >> Here below my R code with an error message. Can somebody help me to 
fix
>> this error?
>> >> Really appreciate your help.
>> >>
>> >> Best,
>> >>
>> >> 
>> >> # MSE CROSSVALIDATION Lasso regression
>> >>
>> >> library(glmnet)
>> >>
>> >>
>> >>
>> 
x1=c(34,35,12,13,15,37,65,45,47,67,87,45,46,39,87,98,67,51,10,30,65,34,57,68,98,86,45,65,34,78,98,123,202,231,154,21,34,26,56,78,99,83,46,58,91)
>> >>
>> 
x2=c(1,3,2,4,5,6,7,3,8,9,10,11,12,1,3,4,2,3,4,5,4,6,8,7,9,4,3,6,7,9,8,4,7,6,1,3,2,5,6,8,7,1,1,2,9)
>> >>
>> 
y=c(2,6,5,4,6,7,8,10,11,2,3,1,3,5,4,6,5,3.4,5.6,-2.4,-5.4,5,3,6,5,-3,-5,3,2,-1,-8,5,8,6,9,4,5,-3,-7,-9,-9,8,7,1,2)
>> >> T=data.frame(y,x1,x2)
>> >>
>> >> z=matrix(c(x1,x2), ncol=2)
>> >> cv_model=glmnet(z,y,alpha=1)
>> >> best_lambda=cv_model$lambda.min
>> >> best_lambda
>> >>
>> >>
>> >> # Create a list to store the results
>> >> lst<-list()
>> >>
>> >> # This statement does the repetitions (looping)
>> >> for(i in 1 :1000) {
>> >>
>> >> n=45
>> >>
>> >> p=0.667
>> >>
>> >> sam=sample(1 :n,floor(p*n),replace=FALSE)
>> >>
>> >> Training =T [sam,]
>> >> Testing = T [-sam,]
>> >>
>> >> test1=matrix(c(Testing$x1,Testing$x2),ncol=2)
>> >>
>> >> predictLasso=predict(cv_model, newx=test1)
>> >>
>> >>
>> >> ypred=predict(predictLasso,newdata=test1)
>> >> y=T[-sam,]$y
>> >>
>> >> MSE = mean((y-ypred)^2)
>> >> MSE
>> >> lst[i]<-MSE
>> >> }
>> >> mean(unlist(lst))
>> >> ##
>> >>
>> >>
>> >>
>> >>
>> >> __
>> >> R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
>> >> https://stat.ethz.ch/mailman/listinfo/r-help
>> >> PLEASE do read the posting guide
>> http://www.R-project.org/posting-guide.html
>> >> and provide commented, minimal, self-contained, reproducible code.
>> >
>> > __
>> > R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
>> > https://stat.ethz.ch/mailman/listinfo/r-help
>> > PLEASE do read the posting guide
>> http://www.R-project.org/posting-guide.html
>> > and provide commented, minimal, self-contained, reproducible code.
>> 
>> __
>> R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
>> https://stat.ethz.ch/mailman/listinfo/r-help
>> PLEASE do read the posting guide
>> http://www.R-project.org/posting-guide.html
>> and provide commented, minimal, self-contained, reproducible code.
>> 


> -- 
> Jin
> --
> Jin Li, PhD
> Founder, Data2action, Australia
> https://www.researchgate.net/profile/Jin_Li32
> https://scholar.google.com/citations?user=Jeot53EJ=en

> [[alternative HTML version deleted]]

> __
> R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide 
http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide 

Re: [R] stopping R emails

[Martin Maechler]

>>>>> J C Nash 
>>>>> on Thu, 19 Oct 2023 07:52:11 -0400 writes:

> Dear Juel,

> The R lists are automated, and while there is probably
> someone with access to remove particular subscribers, it
> is generally easier to UNSUBSCRIBE to them.

> I believe Jim was on several lists. The full collection is
> at https://www.r-project.org/mail.html

As (R mailing lists) *Site* maintainer, I can remove subscribers
from all lists at once.

I have done so with Jim's e-mail (above).
The result was that the address was unsubscribed from
R-help  and  R-package-devel, no others.

> The main help list can be unsubscribed as described at the
> bottom of most postings:
> __
> R-help@r-project.org mailing list -- To UNSUBSCRIBE and
> more, see https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide
> http://www.R-project.org/posting-guide.html and provide
> commented, minimal, self-contained, reproducible code.

> There is also the package-devel list, which can be
> unsubscribed at

> https://stat.ethz.ch/mailman/listinfo/r-package-devel

> Similarly https://stat.ethz.ch/mailman/listinfo/r-devel

> I am copying this to the R-help list to inform other users
> so hopefully you don't get multiple similar messages. So
> you will likely see the msg copied there before you manage
> to unsubscribe.

> With condolences,
> John Nash

>From me, as well.

Jim Lemon has been one of the frequent really *friendly*
and patient "helpers" to many who have searched for support and
help on the R mailing lists (R-help and R-package-devel, see above).
His death is indeed a loss to the R community.

Best regards,
Martin

--
Martin Maechler
ETH Zurich  and  R Core team

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] save() and load(): *prefer* saveRDS() and readRDS()

[Martin Maechler]

> Jeff Newmiller via R-help 
> on Mon, 25 Sep 2023 18:46:02 -0700 writes:

> You never created any object in R called irisdataTest. Objects in the 
global environment have names that are unrelated to the names of files on disk.
> The load function modifies an environment to create a variable named as 
it was named in the environment from which it was saved. Thus, you cannot 
simply load an object that was saved with one name into an object named 
something else. It is possible to create a new environment to put the loaded 
objects into, but I wouldn't recommend trying to explain how to do that to a 
beginner.  Rather, I would instead recommend using saveRDS and readRDS instead 
to save/load exactly one object at a time without storing the object name.

> saveRDS( mtcars, "my_mtcars.rds" )
> new_obj <- readRDS( "my_mtcars.rds" )

> I would also guide them to never save their environment when prompted by 
R... the .RData file this creates will remember mistakes made in previous 
sessions making troubleshooting very difficult later. Instead they should focus 
on making a top-to-bottom script that has all their analysis steps so they can 
start from scratch.

Yes!

And just re-iterating what Jeff mentioned above:
Notably when teaching, the use of  saveRDS()  and  readRDS()
should be emphasized as safer / self-documenting, ...
for the case where there's just one object to save/load.

*and* you can always put several objects into a list and
saveRDS() / readRDS() that.

Note: Our pkg {sfsmisc} nowadays contains a nice utility function
list_()  ==> help page online e.g. here
 
https://search.r-project.org/CRAN/refmans/sfsmisc/html/list_named.html

which comes were handy when you want to easily create a *named*
list from a bunch of objects, as e.g. above to be able to nicely use

  saveRDS(list_(obj1, obj2, table3, grob4, data5),
  file = "allthings.rds")
   
The cute utility is very simply defined as

##' list_(a, b, cc)  creates a *named* list  using the actual arguments' names
list_ <- function(...) `names<-`(list(...), vapply(sys.call()[-1L], 
as.character, ""))


> On September 25, 2023 6:23:01 PM PDT, AbouEl-Makarim Aboueissa 
 wrote:
>> Dear ALL:
>> 
>> I am teaching statistical packages class this semester, in R programing I
>> am trying to explain the use of save() and load() with an example using 
the
>> iris data. It seems that the save() function works, BUT when I tried to
>> load the data back to R, it seems that there is a problem(s), I could not
>> figure out what went wrong.
>> 
>> Any help would be highly appreciated.
>> 
>> 
>> I saved the iris data in my computer in the text format, 
"iris.with.head.txt
>> ".
>> 
>> Here are my R codes:
>> 
>>> irisdata<-read.table("G:/iris.with.head.txt", header=T)
>>> 
>>> head(irisdata)
>> Sepal.Length Sepal.Width Petal.Length Petal.Width Species
>> 1  5.1 3.5  1.4 0.2  setosa
>> 2  4.9 3.0  1.4 0.2  setosa
>> 3  4.7 3.2  1.3 0.2  setosa
>> 4  4.6 3.1  1.5 0.2  setosa
>> 5  5.0 3.6  1.4 0.2  setosa
>> 6  5.4 3.9  1.7 0.4  setosa
>> 
>> 
>> 
>> *# saving the data as an .rda*
>> 
>> save(irisdata,file="G:/irisdataTest.rda")
>> 
>> *# load the data back to R*
>> 
>> load(file="G:/irisdataTest.rda")
>> 
>> 
>>> head(irisdataTest)
>> Error in head(irisdataTest) : object 'irisdataTest' not found
>> 
>>> irisdataTest
>> Error: object 'irisdataTest' not found
>> 
>> 
>> 
>> with many thanks
>> abou
>> __
>> 
>> 
>> *AbouEl-Makarim Aboueissa, PhD*
>> 
>> *Professor, Mathematics and Statistics*
>> *Graduate Coordinator*
>> 
>> *Department of Mathematics and Statistics*
>> *University of Southern Maine*
>> 
>> [[alternative HTML version deleted]]
>> 
>> __
>> R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
>> https://stat.ethz.ch/mailman/listinfo/r-help
>> PLEASE do read the posting guide 
http://www.R-project.org/posting-guide.html
>> and provide commented, minimal, self-contained, reproducible code.

> -- 
> Sent from my phone. Please excuse my brevity.

> __
> R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide 
http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.

__
R-help@r-project.org mailing list -- To 

Re: [R] Regarding error in RStudio

[Martin Maechler]

>>>>> Sukriti Sood 
>>>>> on Tue, 5 Sep 2023 16:59:28 + writes:

> Hi, I am Sukriti Sood, a research analyst at Woodstock
> Institute <https://woodstockinst.org/> . I use RStudio
> extensively for our analysis. I have been facing two
> issues for a while:


>   1.  I am unable to copy from RStudio and paste into or
> vice versa to any other programs.  2.  I am facing some
> kind of a conversion error (screenshot attached).

> I tried looking up online however could not find a
> resolution to these issues. Could I please get some help
> with this urgently.

> Thanks!

> Best, Sukriti Sood

Dear Sukriti.

Hmm, the R-help list is really about R, and *not* RStudio.
There are RStudio community places to ask for help with the IDE,
"RStudio Desktop" I think it is called now.

Also screenshots of R console output are really not intended for
this mailing list.  Please rather send *text* to here which you
cut'n'paste (and possible re-format / clean)  from the R console.

Still taking the extra effort and deciphering your screenshot,
I see that you are using R version 4.3.1 for Windows .. which is
fine... then an  iconv() conversion error and an other error
message that "knitr" was not found; finally

[Workspace loaded from C:/WSI/.RData]

Please rename this file, C:/WSI/.RData , to something else
(do this with the file browser from Windows; outside R).

If that does not help, try to start R outside of RStudio,
and report here (*not* by a screenshot) if you still get an
error.
If you get to the R prompt at all please also send the console
output from (typing in the R console)
  > sessionInfo()

If  R  works fine outside RStudio,  you definitely need to get
help from the RStudio community.
Hoping that helps some steps further.

Best regards,
Martin

--
Martin Maechler
ETH Zurich  and  R Core team

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] Time out error while connecting to Github repository

[Martin Maechler]

> siddharth sahasrabudhe via R-help 
> on Sun, 3 Sep 2023 09:54:28 +0530 writes:

> I want to access the .csv file from my github
> repository. While connecting to the Github repository I am
> getting the following error:

> Error in curl::curl_fetch_memory(file) : Timeout was
> reached: [raw.githubusercontent.com] Failed to connect to
> raw.githubusercontent.com port 443 after 5250 ms: Timed
> out

> The R-code is as below:

library(tidyverse)  ## << UNNEEDED !

library(rio)

> data <- import("
> 
https://raw.githubusercontent.com/siddharth-sahasrabudhe/Youtube-video-files/main/deck.csv
> ")

> Can you please suggest how I can able to resolve this
> issue?

Yes: You used the wrong "file name", because you added a
  /  
 on both ends by breaking the line.

This works nicely:

> require(rio)
> dd <- 
> import("https://raw.githubusercontent.com/siddharth-sahasrabudhe/Youtube-video-files/main/deck.csv;)
> str(dd)
'data.frame':   52 obs. of  3 variables:
 $ face : chr  "king" "queen" "jack" "ten" ...
 $ suit : chr  "spades" "spades" "spades" "spades" ...
 $ value: int  13 12 11 10 9 8 7 6 5 4 ...


> -- 
> Regards Siddharth Sahasrabudhe

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] [Pkg-Collaboratos] BioShapes Almost-Package

[Martin Maechler]

> Duncan Murdoch 
> on Mon, 4 Sep 2023 04:51:32 -0400 writes:

> On 03/09/2023 10:47 p.m., Jeff Newmiller wrote:
>> Leonard... the reason roxygen exists is to allow markup
>> in source files to be used to automatically generate the
>> numerous files required by standard R packages as
>> documented in Writing R Extensions.
>> 
>> If your goal is to not use source files this way then the
>> solution is to not use roxygen at all. Just create those
>> files yourself by directly editing them from scratch.

> Just a bit of elaboration on Jeff's suggestion -- here's
> the workflow I prefer to using Roxygen.

> Once you have a function that works:

> 1.  install the package 2.  set your working directory
> to the package "man" directory 3.  run
> `prompt(functionname)` 4.  edit `functionname.Rd` in the
> "man" directory, which will already be filled in as a
> skeleton help file, with comments describing what else
> to add.

> Don't run prompt() again after editing, or you'll lose
> all your edits.  But this is a good way to get started.

> I think for the first few times the comments are really
> helpful, but I wouldn't mind a way to suppress them.

> Duncan Murdoch

Me neither.  A new option, not changing the default, would make sense.

Martin

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] [Pkg-Collaboratos] BioShapes Almost-Package

[Martin Maechler]

> Jeff Newmiller 
> on Sun, 03 Sep 2023 19:47:32 -0700 writes:

> Leonard... the reason roxygen exists is to allow markup in
> source files to be used to automatically generate the
> numerous files required by standard R packages as
> documented in Writing R Extensions.  If your goal is to
> not use source files this way then the solution is to not
> use roxygen at all. Just create those files yourself by
> directly editing them from scratch.

Yes. Many experienced R programmers do not use Roxygen
(or use it only rarely; e.g., together with ESS (Emacs Speaks
 Statistics) to make the initial creation or sometime a thorough
 updating the help pages  man/*.Rd more convenient).

There are different tastes and different work flows for
different people.

Martin


> On September 3, 2023 7:06:09 PM PDT, Leonard Mada via
> R-help  wrote:
>> Thank you Bert.
>> 
>> 
>> Clarification:
>> 
>> Indeed, I am using an add-on package: it is customary for
>> that package - that is what I have seen - to have the
>> entire documentation included as comments in the R src
>> files. (But maybe I am wrong.)
>> 
>> 
>> I will try to find some time over the next few days to
>> explore in more detail the R documentation. Although, I
>> do not know how this will interact with the add-on
>> package.
>> 
>> 
>> Sincerely,
>> 
>> 
>> Leonard
>> 
>> 
>> On 9/4/2023 4:58 AM, Bert Gunter wrote:
>>> 1. R-package-devel is where queries about package
>>> protocols should go.
>>> 
>>> 2. But...  "Is there a succinct, but sufficiently
>>> informative description of documentation tools?"
>>> "Writing R Extensions" (shipped with R) is *the*
>>> reference for R documentation. Whether it's sufficiently
>>> "succinct" for you, I cannot say.
>>> 
>>> "I find that including the documentation in the source
>>> files is very distracting."  ?? R documentation (.Rd)
>>> files are separate from source (.R) files.  Inline
>>> documentation in source files is an "add-on" capability
>>> provided by optional packages if one prefers to do
>>> this. Such packages parse the source files to extract
>>> the documentation into the .Rd files/ So not sure what
>>> you mean here. Apologies if I have misunderstood.
>>> 
>>> " I would prefer to have only basic comments in the
>>> source files and an expanded documentation in a separate
>>> location."  If I understand you correctly, this is
>>> exactly what the R package process specifies. Again, see
>>> the "Writing R Extensions" manual for details.
>>> 
>>> Also, if you wish to have your package on CRAN, it
>>> requires that the package documents all functions in the
>>> package as specified by the "Writing ..." manual.
>>> 
>>> Again, further questions and elaboration should go to
>>> the R-package-devel list, although I think the manual is
>>> really the authoritative resource to follow.
>>> 
>>> Cheers, Bert
>>> 
>>> 
>>> 
>>> On Sun, Sep 3, 2023 at 5:06 PM Leonard Mada via R-help
>>>  wrote:
>>> 
>>> Dear R-List Members,
>>> 
>>> I am looking for collaborators to further develop the
>>> BioShapes almost-package. I added a brief description
>>> below.
>>> 
>>> A.) BioShapes (Almost-) Package
>>> 
>>> The aim of the BioShapes quasi-package is to facilitate
>>> the generation of graphical objects resembling
>>> biological and chemical entities, enabling the
>>> construction of diagrams based on these objects. It
>>> currently includes functions to generate diagrams
>>> depicting viral particles, liposomes, double helix / DNA
>>> strands, various cell types (like neurons, brush-border
>>> cells and duct cells), Ig-domains, as well as more basic
>>> shapes.
>>> 
>>> It should offer researchers in the field of biological
>>> and chemical sciences a tool to easily generate diagrams
>>> depicting the studied biological processes.
>>> 
>>> The package lacks a proper documentation and is not yet
>>> released on CRAN. However, it is available on GitHub:
>>> https://github.com/discoleo/BioShapes
>>> 
>>> Although there are 27 unique cloners on GitHub, I am
>>> still looking for contributors and collaborators. I
>>> would appreciate any collaborations to develop it
>>> further. I can be contacted both by email and on GitHub.
>>> 
>>> 
>>> B.) Documentation Tools
>>> 
>>> Is there a succinct, but sufficiently informative
>>> description of documentation tools?  I find that
>>> including the documentation in the source files is very
>>> distracting. I would prefer to have only basic comments
>>> in the source files and an expanded documentation in a
>>> separate location.
>>> 

Re: [R] MASS::mvrnorm() on MKL may produce different numbers even when the seed is the same?

[Martin Maechler]

>>>>> Bill Dunlap 
>>>>> on Thu, 17 Aug 2023 07:31:12 -0700 writes:

> MKL's results can depend on the number of threads running and perhaps 
other
> things.  They blame it on the non-associativity of floating point
> arithmetic.  This article gives a way to make results repeatable:

> 
https://www.intel.com/content/www/us/en/developer/articles/technical/introduction-to-the-conditional-numerical-reproducibility-cnr.html

> -Bill

Thanks a lot, Bill, for your answer and this pointer to MKL creators
explanation and details on how to achieve reproducibility !

Conditional reproducibility with some cost - speedwise:

 If limited to a particular code-path, Intel MKL performance can in some 
circumstances degrade by more than half. 
This can be easily understood by noting that matrix-multiply performance nearly 
doubled with the introduction of new processors supporting AVX instructions. In 
other cases, performance may degrade by 10-20% if algorithms are restricted to 
maintain the order of operations.


It confirms what I have been claiming for about a dozen years,
that in my experience, *all* optimizing BLAS/Lapack libraries trade
speed for accuracy to some extent, and hence an unoptimized
BLAS/Lapack (as the one in R's sources), should be considered gold-standard.
{Consequently, I have not been fully happy that we switched to
 using an *external* Lapack, when one is found during configuration.
 Of course there *are* other good reasons to do such a switch,
 notably compatibility with other math software running on the same system.}

Now, in the above report, they show how to ensure
  CNR := conditional numerical reproducibility
when using MKL ("conditional" means e.g. the same level of parallelization).
on Intel compatible chips.

I think it would be nice to provide the average R user with a
(possibly super small) R package that allows to turn on (and off) such CNR
reproducibility.
Strict reproducibility when running on the same hardware and
software should be a very high desideratum for all scientists
and I hope also for all data "wranglers" etc..

Martin

--
Martin Maechler
ETH Zurich  and  R Core team

> On Wed, Aug 16, 2023 at 8:11 PM Shu Fai Cheung 
> wrote:

>> Hi All,
>> 
>> When addressing an error in one of my packages in the CRAN check at CRAN,
>> I found something strange which, I believe, is unrelated to my package.
>> I am not sure whether it is a bug or a known issue. Therefore, I would 
like
>> to have advice from experts here.
>> 
>> The error at CRAN check occurred in a test, and only on R-devel with MKL.
>> No
>> issues on all other platforms. The test compares two sets of random
>> numbers,
>> supposed to be identical because generated from the same seed. However,
>> when
>> I tried that in R-devel (2023-08-15 r84957) on Ubuntu 22.04.3 LTS, linked
>> to
>> MKL (2023.2.0), I found that this is not the case in one situation.
>> 
>> I don't know why but somehow only one particular set of means and
>> covariance matrix, among many others in the code, led to that problem.
>> Please find
>> below the code to reproduce the means and the covariance matrix (pardon 
me
>> for the long code):
>> 
>> mu0 <- structure(c(0.52252416853188655, 0.39883382931927774,
>> 1.6296642535174521,
>> 2.9045763671121816, -0.19816874840500939, 0.42610841566522556,
>> 0.30155498531316366, 1.0339601619394503, 3.4125587827873192,
>> 13.125481598475405, 19.275480386183503, 658.94225353462195,
>> 1.0997193726987393,
>> 9.9980286642877214, 6.4947188998602092, -12.952617780813679,
>> 8.4991882784024799, 106.82209520278377, 0.19623712449219838), class =
>> c("numeric"))
>> 
>> sigma0 <- structure(c(0.0047010182215945009, 1.4688424622163808e-17,
>> -2.5269697696885822e-17,
>> -1.2451516929358655e-18, 3.6553475725253408e-19, 3.2092363914356227e-19,
>> -2.6341938382508503e-18, 8.6439582878287556e-19, -1.295240602054123e-17,
>> 1.1154057497258702e-18, -8.2407621704807367e-33, -1.0891686096304908e-15,
>> -2.6800671450262819e-18, -0.0009225142979911, 
-1.4833018148344697e-16,
>> 2.292242132203e-16, -3.5128615476876035e-18, 2.8004770623734002e-33,
>> 2.0818099301348832e-34, 1.294907062174661e-17, 0.012788608283099183,
>> 1.5603789410838518e-15, 1.0425182851251724e-16, 2.758318745465066e-17,
>> -9.7047963858148572e-18, -7.4685438142667792e-17, 
-1.9426723638193857e-17,
>> -7.8775307262071738e-17, -4.0773523140359949e-17, 4.1212975037936416e-18,
>> 

Re: [ESS] ESS code-folding?

[Martin Maechler via ESS-help]

> Westerland, Maggie via ESS-help 
> on Thu, 17 Aug 2023 13:15:39 + writes:

> Ah, I see how this is working now. This looks like a suitable solution 
for me!
> Thanks all,
> Maggie

> --
> Maggie Westerland, MA
> Statistical Programmer
> BUMC, Dept of Rheumatology
> she/her


Great --- note that this has been part of Emacs (independently
of ESS) for"ever" (~ 30 years I guess).

Martin


> From: Karlo Guidoni Martins 
> Sent: Thursday, August 17, 2023 7:29 AM
> To: Sparapani, Rodney 
> Cc: Westerland, Maggie ; ess-help 
(ess-help@r-project.org) 
> Subject: Re: [ESS] ESS code-folding?

> With that code snippet:
> ### acts as the first level of the folding,  as second level and so 
on.

> Check out if the outline-minor-mode is activated after evaluating that 
code snippet as well. The TAB key open and close the folding by default, just 
like org-mode.

> In my case, this works like this:

> Without code folding
> ### test1
> test1 = c(1, 2)
>  test2
> test2 = c(1, 2)

> With code folding
> ### test1...
>  test2...





> On Wed, 16 Aug 2023 at 16:06 Sparapani, Rodney 
mailto:rspar...@mcw.edu>> wrote:
> Hi Karlo:

> This is very interesting.  But, I must not be doing it right.
> Do you have a simple example of how to use this to do case-folding?
> Thanks

> --
> Rodney Sparapani, Associate Professor of Biostatistics, He/Him/His
> Vice President, Wisconsin Chapter of the American Statistical Association
> Institute for Health and Equity, Division of Biostatistics
> Medical College of Wisconsin, Milwaukee Campus


> From: Karlo Guidoni Martins 
mailto:kguidonimart...@gmail.com>>
> Date: Wednesday, August 16, 2023 at 1:02 PM
> To: Sparapani, Rodney mailto:rspar...@mcw.edu>>
> Cc: ess-help (ess-help@r-project.org) 
mailto:ess-help@r-project.org>>
> Subject: Re: [ESS] ESS code-folding?
> ATTENTION: This email originated from a sender outside of MCW. Use 
caution when clicking on links or opening attachments.
> 
> hi!

> this works fine for me:

> ;;; BEG
> ;;; outline-(minor)-mode
> (setq outline-minor-mode-highlight 'override) ; emacs28
> (setq outline-minor-mode-cycle t)

> ;;; outline for ess-mode
> (add-hook 'ess-mode-hook
> #'(lambda ()
> (outline-minor-mode)
> (setq-local outline-regexp "\\(^#\\{3,7\\} \\)\\|\\(^[a-zA-Z0-9_\.]+ ?<- 
?function(.*{\\)")
> (setq-local outline-regexp "\\(^#\\{3,7\\} 
\\)")
> (defun outline-level ()
> ;; ## continues only as a comment.
> (cond ((looking-at "^### ") 1) ; first level
> ((looking-at "^ ") 2) ; second level
> ((looking-at "^# ") 3) ; and so on...
> ((looking-at "^## ") 4)
> ((looking-at "^### ") 5)
> ((looking-at "^ ") 6)
> ((looking-at "^[a-zA-Z0-9_\.]+ ?<- ?function(.*{") 3)
> (t 1000)))
> (outline-hide-body)))

> ;;; force outline height
> (custom-set-faces
> '(outline-1 ((t (:height 1.100 :weight bold
> '(outline-2 ((t (:height 1.075 :weight bold
> '(outline-3 ((t (:height 1.050 :weight bold
> '(outline-4 ((t (:height 1.025 :weight bold
> '(outline-5 ((t (:height 1.000 :weight bold
> '(outline-6 ((t (:height 1.000 :weight bold
> '(outline-7 ((t (:height 1.000 :weight bold
> '(outline-8 ((t (:height 1.000 :weight bold
> )
> ;;; END


> On 16 Aug 2023 14:30:02, "Sparapani, Rodney via ESS-help" 
mailto:ess-help@r-project.org>> wrote:
> Hi Gang:

> One of my student’s asked this question.

> Any resources/knowledge on code folding? in RStudio ‘’ creates a 
collapsible section. Came across 
hideshow-org
 but I don’t want to only be able to use it in org mode.

> Something like

> Without code folding
>  test 
> test = c(1, 2)
> 

> With code folding
>  test 
> 

> Any ideas?
> --
> Rodney Sparapani, Associate Professor of Biostatistics, He/Him/His
> Vice President, Wisconsin Chapter of the American Statistical Association
> Institute for Health and Equity, Division of Biostatistics
> Medical College of Wisconsin, Milwaukee Campus


> [[alternative HTML version deleted]]
> __
> ESS-help@r-project.org mailing list
> 
https://stat.ethz.ch/mailman/listinfo/ess-help

> [[alternative HTML version 

Re: [R] Numerical stability of: 1/(1 - cos(x)) - 2/x^2

[Martin Maechler]

> Leonard Mada 
> on Wed, 16 Aug 2023 20:50:52 +0300 writes:

> Dear Iris,
> Dear Martin,

> Thank you very much for your replies. I add a few comments.

> 1.) Correct formula
> The formula in the Subject Title was correct. A small glitch swept into 
> the last formula:
> - 1/(cos(x) - 1) - 2/x^2
> or
> 1/(1 - cos(x)) - 2/x^2 # as in the subject title;

> 2.) log1p
> Actually, the log-part behaves much better. And when it fails, it fails 
> completely (which is easy to spot!).

> x = 1E-6
> log(x) -log(1 - cos(x))/2
> # 0.3465291

> x = 1E-8
> log(x) -log(1 - cos(x))/2
> # Inf
> log(x) - log1p(- cos(x))/2
> # Inf => fails as well!
> # although using only log1p(cos(x)) seems to do the trick;
> log1p(cos(x)); log(2)/2;

> 3.) 1/(1 - cos(x)) - 2/x^2
> It is possible to convert the formula to one which is numerically more 
> stable. It is also possible to compute it manually, but it involves much 
> more work and is also error prone:

> (x^2 - 2 + 2*cos(x)) / (x^2 * (1 - cos(x)))
> And applying L'Hospital:
> (2*x - 2*sin(x)) / (2*x * (1 - cos(x)) + x^2*sin(x))
> # and a 2nd & 3rd & 4th time
> 1/6

> The big problem was that I did not expect it to fail for x = 1E-4. I 
> thought it is more robust and works maybe until 1E-5.
> x = 1E-5
> 2/x^2 - 2E+10
> # -3.814697e-06

> This is the reason why I believe that there is room for improvement.

> Sincerely,
> Leonard

Thank you, Leonard.
Yes, I agree that it is amazing how much your formula suffers from
(a generalization of) "cancellation" --- leading you to think
there was a problem with cos() or log() or .. in R.
But really R uses the system builtin libmath library, and the
problem is really the inherent instability of your formula.

Indeed your first approximation was not really much more stable:

## 3.) 1/(1 - cos(x)) - 2/x^2
## It is possible to convert the formula to one which is numerically more
## stable. It is also possible to compute it manually, but it involves much
## more work and is also error prone:
## (x^2 - 2 + 2*cos(x)) / (x^2 * (1 - cos(x)))
## MM: but actually, that approximation does not seem better (close to the 
breakdown region):
f1 <- \(x) 1/(1 - cos(x)) - 2/x^2
f2 <- \(x) (x^2 - 2 + 2*cos(x)) / (x^2 * (1 - cos(x)))
curve(f1, 1e-8, 1e-1, log="xy" n=2^10)
curve(f2, add = TRUE, col=2,   n=2^10)
## Zoom in:
curve(f1, 1e-4, 1e-1, log="xy",n=2^9)
curve(f2, add = TRUE, col=2,   n=2^9)
## Zoom in much more in y-direction:
yl <- 1/6 + c(-5, 20)/10
curve(f1, 1e-4, 1e-1, log="x", ylim=yl, n=2^9)
abline(h = 1/6, lty=3, col="gray")
curve(f2, add = TRUE, n=2^9, col=adjustcolor(2, 1/2))

Now, you can use the Rmpfr package (interface to the GNU MPFR
multiple-precision C library) to find out more :

if(!requireNamespace("Rmpfr")) install.packages("Rmpfr")
M <- function(x, precBits=128) Rmpfr::mpfr(x, precBits)

(xM <- M(1e-8))# yes, only ~ 16 dig accurate
## 1.20922560830128472675327e-8
M(10, 128)^-8 # would of course be more accurate,
## but we want the calculation for the double precision number 1e-8

## Now you can draw "the truth" into the above plots:
curve(f1, 1e-4, 1e-1, log="xy",n=2^9)
curve(f2, add = TRUE, col=2,   n=2^9)
## correct:
curve(f1(M(x, 256)), add = TRUE, col=4, lwd=2, n=2^9)
abline(h = 1/6, lty=3, col="gray")

But, indeed we take note  how much it is the formula instability: 
Also MPFR needs a lot of extra bits precision before it gets to
the correct numbers: 

xM <- c(M(1e-8,  80), M(1e-8,  96), M(1e-8, 112), 
M(1e-8, 128), M(1e-8, 180), M(1e-8, 256))
## to and round back to 70 bits for display:
R <- \(x) Rmpfr::roundMpfr(x, 70)
R(f1(xM)) 
R(f2(xM))
## [1] 0  0  
0.15407439555097885670915
## [4] 0.1746653133802175779  0.1749979  
0.1750001

## 1. f1() is even worse than f2() {here at x=1e-8} 
## 2. Indeed, even 96 bits precision is *not* sufficient at all, ...
##which is amazing to me as well !!

Best regards,
Martin

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [ESS] New Emacs Modified distributions - now double the pleasure!

[Martin Maechler via ESS-help]

> Vincent Goulet via ESS-help 
> on Tue, 15 Aug 2023 16:24:42 + writes:

> Hi folks,
> Back in April 2022 [*], I asked here if there was still interest in my 
distributions of Emacs that ship with ESS and AUCTeX ready to go. Since the 
response was generally positive, and since, more importantly, there is still 
interest from the first user of these distributions (that's me, at least on 
macOS), well I'm pleased to announce new releases of my Emacs Modified 
distributions for macOS and Windows:

> https://emacs-modified.gitlab.io 

> Double the pleasure? The distributions now come in two editions: "Latest 
Emacs and ESS" based on GNU Emacs 29.1 and the tip of the development branch of 
ESS; "Legacy Emacs and ESS" based on Emacs 27.2 and ESS 18.10.2 (the latest 
official release). Everything else is the same. In other words, the "legacy" 
distributions now get the updates to the other packages, in particular AUCTeX. 
As someone who still prefers (or is too much used to) ESS 18.10, I felt left 
behind on the other fronts by my own distributions.

...  I am also sorry for the extra work you had, even though I
can argue there have been strong reasons not releasing "development ESS".

Still, at least two of us within ESS-core  have recently
acknowledged we'd want to aim for an official ESS release
where we'd aim to also release an 'ESS+' = {ess + (much of) polymode}
bundle.

> This update required much more time than I originally thought, but 
everything is in place now. You will notice that I merged the two projects 
"Emacs Modified for macOS" and "Emacs Modified for Windows" under the umbrella 
project "Emacs Modified for (macOS|Windows)". A little touch of geekiness in 
the name is Good. (I flirted with the idea to use the true Emacs-lisp regex 
'\(macOS\|Windows\)', but it was too much.) :-D

Thank you very much, Vincent,  for doing this,
in the name of the whole ESS users community !

I will be happy to make use of it myself for the Windows version (on a
Windows terminal server) when I do test  R things on Windows.

> I hope an editor of the ESS web page will read this; could you please 
update the links on the Download page?

I did ( ~  4 hours ago ).
Best regards,
Martin


> Best,
> v.

> Vincent Goulet
> Professeur titulaire
> École d'actuariat, Université Laval

> * https://stat.ethz.ch/pipermail/ess-help/2022-April/013050.html
> __
> ESS-help@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/ess-help

__
ESS-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help

Re: [R] Numerical stability of: 1/(1 - cos(x)) - 2/x^2

[Martin Maechler]

> Iris Simmons 
> on Wed, 16 Aug 2023 02:57:48 -0400 writes:

> You might also be able to rewrite
> log(1 - cos(x))

> as

> log1p(-cos(x))

> On Wed, Aug 16, 2023, 02:51 Iris Simmons  wrote:

>> You could rewrite
>> 
>> 1 - cos(x)
>> 
>> as
>> 
>> 2 * sin(x/2)^2
>> 
>> and that might give you more precision?

Thank you, Iris,
yes, both suggestions are excellent *and* necessary.

Note that this is part  "numerical analysis 101"
and is called "cancellation":

Direct evaluation of  1 - cos(x)  for small 'x'  *cannot* ever
be numerically accurate and suffers from cancellation.

log(1+x) for small x  is slightly more subtle than pure
cancellation, but exactly the same reason we introduced  log1p()
{and expm1(); then even cospi(), sinpi() etc}
into R  even before it was widely adopted in C math libraries.

Martin


>> On Wed, Aug 16, 2023, 01:50 Leonard Mada via R-help 

>> wrote:
>> 
>>> Dear R-Users,
>>> 
>>> I tried to compute the following limit:
>>> x = 1E-3;
>>> (-log(1 - cos(x)) - 1/(cos(x)-1)) / 2 - 1/(x^2) + log(x)
>>> # 0.4299226
>>> log(2)/2 + 1/12
>>> # 0.4299069
>>> 
>>> However, the result diverges as x decreases:
>>> x = 1E-4
>>> (-log(1 - cos(x)) - 1/(cos(x)-1)) / 2 - 1/(x^2) + log(x)
>>> # 0.9543207
>>> # correct: 0.4299069
>>> 
>>> I expected the precision to remain good with x = 1E-4 or x = 1E-5.
>>> 
>>> This part blows up - probably some significant loss of precision of
>>> cos(x) when x -> 0:
>>> 1/(cos(x) - 1) - 2/x^2
>>> 
>>> Maybe there is some room for improvement.
>>> 
>>> Sincerely,
>>> 
>>> Leonard
>>> ==
>>> The limit was part of the integral:
>>> up = pi/5;
>>> integrate(function(x) 1 / sin(x)^3 - 1/x^3 - 1/(2*x), 0, up)
>>> (log( (1 - cos(up)) / (1 + cos(up)) ) +
>>> + 1/(cos(up) - 1) + 1/(cos(up) + 1) + 2*log(2) - 1/3) / 4 +
>>> + (1/(2*up^2) - log(up)/2);
>>> 
>>> # see:
>>> 
>>> 
https://github.com/discoleo/R/blob/master/Math/Integrals.Trig.Fractions.Poly.R
>>> 
>>> __
>>> R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
>>> https://stat.ethz.ch/mailman/listinfo/r-help
>>> PLEASE do read the posting guide
>>> http://www.R-project.org/posting-guide.html
>>> and provide commented, minimal, self-contained, reproducible code.
>>> 
>> 

> [[alternative HTML version deleted]]

> __
> R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide 
http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] Style guide when using "R" in a title

[Martin Maechler]

> Bert Gunter 
> on Wed, 26 Jul 2023 16:05:32 -0700 writes:

> https://www.r-project.org/logo/

> Cheers, Bert

Well, I tend to disagree.

He did not say he'd want to use the R logo
and there is really nobody saying that "you should".

Using the letter 'R' as are regular word (noun) in a title is
perfectly fine.

Martin

> On Wed, Jul 26, 2023 at 4:01 PM Wadsworth, Spencer G
> [STAT]  wrote:
>> 
>> Hello,
>> 
>> I am working on a small booklet to be used with an
>> existing statistics textbook. The purpose of the booklet
>> is to give worked through examples from the textbook
>> using R code and it will be made publicly available with
>> the textbook. The title of the booklet is "R Code
>> Supplement for Basic Engineering Data Collection and
>> Analysis by Vardeman and Jobe".  Someone with whom I'm
>> working on the booklet said that the "R" in the title
>> might need to follow a specific style guide given by the
>> R-project. Is this accurate? Is there a particular font I
>> should use?
>> 
>> Thanks, Spencer
>> 
>> [[alternative HTML version deleted]]
>> 
>> __
>> R-help@r-project.org mailing list -- To UNSUBSCRIBE and
>> more, see https://stat.ethz.ch/mailman/listinfo/r-help
>> PLEASE do read the posting guide
>> http://www.R-project.org/posting-guide.html and provide
>> commented, minimal, self-contained, reproducible code.

> __
> R-help@r-project.org mailing list -- To UNSUBSCRIBE and
> more, see https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide
> http://www.R-project.org/posting-guide.html and provide
> commented, minimal, self-contained, reproducible code.

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] change language at console

[Martin Maechler]

>>>>> Rich Shepard via R-help 
>>>>> on Tue, 18 Jul 2023 10:32:51 - writes:

  > On Wed, 1 Apr 2015, Prof Brian Ripley wrote: 
  >  I would start by trying LANGUAGE=en , e.g. ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​

  > More specifically, you can use en_US or en_GB.  Rich

"en_US" actually does not exist -- see below (but "en"
corresponds to it).

More relevantly, since R 4.2.0  we have

  Sys.setLanguage()

which does slightly more than setting LANGUAGE, notably
internally using  bindtextdomain() in a useful way, such that
the "translation cache" (of already translated messages) is flushed;
It was first considered in response to R's bugzilla issue PR#18055
  --> https://bugs.r-project.org/bugzilla/show_bug.cgi?id=18055

Note that help(Sys.setLanguage) 's examples
contain quite interesting R code , for example the following
(shown with R output here in R 4.3.1 with NLS (:=
Natural Language Support) enabled {as usual I think}, under
Linux (Fedora 36):


>  ## A show off of translations -- platform (font etc) dependent:
>  ## The translation languages available for "base" R in this version of R:

>  if(capabilities("NLS")) withAutoprint({
+langs <- list.files(bindtextdomain("R"),
+pattern = "^[a-z]{2}(_[A-Z]{2}|@quot)?$")
+langs
+txts <- sapply(setNames(,langs),
+   function(lang) { Sys.setLanguage(lang)
+   gettext("incompatible dimensions", 
domain="R-stats") })
+cbind(txts)
+(nTrans <- length(unique(txts)))
+(not_translated <- names(txts[txts == txts[["en"]]]))
+  })
> langs <- list.files(bindtextdomain("R"), pattern = 
> "^[a-z]{2}(_[A-Z]{2}|@quot)?$")
> langs
 [1] "da"  "de"  "en"  "en_GB"   "en@quot" "es"  "fa"  "fr" 
 "it" 
[10] "ja"  "ko"  "lt"  "nn"  "pl"  "pt_BR"   "ru"  "tr" 
 "zh_CN"  
[19] "zh_TW"  
> txts <- sapply(setNames(, langs), function(lang) {
+ Sys.setLanguage(lang)
+ gettext("incompatible dimensions", domain = "R-stats")
+ })
> cbind(txts)
txts
da  "incompatible dimensions"   
de  "inkompatible Dimensionen"  
en  "incompatible dimensions"   
en_GB   "incompatible dimensions"   
en@quot "incompatible dimensions"   
es  "incompatible dimensions"   
fa  "incompatible dimensions"   
fr  "dimensions incompatibles"  
it  "dimensioni incompatibili"  
ja  " 矛盾した次元です "
ko  "incompatible dimensions"   
lt  "nesuderinami matavimo skaičiai"
nn  "incompatible dimensions"   
pl  "niezgodne wymiary" 
pt_BR   "dimensões incompatíveis"   
ru  "несовместимые размерности" 
tr  "uyumsuz boyutlar"  
zh_CN   "维度不相配"
zh_TW   "維度不符合"
> (nTrans <- length(unique(txts)))
[1] 12
> (not_translated <- names(txts[txts == txts[["en"]]]))
[1] "da"  "en"  "en_GB"   "en@quot" "es"  "fa"  "ko"  "nn"  
   

---

In the original NEWS for R 4.2.0 ,
Sys.setLanguage() was labeled as "partly experimental"  but I
think in the mean time has shown some stability  and I'd
recommend its use {such that we find out if should be made even
more reliable}.

Martin

--
Martin Maechler
ETH Zurich  and  R Core team

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] Variable and value labels

[Martin Maechler]

> Anupam Tyagi 
> on Wed, 12 Jul 2023 09:18:55 +0530 writes:

> Hello,

> is there an easy way to do variable and value labels (for
> factor variables) in base-R, without using a package. 

Yes, there are many.
How many help pages (in R , i.e. base-R)  did you consult?

Very general questions as the above are not very useful,
because typically the only concised answer can be yes/no.


> If not, what is an easy and good way to do labels, using an
> add-on package.


> -- 
> Anupam.

>   [[alternative HTML version deleted]]

> __
> R-help@r-project.org mailing list -- To UNSUBSCRIBE and
> more, see https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide
> http://www.R-project.org/posting-guide.html and provide
> commented, minimal, self-contained, reproducible code.

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] printCoefmat() and zap.ind

[Martin Maechler]

>>>>> Martin Maechler 
>>>>> on Fri, 7 Jul 2023 18:12:24 +0200 writes:

>>>>> Shu Fai Cheung 
>>>>> on Thu, 6 Jul 2023 17:14:27 +0800 writes:

>> Hi All,

>> I would like to ask two questions about printCoefmat().

> Good... this function, originally named print.coefmat(),
> is 25 years old (in R) now:

> 
> r1902 | maechler | 1998-08-14 19:19:05 +0200 (Fri, 14 Aug 1998) |
> Changed paths:
> M R-0-62-patches/CHANGES
> M R-0-62-patches/src/library/base/R/anova.R
> M R-0-62-patches/src/library/base/R/glm.R
> M R-0-62-patches/src/library/base/R/lm.R
> M R-0-62-patches/src/library/base/R/print.R

> print.coefmat(.) about ok
> 

> (yes, at the time, the 'stats' package did not exist yet ..)

> so it may be a good time to look at it.


>> First, I found a behavior of printCoefmat() that looks strange to me,
>> but I am not sure whether this is an intended behavior:

>> ``` r
>> set.seed(5689417)
>> n <- 1
>> x1 <- rnorm(n)
>> x2 <- rnorm(n)
>> y <- .5 * x1 + .6 * x2 + rnorm(n, -0.0002366, .2)
>> dat <- data.frame(x1, x2, y)
>> out <- lm(y ~ x1 + x2, dat)
>> out_summary <- summary(out)
>> printCoefmat(out_summary$coefficients)
>> #>   Estimate Std. Error t value Pr(>|t|)
>> #> (Intercept) 1.7228e-08 1.9908e-030.001
>> #> x1  5.0212e-01 1.9715e-03  254.70   <2e-16 ***
>> #> x2  6.0016e-01 1.9924e-03  301.23   <2e-16 ***
>> #> ---
>> #> Signif. codes:  0 '***' 0.001 '**' 0.01 '*' 0.05 '.' 0.1 ' ' 1

>> printCoefmat(out_summary$coefficients,
>> zap.ind = 1,
>> digits = 4)
>> #> Estimate Std. Error t value Pr(>|t|)
>> #> (Intercept) 0.00   0.001991 0.01
>> #> x1  0.502100   0.001971   254.7   <2e-16 ***
>> #> x2  0.600200   0.001992   301.2   <2e-16 ***
>> #> ---
>> #> Signif. codes:  0 '***' 0.001 '**' 0.01 '*' 0.05 '.' 0.1 ' ' 1
>> ```

>> With zap.ind = 1, the values in "Estimate" were correctly
>> zapped using digits = 4. However, by default, "Estimate"
>> and "Std. Error" are formatted together. Because the
>> standard errors are small, with digits = 4, zero's were added
>> to values in "Estimate", resulting in "0.502100" and
>> "0.600200", which are misleading because, if rounded to
>> the 6th decimal place, the values to be displayed should
>> be "0.502122" and "0.600162".

>> Is this behavior of printCoefmat() intended/normal?

> Yes, this is "normal" in the sense that zapsmall() is used.
> I'm not even sure anymore if I was always aware 1998 what exactly the
> simple zapsmall() function is doing.
> It does not do what you want here (and actually *typically* want
> for formatting numbers for display, plotting, etc):
> You "really want" here and in such situations

> zapOnlysmall <- function(x, dig) {
>x[abs(x) <= 10^-dig] <- 0
>x
> }

> and I think I'd replace the use of zapsmall() inside
> printCoefmat() with something like zapOnlysmall() above.

> This will indeed nicely solve your problem.

well..., now that I tried to change it "globally" in
printCoefmat() and I see how many of the lm() summary or anova()
outputs .. outputs that get slightly changed, and sometimes
quite unfavourably,

I think that the "hard" replacement of zapsmall() by
zapOnlysmall() {above}  is too drastic, ... even though it helps
in your case.

... back to the "drawing board" ...

Martin


>> Second, how can I use zap without this behavior?
>> In cases like the one above, I need to use zap such that
>> the intercept will not be displayed in scientific notation.
>> Disabling scientific notation cannot achieve the desired
>> goal.


>> I tried adding cs.ind = 1:

> well, from the help page   ?printCoefmat  

> cs.ind is really about the [ind]ices of [c]oefficient + [s]cale or 
[s]td.err
> So, for lm() you should not have to set cs.ind but rather keep
> it at it's smart default of cs.ind = 1:2 .


>> ```r
>> printCoefmat(out_summary$coefficients,
   

Re: [R] printCoefmat() and zap.ind

[Martin Maechler]

> Shu Fai Cheung 
> on Thu, 6 Jul 2023 17:14:27 +0800 writes:

> Hi All,

> I would like to ask two questions about printCoefmat().

Good... this function, originally named print.coefmat(),
is 25 years old (in R) now:

  
  r1902 | maechler | 1998-08-14 19:19:05 +0200 (Fri, 14 Aug 1998) |
  Changed paths:
 M R-0-62-patches/CHANGES
 M R-0-62-patches/src/library/base/R/anova.R
 M R-0-62-patches/src/library/base/R/glm.R
 M R-0-62-patches/src/library/base/R/lm.R
 M R-0-62-patches/src/library/base/R/print.R

  print.coefmat(.) about ok
  

  (yes, at the time, the 'stats' package did not exist yet ..)

so it may be a good time to look at it.


> First, I found a behavior of printCoefmat() that looks strange to me,
> but I am not sure whether this is an intended behavior:

> ``` r
> set.seed(5689417)
> n <- 1
> x1 <- rnorm(n)
> x2 <- rnorm(n)
> y <- .5 * x1 + .6 * x2 + rnorm(n, -0.0002366, .2)
> dat <- data.frame(x1, x2, y)
> out <- lm(y ~ x1 + x2, dat)
> out_summary <- summary(out)
> printCoefmat(out_summary$coefficients)
> #>   Estimate Std. Error t value Pr(>|t|)
> #> (Intercept) 1.7228e-08 1.9908e-030.001
> #> x1  5.0212e-01 1.9715e-03  254.70   <2e-16 ***
> #> x2  6.0016e-01 1.9924e-03  301.23   <2e-16 ***
> #> ---
> #> Signif. codes:  0 '***' 0.001 '**' 0.01 '*' 0.05 '.' 0.1 ' ' 1

> printCoefmat(out_summary$coefficients,
> zap.ind = 1,
> digits = 4)
> #> Estimate Std. Error t value Pr(>|t|)
> #> (Intercept) 0.00   0.001991 0.01
> #> x1  0.502100   0.001971   254.7   <2e-16 ***
> #> x2  0.600200   0.001992   301.2   <2e-16 ***
> #> ---
> #> Signif. codes:  0 '***' 0.001 '**' 0.01 '*' 0.05 '.' 0.1 ' ' 1
> ```

> With zap.ind = 1, the values in "Estimate" were correctly
> zapped using digits = 4. However, by default, "Estimate"
> and "Std. Error" are formatted together. Because the
> standard errors are small, with digits = 4, zero's were added
> to values in "Estimate", resulting in "0.502100" and
> "0.600200", which are misleading because, if rounded to
> the 6th decimal place, the values to be displayed should
> be "0.502122" and "0.600162".

> Is this behavior of printCoefmat() intended/normal?

Yes, this is "normal" in the sense that zapsmall() is used.
I'm not even sure anymore if I was always aware 1998 what exactly the
simple zapsmall() function is doing.
It does not do what you want here (and actually *typically* want
for formatting numbers for display, plotting, etc):
You "really want" here and in such situations

  zapOnlysmall <- function(x, dig) {
  x[abs(x) <= 10^-dig] <- 0
  x
  }

and I think I'd replace the use of zapsmall() inside
printCoefmat() with something like zapOnlysmall() above.

This will indeed nicely solve your problem.


> Second, how can I use zap without this behavior?
> In cases like the one above, I need to use zap such that
> the intercept will not be displayed in scientific notation.
> Disabling scientific notation cannot achieve the desired
> goal.


> I tried adding cs.ind = 1:

well, from the help page   ?printCoefmat  

cs.ind is really about the [ind]ices of [c]oefficient + [s]cale or [s]td.err
So, for lm() you should not have to set cs.ind but rather keep
it at it's smart default of cs.ind = 1:2 .


> ```r
> printCoefmat(out_summary$coefficients,
> zap.ind = 1,
> digits = 4,
> cs.ind = 1)
> #> Estimate Std. Error t value Pr(>|t|)
> #> (Intercept)   0.   0.001991 0.01
> #> x10.5021   0.001971   254.7   <2e-16 ***
> #> x20.6002   0.001992   301.2   <2e-16 ***
> #> ---
> #> Signif. codes:  0 '***' 0.001 '**' 0.01 '*' 0.05 '.' 0.1 ' ' 1
> ```

> However, this solution is not ideal because the numbers
> of decimal places of "Estimate" and "Std. Error" are
> different. How can I get the output like this one?


> ```r
> #> Estimate Std. Error t value Pr(>|t|)
> #> (Intercept)   0.   0.0020 0.01
> #> x10.5021   0.0020   254.7   <2e-16 ***
> #> x20.6002   0.0020   301.2   <2e-16 ***
> ```

> Thanks for your attention.

> Regards,
> Shu Fai Cheung

Thank you, Shu Fai,
for your careful and thoughtful report!

Best regards,
Martin

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [ESS] ESS "taking over" {[Rd] New behavior when running script in package directory?}

[Martin Maechler via ESS-help]

> Mikael Jagan 
> on Wed, 21 Jun 2023 12:41:02 -0400 writes:

> Surely this behaviour is just a case of ESS being "too clever", sourcing
> *.R files in special way when it detects that a file belongs to a package
> (loading dependencies automatically, etc.)?

> The function ss() is defined inside of .ess.source(), which is defined 
here:

> 
https://github.com/emacs-ess/ESS/blob/5c4ae91cefa5c56fd13b204a9a996825af836a67/etc/ESSR/R/.basic.R#L168

> If you think that there is a bug, then you could report it there ...

> Mikael

Yes.  Unfortunately, there are quite a few other of such
instances, which are much time consuming to me (notably as
ESS/polymode then also again and again tries to gather info
about all of the 20'000+ packages in my .libPaths() .. which
slows down even opening an existing *.R file sometimes !!)

where ESS "takes over" seemlingly almost all of Emacs, including
notably often times my *shell* buffer in emacs ..

This should *REALLY* be switched to ESS-help (and
possibly/ideally github issues for ESS) now,
and so I will CC this to ESS-help only -- no longer to R-devel
(to which I'll post a pointer to this message on ESS-help).

Martin

> On 2023-06-21 6:00 am, r-devel-requ...@r-project.org wrote:
>> When I run a script foo.R containing some trivial code in my home
>> directory, via Emacs/ESS, everything works as expected: R
>> starts, and a setwd() command to set the working directory is
>> run automatically before the code in the script is run.
>> 
>> But if I copy foo.R to some package/R directory strange
>> things happen. When I use Emacs/ESS to run the script
>> in its new location, R starts, and setwd() is called to set
>> the working directory, but then one or more libraries that the
>> package depends on are loaded, even though I am using no
>> libraries in foo.R.
>> 
>> Now consider foo.R that contains the following trivial code:
>> secsToRDateTime <- function(secs) {
>> day2sec <- 60*60*24
>> days <- secs/day2sec
>> }
>> 
>> When I try to run this from package/R I get...
>> 
>> Error in ss(file, echo = visibly, local = local, print.eval = output,  :
>> /tmp/gpstime.R!CuSewT:2:0: unexpected end of input
>> 1: secsToRDateTime <- function(secs) {
>> ^
>> 
>> As I said, there are no problems when the script is run from my
>> home directory. This suggests that test scripts can no longer be
>> tested in a package's R directory?
>> 
>> Is this true?
>> 
>> Thanks,
>> Dominick

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

__
ESS-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help

Re: [R] warnng to an error....

[Martin Maechler]

> akshay kulkarni 
> on Sat, 17 Jun 2023 18:35:53 + writes:

> Dear Bert, Duncan's theory is workingprobably the same
> as yours...

"theory" .. well *truth*.



Note that I wrote a blog post I had hope would be read more
( --> and be cited more .. when helping peopling with such problems ;-))

Simple search ("google") for  "class think R blog"
or directly
  https://blog.r-project.org/2019/11/09/when-you-think-class.-think-again/

To say it again:   Using  something like

if(... class(x) == "" ..)

is almost always (*) bad code.
Everyone should learn about  inherits() and why sane R code
should use that instead.

---
*)  It may be ok, e.g., when `x` was very expliclitly
constructed in the same part of code a bit earlier

Martin


> THanking you, Yours sincerely, AKSHAY M KULKARNI
>  From: Bert Gunter
>  Sent: Saturday, June 17, 2023
> 11:28 PM To: akshay kulkarni  Cc: R
> help Mailing list  Subject: Re: [R]
> warnng to an error

> What is class(x) ??

> I think you need to (re?) learn about S3 classes, which
> can in general be vectors. See ?class (the S3 portion) or
> any tutorial on S3 classes in R. I have no idea what you
> are trying to do, but I *suspect* it may be accomplished
> through S3 inheritance rather than changing the class
> vector. That is just a guess, however.

> -- Bert

> On Sat, Jun 17, 2023 at 10:27 AM akshay kulkarni
> mailto:akshay...@hotmail.com>>
> wrote: Dear members, AN update: I have changed the if
> clause to:

> if(class(x)[1] == "xts") || class(x)[2] == "zoo") {code}

> but am bootless.

> PLease help...

> THanking you, Yours sincerely, AKSHAY M KULKARNI

>  From: R-help
> mailto:r-help-boun...@r-project.org>>
> on behalf of akshay kulkarni
> mailto:akshay...@hotmail.com>>
> Sent: Saturday, June 17, 2023 10:46 PM To: R help Mailing
> list mailto:r-help@r-project.org>>
> Subject: [R] warnng to an error

> Dear members,

>   I have the following code:

>> FUN(OHLCDataEP[[63]])
> Error in (class(x) == "xts") || (class(x) == "zoo") :
> 'length = 2' in coercion to 'logical(1)'
>> traceback()
> 2: ygix(x, "c") at #9 1: FUN(OHLCDataEP[[63]])
>> class(OHLCDataEP[[63]])
> [1] "xts" "zoo"

> The following is in ygix() :

> if((class(x) == "xts") || (class(x) == "zoo")

> I think this would have been a warning
> 
(https://stackoverflow.com/questions/72848442/r-warning-lengthx-2-1-in-coercion-to-logical1)
> but I am on a ubuntu22.04 machine with R 4.3.0.

> What should I do? Change it to: if((class(x)[1] == "xts")
> || (class(x)[2] == "zoo")) {code}...

> or is there any workaround?

> THanking you, Yours sincerely, AKSHAY M KULKARNI
> 
[https://cdn.sstatic.net/Sites/stackoverflow/Img/apple-touch-i...@2.png?v=73d79a89bded]
> R Warning 'length(x) = 2 > 1' in coercion to
> 
'logical(1)'
> Using R 4.1.3 I observe: var - 0 
> if(is.data.frame(var) || is.vector(var)) var -
> as.matrix(var)  is.null(var) || (!is.matrix(var)
>  var == 0) || (dim(var)==c(1,1) 
> stackoverflow.com 



> [[alternative HTML version deleted]]

> __
> R-help@r-project.org mailing
> list -- To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do
> read the posting guide
> http://www.R-project.org/posting-guide.html and provide
> commented, minimal, self-contained, reproducible code.

> [[alternative HTML version deleted]]

> __
> R-help@r-project.org mailing
> list -- To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do
> read the posting guide
> http://www.R-project.org/posting-guide.html and provide
> commented, minimal, self-contained, reproducible code.

>   [[alternative HTML version deleted]]

> __
> R-help@r-project.org mailing list -- To UNSUBSCRIBE and
> more, see https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide
> http://www.R-project.org/posting-guide.html and provide
> commented, minimal, self-contained, reproducible code.

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide 

Re: [R] error in arfima...

[Martin Maechler]

>>>>> akshay kulkarni 
>>>>> on Mon, 5 Jun 2023 14:11:12 + writes:

> Dear Martin,
> Sad that the bug is beyond your ken...

well, that's not exactly what I tried to say
(and I did ask you for more output from your R session and
 also asked about what happens if you try things several time in
 a row, etc).

At the moment, it looks to me that nobody can reproduce the
problem with what you've given, and my personal guess is that
something is "bad" only on your computer, i.e., your combination
of hardware, software, your R installation, your installation of the forecast 
package
and its many dependencies (other R packages), etc.
..


> Fortunately, the error happens only rarely...The length of LYGH was 719 
and there were only two such errors..I will just replace them with NA and make 
do.

> By the by, what if I send LYGH as an attachment to your actual mail ( not 
the r-help mail)? Will it help? Can you then pinpoint the cause?

Yes, please do that. Make the file "LYGH.rds" available (on the
web or send to me) which you get after

  saveRDS(LYGH, file="LYGH.rds")


> Or should I raise a bug report? If yes, how( I never raised one)?

We don't know yet if there is any bug, see above.
Martin

> THanking you,
> Yours sincerely,
    > AKSHAY M KULKARNI
> 
> From: Martin Maechler 
    > Sent: Monday, June 5, 2023 3:19 PM
> To: akshay kulkarni 
> Cc: Martin Maechler ; R help Mailing list 

> Subject: Re: [R] error in arfima...


>> Dear Martin,
>> REgrets to reply this late

>> I am staring at a conundrum never before encountered in my experience 
with R:

>> LYGH[[201]]
>> [1] 45.40  3.25  6.50  2.15
>> > arfima(LYGH[[201]])
>> Error in .fdcov(x, fdf$d, h, nar = nar, nma = nma, hess = hess, fdf.work 
= fdf$w) :
>> NA/NaN/Inf in foreign function call (arg 5)
>> > arfima(c(45.40,3.25,6.50,2.15))

>> Call:
>> arfima(y = c(45.4, 3.25, 6.5, 2.15))

>> Coefficients:
>> d
>> 4.583013e-05
>> sigma[eps] = 18.01252
>> a list with components:
>> [1] "log.likelihood"  "n"   "msg" "d"
   "ar"
>> [6] "ma"  "covariance.dpq"  "fnormMin""sigma"
   "stderror.dpq"
>> [11] "correlation.dpq" "h"   "d.tol"   "M"   
"hessian.dpq"
>> [16] "length.w""residuals"   "fitted"  "call"
"x"
>> [21] "series"

>> Please note that the index of LYGH has changed from 202 to 201 due to 
some randomness in one of my function.

>> PLEASE HELP.

>> Output of dput LYGH[[201]]:

>> > dput(LYGH[[201]])
>> c(45.4, 3.25, 6.5, 2.149998)

>> output of session info()

>> sessionInfo()
>> R version 4.1.2 (2021-11-01)
>> Platform: x86_64-w64-mingw32/x64 (64-bit)
>> Running under: Windows Server x64 (build 14393)

>> Matrix products: default

>> locale:
>> [1] LC_COLLATE=English_United States.1252  LC_CTYPE=English_United 
States.1252
>> [3] LC_MONETARY=English_United States.1252 LC_NUMERIC=C
>> [5] LC_TIME=English_United States.1252

>> attached base packages:
>> [1] parallel  stats graphics  grDevices utils datasets  methods  
 base

>> other attached packages:
>> [1] pbmcapply_1.5.1 imputeTS_3.3forecast_8.17.0

>> loaded via a namespace (and not attached):
>> [1] Rcpp_1.0.7urca_1.3-3pillar_1.9.0  compiler_4.1.2 
   tseries_0.10-51
>> [6] tools_4.1.2   xts_0.12.1nlme_3.1-153  
lifecycle_1.0.3   tibble_3.2.1
>> [11] gtable_0.3.3  lattice_0.20-45   pkgconfig_2.0.3   rlang_1.1.0   
cli_3.6.1
>> [16] rstudioapi_0.14   curl_4.3.2xml2_1.3.3dplyr_1.1.1   
generics_0.1.3
>> [21] vctrs_0.6.1   gridtext_0.1.5ggtext_0.1.2  lmtest_0.9-40 
grid_4.1.2
>> [26] nnet_7.3-16   tidyselect_1.2.0  glue_1.6.2R6_2.5.1  
fansi_1.0.4
>> [31] ggplot2_3.4.2 TTR_0.24.3magrittr_2.0.3scales_1.2.1  
quantmod_0.4.20
>> [36] timeDate_4021.106 colorspace_2.1-0  fracdiff_1.5-1
quadprog_1.5-8utf8_1.2.3
>> [41] stinepack_1.4 munsell_0.5.0 zoo_1.8-10


>> PLease Also note:

>> arfima(c(45.4, 3.25, 

Re: [R] error in arfima...

[Martin Maechler]

 utils methods   base

> other attached packages:
> [1] forecast_8.21  fortunes_1.5-4 sfsmisc_1.1-15

> loaded via a namespace (and not attached):
>  [1] gtable_0.3.3  dplyr_1.1.2   compiler_4.3.0
>  [4] tidyselect_1.2.0  Rcpp_1.0.10   parallel_4.3.0
>  [7] scales_1.2.1  lattice_0.21-8ggplot2_3.4.2
> [10] R6_2.5.1  generics_0.1.3curl_5.0.0
> [13] lmtest_0.9-40 tibble_3.2.1  munsell_0.5.0
> [16] nnet_7.3-19   timeDate_4022.108 pillar_1.9.0
> [19] rlang_1.1.1   quantmod_0.4.22   utf8_1.2.3
> [22] urca_1.3-3quadprog_1.5-8cli_3.6.1
> [25] magrittr_2.0.3xts_0.13.1grid_4.3.0
> [28] nlme_3.1-162  lifecycle_1.0.3   fracdiff_1.5-2
> [31] vctrs_0.6.2   glue_1.6.2tseries_0.10-54
> [34] zoo_1.8-12fansi_1.0.4   colorspace_2.1-0
> [37] TTR_0.24.3tools_4.3.0   pkgconfig_2.0.3
> >
> ##---end__R_transcript---


> Note that your error message pointed me to my (old, but still
> fine) package {fracdiff} with its principal function fracdiff()
> around which   arfima()  is a user-friendly and
> generalization wrapper.

> In other words arfima() calls fracdiff::fracdiff() and the error
> happens there --- for you, but not for me, if I try to use the
> same data as you.
> I see that you must have found that too, because you mentioned
>View(environment(fracdiff)$.fdcov)

> Maybe you need to

>   update.packages()

> {which should re-install R packages you have installed but which
>  have become outdated in the mean time}

> If the error persists, please send us the output of

> 1)
>dput(LYGH[[202]])

>so we get your exact data

> 2)
>sessionInfo()

>so we get much info about your R "setup"

>  last but not least:  If you are really calling arfima()
> with a time series of length 4  (which your LYGH[[202]] above
> seems to suggest)
> then you really need to learn a bit about the tools you are
> using: It really does not make any sense to fit a somewhat
> sophisticated time-series model (or *any* time-series model, I'd say)
> to a "series" with 4 values.

> Best regards,
> Martin

> --
> Martin Maechler
> ETH Zurich  and  R Core team

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] error in arfima...

[Martin Maechler]

ion fracdiff()
around which   arfima()  is a user-friendly and
generalization wrapper.

In other words arfima() calls fracdiff::fracdiff() and the error
happens there --- for you, but not for me, if I try to use the
same data as you.
I see that you must have found that too, because you mentioned
   View(environment(fracdiff)$.fdcov)

Maybe you need to

  update.packages()

{which should re-install R packages you have installed but which
 have become outdated in the mean time}

If the error persists, please send us the output of

1)
   dput(LYGH[[202]])

   so we get your exact data

2)
   sessionInfo()

   so we get much info about your R "setup"

 last but not least:  If you are really calling arfima()
with a time series of length 4  (which your LYGH[[202]] above
seems to suggest)
then you really need to learn a bit about the tools you are
using: It really does not make any sense to fit a somewhat
sophisticated time-series model (or *any* time-series model, I'd say) 
to a "series" with 4 values.

Best regards,
Martin

--
Martin Maechler
ETH Zurich  and  R Core team

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

[R] Asking about R "Security" ..

[Martin Maechler]

> Ivan Krylov 
> on Wed, 17 May 2023 11:52:27 +0300 writes:

> В Tue, 16 May 2023 13:47:19 +
> "MAJID, Ayesha \(NHS ENGLAND - X26\) via R-help" 

[ . ]
[ . ]
[ .. helpful & useful answers / pointers to public information .. ]
[ . ]
[ . ]

> (Did you mean to ask these questions at the public mailing list open
> for J. Random Hackers like me to answer?)

> -- 
> Best regards,
> Ivan

Actually, people typically ask "the R Foundation" or even
individual RF / R-core members such as me about this ...

... as if we were a company with staff to answer such questions;
but we (volunteering individuals) really do *not* have the time
resources for that,
and consequently, also in my function---shared with another few
individuals---as gatekeeper to the R foundation / R core / R webmaster
e-mail addresses, I typically deflect such questions to the
public web sites *and* public e-mail lists.

The big advantage of this approach is that at least the answers
are findable by web searches in the future, and so, hopefully
have to be answered less frequently by volunteers as you, Ivan,
for whom we are really very grateful.

Martin

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] Regex Split?

[Martin Maechler]

>>>>> Bill Dunlap on Fri, 5 May 2023 08:19:21 -0700 writes:

https://bugs.r-project.org/show_bug.cgi?id=16745 (from 2016, still labelled
 'UNCONFIRMED") contains some other examples of strsplit misbehaving when
using 0-length perl look-behinds.  E.g.,

Thank you, Bill -- yes, uhmm, ... a bit embarrassing.

I've finally changed the R bugzilla report's state to "CONFIRMED" now,
and also added the "HELPWANTED" keyword.
I think we (R Core) should be sorry to have (forgotten / not
cared about) the issue completely.

It's not hard to at least agree that the current behavior is buggy,
e.g., in the example you show here :

>> strsplit(split="[[:<:]]", "One, two; three!", perl=TRUE)[[1]]
> [1] "O"  "n"  "e"  ", " "t"  "w"  "o"  "; " "t"  "h"  "r"  "e"  "e"  "!"
>> gsub(pattern="[[:<:]]", "#", "One, two; three!", perl=TRUE)
    > [1] "#One, #two; #three!"

[...]
[...]

Maybe this should be continued either on Bugzilla (i.e., the URL above),
or if needed, additionally  on R-devel.

Yes, I also added that we'd grateful for (tested) patches and/or
code reviewers.

Martin


--
Martin Maechler
ETH Zurich  and  R Core team

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] "prob" package alternative

[Martin Maechler]

> peter murage 
> on Tue, 4 Apr 2023 06:24:56 + writes:

> Which package in R replaced package prob?

Well, if you google that you should quickly be lead to
(something I even think makes sense to memorize as "rule"
  package= ) :

  https://CRAN.R-project.org/package=prob

which now says that the package was archived as it depended on
another package that was archived.

Both are still there -- in the CRAN archive --
but to install them may be a bit of work particularly if you are
on Windows (as it suggeested you are via a Microsoft "add" at
the end of your R-help post ..).
One way I'd use is Winbuilder
(which will require you to set yourself as formal "Maintainer" of
 the package before submission).

An alternative may be to use Rhub ..
or then learn to do it yourself, by installing the "Rtools" (for Windows):
---> https://cran.r-project.org/bin/windows/Rtools/
 
With best regards,
Martin

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] Flickering when scrolling in R graphics windows

[Martin Maechler]

> Ziyun Tang 
> on Sat, 21 Jan 2023 15:14:15 -0500 writes:

> Hello, I have been experiencing some issues regarding scrolling with
> the mouse or trackpad in R graphics windows (from the base graphics
> package), which sometimes results in flickering, and wanted to see if
> anyone else had the same issues, or any advice. This happens for R
> version 4.2.2 on Windows 10 x64, and occurs when using Rgui and at the
> command line (whenever graphics windows are invoked). Note that some
> of the example code below can cause flickering and can be an issue for
> those with photosensitive epilepsy.

> Specifically, I have been experiencing three main issues, as follows:

> 1. When viewing a dataset with View(), the graphics window flickers
> when scrolling downwards too quickly, even with the option
> buffered=TRUE. For example:
>> View(iris)

If you use [Page Up]  and [Page Down]  there is no "flickering",
also using the cursor (up/down "arrows").
Still here, I would not think anything to be "wrong".
If you tell the computer to refresh a screen more quickly than
makes sense I guess you must expect what you see here.
(but yes, more modern GUIs would do 'smooth scrolling' here; I
 think that's not available for the graphapp GUI in R for Windows)

By "scrolling", what exactly do you mean?
Is it that you use your mouse "wheel"? ...  I assume "yes" in
the following, because in that case I can partly reproduce what
you describe.


> 2. When viewing a graph with plot(), and scrolling down, the graphics
> window flickers between the background and the graph itself. For
> example:
>> plot(iris$Sepal.Length, iris$Sepal.Width)

At first I wrote
   I don't understand how you can "scroll down" in this plot

but now that I've guessed you mean "mouse wheel scrolling" I can
indeed see what you describe.

> 3. When viewing a matrix of scatterplots with pairs(), and scrolling
> down, the graphics window flickers between the background and the
> individual scatterplots. In some instances, when scrolling down with
> the trackpad, the window flickers continuously, and subsequently
> closing the window crashes R. For example:
>> pairs(iris[1:4])

That you bring R to crash just by "scrolling" really seems a bad
thing and points to a bug.
OTOH, I have not been able to replicate a crash.

I don't know what mouse-wheel-scrolling should do in a graphics window
in R for Windows.
In our terminal server version of Windows,
using Rterm (via ESS = Emacs Speaks Statistics), I can indeed
see that  mouse-scrolling in a graphics window has *very funny*
/ strange effects when using the default interactive graphics
device ( .Device == "windows" ) :

Notably, after say   pairs(iris)mouse-wheel-scrolling
"kind of" redraws some of the panel plots mostly in full size
(instead of the size they were as panels and as part of the full
"pairs" i.e., scatter plot matrix.

If instead I use RStudio and their own device "RD"
mouse-wheel-scrolling has no effect, e.g., after  pairs(iris).
And "no effect" is clearly better than what we observe with the R
default device "windows" i.e., windows() in the above situation.


> My sessionInfo() is as follows:

> R version 4.2.2 (2022-10-31 ucrt)
> Platform: x86_64-w64-mingw32/x64 (64-bit)
> Running under: Windows 10 x64 (build 19044)

> Matrix products: default

> locale:
> [1] LC_COLLATE=English_United States.utf8
> [2] LC_CTYPE=English_United States.utf8
> [3] LC_MONETARY=English_United States.utf8
> [4] LC_NUMERIC=C
> [5] LC_TIME=English_United States.utf8

> attached base packages:
> [1] stats graphics  grDevices utils datasets  methods   base

> loaded via a namespace (and not attached):
> [1] compiler_4.2.2 tools_4.2.2

> Thank you in advance,
> Ziyun

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] Printing special characters

[Martin Maechler]

> Rui Barradas 
> on Mon, 16 Jan 2023 08:46:43 + writes:

> Às 08:31 de 16/01/2023, Jeff Newmiller escreveu:
>> Use the Cairo PDF device?
>> 
>> On January 16, 2023 12:18:48 AM PST, Dennis Fisher
>>  wrote:
>>> R 4.2.2 OS X
>>> 
>>> Colleagues
>>> 
>>> A file that I have read includes strings like this:
>>> "EVENT ≥ 30 sec" When I include the string in a graphic
>>> using: mtext(STRING, …)  it appears as: "EVENT ... 30
>>> sec"
>>> 
>>> Is there a simple work-around (short of reformatting all
>>> the strings, then using plotmath)?
>>> 
>>> Dennis
>>> 
>>> Dennis Fisher MD P < (The "P Less Than" Company) Phone /
>>> Fax: 1-866-PLessThan (1-866-753-7784) www.PLessThan.com
>>> 
>>> __
>>> R-help@r-project.org mailing list -- To UNSUBSCRIBE and
>>> more, see https://stat.ethz.ch/mailman/listinfo/r-help
>>> PLEASE do read the posting guide
>>> http://www.R-project.org/posting-guide.html and provide
>>> commented, minimal, self-contained, reproducible code.
>> 
> Hello,

> I had no problems with

> X11()
> plot(1,1, pch = "") 
> text(1, 1, "EVENT ≥ 30 sec")
> #dev.off()

Yes, for me too.
X11() *is*  by default the "X11cairo" device and that works, the
same as the "Cairo PDF" device that Jeff mentioned above.

Indeed,
  cairo_pdf("utf8-ex.pdf")  # works nicely

whereas  pdf("utf8-ex.pdf") does not {for me, with default font
families etc}, but rather shows the "..." instead.

*and* gives warnings during the plot
  conversion failure on 'EVENT ≥ 30 sec' in 'mbcsToSbcs': dot substituted for 

  conversion failure on 'EVENT ≥ 30 sec' in 'mbcsToSbcs': dot substituted for 
<89>
  conversion failure on 'EVENT ≥ 30 sec' in 'mbcsToSbcs': dot substituted for 


BTW, a simple one liner for testing is

   plot(1, type="n", axes=FALSE, main = "EVENT ≥ 30 sec")

Note that help(pdf)  contains

   See Also:

pdfFonts, pdf.options, embedFonts, Devices, postscript.

cairo_pdf and (on macOS only) quartz for other devices that
can produce PDF.

More details of font families and encodings and especially
handling text in a non-Latin-1 encoding and embedding fonts can be
found in

Paul Murrell and Brian Ripley (2006).  “Non-standard fonts in
PostScript and PDF graphics.” _R News_, *6*(2), 41-47.
.

-
Martin

> Hope this helps,
> Rui Barradas

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] Integer division

[Martin Maechler]

>>>>> Richard O'Keefe 
>>>>> on Wed, 21 Dec 2022 16:44:51 +1300 writes:

> Lack of consensus: I should mention Python's // operator,
> which does flooring division.  I should mention Common
> Lisp, where (floor - -), (ceiling - -), (round - -), and
> (truncate - -) all return a quotient and appropriate
> remainder.  I should mention Smalltalk, where // and \\
> are flooring quotient and remainder and quo: and rem: are
> truncating quotient and remainder.  I should give
> dishonourable mention to certain programming languages
> where the quotient and remainder operators do not actually
> fit together.

> Why the lack of consensus: It starts with the fact that
> there wasn't an agreed *mathematical* definition.  Number
> theorists, as a rule, don't care about negative numbers
> all that much.  To the extent that they do care, x mod y
> has to go around in neat cycles, which flooring division
> does satisfy and truncating division does not.

>   It then goes on to early computers which used sign-and-
> magnitude or ones-complement representation.  In those
> computers, truncating division was the *obvious* thing to
> do.  It also had the nice property that n / (2**k) was the
> same thing as an arithmetic right shift by k bits.  And
> then twos-complement became popular.  And not only is the
> twos-complement range asymmetric (so that x might be
> representable but -x not) but arithmetic right shifts
> aren't the same as truncating division any more.  Whoops!

>   And then, although flooring division still made sense
> for twos-complement but truncating division didn't really,
> new programming languages kept on specifying truncating
> division because the programming languages of the 1960s
> for the hardware of the 1960s did so.  So new hardware
> designers supported the new programming languages without
> supporting the *reasons* why truncating division had been
> used.

>> (-8:7)%%4
>  [1] 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3

> Think about for example histogramming a collection of
> integers by their remainders and what would happen with
> truncating remainder.

> On Tue, 20 Dec 2022 at 19:53, Göran Broström 
> wrote:

>> Thanks Richard,
>> 
>> the "rounding claim" was my mistake (as I replied to
>> Martin), I should said "truncates toward zero" as you
>> explain.
>> 
>> However, my point was that these two mathematical
>> functions should be defined in the documentation, as you
>> also say. And I was surprised that there is no consensus
>> regarding the definition of such elementary functions.
>> 
>> Göran

[...]

Thank you all for your contributions, notably Richard's last one
providing really interesting historical context (of "why this mess?").

Note that the Wikipedia page
  https://en.m.wikipedia.org/wiki/Modulo_operation

also does mention "Euclidean division" which does have possibly
even nicer mathematical properties than the floored division
R (and quite a few other good softwares) use.

Still, be assured that we won't change R here.  Mathematical
(Algebra) related R packages can easily introduce corresponding
versions of div() and mod() functions, I'd say,  and I'd guess
these would already exist somewhere.

Yesterday, I've updated the  ?Arithmetic help page which now
does mention (more clearly if it was really already derivable
from the previous doc) what happens, also mentioning Knuth and
the Wikipedia page.

--> https://stat.ethz.ch/R-manual/R-devel/library/base/html/Arithmetic.html

(search for  "R-devel R-manual ETH" in your browser, then
 -> 'Packages' -> 'base' ..)

Martin

--
Martin Maechler
ETH Zurich  and  R Core team

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] Integer division

[Martin Maechler]

>>>>> Jeff Newmiller 
>>>>> on Mon, 19 Dec 2022 08:37:32 -0800 writes:

> See https://en.m.wikipedia.org/wiki/Modulo_operation,
> Variants of the definition, esp the point that Knuth
> recommended the floor definition. The behavior of %/%
> follows from the definition of %% given the documented
> relation in ?Arithmetic.

> R is not obligated to repeat the mistakes of C or Fortran.

Fortune nomination!  ==> BCC:  maintainer("fortunes")

The Wikipedia page is indeed revealing amazing facts about how
differently this has been implemented in computer languages.

Then, after all,  Göran still got a point to make here, given that
not anymore are all R users equipped with a Ph.D in math or equivalent..:

It would probably be helpful to add a short paragraph to  ?Arithmetic
about the fact that R's %% uses the "floored" version, as
recommended by Donald Knuth and as documented on the above
Wikipedia page.

Martin

> On December 19, 2022 7:15:01 AM PST, "Göran Broström"
>  wrote:
>> 
>> 
>> Den 2022-12-19 kl. 15:41, skrev Martin Maechler:
>>>>>>>> Göran Broström on Mon, 19 Dec 2022 14:22:00 +0100
>>>>>>>> writes:
>>> 
>>> > I have a long vector x with five-digit codes where the
>>> > first digit of each is of special interest, so I
>>> extracted > them through
>>> 
>>> >> y <- x %/% 1
>>> 
>>> > but to my surprise y contained the value -1 in some >
>>> places. It turned out that x contains -1 as a symbol for
>>> > 'missing value' so in effect I found that
>>> 
>>> >> -1 %/% 1 == -1
>>> 
>>> > Had to check the help page for "%/%", and the first >
>>> relevant comment I found was:
>>> 
>>> > "Users are sometimes surprised by the value returned".
>>> 
>>> > No surprise there. Further down:
>>> 
>>> > ‘%%’ indicates ‘x mod y’ (“x modulo y”) and ‘%/%’ >
>>> indicates integer division.  It is guaranteed that
>>> 
>>> > ‘ x == (x %% y) + y * (x %/% y) ’ (up to rounding >
>>> error)
>>> 
>>> > I did expect (a %/% b) to return round(a / b), like >
>>> gfortran and gcc,
>>> 
>>> What???  I cannot believe you.
>> 
>> Well, you shouldn't, I generalized too far.
>>> 
>>> No time for checking now, but I bet that 8 / 3 gives 2
>>> and not 3 in C and Fortran (and hence gcc, etc)
>> 
>> But compare -8 %/% 3 in R and -8 / 3 in C/Fortran.
>> 
>> G,
>> 
>>> 
>>> 
>>> > but instead I get floor(a / b) in > R. What is the
>>> reason for these different definitions? And > shouldn't
>>> R's definition be documented?
>>> 
>>> 
>>> 
>>> > Thanks, Göran
>>> 
>>> > __ >
>>> R-help@r-project.org mailing list -- To UNSUBSCRIBE and
>>> > more, see https://stat.ethz.ch/mailman/listinfo/r-help
>>> > PLEASE do read the posting guide >
>>> http://www.R-project.org/posting-guide.html and provide
>>> > commented, minimal, self-contained, reproducible code.
>> 
>> __
>> R-help@r-project.org mailing list -- To UNSUBSCRIBE and
>> more, see https://stat.ethz.ch/mailman/listinfo/r-help
>> PLEASE do read the posting guide
>> http://www.R-project.org/posting-guide.html and provide
>> commented, minimal, self-contained, reproducible code.

> -- 
> Sent from my phone. Please excuse my brevity.

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] Integer division

[Martin Maechler]

> Göran Broström 
> on Mon, 19 Dec 2022 14:22:00 +0100 writes:

> I have a long vector x with five-digit codes where the
> first digit of each is of special interest, so I extracted
> them through

>> y <- x %/% 1

> but to my surprise y contained the value -1 in some
> places. It turned out that x contains -1 as a symbol for
> 'missing value' so in effect I found that

>> -1 %/% 1 == -1

> Had to check the help page for "%/%", and the first
> relevant comment I found was:

> "Users are sometimes surprised by the value returned".

> No surprise there. Further down:

> ‘%%’ indicates ‘x mod y’ (“x modulo y”) and ‘%/%’
> indicates integer division.  It is guaranteed that

>   ‘ x == (x %% y) + y * (x %/% y) ’ (up to rounding
> error)

> I did expect (a %/% b) to return round(a / b), like
> gfortran and gcc, 

What???  I cannot believe you.

No time for checking now, but I bet that 
8 / 3  gives 2 and not 3  in C and Fortran
(and hence gcc, etc) 


> but instead I get floor(a / b) in
> R. What is the reason for these different definitions? And
> shouldn't R's definition be documented?



> Thanks, Göran

> __
> R-help@r-project.org mailing list -- To UNSUBSCRIBE and
> more, see https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide
> http://www.R-project.org/posting-guide.html and provide
> commented, minimal, self-contained, reproducible code.

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] bgroup not rendering properly

[Martin Maechler]

>>>>> Martin Maechler 
>>>>> on Tue, 13 Dec 2022 11:02:23 +0100 writes:

>>>>> Jinsong Zhao 
>>>>> on Tue, 13 Dec 2022 17:07:00 +0800 writes:

>> I don

Jinsong started on top and I did not see his continuation
at the very bottom
(so scroll down there!)


>> On 2022/12/13 10:13, Derek Ogle wrote:
>>> bgroup() from plotmath does not render properly for
>>> me. For example
>>> 
>>> plot(0,xlim=c(0,1),ylim=c(0,1))
>>> text(0.3,0.5,expression(bgroup('(',atop(x,y),')')))
>>> text(0.7,0.5,expression(group('(',atop(x,y),')')))

> Almost surely a Windows-only problem i.e. bug, See also
> the bug fixed yesterday, PR#18440,
> https://bugs.r-project.org/show_bug.cgi?id=18440

> Note that "rendering" of graphics strongly depends on your
> graphics device (people no longer learn about nowadays).
> Hence, use

>.Device or dev.cur()

> and report that along with your session info.

> I bet that you will see that after

> png("bgroup.png") # or pdf("bgroup.pdf")
> expression(bgroup('(',atop(x,y),')') dev.off()

> the resulting PNG or PDF will look fine, even on Windows
> in R 4.2.2.

> Martin

>>> 
>>> and
>>> 
>>> library(ggplot2) ggplot(mtcars, aes(wt, mpg)) +
>>> annotate("text", x=2.5, y=25,
>>> label="bgroup('(',atop(x,y),')')", parse=TRUE) +
>>> annotate("text", x=3.5, y=25,
>>> label="group('(',atop(x,y),')')", parse=TRUE)
>>> 
>>> both show a proper (though ugly) result from group()
>>> (the second text() or annotation()) but unrecognizable
>>> characters (rather than large parentheses) from
>>> bgroup().
>>> 
>>> This problematic result occurred for me when using
>>> v4.2.2, but not when using 4.2.0, 4.1.2, 4.1.0, or
>>> 4.0.5. My sessionInfo is further below.
>>> 
>>> I did ask this on stackoverflow
>>> 
<https://stackoverflow.com/questions/74738827/bgroup-does-not-render-properly-on-ggplot>
>>> where the resulting figures can be seen.
>>> 
>>> 
>>> 
>>> R version 4.2.2 (2022-10-31 ucrt) Platform:
>>> x86_64-w64-mingw32/x64 (64-bit) Running under: Windows
>>> 10 x64 (build 19044)
>>> 
>>> Matrix products: default
>>> 
>>> locale: [1] LC_COLLATE=English_United States.utf8 [2]
>>> LC_CTYPE=English_United States.utf8 [3]
>>> LC_MONETARY=English_United States.utf8 [4] LC_NUMERIC=C
>>> [5] LC_TIME=English_United States.utf8
>>> 
>>> attached base packages: [1] stats graphics grDevices
>>> utils datasets methods base
>>> 
>>> loaded via a namespace (and not attached): [1]
>>> compiler_4.2.2 tools_4.2.2

>> I don't see any problem, especially when outputing the
>> plot to a pdf file.

>> Best, Jinsong

Interesting, so even on Windows, the problem does not always
show evidently.
The pdf is clearly working (see my own first reply),
but then, could it be that there's a difference between Jinsong's
computer or his way of using R and the others, Rui and Derek ?

The ugly rectangles are typically shown for characters for which
the graphics device does not find any fonts...
and in principle there may be subtle differences.

Is it always within RStudio which I think *does* use R's own
"graphapp" based Windows device. 
It that's still true, then same would probably happen within
bare RGui.

For me, on a (2016!) Windows terminal server,
the bgroup() things also work nicely, at least if I use R from
ESS (-> Rterm). 

Martin

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] bgroup not rendering properly

[Martin Maechler]

> Jinsong Zhao 
> on Tue, 13 Dec 2022 17:07:00 +0800 writes:

> I don

>  On 2022/12/13 10:13, Derek Ogle wrote:
>> bgroup() from plotmath does not render properly for
>> me. For example
>> 
>> plot(0,xlim=c(0,1),ylim=c(0,1))
>> text(0.3,0.5,expression(bgroup('(',atop(x,y),')')))
>> text(0.7,0.5,expression(group('(',atop(x,y),')')))

Almost surely a  Windows-only problem i.e. bug,
See also the bug fixed yesterday, PR#18440,
https://bugs.r-project.org/show_bug.cgi?id=18440

Note that "rendering" of graphics strongly depends on your
graphics device (people no longer learn about nowadays).
Hence, use

   .Device
or
   dev.cur()

and report that along with your session info.

I bet that you will see that after

png("bgroup.png")  # or pdf("bgroup.pdf")
expression(bgroup('(',atop(x,y),')')
dev.off()

the resulting PNG or PDF will look fine,
even on Windows in R 4.2.2.

Martin


>> 
>> and
>> 
>> library(ggplot2) ggplot(mtcars, aes(wt, mpg)) +
>> annotate("text", x=2.5, y=25,
>> label="bgroup('(',atop(x,y),')')", parse=TRUE) +
>> annotate("text", x=3.5, y=25,
>> label="group('(',atop(x,y),')')", parse=TRUE)
>> 
>> both show a proper (though ugly) result from group() (the
>> second text() or annotation()) but unrecognizable
>> characters (rather than large parentheses) from bgroup().
>> 
>> This problematic result occurred for me when using
>> v4.2.2, but not when using 4.2.0, 4.1.2, 4.1.0, or
>> 4.0.5. My sessionInfo is further below.
>> 
>> I did ask this on stackoverflow
>> 

>> where the resulting figures can be seen.
>> 
>> 
>> 
>> R version 4.2.2 (2022-10-31 ucrt) Platform:
>> x86_64-w64-mingw32/x64 (64-bit) Running under: Windows 10
>> x64 (build 19044)
>> 
>> Matrix products: default
>> 
>> locale: [1] LC_COLLATE=English_United States.utf8 [2]
>> LC_CTYPE=English_United States.utf8 [3]
>> LC_MONETARY=English_United States.utf8 [4] LC_NUMERIC=C
>> [5] LC_TIME=English_United States.utf8
>> 
>> attached base packages: [1] stats graphics grDevices
>> utils datasets methods base
>> 
>> loaded via a namespace (and not attached): [1]
>> compiler_4.2.2 tools_4.2.2
> I don't see any problem, especially when outputing the
> plot to a pdf file.

> Best, Jinsong

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] if documentation

[Martin Maechler]

> PIKAL Petr 
> on Wed, 7 Dec 2022 07:04:38 + writes:

> Hallo all Not sure if it is appropriate place but as I am
> not involved in r-devel list I post here.

 

> Documentation for Control (if, for, while, .) is missing
> "if else" command.  Although it can be find online
> elsewhere I believe that adding it either as an example or
> as a third entry and paragraph about nested if's could be
> beneficial.

 

> if(cond) cons.expr else if (cond) alt.expr else alt2.expr

> Nested if expressions are better realized with "else if"
> instead of sequence of plain "else" control statements
> especially when using several of them.

I agree.  However there is no "else if" special.

As everything that *happens* in R is a function call (John Chambers),
indeed, `if` is a function too, with an unusual syntax which may
involve `else`.

If you look more closely, `if` is a function with 3 arguments,
where the last (3rd) is optional and has a default of NULL :

Some code towards proving the above :


(t1 <- if(TRUE)  1:3 ) # is identical to  if(TRUE) 1:3 else NULL
f1  <- if(FALSE) 1:3   # is identical to
f2  <- if(FALSE) 1:3 else NULL
identical(f1,f2)
f3  <- if(FALSE) 1:3 else 111

`if`(TRUE, 1:3)
`if`(TRUE, 1:3, NULL)

`if`(FALSE, 1:3)   # returns invisibly
`if`(FALSE, 1:3, NULL)
`if`(FALSE, 1:3, 111)

--

So, 'if(.) else'  or 'if(...) else if(..) ..'
etc are
all just versions of calling the `if` function sometimes, in a
nested way.

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] confusion about dev.prev()

[Martin Maechler]

> Peter Langfelder 
> on Mon, 5 Dec 2022 21:40:13 +0800 writes:

> Ah, thanks, got it. Misread the help again...

... I think we all had ... and then known for a while  and then
forgot again ...

If you see how to improve the help page, so this happens less, ..
we'd look at it to add the improvement there.

Martin

> Peter

> On Mon, Dec 5, 2022 at 9:38 PM Ivan Krylov  wrote:
>> 
>> В Mon, 5 Dec 2022 21:28:16 +0800
>> Peter Langfelder  пишет:
>> 
>> > Open two devices, plot a plot, call dev.prev() and plot again. I
>> > would expect the second plot to appear in the first device, but that
>> > is not what happens; both plots appear in the second device.
>> 
>> Unfortunately, dev.prev() and dev.next() only return the number of the
>> respective device. You need dev.set() to actually make the change.
>> 
>> --
>> Best regards,
>> Ivan

> __
> R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide 
http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [ESS] A discrepancy between elpa version and ubuntu/mint version

[Martin Maechler via ESS-help]

On Thu, Nov 17, 2022 at 7:29 PM Ottorino via ESS-help
 wrote:
>
> Hi all,
>
> I think I've found a discrepancy
>
> in file
>
> /home/user/.emacs.d/elpa/ess-20221108.1714/ess-r-mode.el
>
> at lines 264-270
>
> I can find the variable
>
> ess-r-mode-map
>
> while in
>
> /usr/share/emacs/site-lisp/elpa-src/ess-18.10.2//ess-r-mode.el
>
> there's not such a variable.

Well, ESS now "lives" @ github  (not my decision), and so the always
current source is there, in this case it is

 https://github.com/emacs-ess/ESS/blob/master/lisp/ess-r-mode.el#L264-L270

which is indeed defining `ess-r-mode-map` ... and I think I would
expect in general that your own elpa version will be close to current
whereas OS installation in /usr/share/.. would typically be slightly older.
OTOH, those should have been more tested against other parts of your emacs etc..

> I realize this because on two identical systems (Mint 20.03, emacs 26.3)
> there were two different versions installed
>
>
> PS
>
> My previous problems with lintr were due to ~/.cache/R/lintr not
> writable for some obscure reasons.
>
> Thanks Rodney for your advice.
>
> __
> ESS-help@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/ess-help



-- 
Martinhttp://stat.ethz.ch/~maechler
Seminar für Statistik, ETH Zürich HG G 16   Rämistrasse 101
CH-8092 Zurich, SWITZERLAND   ☎ +41 44 632 3408<><

__
ESS-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help

Re: [R] Rare behaviour for nlme::reStruct example and question about ?lmeObject

[Martin Maechler]

> Iago  
> on Thu, 17 Nov 2022 11:53:31 +0100 writes:

> Thank you Martin,
> Regarding my question about `terms`, I meant the `terms` component of 
> the `lme` output. For example, for

> fm1 <- lme(distance ~ age, data = Orthodont)

> I can see through str(fm1), the next:

> $ terms   :Classes 'terms', 'formula'  language distance ~ age
>   .. ..- attr(*, "variables")= language list(distance, age)
>   .. ..- attr(*, "factors")= int [1:2, 1] 0 1
>   .. .. ..- attr(*, "dimnames")=List of 2
>   .. .. .. ..$ : chr [1:2] "distance" "age"
>   .. .. .. ..$ : chr "age"
>   .. ..- attr(*, "term.labels")= chr "age"
>   .. ..- attr(*, "order")= int 1
>   .. ..- attr(*, "intercept")= int 1
>   .. ..- attr(*, "response")= int 1
>   .. ..- attr(*, ".Environment")=
>   .. ..- attr(*, "predvars")= language list(distance, age)
>   .. ..- attr(*, "dataClasses")= Named chr [1:2] "numeric" "numeric"
>   .. .. ..- attr(*, "names")= chr [1:2] "distance" "age"

> However, there is no paragraph for this component among those in 
> ?lmeObject (in the Value section) as there is for fixDF, apVar, call, 
> etc.. If not needed, I assume the explanation would be that `terms` does 
> not need to be included in a legitimate ´"lme"´ object'.

> Kind regards,
> Iago

I see; now I understand what you meant. I've taken time to check and
found that the 'terms' part *is* needed, even though not for the
simplest methods such as summary(), residuals(), ..  and so have
added it to the  ?lmeObject  help page for the next version of
nlme.

Thank you, Iago!

Best,
Martin

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] Rare behaviour for nlme::reStruct example and question about ?lmeObject

[Martin Maechler]

>>>>> Martin Maechler 
>>>>> on Thu, 17 Nov 2022 09:16:04 +0100 writes:

>>>>> Andrew Simmons 
>>>>> on Tue, 15 Nov 2022 18:01:55 -0500 writes:

>> This seems to be a bug. I tried creating this function in the global
>> environment:

>> str.pdMat <- function (object, ...)
>> {
>> if (nlme::isInitialized(object)) {
>> NextMethod()
>> }
>> else {
>> cat(" Uninitialized positive definite matrix structure of class ",
>> class(object)[1], ".\n", sep = "")
>> }
>> }

> Thank you, Iago, for the question and Andrew for your proposal.

> Yes, I agree that something like the above -- which is derived from the
> print.pdMat method --  should be added to nlme and will do this
> myself.

My current working proposal gives this:

> (rs <- reStruct(list(Dog = ~day, Side = ~1), data = Pixel))
Uninitialized random effects structure
> str(rs)
List of 2
 $ Side:Uninitialized 'pdLogChol', 'pdSymm', 'pdMat': ~1
 $ Dog :Uninitialized 'pdLogChol', 'pdSymm', 'pdMat': ~day
 - attr(*, "settings")= int [1:5] 0 1 0 4 4
 - attr(*, "class")= chr "reStruct"
>

Martin

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] Rare behaviour for nlme::reStruct example and question about ?lmeObject

[Martin Maechler]

> Andrew Simmons 
> on Tue, 15 Nov 2022 18:01:55 -0500 writes:

   > This seems to be a bug. I tried creating this function in the global
   > environment:

   > str.pdMat <- function (object, ...)
   > {
   > if (nlme::isInitialized(object)) {
   > NextMethod()
   > }
   > else {
   > cat(" Uninitialized positive definite matrix structure of class ",
   > class(object)[1], ".\n", sep = "")
   > }
   > }

Thank you, Iago, for the question and Andrew for your proposal.

Yes, I agree that something like the above -- which is derived from the
print.pdMat method --  should be added to nlme and will do this
myself.

   > and the code you sent works:
   > 
   > > library(nlme)
   > > rs1 <- reStruct(list(Dog = ~day, Side = ~1), data = Pixel)
   > > rs1
   > Uninitialized random effects structure
   > > str(rs1)
   > List of 2
   >  $ Side: Uninitialized positive definite matrix structure of class 
pdLogChol.
   >  $ Dog : Uninitialized positive definite matrix structure of class 
pdLogChol.
   >  - attr(*, "settings")= int [1:5] 0 1 0 4 4
   >  - attr(*, "class")= chr "reStruct"

In addition, Iago, asked

   > > > In addition to that I would like to ask if shouldn't be `terms`
   > > > documented in `?lmeObject`.

I probably have misunderstood the question completely (?)

I've now searched through ?lmeObject 
which was written under the assumption that the reader has
already read (parts of) the  ?lme  help page.

Now "terms" only appears in  ?lmeObject in this paragraph

   fixDF: a list with components ‘X’ and ‘terms’ specifying the
  denominator degrees of freedom for, respectively, t-tests for
  the individual fixed effects and F-tests for the
  fixed-effects terms in the models.

and I don't think that there needs to be more explanation.

(??)

Martin

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [ESS] Tab completion for CamelCase

[Martin Maechler via ESS-help]

> Naresh Gurbuxani via ESS-help 
> on Mon, 7 Nov 2022 17:54:58 + writes:

> My ess setup on mac works well with tab completion of CamelCase variable 
names.  However, on Windows, tab completes variable names with all lowercase 
letters.  So it does give me complete variable name, which needs some letters 
to be converted to uppercase.

This is strange.
At least on regular platform, i.e., non-Windows,  ESS really
uses base R's own completion engine and that will definitely
differentiate lower- and upper-case,  and hence correctly treat
CamelCase.

Which Version of ESS (and Emacs) are you talking about?
(M-x emacs-version  /  M-x ess-version)

Martin

> Can tab completion on Windows give proper CamelCase variables?

> Thanks,
> Naresh

__
ESS-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help

Re: [R] unexpected 'else' in " else"

[Martin Maechler]

>>>>> Ebert,Timothy Aaron 
>>>>> on Fri, 21 Oct 2022 12:05:58 + writes:

> I can get it to work with
> ifelse(is.matrix(r), r[w!=0, , drop=FALSE], r[w!=0])

Note that this is *not* good advice:

  if(Cnd) A else Bis very much more efficient  than
  ifelse(Cnd, A, B)

whenever it is appropriate, i.e.,
the condition Cnd is a simple TRUE or FALSE.

ifelse() is very much over-used!

{For the more sophisticated reader:
 In R, these both are function calls:
 `if` is a function of 3 argument with a "peculiar" syntax and
 the third argument with default NULL.
}

Martin Maechler
ETH Zurich  and  R Core team



> With w and r as defined r is not a  matrix, so the first part will never 
execute. The test is for w not equal to zero so it is always true for these 
vectors. It is usually good to have test code such that all possible cases are 
activated.

> r<--1:8
> w<- -1:5
> if(is.matrix(r)){
> r[w!=0, , drop=FALSE]
> } else r[w != 0]

> I think this also works. The "else" must follow the } and you put in a 
carriage return after the }

> I think that is the answer, but not 100% sure.

> Tim

> -Original Message-
> From: R-help  On Behalf Of Andrew Simmons
> Sent: Friday, October 21, 2022 5:37 AM
> To: Jinsong Zhao 
> Cc: R-help Mailing List 
> Subject: Re: [R] unexpected 'else' in " else"

> [External Email]

> The error comes from the expression not being wrapped with braces. You 
could change it to

> if (is.matrix(r)) {
> r[w != 0, , drop = FALSE]
> } else r[w != 0]

> or

> {
> if (is.matrix(r))
> r[w != 0, , drop = FALSE]
> else r[w != 0]
> }

> or

> if (is.matrix(r)) r[w != 0, , drop = FALSE] else r[w != 0]


> On Fri., Oct. 21, 2022, 05:29 Jinsong Zhao,  wrote:

>> Hi there,
>> 
>> The following code would cause R error:
>> 
>> > w <- 1:5
>> > r <- 1:5
>> > if (is.matrix(r))
>> + r[w != 0, , drop = FALSE]
>> > else r[w != 0]
>> Error: unexpected 'else' in "else"
>> 
>> However, the code:
>> if (is.matrix(r))
>> r[w != 0, , drop = FALSE]
>> else r[w != 0]
>> is extracted from stats::weighted.residuals.
>> 
>> My question is why the code in the function does not cause error?
>> 
>> Best,
>> Jinsong
>> 
>> __
>> R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
>> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat
>> .ethz.ch%2Fmailman%2Flistinfo%2Fr-helpdata=05%7C01%7Ctebert%40ufl
>> .edu%7C98bd495a0754455cbead08dab348311f%7C0d4da0f84a314d76ace60a62331e
>> 1b84%7C0%7C0%7C638019419897938843%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w
>> LjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C
>> sdata=9ImIUx0YyKjFMTDRrwa5fnkqiJL9aDjpGCRxxfI6Hlk%3Dreserved
>> =0
>> PLEASE do read the posting guide
>> https://nam10.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.r
>> -project.org%2Fposting-guide.htmldata=05%7C01%7Ctebert%40ufl.edu%
>> 7C98bd495a0754455cbead08dab348311f%7C0d4da0f84a314d76ace60a62331e1b84%
>> 7C0%7C0%7C638019419897938843%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
>> DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C
>> sdata=WsqoNk2NQ6NOjKoOKwf%2FPU57XkAwKtRhw6xb68COT1o%3Dreserved=0
>> and provide commented, minimal, self-contained, reproducible code.
>> 

> [[alternative HTML version deleted]]

> __
> R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
> 
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-helpdata=05%7C01%7Ctebert%40ufl.edu%7C98bd495a0754455cbead08dab348311f%7C0d4da0f84a314d76ace60a62331e1b84%7C0%7C0%7C638019419898095081%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=2mYpa25vpXNvPNINi9XxCtc7Vbj4Sp4IQUsA9fL%2BA60%3Dreserved=0
> PLEASE do read the posting guide 
https://nam10.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.r-project.org%2Fposting-guide.htmldata=05%7C01%7Ctebert%40ufl.edu%7C98bd495a0754455cbead08dab348311f%7C0d4da0f84a314d76ace60a62331e1b84%7C0%7C0%7C638019419898095081%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=21L

Re: [R] Unintended behaviour of stats::time not returning integers for the first cycle

[Martin Maechler]

>>>>> Martin Maechler 
>>>>> on Wed, 19 Oct 2022 10:05:31 +0200 writes:

>>>>> Andreï V Kostyrka 
>>>>> on Tue, 18 Oct 2022 16:26:28 +0400 writes:

>> Sure, this works, and I was thinking about this solution, but it seems 
like
>> a dirty one-time trick. I was wondering whether the following 3 lines 
could
>> be considered for inclusion by the core developers, but did not know 
which
>> mailing list to write to. 

> As Jeff alluded to, *every* message to this list has a footer
> with a link to *the POSTING GUIDE"  ...

> and from there you quickly learn it is 'R-devel' (instead of 'R-help').

> Now that we have already half a dozen messages here, let's keep
> the whole thread here, even if only for ease of reading the list 
archives(!)

>> Here is my proposal:

>> correctTime <- function (x, offset = 0, ...) { # Changes
>> stats:::time.default
>> n <- if (is.matrix(x)) nrow(x) else length(x)
>> xtsp <- attr(hasTsp(x), "tsp")
>> y <- seq.int(xtsp[1L], xtsp[2L], length.out = n) + offset/xtsp[3L]
>> round.y <- round(y)
>> near.integer <- abs(round.y - y) < sqrt(.Machine$double.eps)
>> y[near.integer] <- round.y[near.integer]
>> tsp(y) <- xtsp
>> y
>> }

> Yes, some such change does make sense to me, too.
> As the computations above are relatively costly (compared to the
> current  time.default()  implementation),
> and also for strict back compatibility reasons, I think the
> correction should only happen when the user asks for it,  say by
> using a new argument 'roundYear = TRUE'  (where the default
> remains roundYear=FALSE).

> Martin Maechler
> ETH Zurich  and  R Core tam

After some more thinking and pondering:

No, there's no need for a 'roundYear = *' argument, but rather
we'd use the 'ts.eps' argument as in many similar situations
with ts() objects needing rounding adjustments.

Consequently, my current (only little tested) proposal  is

time.default <- function (x, offset = 0, ts.eps = getOption("ts.eps"), ...)
{
xtsp <- attr(hasTsp(x), "tsp")
y <- seq.int(xtsp[1L], xtsp[2L], length.out = NROW(x)) + offset/xtsp[3L]
if(ts.eps > 0) {
iy <- round(y)
nearI <- abs(iy - y) < ts.eps
y[nearI] <- iy[nearI]
}
tsp(y) <- xtsp
y
}

It *does* fix your example(s) below.

Martin


>> x <- ts(2:252, start = c(2002, 2), freq = 12)
>> d <- seq.Date(as.Date("2002-02-01"), to = as.Date("2022-12-01"), by =
>> "month")
>> true.year <- rep(2002:2022, each = 12)[-1]
>> wrong.year <- floor(as.numeric(time(x)))
>> print(as.numeric(time(x))[240], 20) # 2021.7726, the floor of
>> which is 2021
>> print(correctTime(x)[240], 20) # 2022

>> On Sat, Oct 15, 2022 at 11:56 AM Eric Berger  
wrote:

>>> Alternatively
>>> 
>>> correct.year <- floor(time(x)+1e-6)
>>> 
>>> On Sat, Oct 15, 2022 at 10:26 AM Andreï V. Kostyrka <
>>> andrei.kosty...@gmail.com> wrote:
>>> 
>>>> Dear all,
>>>> 
>>>> 
>>>> 
>>>> I was using stats::time to obtain the year as a floor of it, and
>>>> encountered a problem: due to a rounding error (most likely due to its
>>>> reliance on the base::seq.int internally, but correct me if I am 
wrong),
>>>> the actual number corresponding to the beginning of a year X can still 
be
>>>> (X-1).999..., resulting in the following undesirable behaviour.
>>>> 
>>>> 
>>>> 
>>>> One of the simplest ways of getting the year from a ts object is
>>>> floor(time(...)). However, if the starting time cannot be represented
>>>> nicely as a power of 2, then, supposedly integer time does not have a
>>>> .00... mantissa:
>>>> 
>>>> 
>>>> 
>>>> x <- ts(2:252, start = c(2002, 2), freq = 12)
>>>> 
>>>> d <- seq.Date(as.Date("2002-02-01"), to = as.Date("2022-12-01"), by =
>>>> "month")
>>>> 
>>>> true.year <- rep(2002:2022, each = 12)[-1]
>>>> 
>>>> wrong.year <- floor(as.numeric(time(x)))
>>>> 
>>>> tail(cbind(as.character(d), true.year, w

Re: [R] Unintended behaviour of stats::time not returning integers for the first cycle

[Martin Maechler]

>>>>> Andreï V Kostyrka 
>>>>> on Tue, 18 Oct 2022 16:26:28 +0400 writes:

> Sure, this works, and I was thinking about this solution, but it seems 
like
> a dirty one-time trick. I was wondering whether the following 3 lines 
could
> be considered for inclusion by the core developers, but did not know which
> mailing list to write to. 

As Jeff alluded to, *every* message to this list has a footer
with a link to *the POSTING GUIDE"  ...

and from there you quickly learn it is 'R-devel' (instead of 'R-help').

Now that we have already half a dozen messages here, let's keep
the whole thread here, even if only for ease of reading the list archives(!)

> Here is my proposal:

> correctTime <- function (x, offset = 0, ...) { # Changes
> stats:::time.default
>  n <- if (is.matrix(x)) nrow(x) else length(x)
>  xtsp <- attr(hasTsp(x), "tsp")
>  y <- seq.int(xtsp[1L], xtsp[2L], length.out = n) + offset/xtsp[3L]
>  round.y <- round(y)
>  near.integer <- abs(round.y - y) < sqrt(.Machine$double.eps)
>  y[near.integer] <- round.y[near.integer]
>  tsp(y) <- xtsp
> y
> }

Yes, some such change does make sense to me, too.
As the computations above are relatively costly (compared to the
current  time.default()  implementation),
and also for strict back compatibility reasons, I think the
correction should only happen when the user asks for it,  say by
using a new argument 'roundYear = TRUE'  (where the default
remains roundYear=FALSE).

Martin Maechler
ETH Zurich  and  R Core tam

> x <- ts(2:252, start = c(2002, 2), freq = 12)
> d <- seq.Date(as.Date("2002-02-01"), to = as.Date("2022-12-01"), by =
> "month")
> true.year <- rep(2002:2022, each = 12)[-1]
> wrong.year <- floor(as.numeric(time(x)))
> print(as.numeric(time(x))[240], 20) # 2021.7726, the floor of
> which is 2021
> print(correctTime(x)[240], 20) # 2022

> On Sat, Oct 15, 2022 at 11:56 AM Eric Berger  
wrote:

>> Alternatively
>> 
>> correct.year <- floor(time(x)+1e-6)
>> 
>> On Sat, Oct 15, 2022 at 10:26 AM Andreï V. Kostyrka <
>> andrei.kosty...@gmail.com> wrote:
>> 
>>> Dear all,
>>> 
>>> 
>>> 
>>> I was using stats::time to obtain the year as a floor of it, and
>>> encountered a problem: due to a rounding error (most likely due to its
>>> reliance on the base::seq.int internally, but correct me if I am wrong),
>>> the actual number corresponding to the beginning of a year X can still 
be
>>> (X-1).999..., resulting in the following undesirable behaviour.
>>> 
>>> 
>>> 
>>> One of the simplest ways of getting the year from a ts object is
>>> floor(time(...)). However, if the starting time cannot be represented
>>> nicely as a power of 2, then, supposedly integer time does not have a
>>> .00... mantissa:
>>> 
>>> 
>>> 
>>> x <- ts(2:252, start = c(2002, 2), freq = 12)
>>> 
>>> d <- seq.Date(as.Date("2002-02-01"), to = as.Date("2022-12-01"), by =
>>> "month")
>>> 
>>> true.year <- rep(2002:2022, each = 12)[-1]
>>> 
>>> wrong.year <- floor(as.numeric(time(x)))
>>> 
>>> tail(cbind(as.character(d), true.year, wrong.year), 15) # Look at
>>> 2022-01-01
>>> 
>>> print(as.numeric(time(x))[240], 20) # 2021.7726, the floor 
of
>>> which is 2021
>>> 
>>> 
>>> 
>>> Yes, I have read the 'R inferno' book and know the famous '0.3 != 0.7 -
>>> 0.4' example, but I believe that the expected / intended behaviour would
>>> be
>>> actually returning round years for the first observation in a year. This
>>> could be achieved by rounding the near-integer time to integers.
>>> 
>>> 
>>> 
>>> Since users working with dates are expecting to get exact integer years
>>> for
>>> the first cycle of a ts, this should be changed. Thank you in advance 
for
>>> considering a fix.
>>> 
>>> 
>>> 
>>> Yours sincerely,
>>> 
>>> Andreï V. Kostyrka
>>> 
>>> [[alternative HTML version deleted]]
>>> 
>>> __

Re: [R] Error in if (class(networks) == "matrix") from a function

[Martin Maechler]

> Eric Berger 
> on Wed, 21 Sep 2022 22:26:39 +0300 writes:

> In R 4.2.0 there is a significant change. When you use an if() statement
> with a condition of length > 1 this now reports an error.
> e.g. this link mentions it as a change
> https://www.jumpingrivers.com/blog/new-features-r420/

> In your case this is because class(obj) can return a character vector of
> length > 1 (all the classes).
> One possible workaround would be:

> if ( "matrix" %in% class(networks) ) ...

Yes,  however, in general, the recommendation in the related R
blog,

would have been

  if(inherits(networks, "matrix"))

which I consider better *correctly readable* (and also expect
to be more efficient).

Lastly, in this special case, I'd try

if(is.matrix(networks))

i.e., I'd try to see if the fast  is.matrix(.)  applies to your 'networks'
(and I'm guessing "yes" with high confidence ..).

Martin

> HTH,
> Eric


> On Wed, Sep 21, 2022 at 10:21 PM Chao Liu  wrote:

>> Dear R-Help community,
>> 
>> This is a crosspost on SO but I've had no luck so far. So I have a 
function
>> which computes a centrality index for the nodes in a network or matrix.
>> Here is the function:
>> 
>> library(igraph) #load package igraph
>> centrality <- function (networks, type = c("indegree", "outdegree",
>> "freeman",
>> "betweenness", "flow", "closeness", "eigenvector", "information",
>> "load", "bonpow"), directed = TRUE, lag = 0, rescale = FALSE,
>> center = FALSE, coefname = NULL, ...) {
>> if (is.null(directed) || !is.logical(directed)) {
>> stop("'directed' must be TRUE or FALSE.")
>> }
>> else if (length(directed) != 1) {
>> stop("The 'directed' argument must contain a single logical
>> value only.")
>> }
>> else if (directed == FALSE) {
>> gmode <- "graph"
>> }
>> else {
>> gmode <- "digraph"
>> }
>> objects <- checkDataTypes(y = NULL, networks = networks,
>> lag = lag)
>> centlist <- list()
>> for (i in 1:objects$time.steps) {
>> if (type[1] == "indegree") {
>> cent <- degree(objects$networks[[i]], gmode = gmode,
>> cmode = "indegree", rescale = rescale, ...)
>> }
>> else if (type[1] == "outdegree") {
>> cent <- degree(objects$networks[[i]], gmode = gmode,
>> cmode = "outdegree", rescale = rescale, ...)
>> }
>> else if (type[1] == "freeman") {
>> cent <- degree(objects$networks[[i]], gmode = gmode,
>> cmode = "freeman", rescale = rescale, ...)
>> }
>> else if (type[1] == "betweenness") {
>> cent <- betweenness(objects$networks[[i]], gmode = gmode,
>> rescale = rescale, ...)
>> }
>> else if (type[1] == "flow") {
>> cent <- flowbet(objects$networks[[i]], gmode = gmode,
>> rescale = rescale, ...)
>> }
>> else if (type[1] == "closeness") {
>> cent <- closeness(objects$networks[[i]], gmode = gmode,
>> rescale = rescale, ...)
>> }
>> else if (type[1] == "eigenvector") {
>> cent <- evcent(objects$networks[[i]], gmode = gmode,
>> rescale = rescale, ...)
>> }
>> else if (type[1] == "information") {
>> cent <- infocent(objects$networks[[i]], gmode = gmode,
>> rescale = rescale, ...)
>> }
>> else if (type[1] == "load") {
>> cent <- loadcent(objects$networks[[i]], gmode = gmode,
>> rescale = rescale, ...)
>> }
>> else if (type[1] == "bonpow") {
>> cent <- bonpow(objects$networks[[i]], gmode = gmode,
>> rescale = rescale, tol = 1e-20, ...)
>> }
>> else {
>> stop("'type' argument was not recognized.")
>> }
>> centlist[[i]] <- cent
>> }
>> time <- numeric()
>> y <- numeric()
>> for (i in 1:objects$time.steps) {
>> time <- c(time, rep(i, objects$n[[i]]))
>> if (is.null(centlist[[i]])) {
>> y <- c(y, rep(NA, objects$n[[i]]))
>> }
>> else {
>> if (center == TRUE) {
>> centlist[[i]] <- centlist[[i]] - mean(centlist[[i]],
>> na.rm = TRUE)
>> }
>> y <- c(y, centlist[[i]])
>> }
>> }
>> if (is.null(coefname) || !is.character(coefname) || length(coefname) >
>> 1) {
>> coeflabel <- ""
>> }
>> else {
>> coeflabel <- paste0(".", coefname)
>> }
>> if (lag == 0) {
>> laglabel <- ""
>> }
>> else {
>> laglabel <- paste0(".lag", paste(lag, collapse = "."))
>> }
>> label <- paste0(type[1], coeflabel, laglabel)
>> dat <- data.frame(y, time = time, node = objects$nodelabels)
>> dat$node <- as.character(dat$node)
>> colnames(dat)[1] <- label
>> attributes(dat)$lag <- lag
>> return(dat)}
>> 
>> Here is the matrix:
>> 
>> dat <- read.table(text="A B #this is edgelist
>> 1 2
>> 1 3
>> 1 2
>> 2 1
>> 2 3
>> 3 1
>> 3 2
>> 3 1", header=TRUE)
>> datmat <- as.matrix(get.adjacency(graph.edgelist(as.matrix(dat),
>> directed=TRUE))) #this 

Re: [R] Error generated by nlme::gnls

[Martin Maechler]

>>>>> Bill Dunlap 
>>>>> on Sun, 24 Jul 2022 08:51:09 -0700 writes:

> I think the intent of this code was to see if the formula
> had solely a literal 1 on the right hand side.  Then
> !identical(pp[[3]], 1) would do it, avoiding the overhead
> of calling deparse.  Note that the 1 might be an integer,
> which the current code would (erroneously) not catch, so
> !identical(pp[[3]], 1) && !identical(pp[[3]], 1L) or
> something equivalent would be better.

> -Bill

Thanks a lot, Bill, Ivan, Ben  et al. !

This is indeed a very old coding bug triggered by the more
strict checks in  R 4.2.x.

I will indeed try Bill's proposal rather than remaining with
deparse by using deparse1().

"Of course", this should hopefully be fixed in the next release
of nlme.

Martin Maechler
ETH Zurich   and  R Core team


> On Sun, Jul 24, 2022 at 5:58 AM Ivan Krylov
>  wrote:

>> Sorry for being too terse in my previous e-mail!
>> 
>> On Sun, 24 Jul 2022 23:03:02 +1200 Rolf Turner
>>  wrote:
>> 
>> > The maintainer of the nlme package (who is, according
>> to maintainer(), > "R-core") could change the code so
>> that it uses invokes deparse1() > rather than deparse,
>> but the user cannot do so, not without in effect >
>> re-creating the package.
>> 
>> You're right. I think there's a buglet in nlme::gnls that
>> nobody noticed until R 4.2.0 was released *and* Aaron
>> Crowley used the function with a sufficiently long
>> formula.
>> 
>> > Also, the question remains: why did Aaron Crowley's
>> code work in the > past, whereas now it throws an error?
>> What changed?
>> 
>> gnls() may have been performing the `if (deparse(...) !=
>> '1')` test for a long time, but never crashed before
>> because it wasn't a fatal error until R
>> 4.2.0. Previously, if() would issue a warning and use the
>> first element of the boolean vector.
>> 
>> R 4.2.0 was released this April, which was less than 6
>> months ago. I think it all fits.
>> 
>> A temporary solution would be to make use of the fact
>> that R is a very dynamic language and perform surgery on
>> a live function inside a loaded package:
>> 
>> library(codetools)
>> 
>> nlme <- loadNamespace('nlme') unlockBinding('gnls', nlme)
>> nlme$gnls <- `body<-`(fun = nlme$gnls, value = walkCode(
>> body(nlme$gnls), makeCodeWalker( call = function(e, w)
>> as.call(lapply(as.list(e), function(ee) if (!missing(ee))
>> walkCode(ee, w) )), leaf = function(e, w) if
>> (is.symbol(e) && e == 'deparse') { as.name('deparse1') }
>> else e ) )) lockBinding('gnls', nlme) rm(nlme)
>> 
>> grep('deparse', deparse(nlme::gnls), value = TRUE) # [1]
>> " deparse1(pp[[3]]), sep = \"~\"), collapse = \",\"), " #
>> [2] " if (deparse1(params[[nm]][[3]]) != \"1\") {" # [3]
>> " list(row.names(dataModShrunk), deparse1(form[[2]]))), "
>> 
>> Aaron's example seems to work after this, modulo needing
>> 12 starting values instead of 13.
>> 
>> --
>> Best regards, Ivan
>> 
>> __
>> R-help@r-project.org mailing list -- To UNSUBSCRIBE and
>> more, see https://stat.ethz.ch/mailman/listinfo/r-help
>> PLEASE do read the posting guide
>> http://www.R-project.org/posting-guide.html and provide
>> commented, minimal, self-contained, reproducible code.
>> 

>   [[alternative HTML version deleted]]

> __
> R-help@r-project.org mailing list -- To UNSUBSCRIBE and
> more, see https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide
> http://www.R-project.org/posting-guide.html and provide
> commented, minimal, self-contained, reproducible code.

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] R_LIBS var needed to be set after upgrade to R 4.2.2

[Martin Maechler]

> Ashim Kapoor 
> on Wed, 1 Jun 2022 14:30:58 +0530 writes:

> Dear Sir,
>> > I upgraded to R 4.2.2  on Debian 10 today.
>> 
>> Well, I assume you mean R 4.2.0 .. at least that one exists.

> My bad, yes I made a typo. I did mean R 4.2.0.

>> > The R shell incantation worked fine and all libraries would load but,
>> > I needed to point the R_LIBS variable to
>> > /usr/local/lib/R/site-library/ in order for the R --vanilla < myfile.R
>> > incantation to find the libraries.
>> 
>> you mean other installed *packages*
>> 
>> > May I ask, why was this ? I never needed to do this on any previous
>> > upgrade to R.
>> 
>> Well,  for me, the R --vanilla   form also only sees the
>> 29 (14 "base" + 15 "Recommended") packages that come with R.

> Has this ALWAYS been the case for you ? Even with prior versions of R ?

Yes; I'm sorry this was unclear.

>> Debian (& Ubuntu etc)  have used a similar setup where the
>> default {R-level}  .libPaths() has contained three libraries,
>> via
>> 
>> 
R_LIBS_SITE=${R_LIBS_SITE-'/usr/local/lib/R/site-library:/usr/lib/R/site-library:/usr/lib/R/library'}
>> 
>> see
>> 
>> https://cloud.r-project.org/bin/linux/debian/#pathways-to-r-packages
>> 
>> also for much more.
>> Note (also from the above CRAN page
>> https://cloud.r-project.org/bin/linux/debian/
>> [ Remember "menu"  "Binaries" -> "Linux" -> "Debian" ]
>> 
>> The good thing about the Debian (and derivatives) setup is that
>> it also separates (as I do) the  "packages that come with R" in
>> one library (= /usr/lib/R/library) from packages that are
>> installed differently.

> My confusion is : Earlier R --vanilla incantation was working fine,
> even without my intervening and
> adding to R_LIBS. That is why I was confused.

> My main query is : Is there anything special to R 4.2.0 which needs
> R_LIBS to be setup seperately?

to which Jeroen Ooms answered nicely -- thank you, Jeroen!

> I was hit by this problem as well a few weeks ago. You may get a more
> detailed answer in r-sig-debian or from Dirk directly, but from what I
> understood, this is now expected behavior: indeed if you start R
> --vanilla then /usr/local/lib is no longer included in the library path.

> The reason is that R-core made a change in 4.2.0 to pre-set values for
> R_LIBS_USER and R_LIBS_SITE in Renviron [1] which would take
> precedence over the proper distro defaults (that include
> /usr/local/lib) as configured by the r-base deb/rpm packages. To
> mitigate the problem the r-base deb package moved the appropriate
> R_LIBS_USER and R_LIBS_SITE definitions into Renviron.site, which
> takes precedence over Renviron. However a side effect of this solution
> is that Renviron.site is ignored in --vanilla mode. At least this is
> my best understanding of the problem.

> [1] https://cran.r-project.org/doc/manuals/r-release/NEWS.html

Yes, as

 R --help | grep -A1 -e --vanilla | head -2

has given
 
  --vanilla Combine --no-save, --no-restore, --no-site-file,
--no-init-file and --no-environ

(unchanged for many years).


Being a Linux user of more than 25 years, I've not been much of a
Debian-or-derivatives user in recent years (apart from setting up
and maintaining Ubuntu LTS on my wife's computer) mainly because
of lazyness as our IT staff helps me solve all problems with
Fedora quickly, including lowelevel device-related ones,
I think that Debian(+derivatives) has always been the exception
among the Linux distros and for all the others, '--vanilla'
really meant "vanilla" in a loose sense, i.e., "just base R".

I agree that I had wanted a "vanilla+strawberry" version myself, really.
which would be just not have the  --no-site-file  switch,
so we could call it
   --vanilla+site

{Others may hate  "feature creep" and yet more output from
'R --help'  ..}

Martin

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] R_LIBS var needed to be set after upgrade to R 4.2.2

[Martin Maechler]

> Ashim Kapoor 
> on Wed, 1 Jun 2022 11:24:21 +0530 writes:

> Dear All,

> I upgraded to R 4.2.2  on Debian 10 today.

Well, I assume you mean R 4.2.0 .. at least that one exists.

> The R shell incantation worked fine and all libraries would load but,
> I needed to point the R_LIBS variable to
> /usr/local/lib/R/site-library/ in order for the R --vanilla < myfile.R
> incantation to find the libraries.

you mean other installed *packages*

> May I ask, why was this ? I never needed to do this on any previous
> upgrade to R.

Well,  for me, the R --vanilla   form also only sees the
29 (14 "base" + 15 "Recommended") packages that come with R.

Debian (& Ubuntu etc)  have used a similar setup where the
default {R-level}  .libPaths() has contained three libraries,
via

R_LIBS_SITE=${R_LIBS_SITE-'/usr/local/lib/R/site-library:/usr/lib/R/site-library:/usr/lib/R/library'}

see

   https://cloud.r-project.org/bin/linux/debian/#pathways-to-r-packages

also for much more.
Note (also from the above CRAN page
  https://cloud.r-project.org/bin/linux/debian/
   [ Remember "menu"  "Binaries" -> "Linux" -> "Debian" ]
   
The good thing about the Debian (and derivatives) setup is that
it also separates (as I do) the  "packages that come with R" in
one library (= /usr/lib/R/library) from packages that are
installed differently.


> Many thanks,
> Ashim

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] glm with family binomial and link identity

[Martin Maechler]

TLDR:  No, there was no such change in R 4.2.0

> Ralf Goertz 
> on Wed, 27 Apr 2022 10:27:33 +0200 writes:

> Hi,
> I just noticed that (with my version 4.2.0) it is no longer possible to
> use glm with family=binomial(link=identity). Why is that? It was
> possible with 4.0.x as a colleague of mine just confirmed. 

That's not correct I think:

I've now tried your example in R versions 3.5.x, 4.0.5, 4.1.3, and 4.2.0
and it gave the same error everywhere:

d <- data.frame(y  = c( 0, 1,  0, 1),
trt= c( 0, 0,  1, 1),
w  = c(97, 3, 90, 10))
r0 <- try(
glm(y ~ trt, weights = w, data=d, family = binomial(link = identity)) 
)
## Error in binomial(link = identity) : 
##   link "identity" not available for binomial family; available links are 
‘logit’, ‘probit’, ‘cloglog’, ‘cauchit’, ‘log’

And indeed, binomial() has started with

> head(binomial)
  
1 function (link = "logit")   
2 {   
3 linktemp <- substitute(link)
4 if (!is.character(linktemp))
5 linktemp <- deparse(linktemp)   
6 okLinks <- c("logit", "probit", "cloglog", "cauchit", "log")
> 

*forever*.

It is slightly interesting (to me at least) that if you use a string,
you can use all valid arguments for make.link() and not just
those that are declared "ok" by the code.

HOWEVER, this all has been documented for a long time,
in  ?family == ?binomial

  Note:

 The ‘link’ and ‘variance’ arguments have rather awkward semantics
 for back-compatibility.  The recommended way is to supply them as
 quoted character strings, but they can also be supplied unquoted
 (as names or expressions).  Additionally, they can be supplied as
 a length-one character vector giving the name of one of the
 options, or as a list (for ‘link’, of class ‘"link-glm"’).  The
 restrictions apply only to links given as names: when given as a
 character string all the links known to make.link are accepted.



 



> After all it is useful to compute risk differences with factors.

at least it was neand

> __
> R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide 
http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] pam() with more general dissimilarity / distance

[Martin Maechler]

I was asked in private, but reply in public,
so others can also find this answer in the future:

On Fri, Apr 8, 2022 at 1:11 PM  . wrote :
>  Hello
> dear Dr. Maechler
> I have a question about "pam" function in the cluster package. In this
> function, we choose one of the  euclidean or manhattan distances to
> calculate dissimilarity but in the mixed typed data sets the true index may
> be jaccard or other indicators.
> How can we allocate the "true" metric for each variable?
> Best regards
>

yes,  you can use pam() use in two ways;  see this part of the help page :

  Arguments:

   x: data matrix or data frame, or dissimilarity matrix or object,
  depending on the value of the ‘diss’ argument.

  In case of a matrix or data frame, each row corresponds to an
  observation, and each column corresponds to a variable.  All
  variables must be numeric.  Missing values (NAs) _are_
  allowed-as long as every pair of observations has at least
  one case not missing.

  In case of a dissimilarity matrix, ‘x’ is typically the
  output of daisy or dist.  Also a vector of length
  n*(n-1)/2 is allowed (where n is the number of observations),
  and will be interpreted in the same way as the output of the
  above-mentioned functions. Missing values (NAs) are _not_
  allowed.

So, you can first use   dx <-  daisy(x, ...) and use the correct
distance between your observational units,
After that you can use the computed distance / dissimilarity matrix
(the `dx`)  in you call to pam():

px <- pam(dx, k=., )

I hope this helps you.
With best regards,
Martin

--
Martin Maechler
ETH Zurich

‪

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] [External] Weird behaviour of order() when having multiple ties

[Martin Maechler]

> Stefan Fleck 
> on Sun, 30 Jan 2022 21:07:19 +0100 writes:

> it's not about the sort order of the ties, shouldn't all the 1s in
> order(c(2,3,4,1,1,1,1,1)) come before 2,3,4? because that's not what
> happening

aaah.. now we are getting somewhere:
It looks you have always confused order() with sort() ...
have you ?


> On Sun, Jan 30, 2022 at 9:00 PM Richard M. Heiberger  
wrote:

>> when there are ties it doesn't matter which is first.
>> in a situation where it does matter, you will need a tiebreaker column.
>> --
>> *From:* R-help  on behalf of Stefan Fleck <
>> stefan.b.fl...@gmail.com>
>> *Sent:* Sunday, January 30, 2022 4:16:44 AM
>> *To:* r-help@r-project.org 
>> *Subject:* [External] [R] Weird behaviour of order() when having multiple
>> ties
>> 
>> I am experiencing a weird behavior of `order()` for numeric vectors. I
>> tested on 3.6.2 and 4.1.2 for windows and R 4.0.2 on ubuntu. Can anyone
>> confirm?
>> 
>> order(
>> c(
>> 0.6,
>> 0.5,
>> 0.3,
>> 0.2,
>> 0.1,
>> 0.1
>> )
>> )
>> ## Result [should be in order]
>> [1] 5 6 4 3 2 1
>> 
>> The sort order is obviously wrong. This only occurs if i have multiple
>> ties. The problem does _not_ occur for decreasing = TRUE.
>> 
>> [[alternative HTML version deleted]]
>> 
>> __
>> R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
>> 
>> 
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-helpdata=04%7C01%7Crmh%40temple.edu%7Cbae20314c2314a5cc7cd08d9e429e33f%7C716e81efb52244738e3110bd02ccf6e5%7C0%7C0%7C637791692024451993%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=O6R%2FNM6IdPzP8RY3JIWfLgmkE%2B0KcVyYBxoRMo8v2dk%3Dreserved=0
>> PLEASE do read the posting guide
>> 
https://nam10.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.r-project.org%2Fposting-guide.htmldata=04%7C01%7Crmh%40temple.edu%7Cbae20314c2314a5cc7cd08d9e429e33f%7C716e81efb52244738e3110bd02ccf6e5%7C0%7C0%7C637791692024451993%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=6hlfMjZLzopVzGnFVWlGnoEqvZBQwXPlxMuZ2sglEUk%3Dreserved=0
>> and provide commented, minimal, self-contained, reproducible code.
>> 

> [[alternative HTML version deleted]]

> __
> R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide 
http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] function problem: multi selection in one argument

[Martin Maechler]

>>>>> Rui Barradas 
>>>>> on Tue, 25 Jan 2022 14:22:47 + writes:

> Hello,
> Here are 3 functions that do what the question asks for. The first 2 are 
> tidyverse solutions, the last one a base R function.

> I don't understand why the group_by and mutate, that's why I've included 
> a 2nd tidyverse function. And the base R function follows the same lines 
> of outputing the table only without data transformation.

> And the test dataset is not iris, it only has one factor variable. It 
> doesn't make sense to table a continuous variable such as Petal.Width.

> The data set mtcars has several numeric variables that are in fact 
> categorical ("vs", "am") and one, "cyl", that can be tabled. The 
> examples below use mtcars.



> f3 <- function(data, ...){
>   groups <- unlist(list(...))
>   temp <- data %>%
> select(all_of({{groups}})) %>%
> group_by(across(all_of({{groups}}))) %>%
> mutate(numbering = row_number(), max = n())
>   temp %>%
> select(all_of({{groups}})) %>%
> table()
> }

> f4 <- function(data, ...){
>   groups <- unlist(list(...))
>   data %>%
> select(all_of({{groups}})) %>%
> table()
> }

> f5 <- function(data, ...){
>   temp <- lapply(list(...), \(col) data[[col]])
>   table(setNames(temp, list(...)))
> }

> f3(mtcars, "am", "cyl")
> f4(mtcars, "am", "cyl")
> f5(mtcars, "am", "cyl")

> Hope this helps,
> Rui Barradas

Thank you, Rui!

Note that your base R solution can be vastly simplified :

> f6 <- function(data, ...) table(data[, unlist(list(...))])
> f6(mtcars, "am", "cyl")
   cyl
am   4  6  8
  0  3  4 12
  1  8  3  2
> 

If you started measuring carefully, I'm sure this would not only
be the shortest but also by far the fastest solution ...

Best,
Martin

--
Martin Maechler
ETH Zurich  and   R Core Team


> Às 00:14 de 25/01/2022, Kai Yang via R-help escreveu:
>> Hello Team,
>> I can run the function below:
>> 
>> library(tidyverse)
>> 
>> f2 <- function(indata, subgrp1){
>>   indata0 <- indata
>>   temp<- indata0 %>% select({{subgrp1}}) %>% arrange({{subgrp1}}) %>%
>> group_by({{subgrp1}}) %>%
>> mutate(numbering =row_number(), max=max(numbering))
>>   view(temp)
>>   f_table <- table(temp$Species)
>>   view(f_table)
>>   return(f_table)
>> }
>> f2(iris, Species)
>> 
>> You can see the second argument I use Species only, and it works fine.
>> But If I say, I want the 2nd argument = Petal.Width, Species , how 
should I write the argument? I did try f2(iris, c(Petal.Width, Species)), but I 
got error message:
>> Error: arrange() failed at implicit mutate() step.
>> * Problem with `mutate()` column `..1`.
>> i `..1 = c(Petal.Width, Species)`.
>> i `..1` must be size 150 or 1, not 300.
>> 
>> I'm not sure how to fix the problem either in function or can fix it 
when using the function.
>> Thank you,
>> Kai
>> [[alternative HTML version deleted]]
>> 
>> __
>> R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
>> https://stat.ethz.ch/mailman/listinfo/r-help
>> PLEASE do read the posting guide 
http://www.R-project.org/posting-guide.html
>> and provide commented, minimal, self-contained, reproducible code.

> __
> R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide 
http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] How to create density ellipses with R

[Martin Maechler]

>>>>> Gerrit Eichner 
>>>>> on Fri, 14 Jan 2022 16:42:28 +0100 writes:

> Hi Paul, take a look at base R's function contour (and the
> Examples section of its help page), and follow maybe the
> hints under "See also".

>   Hth -- Gerrit

Also, with Recommended packages 'cluster' and its
ellipsoidPoints() function:

The result of

 library(cluster)
 example(ellipsoidPoints)

is the attached plot with a classical and
robust (via recommend pkg 'MASS') covariance ellipse drawn.

Best,
Martin

--
Martin Maechler
ETH Zurich; R Core, and maintainer of 'cluster'

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] Adding SORT to UNIQUE

[Martin Maechler]

> Rui Barradas 
> on Mon, 20 Dec 2021 17:05:33 + writes:

> Hello,
> Package stringr has functions str_sort and str_order, both with an 
> argument 'numeric' that will sort the numbers correctly.
> Maybe that's what you are looking for, see the example below.


> x <- sample(sprintf("ab%d", 1:20)) # shuffle the vector
> stringr::str_sort(x, numeric = TRUE)   # sort considering the numbers

Again:
There's really no need to use non-base R here (and in almost all
such questions about string handling!)
as Avi Gross' answer shows.


> Hope this helps,

> Rui Barradas


> Às 16:58 de 20/12/21, Stephen H. Dawson, DSL via R-help escreveu:
>> Hi,
>> 
>> 
>> Running a simple syntax set to review entries in dataframe columns. Here 
>> is the working code.
>> 
>> Data <- read.csv("./input/Source.csv", header=T)
>> describe(Data)
>> summary(Data)
>> unique(Data[1])
>> unique(Data[2])
>> unique(Data[3])
>> unique(Data[4])
>> 
>> I would like to add sort the unique entries. The data in the various 
>> columns are not defined as numbers, but also text. I realize 1 and 10 
>> will not sort properly, as the column is not defined as a number, but 
>> want to see what I have in the columns viewed as sorted.
>> 
>> QUESTION
>> What is the best process to sort unique output, please?
>> 
>> 
>> Thanks.

> __
> R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide 
http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] Bug in list.files(full.names=T)

[Martin Maechler]

> Bill Dunlap 
> on Mon, 20 Dec 2021 08:40:04 -0800 writes:

>> 
>> > Why would one ever *add* a final unneeded path separator,
>> > unless one wanted it?
>> 

> Good question, but it is common for Windows installer programs to add a
> terminal backslash to PATH entries.  E.g., on my Windows laptop I get

>> grep(value=TRUE, "$", strsplit(Sys.getenv("PATH"), ";")[[1]])
> [1] "C:\\Python39\\Scripts\\"
> [2] "C:\\Python39\\"
> [3] "C:\\WINDOWS\\System32\\WindowsPowerShell\\v1.0\\"
> [4] "C:\\WINDOWS\\System32\\OpenSSH\\"
> [5] "C:\\Program Files\\nodejs\\"
> [6] "C:\\Program Files\\Pandoc\\"
> [7] "C:\\Program Files\\MiKTeX\\miktex\\bin\\x64\\"
> [8] "C:\\Program Files\\PuTTY\\"

> I did not add those entries by hand; all were added by installer programs.

> -Bill

Thanks a lot, Bill,  for giving this part of the picture
(even though you did not show how many there were in your PATH which
 did *not* end in `\\` ..)

However the reason for my 2nd post was that I could *not* at all
confirm what Mario reported, but rather I saw
having a final "/" and not having it
to give the *same* behavior on R for Windows versions
from 3.6.1 to 4.1.2 on our M$ Windows terminal server (2016)
and now, as I just checked, it also *still* has the same Windows-specific
behavior in R-devel-ucrt (the one from Tomas Kalibera) :

If I use a trailing `/` or `\\` it is *kept*, but no additional
fsep (i.e. '/' or `\\`) is added (on Windows) when I use

 list.files(dir, full.names=TRUE)

contrary to what Mario reported (to happen in R 4.1.2, but not R 3.6.1)

Martin

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] Bug in list.files(full.names=T)

[Martin Maechler]

>>>>> Martin Maechler 
>>>>> on Mon, 20 Dec 2021 09:46:23 +0100 writes:

>>>>> Mario Reutter 
>>>>> on Sat, 18 Dec 2021 15:55:37 +0100 writes:

>> Dear everybody,

>> I'm a researcher in the field of psychology and a
>> passionate R user. After having updated to the newest
>> version, I experienced a problem with list.files() if the
>> parameter full.names is set to TRUE.  A path separator
>> "/" is now always appended to path in the output even if
>> path %>% endsWith("/"). This breaks backwards
>> compatibility in case path ends with a path
>> separator. The problem occurred somewhere between R
>> version 3.6.1 (2019-07-05) and 4.1.2 (2021-11-01).

>> Example:
>>>> list.files("C:/Data/", full.names=T)
>> C:/Data//file.csv

>> Expected behavior: Either a path separator should never
>> be appended in accordance with the documentation:
>> "full.names a logical value. If TRUE, the directory path
>> is prepended to the file names to give a relative file
>> path."  Or it could only be appended if path doesn't
>> already end with a path separator.

> This expected behavior has never been documented AFAIK.  I
> tried R 3.6.1 on Linux and it already behaved like that:
> If you append a path separator it is kept in addition to
> the new one even though it's not needed:

>> list.files("/tmp", "^[abc]", full.names = TRUE)
> [1] "/tmp/check_proc__localuser"

>> list.files("/tmp/", "^[abc]", full.names = TRUE)
> [1] "/tmp//check_proc__localuser"

> Why would one ever *add* a final unneeded path separator,
> unless one wanted it?

> Note that the default is ".", not "./" ..

> I think the change you see made R-for-Windows compatible
> to the rest of the univeRse where list.files() aka dir()
> always behaved like this.

> I agree that ideally this would have been mentioned in
> some of the NEWS; maybe it *is* mentioned in the rw-faw (R
> for Windows FAQ) or other R for Windows news.. ?

On the other hand, now that I tried it,
on the Windows Terminal Server 2016 I've access to,
I see what you said *was* your previous behavior, i.e.,
I see this {R code with comments for what I see} :

##
str(c0 <- list.files("C:/"))
## chr [1:23] "$Recycle.Bin" "536F22AB9746" "Boot" "bootmgr" "BOOTNxsXT" ...
str(c1 <- list.files("C:/Boot", full.names=TRUE))
str(c1s <- list.files("C:/Boot/", full.names=TRUE))# extra '/' at end
## but even here, the extra trailing '/' does *not* harm
all(c1 == c1s) ## TRUE !

The above, using ESS and plain RGui Windows *and* Rstudio;
for ESS in the following of my (dozen or so on Windows server) R versions :
R 3.6.1, 4.0.0, 4.1.1, 4.1.2

... so I remain quite a bit puzzled...

Maybe other R-on-Windows users can have a look?
Martin

>> My question would now be if this warrants a bug report?

> I don't think so.  As I'm saying above, I think this has
> rather been a bug fix, making R more universal / less
> platform-dependent.

> Last but not least: You'd ideally update more than every
> 2.5 years...

> Best, Martin Maechler



>> And if you agree, could someone issue the report since
>> I'm not a member on Bugzilla?

>> Thank you and best regards, Mario Reutter

> __
> R-help@r-project.org mailing list -- To UNSUBSCRIBE and
> more, see https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide
> http://www.R-project.org/posting-guide.html and provide
> commented, minimal, self-contained, reproducible code.

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

[R] Call for proposals to organize useR! 2023 as a hybrid conference

[Martin Maechler]

Dear All,

The R Foundation Conference Committee invites proposals to organize useR! 2023 
as a hybrid conference:

https://www.r-project.org/conferences/useR_2023_call.html

The call is open to hosts worldwide and the deadline for outline proposals is 
**Friday 28 January 2022**. 

Any queries should be sent to r-conferen...@r-project.org (after a careful read 
of the call!).

Best wishes,

Heather Turner
on behalf of the R Foundation Conference Committee

___
r-annou...@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-announce

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] Bug in list.files(full.names=T)

[Martin Maechler]

>>>>> Mario Reutter 
>>>>> on Sat, 18 Dec 2021 15:55:37 +0100 writes:

> Dear everybody,

> I'm a researcher in the field of psychology and a
> passionate R user. After having updated to the newest
> version, I experienced a problem with list.files() if the
> parameter full.names is set to TRUE.  A path separator "/"
> is now always appended to path in the output even if path
> %>% endsWith("/"). This breaks backwards compatibility in
> case path ends with a path separator. The problem occurred
> somewhere between R version 3.6.1 (2019-07-05) and 4.1.2
> (2021-11-01).

> Example:
>>> list.files("C:/Data/", full.names=T)
> C:/Data//file.csv

> Expected behavior: Either a path separator should never be
> appended in accordance with the documentation: "full.names
> a logical value. If TRUE, the directory path is prepended
> to the file names to give a relative file path."  Or it
> could only be appended if path doesn't already end with a
> path separator.

This expected behavior has never been documented AFAIK.
I tried R 3.6.1 on Linux  and it already behaved like that:  If
you append a path separator  it is kept in addition to the new
one even though it's not needed:

> list.files("/tmp", "^[abc]", full.names = TRUE)
[1] "/tmp/check_proc__localuser"

> list.files("/tmp/", "^[abc]", full.names = TRUE)
[1] "/tmp//check_proc__localuser"

Why would one ever *add* a final unneeded path separator, unless
one wanted it?

Note that the default is  ".",  not "./"  ..

I think the change you see made R-for-Windows compatible
to the rest of the univeRse where list.files() aka dir() always
behaved like this.

I agree that ideally this would have been mentioned in some of
the NEWS; maybe it *is* mentioned in the rw-faw (R for Windows
FAQ) or other R for Windows news.. ?


> My question would now be if this warrants a bug report?

I don't think so.
As I'm saying above, I think this has rather been a bug fix,
making R more universal / less platform-dependent.

Last but not least: You'd ideally update more than every 2.5 years...

Best,
Martin Maechler



> And if you agree, could someone issue the report since I'm
> not a member on Bugzilla?

> Thank you and best regards, Mario Reutter

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] Forwarding missing arguments to the `[` method

[Martin Maechler]

> Ivan Krylov 
> on Wed, 8 Dec 2021 16:52:00 +0300 writes:

I have always learnt a lot about programming when reading other
people's code .. notably if those people new what they are
doing.

In this case, studying R-core's

`[.data.frame`  and

`[<-.data.frame`

{or for S4 methods, the 'Matrix' or 'Rmpfr' packages}

should show you a lot.

What you should take from there:
Do work with *both*
missing(drop)
and
nargs()

(and more)
in order to distinguish m[i] from m[i,] etc


Best,
Martin


> Got some progress on this, but still not sure how to continue. First, a
> much more simple script reproducing the behaviour that confuses me:

> foo <- function(x, ...) structure(x, class = 'foo')
> `[.foo` <- function(x, i, ..., drop = TRUE) {
>   print(sys.call())
>   print(match.call())
>   foo(NextMethod()) # x[] should return an object of class foo
> }
> `[<-.foo` <- function(x, i, ..., value) {
>   print(sys.call())
>   print(match.call())
>   x[i, ..., drop = FALSE]
>   # imagine that we need to perform some checks on the
>   # subset of x that we're about to replace
>   NextMethod()
> }
> 
> x <- foo(42)
> x[]  # this works
> x[] <- 1 # this doesn't
> 
> Now, the crucial difference between the x[] and x[] <- 1 calls is that
> in the former case, the `i` argument isn't even specified:
> 
> x[]
> # `[.foo`(x, )
> # `[.foo`(x = x)
> # [1] 42
> # attr(,"class")
> # [1] "foo"
> 
> While in the latter case, `i` is specified in the x[] call (but
> missing):
> 
> x[] <- 1
> # `[<-.foo`(`*tmp*`, , value = 1)
> # `[<-.foo`(x = `*tmp*`, value = 1)
> # x[i, ..., drop = FALSE]
> # `[.foo`(x = x, i = i, drop = FALSE)
> Error in NextMethod() : argument "i" is missing, with no default
> 
> What's the best way to forward the arguments from [<-.class methods to
> the [.class methods in order to handle cases like x[] properly?
> 
> -- 
> Best regards,
> Ivan
> 
> __

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] GPL or not (was "(no subject)")

[Martin Maechler]

>>>>> Arnaud FELD 
>>>>> on Tue, 9 Nov 2021 23:03:40 +0100 writes:

> Thanks for your answer. That is helpful even if that is disappointing
> for me ;) I can see now that, as R (base and recommended packages) has
> had contributions from a lot of people, it's not like a package, you
> just can't have a punctual "okay do what you want". I'll have to stick
> with a slow window call, I guess.

> I was right to ask anyway, and thanks for your advices.

Rather you should think long and hard if and why you  really
really want to stick with a non-GPL licence for you package.
That is the real problem and a shame in my eyes!

R would almost surely never have grown big if the original authors,
Ross Ihaka and Robert Gentleman  hadn't decided to adopt the GNU Public 
Licence (GPL)  very early ... and Ross & Robert said it was to a
large extent because I had insisted that this was important and
would potentially bring quite a few highly qualified people (all
from academia at the time) to adopt and contribute to R.

So, *not* using  GPL  for your package feels slightly as a slap
in the face of all the people who made R what it is today.

and just for those it is not obvious:
You *could* easily copy part of R code into your package if
you switched to use GPL -- of course still attributing these
parts a copyrighted by the R Core team.
Quite a few package maintainers have done so, e.g.,
testthat, actuar, pryr, vetr, DPQ, round, ... {I count about 80
CRAN packages}

Martin

--
Martin Maechler
ETH Zurich  and  R Core team


> Le mar. 9 nov. 2021 à 22:51, Duncan Murdoch  a 
écrit :
>> 
>> On 09/11/2021 3:52 p.m., Jeff Newmiller wrote:
>> > I understand that, but the reason he gives for copying code from the 
stats package is to change the license. That decision seems like something that 
requires a very direct communication with/permission from the maintainer.
>> 
>> The stats package doesn't give a valid maintainer() address.  It gives a
>> vague reference to the r-project.org website, but that website doesn't
>> give a contact address.
>> 
>> In fact, the authorship of R is very widely distributed among at least
>> dozens of contributors.  Identifying and contacting them all would be a
>> nightmare but probably isn't necessary.  However, identifying and
>> contacting the necessary ones (the ones who hold copyright on the parts
>> he wants to copy) would be very difficult.  Not contacting the relevant
>> ones would mean Arnaud's work would be potentially in violation of their
>> copyright.
>> 
>> Even if he did manage to contact all the copyright holders, some of them
>> would probably not agree to more permissive licenses.  For example, I am
>> a copyright holder on some parts of the source, and I wouldn't agree to
>> relicensing.
>> 
>> Duncan Murdoch
>> 
>> 
>> 
>> >
>> > On November 9, 2021 12:21:18 PM PST, Duncan Murdoch 
 wrote:
>> >> On 09/11/2021 2:45 p.m., Jeff Newmiller wrote:
>> >>> This question isn't a "how to do package development" question... 
this is about a specific package so you should send email to the package 
developer identified by the maintainer() function.
>> >>
>> >> I think Arnaud is the package developer; his question is whether he 
can
>> >> copy R source into his package.
>> >>
>> >> Duncan Murdoch
>> >>
>> >>>
>> >>> I can't foresee this request finding a positive response from R 
Core, but email seems the most correct approach.
>> >>>
>> >>> On November 9, 2021 11:34:12 AM PST, Bert Gunter 
 wrote:
>> >>>> Questions about package development should be posted to
>> >>>> R-package-devel (**not R-devel**).
>> >>>> See https://www.r-project.org/mail.html  for details.
>> >>>>
>> >>>> (I am not sure that they get into legal weeds there, but it seems 
like
>> >>>> the right place to try).
>> >>>>
>> >>>> Bert Gunter
>> >>>>
>> >>>> "The trouble with having an open mind is that people keep coming 
along
>> >>>> and sticking things into it."
>> >>>> -- Opus (aka Berkeley Breathed in his "Bloom County" comic strip )
>> >>>>
>> >>>> On Tue, Nov 9, 2021 at 11:17 AM Arnaud FELD 
 wrote:
  

Re: [R] extracting a R object from an R image

[Martin Maechler]

> Jeff Newmiller 
> on Fri, 05 Nov 2021 16:45:02 -0700 writes:

> IMO you are being a bit too literal. It is absolutely possible to load 
the file into a dedicated environment and use the $ or [[]] extraction operator 
to access a specific object in that environment.
> ?load
> ?new.env

> Or, you can attach the file, copy to a new variable, and detach. (see 
examples in ?load)

Exactly: In the eyes of most R experts, it is the only useful use of attach():

   attach(".RData") 
   ls.str(2) # -> get alevel-1 str(.) of the objects in your image


> On November 5, 2021 3:26:49 PM PDT, Bert Gunter  
wrote:
>> You can't. You can only save and load whole .RData files. You can, of
>> course, save and load separate R objects in separate files. But note
>> in ?save.image:
>> 
>> "For saving single R objects, saveRDS() is mostly preferable to
>> save(), notably because of the functional nature of readRDS(), as
>> opposed to load(). "
>> 
>> You may wish to search on "data serialization" (e.g. on Wikipedia) or
>> similar to better understand the underlying ideas.
>> 
>> Bert Gunter
>> 
>> "The trouble with having an open mind is that people keep coming along
>> and sticking things into it."
>> -- Opus (aka Berkeley Breathed in his "Bloom County" comic strip )
>> 
>> Bert Gunter
>> 
>> "The trouble with having an open mind is that people keep coming along
>> and sticking things into it."
>> -- Opus (aka Berkeley Breathed in his "Bloom County" comic strip )
>> 
>> 
>> On Fri, Nov 5, 2021 at 3:01 PM Bogdan Tanasa  wrote:
>>> 
>>> Dear all,
>>> 
>>> I saved my work in a Rimage that contains multiple objects ;
>>> 
>>> the objects were generated with Monocle3 :
>>> 
>>> https://cole-trapnell-lab.github.io/monocle3/docs/starting/
>>> 
>>> one object is called CDS.
>>> 
>>> How shall I extract this object CDS (that has a complex structure) from 
the
>>> R image ?
>>> 
>>> thank you,
>>> 
>>> Bogdan
>>> 
>>> [[alternative HTML version deleted]]
>>> 
>>> __
>>> R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
>>> https://stat.ethz.ch/mailman/listinfo/r-help
>>> PLEASE do read the posting guide 
http://www.R-project.org/posting-guide.html
>>> and provide commented, minimal, self-contained, reproducible code.
>> 
>> __
>> R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
>> https://stat.ethz.ch/mailman/listinfo/r-help
>> PLEASE do read the posting guide 
http://www.R-project.org/posting-guide.html
>> and provide commented, minimal, self-contained, reproducible code.

> -- 
> Sent from my phone. Please excuse my brevity.

> __
> R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide 
http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] typo in documentation for array // how to report such

[Martin Maechler]

>>>>> Mathew Englander 
>>>>> on Fri, 29 Oct 2021 20:30:16 -0700 writes:

> I noticed a typo in the ?array help-file ("Multi-way
> Arrays"), which is also at this web page:
> https://stat.ethz.ch/R-manual/R-patched/library/base/html/array.html

> In the "Arguments" section of that page, under the
> subheading "dimnames", the second sentence begins "This
> must a list..." and it ought to read, "This must be a
> list...".

> I'm not subscribed to the mailing list, so please reply by
> email to let me know where I should report typos like this
> if I find any, in the future. I considered filing a bug
> report on Bugzilla but this obviously is not a bug in R,
> but just a mistake in the manual. I figured that someone
> reading this mailing list would know the proper person to
> alert, to fix the typo in the next edition of the R
> Manual.

Thank you, Mathew!

As to your question on how/where to report a bug etc,
as we actually *do* count the documentation inside the sources,
notably the help files, as part of R in the sense of 'bug'.
We have a careful (sometimes too detailed) page on the topic:
   https://www.r-project.org/bugs.html

Still, in such cases, the most efficient -- but not always available --
approach is to privately contact a member of the R core team
with the typo to be fixed, so it will happen swiftly and not
many people need to spend time with it.
 -> https://www.r-project.org/contributors.html

Another possible venue may be to contact the  'R Contribution'
working group  --> https://forwards.github.io/rcontribution/
of which several experienced members would know how to
efficiently address this.

.. and yes, I've added the missing "be" now ... but (of course) not in time
for the release of   R 4.1.2   which is planned for today.

Martin


Martin Maechler
ETH Zurich  and  R Core team

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] customize the step value

[Martin Maechler]

> Duncan Murdoch 
> on Fri, 29 Oct 2021 09:07:31 -0400 writes:

> On 29/10/2021 4:34 a.m., PIKAL Petr wrote:
>> Hi
>> 
>> One has to be careful when using fractions in seq step.
>> 
>> Although it works for 0.5
>>> (seq(0,10, .5) - round(seq(0,10,.5),2))==0
>> [1] TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE
>> TRUE
>> [16] TRUE TRUE TRUE TRUE TRUE TRUE
>> 
>> in case of 0.3 (or others) it does not always result in expected values 
(see
>> FAQ 7.31 for explanation)
>> 
>>> (seq(0,10, .3) - round(seq(0,10,.3),2))==0
>> [1]  TRUE  TRUE  TRUE FALSE  TRUE  TRUE FALSE  TRUE  TRUE FALSE  TRUE  
TRUE
>> [13] FALSE  TRUE  TRUE  TRUE  TRUE  TRUE FALSE  TRUE  TRUE  TRUE  TRUE 
FALSE
>> [25] FALSE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE FALSE  TRUE  TRUE


> Petr is right, it's unsafe to use fractional values for the step.  0.5 
> works because it has a power of 2 in the denominator and so does the 
> start value, but it's easy to make mistakes when you rely on that (e.g. 
> changing the step size from 0.5 to 0.3 would break things).

> A better idea is to modify a sequence of integers.  For example, to get 
> 1.5 to 3.5 by 0.5, you can do (3:7)*0.5, and for 0 to 3 by 0.3, use 
> (0:10)*0.3.


Well, but you will not get truly equidistant (to the last bit)
sequences also by that and people who are not aware of
FAQ 7.31  and its consequences do wrongly assume that

length(unique(diff(seqVec))) == 1

for any  seqVec <-  k * seq()   # k a "scalar" (of length 1)

but the reality of floating point arithmetic can be quite
different than pure math :

In this case and on my platform the two ways to construct the
sequence are even identical:

> identical((0:10)*0.3, seq(0, 3, by=.3))
[1] TRUE
> sv <- (0:10)*0.3
> length(unique(diff(sv))) # you'd like |-->  1 (the number 0.3 !)
[1] 5
>

Martin

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] R code in RData

[Martin Maechler]

> Bert Gunter 
> on Wed, 27 Oct 2021 10:47:14 -0700 writes:

> See ?load, but you may be confused. Strictly speaking, there is no code in
> an .Rdata file, only a (typically binary, but possibly ascii)
> representation of objects, usually as produced by ?save. Of course,
> functions are also objects, so that if you load a file with functions, the
> function code is available.

> You can save and load command histories via ?savehistory, which, like 
?save
> and ?load can usually be accessed through any GUI interface that you are
> using.

> Warning: I believe the above is correct, but I may be wrong in at least
> some details, so give others a chance to reply and possibly correct.

> Cheers,
> Bert

> Bert Gunter

In spite of really not recommending to work with .RData but
rather with R *scripts*  (or R Sweave / R markdown documents),
an often forgotten considerably more flexible and in that sense better
alternative to load() in such situations is  attach()
which creates an environment in which the objects are loaded and
attaches that to the search() path.

Example (from my current R console):

> save.image() # creates .RData
> attach(".RData")
> ls.str(pos=2)
logi :  Named logi [1:3] FALSE NA TRUE
Mlibrary : function (pkg, lib = NULL, check64.32 = TRUE, ...)  
ncF :  int [1:5, 1:3] 5 6 2 1 15 5 6 2 1 15 ...
nchars : function (x, ...)  
ncT :  int [1:5, 1:3] 5 6 NA 1 15 5 6 NA 1 15 ...
x :  chr [1:5] "asfef" "qwerty" NA "b" "stuff.blah.yech"
> 

So, indeed,  ls.str()  comes handy as well..

Best,
Martin

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] R code in RData

[Martin Maechler]

> Jeff Newmiller 
> on Wed, 27 Oct 2021 11:43:08 -0700 writes:

> Sounds right, though the OP appears to be assuming that the code used to 
generate the data objects in the file will also be there, and we need to be 
more definitive about that: it is not. Depending how the code was constructed, 
there may be useful information in the functions that were stored in the 
environment from which the save file was created, but this is not in any way 
guaranteed to be useful. In particular, there is no trace IN the RData file of 
which packages need to be loaded in order to access the objects stored in that 
RData file.
> This is one of the reasons depending on RData files for archiving work is 
not advisable... and why putting code in R scripts or Sweave/knitr-based 
literate programming files IS recommended.

Yes, very strongly recommended.

Citation:

  The source code is real.  Objects are realizations of the source code.
    

This has been the philosophy of using R-like systems
with ESS ("Emacs Speaks Statistics",  formerly 'S-mode') since the late 1980s,
also adopted by RStudio since 2011.


> On October 27, 2021 10:47:14 AM PDT, Bert Gunter  
wrote:
>> See ?load, but you may be confused. Strictly speaking, there is no code 
in
>> an .Rdata file, only a (typically binary, but possibly ascii)
>> representation of objects, usually as produced by ?save. Of course,
>> functions are also objects, so that if you load a file with functions, 
the
>> function code is available.
>> 
>> You can save and load command histories via ?savehistory, which, like 
?save
>> and ?load can usually be accessed through any GUI interface that you are
>> using.
>> 
>> Warning: I believe the above is correct, but I may be wrong in at least
>> some details, so give others a chance to reply and possibly correct.
>> 
>> Cheers,
>> Bert
>> 
>> Bert Gunter
>> 
>> "The trouble with having an open mind is that people keep coming along 
and
>> sticking things into it."
>> -- Opus (aka Berkeley Breathed in his "Bloom County" comic strip )
>> 
>> 
>> On Wed, Oct 27, 2021 at 10:18 AM Bogdan Tanasa  wrote:
>> 
>>> Dear all, would you please advice :
>>> 
>>> I have an Rdata file, what is the way to print the R code that has been
>>> used inside the Rdata file ?
>>> 
>>> thank you,
>>> 
>>> Bogdan
>>> 
>>> [[alternative HTML version deleted]]
>>> 
>>> __
>>> R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
>>> https://stat.ethz.ch/mailman/listinfo/r-help
>>> PLEASE do read the posting guide
>>> http://www.R-project.org/posting-guide.html
>>> and provide commented, minimal, self-contained, reproducible code.
>>> 
>> 
>> [[alternative HTML version deleted]]
>> 
>> __
>> R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
>> https://stat.ethz.ch/mailman/listinfo/r-help
>> PLEASE do read the posting guide 
http://www.R-project.org/posting-guide.html
>> and provide commented, minimal, self-contained, reproducible code.

> -- 
> Sent from my phone. Please excuse my brevity.

> __
> R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide 
http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] KeyboardSimulator mouse.get_cursor() Not Working

[Martin Maechler]

>>>>> Sparks, John 
>>>>> on Mon, 25 Oct 2021 15:36:07 + writes:

> Hi, I tried using the mouse.get_cursor() function in the
> KeyboardSimulator library but it appears to no longer be
> working.

> When I first tried it I got an error message

> Error in get_cursor() :

>   function 'Rcpp_precious_remove' not provided by package
> 'Rcpp'.

> I installed and loaded the Rcpp library and then why I try
> the get_cursor() function it freezes my Windows gui
> version of R.

> My Sys.info() is shown below.

> Any help would be appreciated.

> Thanks.  --John Sparks,

>> Sys.info()
>sysname release version nodename machine login
> "Windows" "10 x64" "build 19043" "SPARKS-PC" "x86-64"
> "JSparks" user effective_user "JSparks" "JSparks"

BTW: A package *only* available on Windows

What was the answer of

 maintainer("KeyboardSimulator")

when you asked him about the problem?
This is *the* approach to take first in such cases... unless
for standard R ("base" + "Recommended") packages or other
very very widely used packages, say ggplot2.

Best regards,
Martin

--
Martin Maechler
ETH Zurich  and R Core team

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] Do not show a "message d'avis" that qbeta reports

[Martin Maechler]

>>>>> Duncan Murdoch 
>>>>> on Wed, 20 Oct 2021 07:17:30 -0400 writes:

> Translations are done by the translation teams, listed
> here:
> <https://developer.r-project.org/TranslationTeams.html>.
> If you'd like to offer help, you could contact someone on
> that list.

> Duncan Murdoch

Indeed.   Currently, the French team is just one person, and
maybe they will be happy to share the workload  or to get
another pair of eyes to look at it...

Martin Maechler


> On 20/10/2021 6:47 a.m., Marc Girondot via R-help wrote:
>> Thanks ! It works.
>> 
>> So "Warnings" has been translated in French by "Message
>> d'avis :" !  > warning("Essai") Message d'avis : Essai
>> 
>> It is not the best translation...  I would prefer:
>> "Attention: "
>> 
>> Marc
>> 
>> Le 20/10/2021 à 12:28, Enrico Schumann a écrit :
>>> On Wed, 20 Oct 2021, Marc Girondot via R-help writes:
>>> 
>>>> Dear R-helpers
>>>> 
>>>> Do you know how to not show a "message d'avis" that
>>>> qbeta reports. suppressMessages and capture.output are
>>>> not working.
>>>> 
>>>> (PS I Know that qbeta with shape2 being 1e-7 is
>>>> "strange"... this is obtained during an optimization
>>>> process. Just I don't want see the messages).
>>>> 
>>>> Thanks
>>>> 
>>>> Marc Girondot
>>>> 
>>>> q <- qbeta(p=c(0.025, 0.975), shape1 = 3.3108797,
>>>> shape2 = 0.001) Message d'avis : Dans qbeta(p =
>>>> c(0.025, 0.975), shape1 = 3.3108797, shape2 = 1e-07) :
>>>>   qbeta(a, *) =: x0 with |pbeta(x0,*) - alpha| =
>>>> 0.024997 is not accurate
>>>> 
>>>> suppressMessages(q <- qbeta(p=c(0.025, 0.975), shape1 =
>>>> 3.3108797, shape2 = 0.001)) Message d'avis : Dans
>>>> qbeta(p = c(0.025, 0.975), shape1 = 3.3108797, shape2 =
>>>> 1e-07) :   qbeta(a, *) =: x0 with |pbeta(x0,*) - alpha|
>>>> = 0.024997 is not accurate
>>>> 
>>>> capture.output(q <- qbeta(p=c(0.025, 0.975), shape1 =
>>>> 3.3108797, shape2 = 0.001), type = "message")
>>>> character(0) Message d'avis : Dans qbeta(p = c(0.025,
>>>> 0.975), shape1 = 3.3108797, shape2 = 1e-07) :  
>>>> qbeta(a, *) =: x0 with |pbeta(x0,*) - alpha| = 0.024997
>>>> is not accurate
>>>> 
>>>> capture.output(q <- qbeta(p=c(0.025, 0.975), shape1 =
>>>> 3.3108797, shape2 = 0.001), type = "output")
>>>> character(0) Message d'avis : Dans qbeta(p = c(0.025,
>>>> 0.975), shape1 = 3.3108797, shape2 = 1e-07) :  
>>>> qbeta(a, *) =: x0 with |pbeta(x0,*) - alpha| = 0.024997
>>>> is not accurate
>>>> 
>>> Try 'suppressWarnings'.
>>> 
>>> 
>> 
>> __
>> R-help@r-project.org mailing list -- To UNSUBSCRIBE and
>> more, see https://stat.ethz.ch/mailman/listinfo/r-help
>> PLEASE do read the posting guide
>> http://www.R-project.org/posting-guide.html and provide
>> commented, minimal, self-contained, reproducible code.
>> 

> __
> R-help@r-project.org mailing list -- To UNSUBSCRIBE and
> more, see https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide
> http://www.R-project.org/posting-guide.html and provide
> commented, minimal, self-contained, reproducible code.

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] Replacing NA s with the average

[Martin Maechler]

>>>>> Richard O'Keefe 
>>>>> on Tue, 19 Oct 2021 14:22:53 +1300 writes:

> It *sounds* as though you are trying to impute missing data.
> There are better approaches than just plugging in means.
> You might want to look into CALIBERrfimpute or missForest.

Yes, indeed!
Put even more strongly:  "Imputation" has been an
important topic for decennia and it has been shown since the
1980s that plugging in columns means can be *very misleading*
for everything you do later with that modified data set.

The Wikipedia page is quite good as short intro
  https://en.wikipedia.org/wiki/Imputation_(statistics)

When I've been teaching about this, I've strongly recommended
multiple imputation and the "state-of-the-art" package  'mice'
which comes with a really good text book:

  Stef van Buuren (2012) -- Flexible Imputation of Missing Data 
  https://doi.org/10.1201/b11826 
  (= reference [12] in the Wikipedia article)

where in the first chapter you see a nice example on how bad
mean imputation typically will be ..

The JSS paper on mice is a more technical (I'd say "to be used
once you are already aware that 'mean imputation' should rarely be used):

> citation(package="mice")

To cite mice in publications use:

  Stef van Buuren, Karin Groothuis-Oudshoorn (2011). mice: Multivariate
  Imputation by Chained Equations in R. Journal of Statistical Software, 45(3),
  1-67. URL https://www.jstatsoft.org/v45/i03/.


Best regards,
Martin Maechler
ETH Zurich   and  R Core team


> On Tue, 19 Oct 2021 at 01:39, Admire Tarisirayi Chirume
>  wrote:
>> 
>> Good day colleagues. Below is a csv file attached which i am using in my
>> > analysis.
>> >
>> >
>> >
>> > household.id <http://hh.id>
>> >
>> > hd17.perm
>> >
>> > hd17employ
>> >
>> > health.exp
>> >
>> > total.food.exp
>> >
>> > total.nfood.exp
>> >
>> > 1
>> >
>> > 2
>> >
>> > yes
>> >
>> > 1654
>> >
>> > 23654
>> >
>> > 23655
>> >
>> > 2
>> >
>> > 2
>> >
>> > yes
>> >
>> > NA
>> >
>> > NA
>> >
>> > 65984
>> >
>> > 3
>> >
>> > 6
>> >
>> > no
>> >
>> > 2547
>> >
>> > 123311
>> >
>> > 52416
>> >
>> > 4
>> >
>> > 8
>> >
>> > NA
>> >
>> > 2365
>> >
>> > 13648
>> >
>> > 12544
>> >
>> > 5
>> >
>> > 6
>> >
>> > NA
>> >
>> > 1254
>> >
>> > 36549
>> >
>> > 12365
>> >
>> > 6
>> >
>> > 8
>> >
>> > yes
>> >
>> > 1236
>> >
>> > 236541
>> >
>> > 26522
>> >
>> > 7
>> >
>> > 8
>> >
>> > no
>> >
>> > NA
>> >
>> > 13264
>> >
>> > 23698
>> >
>> >
>> >
>> >
>> >
>> > So I created a df using the above and its a csv file as follows
>> >
>> > wbpractice <- read.csv("world_practice.csv")
>> >
>> > Now i am doing data cleaning and trying to replace all missing values 
with
>> > the averages of the respective columns.
>> >
>> > the dimension of the actual dataset is;
>> >
>> > dim(wbpractice)
>> [1] 319986
>> 
>> I used the following script which i executed by i got some error messages
>> 
>> for(i in 1:ncol( wbpractice  )){
>> wbpractice  [is.na( wbpractice  [,i]), i] <- mean( wbpractice  [,i],
>> na.rm = TRUE)
>> }
>> 
>> Any help to replace all NAs with average values in my dataframe?
>>

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

[R] Sebastian Meyer joins the R core team

[Martin Maechler]

We are very happy to announce that

Sebastian Meyer (http://www.imbe.med.uni-erlangen.de/ma/S.Meyer ;
 Twitter @bastistician; also https://github.com/bastistician/)

has joined the R core team yesterday (Oct 13).  He has been an
active contributor notably in handling and fixing R bugzilla issues in
dozens of contributions and also by direct communication,
mainly during the last 2 years but starting considerably earlier.

The R Core team

___
r-annou...@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-announce

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [ESS] Advice on setting up ESS to edit and knit Rmarkdown files

[Martin Maechler via ESS-help]

> Lionel Henry via ESS-help 
> on Wed, 22 Sep 2021 15:15:42 +0200 writes:

> We'd love to do a release but ESS is not in a good place
> right now.  

Definitely.  The reason is that there have been too many bugs
introduced with the new features, so we could/should not
release.

This has been the real reason for not releasing formally.

In addition, another important goal for the release has been to
create an ESS+ "package" (not mainly an ELPA package, but also a
traditional  tarball / zip file) which will contain
ESS plus relevant parts of polymode even though the latter is
only maintained by one of us; the use of both *and* correct
interplay between polymode and ESS is really crucial for parts
modern R using ESS, notably as we had decided to declare the ess
noweb-mode (for editing *.Rnw, i.e., Sweave & (tex-based) knitr)
as obsolete. 

> Recent versions of Emacs interrupt background
> commands (essential to completion and contextual help like
> eldoc) when the user starts typing, which causes hard to
> solve problems.

> The dev branch is mostly working but not 100%
> correctly. Unfortunately none of us seem to have the time
> to work on ESS at the moment.

> That said, while Martin, Vitalie and I notice issues here
> and there, we haven't had serious bug reports in a while,
> despite the dev branch being used by many Melpa users. So
> maybe releasing in the current state is better than  nothing.

Well...
It would be the first ESS release with serious (for some / in
some use case situaitons) known bugs ..

> Best, Lionel


> On 9/22/21, Dirk Eddelbuettel via ESS-help
>  wrote:
>> 
>> On 20 September 2021 at 13:59, Sparapani, Rodney via
>> ESS-help wrote: | Generally, this stuff should just work
>> out-of-the-box.
>> 
>> Understood.
>> 
>> | And we are not a company like RStudio so this FOSS
>> setup works for us as | developers and hopefully it still
>> serves the users well.
>> 
>> But legal structure has nothing to with 'calling a
>> release'. Which is done by authors (who should know the
>> code better than users) saying "yep what we have at HEAD
>> right now is good" and then cut a tarball.  That is a
>> _marker_.  Which some less-informed people like me can
>> take (and then ship downstream to Debian, and with that
>> Ubuntu etc).
>> 
>> Without a marker, no shipment. Less ideal to me and
>> others.
>> 
>> So pretty-please if someone would: could a release one of
>> these moons. It does not have to be frequent or regularly
>> schedule or anything.  But maybe more often than once
>> every few years?  Maybe when you sync with upstream Emacs
>> (assuming you do now)?
>> 
>> Dirk
>> 
>> --
>> https://dirk.eddelbuettel.com | @eddelbuettel |
>> e...@debian.org
>> 
>> __
>> ESS-help@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/ess-help
>> 

> __
> ESS-help@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/ess-help

__
ESS-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help

Re: [R] Windows: start script but keep being in R-shell after finish

[Martin Maechler]

> Duncan Murdoch 
> on Tue, 21 Sep 2021 09:09:40 -0400 writes:

> On 21/09/2021 3:12 a.m., c.bu...@posteo.jp wrote:
>> Hello together,
>> 
>> I was using R some years ago and I am sorry for asking such a dumb
>> question. I found some help instructions about commandline interface but
>> I still miss the piece of information I need. I assume it depends on my
>> non-nativ English that I am not able to ask the correct (worded)
>> question to the search engines.
>> 
>> I use R-for-windows on the shell. No GUI, IDE or anything else.
>> When I am in windows shell ("command prompt"?) I wan't to run an
>> R-script (filename *.R). But when the script is finished or interrupted
>> the R-prompt should do not close.
>> 
>> In python I would do
>> 
>> python3 -i -m myscript

> I don't think R supports this, but the following almost works:

> cat myscript.R - | Rterm --ess

Inside R, we use

  source("mycript.R")

where source() has several optional arguments in addition,
such as 'echo=TRUE' 

Probably Duncan did not mention it here, because indeed, it's
not quite equivalent to running the above semi-"batch mode"...

Martin


> This copies your file followed by stdin into the stdin of R.  The --ess 
> option tells R to act as if input is interactive, despite what it sees.

> This comes kind of close, but there are a couple of problems.

> - If I type really fast, the characters appear in the wrong order in R.
> - At the end when I quit, it sits there for a while until I hit enter, 
> then gives the error message "cat: write error: no more space on device".

> Perhaps these problems can be fixed.

> Another approach would be to set an environment variable specifying that 
> myscript.R is a user profile file, set via environment variable

> R_PROFILE_USER=myscript.R

> This has the disadvantage of overriding a pre-existing user profile 
> file, but if this is just for you, I guess you know if you have one.

> Duncan Murdoch

> __
> R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide 
http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] Query regarding stats/p.adjust package (base) - specifically 'Hochberg' function

[Martin Maechler]

> Bert Gunter 
> on Tue, 24 Aug 2021 10:50:50 -0700 writes:

> 1. No Excel attachments made it through. Binary
> attachments are generally stripped by the list server for
> security reasons.

> 2. As you may have already learned, this is the wrong
> forum for statistics or package specific questions. Read
> *and follow* the posting guide linked below to post on
> r-help appropriately. In particular, for questions about
> specific non-standard packages, contact package
> maintainers (found through e.g. ?maintainers)

> 3. Statistics issues generally don't belong here. Try
> stats.stackexchange.com instead perhaps.

> 4. We are not *R Core development,* and you probably
> should not be contacting them either.  See here for
> general guidelines for R lists:
> https://www.r-project.org/mail.html


> Bert Gunter

> "The trouble with having an open mind is that people keep
> coming along and sticking things into it."  -- Opus (aka
> Berkeley Breathed in his "Bloom County" comic strip )

Well, this was a bit harsh of an answer, Bert.

p.adjust() is a standard R  function  (package 'stats') -- as
David Swanepoel did even mention.

I think he's okay asking here if the algorithms used in such a
standard R functions are  "ok"  and how/why they seemlingly
differ from other implementations ...

Martin

> On Tue, Aug 24, 2021 at 10:39 AM David Swanepoel
>  wrote:
>> 
>> Dear R Core Dev Team, I hope all is well your side!  My
>> apologies if this is not the correct point of contact to
>> use to address this. If not, kindly advise or forward my
>> request to the relevant team/persons.
>> 
>> I have a query regarding the 'Hochberg' method of the
>> stats/p.adjust R package and hope you can assist me
>> please. I have attached the data I used in Excel, which
>> are lists of p-values for two different tests (Hardy
>> Weinberg Equilibrium and Linkage Disequilibrium) for four
>> population groups.
>> 
>> The basis of my concern is a discrepancy specifically
>> between the Hochberg correction applied by four different
>> R packages and the results of the Hochberg correction by
>> the online tool,
>> MultipleTesting.com.
>> 
>> Using the below R packages/functions, I ran multiple test
>> correction (MTC) adjustments for the p-values listed in
>> my dataset. All R packages below agreed with each other
>> regarding the 'significance' of the p-values for the
>> Hochberg adjustment.
>> 
>> 
>> * stats/p.adjust (method: Hochberg) * mutoss/hochberg *
>> multtest/mt.rawp2adjp (procedure: Hochberg) * elitism/mtp
>> (method: Hochberg)
>> 
>> In checking the same values on the MultipleTesting.com,
>> more p-values were flagged as significant for both the
>> HWE and LD results across all four populations. I show
>> these differences in the Excel sheet attached.
>> Essentially, using the R packages, only the first HWE
>> p-value of Pop2 is significant at an alpha of 0.05. Using
>> the MT.com tool, however, multiple p-values are shown to
>> be significant across both tests with the Hochberg
>> correction (the highlighted cells in the Excel sheet).
>> 
>> 
>> I asked the authors of MT.com about this, and they gave
>> the following response:
>> 
>> "we have checked the issue, and we believe the
>> computation by our page is correct (I cannot give opinion
>> about the other packages).  When we look on the original
>> Hochberg paper, and we only use the very first (smallest)
>> p value, then m"=1, thus, according to the equation in
>> the Hochberg 1988 paper, in this case practically there
>> is no further correction necessary.  In other words, in
>> case the *smallest* p value is smaller than alpha, then
>> the *smallest* p value will remain significant
>> irrespective of the other p values when we make the
>> Hochberg correction."
>> 
>> I have attached the Hochberg paper here but,
>> unfortunately, I don't understand enough of the stats to
>> verify this. I have applied their logic on the same Excel
>> sheet under the section "MT.com explanation", which shows
>> why they consider the highlighted values significant.
>> 
>> I have also attached the 2 R files that I used to do the
>> MTC runs and they can be run as is. They are just quite
>> long as they contain many of the other MTC methods in the
>> different packages too.
>> 
>> Kindly provide your thoughts as to whether you agree with
>> this interpretation of the Hochberg paper or not? I would
>> like to see concordance between the MT.com tool and the
>> different R packages above (or understand why they are
>> different), so that I can be more confident in the
>> explanations 

Re: [R] Formula compared to call within model call

[Martin Maechler]

>>>>> Tim Taylor 
>>>>> on Wed, 11 Aug 2021 08:45:48 + writes:

> Manipulating formulas within different models I notice the following:

> m1 <- lm(formula = hp ~ cyl, data = mtcars)
> m2 <- update(m1, formula. = hp ~ cyl)
> all.equal(m1, m2)
> #> [1] TRUE
> identical(m1, m2)
> #> [1] FALSE
> waldo::compare(m1, m2)
> #> `old$call[[2]]` is a call
> #> `new$call[[2]]` is an S3 object of class , a call

> I'm aware formulas are a form of call but what I'm unsure
> of is whether there is meaningful difference between the
> two versions of the models? 

A good question.
In principle, the promise of an update()  method should be to
produce the *same* result as calling the original model-creation
(or more generally object-creation) function call.

So, already with identical(), you've shown that this is not
quite the case for simple lm(),
and indeed that is a bit undesirable.

To answer your question re "meaningful" difference,
given what I say above is:
No, there shouldn't be any relevant difference, and if there is,
that may considered a bug in the respective update() method,
here update.lm.

More about this in the following  R code snippet :

## MM: indeed,
identical(m1$call, m2$call) #> [1] FALSE
noCall <- function(x) x[setdiff(names(x), "call")]
identical(noCall(m1), noCall(m2))# TRUE!
## look closer:
c1 <- m1$call
c2 <- m2$call
str(as.list(c1))
## List of 3
##  $: symbol lm
##  $ formula: language hp ~ cyl
##  $ data   : symbol mtcars

str(as.list(c2))
## List of 3
##  $: symbol lm
##  $ formula:Class 'formula'  language hp ~ cyl
##   .. ..- attr(*, ".Environment")=
##  $ data   : symbol mtcars

identical(c1[-2], c2[-2]) # TRUE ==> so, indeed the difference is *only* in the 
formula ( = [2]) component
f1 <- c1$formula
f2 <- c2$formula
all.equal(f1,f2) # TRUE
identical(f1,f2) # FALSE
## Note that this is typically *not* visible if the user uses the accessor 
functions:
identical(formula(m1), formula(m2)) # TRUE !
## and indeed, the formula() method for 'lm'  does set the environment:
stats:::formula.lm


--
Martin Maechler
ETH Zurich   and  R Core

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] density with weights missing values

[Martin Maechler]

>>>>> Matthias Gondan 
>>>>> on Mon, 12 Jul 2021 15:09:38 +0200 writes:

> Weighted mean behaves differently:
> • weight is excluded for missing x
> • no warning for sum(weights) != 1

>> weighted.mean(c(1, 2, 3, 4), weights=c(1, 1, 1, 1))
> [1] 2.5
>> weighted.mean(c(1, 2, 3, NA), weights=c(1, 1, 1, 1))
> [1] NA
>> weighted.mean(c(1, 2, 3, NA), weights=c(1, 1, 1, 1), na.rm=TRUE)
> [1] 2


I'm sure the 'weights' argument in weighted.mean() has been used
much more often than the one in density().
Hence, it's quite "probable statistically" :-)  that the
weighted.mean() behavior in the NA case has been more rational
and thought through 

So I agree with you, Matthias, that ideally density() should
behave differently here,  probably entirely analogously to weighted.mean().

Still, Bert and others are right that there is no bug formally,
but something that possibly should be changed; even though it
breaks back compatibility for those cases,  such case may be
very rare (I'm not sure I've ever used weights in density() but
I know I've used it very much all those 25 years ..).

https://www.r-project.org/bugs.html

contains good information about determining if something may be
a bug in R *and* tell you how to apply for an account on R's
bugzilla for reporting it formally.
I'm hereby encouraging you, Matthias, to do that and then in
your report mention both density() and weighted.mean(), i.e., a
cleaned up version of the union of your first 2 e-mails..

Thank you for thinking about this and concisely reporting it.
Martin


> Von: Richard O'Keefe
> Gesendet: Montag, 12. Juli 2021 13:18
> An: Matthias Gondan
> Betreff: Re: [R] density with weights missing values

> Does your copy of R say that the weights must add up to 1?
> ?density doesn't say that in mine.   But it does check.

another small part to could be improved, indeed,
thank you, Richard.

--
Martin Maechler
ETH Zurich  and  R Core team
 
> On Mon, 12 Jul 2021 at 22:42, Matthias Gondan  
wrote:
>> 
>> Dear R users,
>> 
>> This works as expected:
>> 
>> • plot(density(c(1,2, 3, 4, 5, NA), na.rm=TRUE))
>> 
>> This raises an error
>> 
>> • plot(density(c(1,2, 3, 4, 5, NA), na.rm=TRUE, weights=c(1, 1, 1, 1, 1, 
1)))
>> • plot(density(c(1,2, 3, 4, 5, NA), na.rm=TRUE, weights=c(1, 1, 1, 1, 1, 
NA)))
[..]

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] Beginner problem - using mod function to print odd numbers

[Martin Maechler]

>>>>> David Carlsonon Sun, 6 Jun 2021 15:21:34 -0400 writes:

> There is really no need for a loop:
> num <- 1:100
> num[ifelse(num %% 2 == 1, TRUE, FALSE)]

> [1]  1  3  5  7  9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49
> [26] 51 53 55 57 59 61 63 65 67 69 71 73 75 77 79 81 83 85 87 89 91 93 95 97 
> 99

Well, and the above "works" but is really another proof of my
year-long claim that people use  ifelse(.)  *MUCH MUCH* too often,
and should really learn to use alternatives, in this case,
"R 101" (*long* before fooverse):

Use

num[num %% 2 == 1]

instead of much slower and ...@#^$

num[ifelse(num %% 2 == 1, TRUE, FALSE)]

Martin Maechler
ETH Zurich 

> On Sat, Jun 5, 2021 at 2:05 PM William Michels via R-help
>  wrote:
>> 
>> > i <- 1L; span <- 1:100; result <- NA;
>> > for (i in span){
>> + ifelse(i %% 2 != 0, result[i] <- TRUE, result[i] <- FALSE)
>> + }
>> > span[result]
>> [1]  1  3  5  7  9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43

 []

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] Solving a quadratically constrained linear program with inital values

[Martin Maechler]

>>>>> Bert Gunter 
>>>>> on Mon, 17 May 2021 17:27:27 -0700 writes:

> Have you looked here:
> https://cran.r-project.org/web/views/Optimization.html

yes, he has .. and I've suggested to him to ask here ... 

> (Warning: I have no idea whether your query even makes
>  mathematical sense.)

Indeed, it *does* make sense; at least for the case of positive
(semi-)definite \Sigma  which we may well assume for the moment.

Martin Maechler


> Bert Gunter

> "The trouble with having an open mind is that people keep coming along and
> sticking things into it."
> -- Opus (aka Berkeley Breathed in his "Bloom County" comic strip )


> On Mon, May 17, 2021 at 12:56 PM Pascal Kündig 
> wrote:

>> Hi everyone,
>> I'm looking for an R-function that solves a quadratically constrained
>> linear program of the form:
>> 
>> min(x) -\mu' x
>> subject to
>> x' \Sigma x <= s
>> 1'x <= 1
>> -1'x <= -1
>> Ix <= u
>> -Ix <= -b
>> 
>> while considering a given starting value for the vector x.
>> The above problem results from a larger program of the same structure
>> and by setting the constraint that some elements of the solution vector
>> \tilde{x} of this larger program have to be 0 if they lie below a
>> certain threshold. The starting value for the vector x is therefore a
>> subvector of \tilde{x}. \Sigma is symmetric but not necessarily positive
>> definite.
>> 
>> __
>> R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
>> https://stat.ethz.ch/mailman/listinfo/r-help
>> PLEASE do read the posting guide
>> http://www.R-project.org/posting-guide.html
>> and provide commented, minimal, self-contained, reproducible code.
>> 

> [[alternative HTML version deleted]]

> __
> R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide 
http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] Matrix::solve() with 1-d arrays -- treating "array" as "numeric"?

[Martin Maechler]

>>>>> Deepayan Sarkar 
>>>>> on Mon, 19 Apr 2021 09:56:58 +0530 writes:

> On Sat, Apr 17, 2021 at 9:08 PM Martin Maechler
>  wrote:
>> 
>> >>>>> Deepayan Sarkar >>>>> on Fri, 16 Apr 2021 11:34:20
>> +0530 writes:
>> 
>> > I get what I initially thought was unexpected behaviour
>> from:
>> 
>> > x <- tapply(runif(100), sample(5, 100, TRUE), mean) >
>> solve(Diagonal(5), x) > # Error: not-yet-implemented
>> method for solve(, ).  > # ->> Ask the
>> package authors to implement the missing feature.
>> 
>> ((why did you not ask the package authors ?? --- never
>> mind))
>> 
>> 
>> > This is because x is a 1-D array, so the operation is
>> not > well-defined. Would it make sense for Matrix to
>> support this (treat > 1-D arrays as column vectors, as it
>> does for plain vectors)? Or should > I make my intent
>> clear with
>> 
>> > solve(Diagonal(5), as.vector(x))
>> 
>> well ...
>> 
>> The "fun" thing is that it actually works when Matrix
>> methods are not fully available, i.e., if you do *not* do
>> require(Matrix) or equivalent, but rather only load the
>> Matrix namespace via
>> 
>> solve(Matrix::Diagonal(5), x)
>> 
>> actually currently works correctly by some "good
>> coincidence" (I have not yet tried to understand, as
>> that's a bit painful: selectMethod("solve",
>> c("ddiMatrix", "array")) is "lying" here ! )
>> 
>> However this looks like a more general problem with S4
>> methods -- and probably a good reason for asking on
>> R-help -- namely, the fact that d1-dimensional (numeric)
>> arrays are not automatically treated as (numeric) vectors
>> i.e. class "numeric" wrt S4 methods.
>> 
>> In the following case the solve() - coincidence does not
>> help, BTW.
>> 
>> Diagonal(3) %*% array(1:3)
>> 
>> ## Error in Diagonal(3) %*% array(1:3) : ##
>> not-yet-implemented method for  %*% 
>> 
>> 
>> In principle, we should consider a way to tell that
>> "array" should be tried as "vector",

> Actually, if you think compatible 1-d numeric arrays
> should 'work', then all I was thinking of was something
> along the following lines: Add an additional

> setMethod("solve", c("ANY", "array"), function(a, b, ...)
> ...

> which would basically do a dimension check for b, for 1-d
> numeric arrays call solve(a, as.vector(b), ...), and error
> out for dim(b) > 2.  The actual details may be more
> involved, but that's the basic idea.

Well, of course, it's just that a method like the one above
would have to be provided for all signatures where something
corresponding for "numeric" now exists ..
and these may easily get to many dozens at least.

In other words  solve() is just one special case of very many
and I was rather interested in finding a method to solve "all
cases" at once - "automagically".

Otherwise, supporting  1d "array" to work Matrix-pkg matrices
would not only mean providing these many dozen of methods now,
but
also for every new functionality that uses S4 methods with
numeric vectors to have to always provide an additional "array"
method, i.e.,  increasing the Matrix-maintenance burden yet more.




>> possibly via something like setIs("array", "vector") or
>> rather setIs("array", "numeric") because in the Matrix
>> package the vectors encountered are really numeric
>> vectors.
>> 
>> .. OTOH, in all of the 3 packages I co-author and which
>> use S4 heavily, Matrix, Rmpfr, lme4, I had till now
>> decided *not* to setIs() because it never worked as I
>> intended, or rather had unpleasant side effects.
>> 
>> Here, setIs("array", "numeric", test=is.numeric)
>> 
>> gives
>> 
>> Error in setIs("array", "numeric", test = is.numeric) :
>> cannot create a 'setIs' relation when neither of the
>> classes (“array” and “numeric”) is local and modifiable
>> in this package
>> 
>> A more successful alternative had been to use
>> setC

Re: [R] Matrix::solve() with 1-d arrays -- treating "array" as "numeric"?

[Martin Maechler]

> Deepayan Sarkar 
> on Fri, 16 Apr 2021 11:34:20 +0530 writes:

> I get what I initially thought was unexpected behaviour from:

> x <- tapply(runif(100), sample(5, 100, TRUE), mean)
> solve(Diagonal(5), x)
> # Error: not-yet-implemented method for solve(, ).
> #  ->>  Ask the package authors to implement the missing feature.

((why did you not ask the package authors ?? --- never mind))


> This is because x is a 1-D array, so the operation is not
> well-defined. Would it make sense for Matrix to support this (treat
> 1-D arrays as column vectors, as it does for plain vectors)? Or should
> I make my intent clear with

> solve(Diagonal(5), as.vector(x))

well ...

The "fun" thing is that it actually works when Matrix methods
are not fully available, i.e., if you do *not* do
require(Matrix) or equivalent,
but rather only load the Matrix namespace via

  solve(Matrix::Diagonal(5), x)

actually currently works correctly by some "good coincidence"
(I have not yet tried to understand, as that's a bit painful:
 selectMethod("solve", c("ddiMatrix", "array"))  is "lying" here ! )
   
However this looks like a more general problem with S4 methods
-- and probably a good reason for asking on R-help --  namely,
the fact that d1-dimensional (numeric) arrays are not automatically treated as
(numeric) vectors i.e. class "numeric"  wrt S4 methods.

In the following case the  solve() - coincidence does not help, BTW.

 Diagonal(3) %*% array(1:3)

 ## Error in Diagonal(3) %*% array(1:3) : 
 ##   not-yet-implemented method for  %*% 


In principle, we should consider a way to tell that "array"
should be tried as "vector",

possibly via something likesetIs("array", "vector")  or
rather  setIs("array", "numeric")  because in the Matrix package
the vectors encountered are really numeric vectors.

.. OTOH, in all of the 3 packages I co-author and which use S4  heavily,  
Matrix, Rmpfr, lme4,
I had till now decided *not* to  setIs()  because it never
worked as I intended, or rather had unpleasant side effects.

Here,
  setIs("array", "numeric", test=is.numeric)

gives

Error in setIs("array", "numeric", test = is.numeric) : 
cannot create a 'setIs' relation when neither of the classes (“array” and 
“numeric”) is local and modifiable in this package

A more successful alternative had been to use  setClassUnion(),
so I could consider defining

  setClassUnion("mVector", c("numeric", "array"))

and replace "numeric" in many of the method signatures by  "mVector"
(but that would then also dispatch for 1d character arrays
 ... not so nicely).



> -Deepayan

> __
> R-help@r-project.org mailing list -- To UNSUBSCRIBE and
> more, see https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide
> http://www.R-project.org/posting-guide.html and provide
> commented, minimal, self-contained, reproducible code.

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] R does not start from (Debian) linux command line - error with doWithOneRestart() - segmentation fault

[Martin Maechler]

>>>>> Ashim Kapoor 
>>>>> on Wed, 7 Apr 2021 10:35:14 +0530 writes:

> Dear R experts,

> Here is my problem :

> R startup FAILS with an error message. The error message
> is more meaningful when I do invoke R via sudo OR as
> root. I attach the startup messages when I invoke R as :

> 1. as non root user 2. with sudo 3. as Root user.

> The error messages ( mentioned in snippets below ) are
> more meaningful to me in the above mentioned order.

Thank you, Ashim.

Yes, the messages point to something really bad.

OTOH ("On the other hand"), what we *can* see is that you try to
start R version 3.6.3.

While that is not extremely old, it may well be older than
several other pieces of software (or even hardware) that you are
running with.

I very very  *strongly* recommend to use an R version 4.0.x ... and why not
use the latest  4.0.5 ?

Then, it may also be caused by a mismatch of system libraries
and your oldish version of R. ... but there I'd strongly
recommend consulting with other Debian users, notably as there
is a dedicated  mailing list  R-SIG-Debian --> do subscribe
there, and ask -- with more details on how you got your R: Is it
the default R on your Debian, which version of Debian,  etc.

Last but not least, Dirk Eddelbuettel, the maintainer of the
official R Debian package maintains a nice web page -- part of
the official CRAN web pages, but unfortunately a bit hidden
nowadays, (not the least because CRAN still uses frames (würg!!)):

  https://cloud.r-project.org/bin/linux/debian/

A very nice and useful page,  much underrated and underused,
probably.

Best regards,

Martin Maechler
ETH Zurich  and  R Core Team


> When I google around for the error message, it looks like
> there is an .xlsx file which has non english characters
> which is messing with Java.

> I do not know how to fix this. I tried :-

> R --vanilla

> so that it would not use any startup scripts but that also
> does not work.

> - snip
> 


> When I try to start R from the command line :

> ~$ R

>  *** caught segfault *** address (nil), cause 'unknown'

> Traceback: 1: NextMethod(.Generic) 2:
> Ops.numeric_version(R_version_built_under, "3.0.0") 3:
> testRversion(pkgInfo, package, pkgpath) 4:
> library(package, lib.loc = lib.loc, character.only = TRUE,
> logical.return = TRUE, warn.conflicts = warn.conflicts,
> quietly = quietly, mask.ok = mask.ok, exclude = exclude,
> include.only = include.only, attach.required =
> attach.required) 5: doTryCatch(return(expr), name,
> parentenv, handler) 6: tryCatchOne(expr, names, parentenv,
> handlers[[1L]]) 7: tryCatchList(expr, classes, parentenv,
> handlers) 8: tryCatch(library(package, lib.loc = lib.loc,
> character.only = TRUE, logical.return = TRUE,
> warn.conflicts = warn.conflicts, quietly = quietly,
> mask.ok = mask.ok, exclude = exclude, include.only =
> include.only, attach.required = attach.required), error =
> function(e) e) 9: require(pkg, quietly = TRUE,
> warn.conflicts = FALSE, character.only = TRUE) 10:
> .OptRequireMethods()

> Possible actions: 1: abort (with core dump, if enabled) 2:
> normal R exit 3: exit R without saving workspace 4: exit R
> saving workspace Selection: Segmentation fault

> - snip
> 

> When I try to start R with sudo it gives a more clear
> message :-

> ~$ sudo R

>  *** caught segfault *** address (nil), cause 'unknown'

> Traceback: 1: NextMethod(.Generic) 2:
> Ops.numeric_version(R_version_built_under, "3.0.0") 3:
> testRversion(pkgInfo, package, pkgpath) 4:
> library(package, lib.loc = lib.loc, character.only = TRUE,
> logical.return = TRUE, warn.conflicts = warn.conflicts,
> quietly = quietly, mask.ok = mask.ok, exclude = exclude,
> include.only = include.only, attach.required =
> attach.required) 5: doTryCatch(return(expr), name,
> parentenv, handler) 6: tryCatchOne(expr, names, parentenv,
> handlers[[1L]]) 7: tryCatchList(expr, classes, parentenv,
> handlers) 8: tryCatch(library(package, lib.loc = lib.loc,
> character.only = TRUE, logical.return = TRUE,
> warn.conflicts = warn.conflicts, quietly = quietly,
> mask.ok = mask.ok, exclude = exclude, include.only =
> include.only, attach.required = attach.required), error =
> function(e) e) 9: require(pkg, quietly = T

Re: [ESS] ESS M-x R failing in a Windows installation

[Martin Maechler via ESS-help]

> Sparapani, Rodney via ESS-help 
> on Wed, 10 Mar 2021 15:40:05 + writes:

> Hi Jeremie: As you say, Windows installs do depend on the
> user’s preferences.  However, in ancient ESS (circa 2004),
> we coded around this by going to the Windows registry.
> However, I have rarely used Windows since so I can’t say
> how that approach might be used today (or if it is, how it
> might be failing).  I think a big issue is that few (if
> any) ESS developers are using Windows.  Rich was probably
> the rear guard and he switched to Mac.

Actually, I use ESS + R  on a Windows server (I log into in a window on my Linux
Desktop/notebook)  every couple of weeks or so,
to test R things (notably those that I know are platform
dependent, e.g., all my numeric / accuracy experiments/research).

I have many (half a dozen to a dozen) versions of R installed on
that server, but indeed  M-x R  had stopped many months ago,
but the current workaround for me has always been
to 

  M-x R-[tab]

[tab] = tabulator for "tab completion" in Emacs,
and then choose from the possible completions which do show both
the 32-bit and 64-bit versions of every version of R (see above).

Martin

> PS. the old registry discussions are probably in the
> archives https://stat.ethz.ch/pipermail/ess-help/

> --
> Rodney Sparapani, Associate Professor of Biostatistics
> Chair ISBA Section on Biostatistics and Pharmaceutical
> Statistics Institute for Health and Equity, Division of
> Biostatistics Medical College of Wisconsin, Milwaukee
> Campus


>   [[alternative HTML version deleted]]

> __
> ESS-help@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/ess-help

__
ESS-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help

Re: [R] quantile from quantile table calculation without original data

[Martin Maechler]

> Jeff Newmiller 
> on Fri, 05 Mar 2021 10:09:41 -0800 writes:

> Your example could probably be resolved with approx. If
> you want a more robust solution, it looks like the fBasics
> package can do spline interpolation. 

base R's  spline package does spline interpolation !!

Martin

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] readline in function call with space in prompt.

[Martin Maechler]

> Jeremie Juste 
> on Mon, 08 Feb 2021 14:28:33 +0100 writes:

> Hello,
> I have noticed a behavior that I don't understand. When I call the
> following function from the prompt.
> test <- function(){
> a <- readline("selection: ")
> a
> }

>> test()
>> selection: |
> I can only type one character and the readline function exits before I can
> press enter.

> however

> test1 <- function(){
> a <- readline("selection:")
> a
> }
>> test1()
>> selection:|
> works as expected.
>> selection: abc[Ret]

> However calling directly readline with a space in the prompt does what I
> would expect.

>> a <- readline("selection: ")
>> selection: abc[Ret]
>> a
>> "abc"

> It is the expected behavior or am I missing something?

> Best regards,
> Jeremie
> -- 
> Jeremie Juste
>> R version 4.0.3 (2020-10-10)

Given that the above works fine in Linux (for Jim Lemon and Rolf Turner),

could you tell us *how* you use R?
In the (Windows) RGui  or from Rstudio  or  ESS   or yet another way?

Usually the UI (user interface) should not matter, but rather
the R version etc.
But the UI may be important for a function like readline()
which does UI ..

Martin

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] arima/fixed

[Martin Maechler]

>>>>> Martin Maechler 
>>>>> on Sat, 30 Jan 2021 12:21:14 +0100 writes:

>>>>> Rolf Turner 
>>>>> on Sat, 30 Jan 2021 16:11:32 +1300 writes:

>> On Fri, 29 Jan 2021 12:47:25 + Nasia Petsa
>>  wrote:

>>> Dear all,
>>> 
>>> I have the following problem with determining the
>>> argument fixed in arima function. What is the length of
>>> argument fixed for an ARIMA(1,0,0)(0,1,1) and what is
>>> the correct order for the parameters

>> Hmm.  The help is indeed pretty opaque, isn't it?

> Can you propose improvements?

> Here(*) is the source code of the help page

>   http://svn.r-project.org/R/trunk/src/library/stats/man/arima.Rd

> We (and future R users) would be glad for less opaque (and
> still concise) wording, notably in simple enough English
> for the 90% non-natively English speaking R users ..

> Thank you in advance!  Martin

In the mean time, Rolf sent me a nicely enhanced arima.Rd
which is now part of R  (R-devel at least):


r79918 | maechler | 2021-02-01 15:07:32 +0100 (Mon, 01 Feb 2021) | 1 line
Changed paths:
   M src/library/stats/man/arima.Rd
   M tests/Examples/stats-Ex.Rout.save

extended for `fixed` arg, plus ex., thanks to Rolf Turner


(Unfortunately, I added 1 stray character when slightly editing
 Rolf's version.)

Such _careful_ contributions are welcome, thank you again!

---
Martin

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] arima/fixed

[Martin Maechler]

> Rolf Turner 
> on Sat, 30 Jan 2021 16:11:32 +1300 writes:

> On Fri, 29 Jan 2021 12:47:25 +
> Nasia Petsa  wrote:

>> Dear all,
>> 
>> I have the following problem with determining the argument fixed in
>> arima function. What is the length  of argument fixed for an
>> ARIMA(1,0,0)(0,1,1) and what is the correct  order for the parameters

> Hmm.  The help is indeed pretty opaque, isn't it?  

Can you propose improvements?

Here(*) is the source code of the help page

  http://svn.r-project.org/R/trunk/src/library/stats/man/arima.Rd

We (and future R users) would be glad for less opaque (and still
concise) wording, notably in simple enough English for the 90%
non-natively English speaking R users ..

Thank you in advance!
Martin


--
*) and really that *is* R's source code repos.
   All else are mirrors (efficient and convenient ones, I agree)

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] random numbers with constraints

[Martin Maechler]

> Abby Spurdle 
> on Thu, 28 Jan 2021 08:48:06 +1300 writes:

> I note that there's a possibility of floating point errors.
> If all values have one digit after the decimal point, you could replace:
> qexp (p, rate) with round (qexp (p, rate), 1).

> However, sometimes uniroot will fail, due to problems with input.

I also think the  constrained.sample() function should not
depend on the global variable 'u',
but rather depend on 'n'   and construct 'u' from  runif(n).

Martin

> On Thu, Jan 28, 2021 at 5:02 AM Denis Francisci
>  wrote:
>> 
>> Wonderful!
>> This is exactly what I need!
>> Thank you very much!!
>> 
>> Denis
>> 
>> 
>> 
>> Il giorno mer 27 gen 2021 alle ore 10:58 Abby Spurdle 
 ha scritto:
>>> 
>>> u <- runif (410)
>>> u <- (u - min (u) ) / diff (range (u) )
>>> 
>>> constrained.sample <- function (rate)
>>> {   plim <- pexp (c (9.6, 11.6), rate)
>>> p <- plim [1] + diff (plim) * u
>>> qexp (p, rate)
>>> }
>>> 
>>> diff.sum <- function (rate)
>>> sum (constrained.sample (rate) ) - 4200
>>> 
>>> rate <- uniroot (diff.sum, c (1, 2) )$root
>>> q <- constrained.sample (rate)
>>> 
>>> length (q)
>>> range (q)
>>> sum (q)
>>> 
>>> 
>>> On Wed, Jan 27, 2021 at 9:03 PM Denis Francisci
>>>  wrote:
>>> >
>>> > Hi,
>>> > I would like to generate random numbers in R with some constraints:
>>> > - my vector of numbers must contain 410 values;
>>> > - min value must be 9.6 and max value must be 11.6;
>>> > - sum of vector's values must be 4200.
>>> > Is there a way to do this in R?
>>> > And is it possible to generate this series in such a way that it 
follows a
>>> > specific distribution form (for example exponential)?
>>> > Thank you in advance,
>>> >
>>> > D.

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.