[Rd] Different results from 'lm' for different 32-bit Windows versions

[Andreas Fromkorth]

Hello,

I recently stumbled upon the fact that different 32-bit R Windows versions 
produce slightly different results when calling 'lm'. More precisely, this 
seems to be caused by a change in the transition from R 3.2.x to R 3.3.0.

A minimal example, for reproducing this is "lm(y~x, data.frame(x=c(1,2,3), 
y=c(1,2,3)))".

In R 3.3.0 the result is
Call:
lm(formula = y ~ x, data = data.frame(x = c(1, 2, 3), y = c(1,
2, 3)))

Coefficients:
(Intercept)x

0 1

In R 3.2.4 Revised on gets the result
Call:
lm(formula = y ~ x, data = data.frame(x = c(1, 2, 3), y = c(1,
2, 3)))

Coefficients:
(Intercept)x
-4.441e-161.000e+00

Both versions behave identically until the call C_Cdqrls in the fit.lm 
function. What causes this changed behavior?

Best regards,

Andreas Fromkorth.
Next PLA 3.0 Trainings (Business classes): www.bioassay.de/training 

_
Dr. Andreas Fromkorth
Project Manager
andreas.fromko...@stegmannsystems.com

Stegmann Systems GmbH, Raiffeisenstr. 2, 63110 Rodgau, Germany
Fon: +49 (6106) 77010-0, Direct: +49 (6106) 77010-213, Fax: +49 (6106) 77010-190
Handelsregister/Commercial Register Offenbach HRB 43033
Gesch?ftsf?hrer/CEO: Dr. Ralf Stegmann

Pick a product: APS 
2.10
 | PLA 
3.0
www.stegmannsystems.com
Follow us on LinkedIn

[[alternative HTML version deleted]]

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

Re: [Rd] .Internal(quit(...)): system call failed: Cannot allocate memory

[Tomas Kalibera]

On 11/21/20 6:51 PM, Jan Gorecki wrote:

Dear R-developers,

Some of the more fat scripts (50+ GB mem used by R) that I am running,
when they finish they do quit with q("no", status=0)
Quite often it happens that there is an extra stderr output produced
at the very end which looks like this:

Warning message:
In .Internal(quit(save, status, runLast)) :
   system call failed: Cannot allocate memory

Is there any way to avoid this kind of warnings? I am using stderr
output for detecting failures in scripts and this warning is a false
positive of a failure.

Maybe quit function could wait little bit longer trying to allocate
before it raises this warning?


If you see this warning, some call to system() or system2() or similar, 
which executes an external program, failed to even run a shell to run 
that external program, because there was not enough memory. You should 
be able to find out where it happens by checking the exit status of 
system().


Tomas




Best regards,
Jan Gorecki

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


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

Re: [Rd] .Internal(quit(...)): system call failed: Cannot allocate memory

[Gregory Warnes]

Try explicitly deleting large data objects by calling `rm`, then `gc`.


On Mon, Nov 23, 2020 at 6:15 AM Tomas Kalibera 
wrote:

> On 11/21/20 6:51 PM, Jan Gorecki wrote:
> > Dear R-developers,
> >
> > Some of the more fat scripts (50+ GB mem used by R) that I am running,
> > when they finish they do quit with q("no", status=0)
> > Quite often it happens that there is an extra stderr output produced
> > at the very end which looks like this:
> >
> > Warning message:
> > In .Internal(quit(save, status, runLast)) :
> >system call failed: Cannot allocate memory
> >
> > Is there any way to avoid this kind of warnings? I am using stderr
> > output for detecting failures in scripts and this warning is a false
> > positive of a failure.
> >
> > Maybe quit function could wait little bit longer trying to allocate
> > before it raises this warning?
>
> If you see this warning, some call to system() or system2() or similar,
> which executes an external program, failed to even run a shell to run
> that external program, because there was not enough memory. You should
> be able to find out where it happens by checking the exit status of
> system().
>
> Tomas
>
>
> >
> > Best regards,
> > Jan Gorecki
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
-- 
"Whereas true religion and good morals are the only solid foundations of
public liberty and happiness . . . it is hereby earnestly recommended to
the several States to take the most effectual measures for the
encouragement thereof." Continental Congress, 1778

[[alternative HTML version deleted]]

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

Re: [Rd] .Internal(quit(...)): system call failed: Cannot allocate memory

[Bill Dunlap]

The call to system() probably is an internal call used to delete the
session's tempdir().  This sort of failure means that a potentially large
amount of disk space is not being recovered when R is done.  Perhaps
R_CleanTempDir() could call R_unlink() instead of having a subprocess call
'rm -rf ...'.  Then it could also issue a specific warning if it was
impossible to delete all of tempdir().  (That should be very rare.)

> q("no")
Breakpoint 1, R_system (command=command@entry=0x7fffa1e0 "rm -Rf
/tmp/RtmppoKPXb") at sysutils.c:311
311 {
(gdb) where
#0  R_system (command=command@entry=0x7fffa1e0 "rm -Rf
/tmp/RtmppoKPXb") at sysutils.c:311
#1  0x557c30ec in R_CleanTempDir () at sys-std.c:1178
#2  0x557c31d7 in Rstd_CleanUp (saveact=, status=0,
runLast=) at sys-std.c:1243
#3  0x557c593d in R_CleanUp (saveact=saveact@entry=SA_NOSAVE,
status=status@entry=0, runLast=) at system.c:87
#4  0x556cc85e in do_quit (call=, op=, args=0x57813f90, rho=) at main.c:1393

-Bill

On Mon, Nov 23, 2020 at 3:15 AM Tomas Kalibera 
wrote:

> On 11/21/20 6:51 PM, Jan Gorecki wrote:
> > Dear R-developers,
> >
> > Some of the more fat scripts (50+ GB mem used by R) that I am running,
> > when they finish they do quit with q("no", status=0)
> > Quite often it happens that there is an extra stderr output produced
> > at the very end which looks like this:
> >
> > Warning message:
> > In .Internal(quit(save, status, runLast)) :
> >system call failed: Cannot allocate memory
> >
> > Is there any way to avoid this kind of warnings? I am using stderr
> > output for detecting failures in scripts and this warning is a false
> > positive of a failure.
> >
> > Maybe quit function could wait little bit longer trying to allocate
> > before it raises this warning?
>
> If you see this warning, some call to system() or system2() or similar,
> which executes an external program, failed to even run a shell to run
> that external program, because there was not enough memory. You should
> be able to find out where it happens by checking the exit status of
> system().
>
> Tomas
>
>
> >
> > Best regards,
> > Jan Gorecki
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

[[alternative HTML version deleted]]

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

Re: [Rd] Two ALTREP questions

[Dirk Eddelbuettel]

On 21 November 2020 at 20:56, Jiefei Wang wrote:
| Hello,
| 
| I have two related ALTREP questions. It seems like there is no way to
| assign attributes to an ALTREP vector without using C++ code. To be more
| specifically, I want to make an ALTREP matrix, I have tried the following R
| code but none of them work.
| ```
| .Internal(inspect(1:6))
| .Internal(inspect(matrix(1:6, 2,3)))
| .Internal(inspect(as.matrix(1:6)))
| .Internal(inspect(structure(1:6, dim = c(2L,3L
| .Internal(inspect({x <- 1:6;attr(x, "dim") <- c(2L,3L);x}))
| .Internal(inspect({x <- 1:6;attributes(x)<- list(dim = c(2L,3L));x}))
| ```
| 
| The only way to make an ALTREP matrix is to use the C level function
| ```
| attachAttrib <- inline::cxxfunction( signature(x = "SEXP", attr = "SEXP" )
| , '
| SET_ATTRIB(x,attr);
| return(R_NilValue);
| ')
| x <- 1:6
| attachAttrib(x, pairlist(dim = c(2L, 3L)))
| .Internal(inspect(x))
| ```

(That's C code. The confusion here is partly our fault. When Romain and I
extended the inline package with 'cxxfunction' to support the then-young but
active Rcpp package, we picked C++. Strictly speaking that isn't required;
you are only in C++ here because ... "it made sense to us 10 years ago" and
it could generalized to C++ or C.  All ALTREP is, of course, purely C as it
is an R API.)
 
| Since the matrix, or adding attributes, is a common need for the object
| operation, I wonder if this missing feature is intended? This also brings
| my second question, it seems like the ALTREP coercion function does not
| handle attributes correctly.  After the coercion, the ALTREP object will
| lose its attributes.
| ```
| coerceFunc <- inline::cxxfunction( signature(x = "SEXP", attr = "SEXP" ) , '
| SET_ATTRIB(x,attr);
| return(Rf_coerceVector(x, REALSXP));
| ')
| > coerceFunc(1:6, pairlist(dim = c(2L, 3L)))
| [1] 1 2 3 4 5 6
| > coerceFunc(1:6 + 0L, pairlist(dim = c(2L, 3L)))
|  [,1] [,2] [,3]
| [1,]135
| [2,]246
| ```
| The problem is that the coercion function is directly dispatched to the
| user-defined ALTREP coercion function, so the user is responsible to attach
| the attributes after the coercion. If he forgets to do so, then the result
| is a plain vector. Similar to the `Duplicate` and `DuplicateEX` functions
| where the former one will attach the attributes by default, I feel that the
| `Coerce` function should only return a plain vector and there should be a
| `CoerceEx` function to do the attribute assignment, so the logic in the
| no-EX ALTREP functions can be consistent. I do not know how dramastic the
| change would be, so maybe this is too hard to do.
| 
| BTW, is there any way to contribute to the R source? I know R has a limited
| resouces, so if possible, I will be happy to fix the matrix issue myself
| and make some minor contributions to the R community.

Yes. The generally recommended way is via a bug report at bugs.r-project.org
(for which you need an account there, and I always forget who the account
creation gatekeeper is ...) preferably with a patch. You effectively need an
R Core "sponsor" as someone has to actually put the code into R base.  So for
"everything else" the recommendation generally is to go via a package. Maybe
the easier route for you is to bundle a few ALTREP helper functions first?

Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [Rd] [External] exists, get and get0 accept silently inputs of length > 1

[luke-tierney]

Thanks for the suggestion.

In R-devel (as of r79474) exists(), get(), and get0() now signal an
error if the first argument has length > 1. This will cause about 30
CRAN packages and possibly a couple of Bioconductor packages to fail
under R-devel.

getS3method() now also signals an error if the class argument has
length > 1. Calls of the form getS2method(generic, class(x)) will now
fail if class(x) has length > 1. I believe most CRAN package issues
related to this change have already been resolved, but a few may
remain.

Best,

luke

On Fri, 13 Nov 2020, Antoine Fabri wrote:


Dear R-devel,

The doc of exists, get and get0 is unambiguous, x should be an object given
as a character string. However these accept longer inputs. It can lead an
uncareful user to think these functions are vectorized when they're not,
and generally lets through bugs that one might have preferred to trigger
earlier failure.

``` r
exists("d")
#> [1] FALSE
exists(c("c", "d"))
#> [1] TRUE
get(c("c", "d"))
#> function (...)  .Primitive("c")
get0(c("c", "d"))
#> function (...)  .Primitive("c")
```

I believe these should either fail, or be vectorized, probably the former.

Thanks,

Antoine

[[alternative HTML version deleted]]

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



--
Luke Tierney
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa  Phone: 319-335-3386
Department of Statistics andFax:   319-335-3017
   Actuarial Science
241 Schaeffer Hall  email:   luke-tier...@uiowa.edu
Iowa City, IA 52242 WWW:  http://www.stat.uiowa.edu

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