[Rd] identical(0, -0)
> William Dunlap
> on Thu, 6 Aug 2009 15:06:08 -0700 writes:
>> -Original Message- From:
>> r-help-boun...@r-project.org
>> [mailto:r-help-boun...@r-project.org] On Behalf Of
>> Giovanni Petris Sent: Thursday, August 06, 2009 3:00 PM
>> To: milton.ru...@gmail.com Cc: r-h...@r-project.org;
>> daniel.gerl...@geodecapital.com Subject: Re: [R] Why is 0
>> not an integer?
>>
>>
>> I ran an instant experiment...
>>
>> > typeof(0) [1] "double" > typeof(-0) [1] "double" >
>> identical(0, -0) [1] TRUE
>>
>> Best, Giovanni
> But 0.0 and -0.0 have different reciprocals
>> 1.0/0.0
>[1] Inf
>> 1.0/-0.0
>[1] -Inf
> Bill Dunlap TIBCO Software Inc - Spotfire Division wdunlap
> tibco.com
yes. {finally something interesting in this boring thread !}
---> diverting to R-devel
In April, I've had a private e-mail communication with John
Chambers [father of S, notably S4, which also brought identical()]
and Bill about the topic,
where I had started suggesting that R should be changed such
that
identical(-0. , +0.)
would return FALSE.
Bill did mention that it does so for (newish versions of) S+
and that he'd prefer that, too,
and John said
>> I agree on having a preference for a bitwise comparison for
>> identical()---that's what the name means after all. But since
>> someone implemented the numerical case as the C == it's probably
>> going to be more hassle than it's worth to change it. But we
>> should make the implementation clear in the documentation.
so in principle, we all agreed that R's identical() should be
changed here, namely by using something like memcmp() instead
of simple '==' , however we haven't bothered to actually
*implement* this change.
I am currently testing a patch which would lead to
identical(0, -0) return FALSE.
Martin Maechler, ETH Zurich
>> > By the way:
>> >
>> > Are there difference between -0 and 0?
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Help with embedding R
Hi I plan to use the Rmetrics package in a software tool for risk management written in C. I have some questions regarding embedding R: 1) Can someone elaborate more on R_tryEval? a) I was looking at the Rpackage.c example under the testing/Embedding folder. I vaguely understood that R_tryEval is used to interactively call R commands and invoke a package. I'm still not clear on how one should exactly go about doing this. What parameters doest R_tryEval take and what is it actually trying to do? 2) How can I convert C data types into R data types? a) I plan to write wrapper functions which take in parameters as doubles or ints. How do I put them into a SEXPREC? b) Also how do I get back the results of the R commands from R_tryEval into regular C data types like int, float, double? 3) On Windows, how can I bundle Rmetrics along with my application? What DLLs am I looking at bundling and where should they be located? Thanks Abhijit [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] options( "menu" )
Hello,
The current implementation of the menu function (in utils) makes it
difficult for front-ends to hook in and propose an alternative display.
Can there be something like options( "menu" ) to give control over it in
case graphics = TRUE. The default could be then be factored out of the
current menu :
default.menu <- function( choices, multiple = FALSE, title ){
if(.Platform$OS.type == "windows" || .Platform$GUI == "AQUA") {
res <- select.list(choices = choices, multiple=multiple,
title=title)
return(match(res, choices, nomatch = 0L))
} else if(.Platform$OS.type == "unix"
&& capabilities("tcltk") && capabilities("X11")
&& nzchar(Sys.getenv("DISPLAY"))) {
res <- tcltk::tk_select.list(choices, multiple=multiple,
title=title)
return(match(res, choices, nomatch = 0L))
}
options( menu = default.menu )
... or maybe this should be done at the select.list level
Romain
--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://tr.im/vzip : Code Snippet : List of CRAN packages
|- http://tr.im/vsK1 : R parser package on CRAN
`- http://tr.im/vshK : Transfer files through Rserve
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] identical(0, -0)
Martin Maechler wrote:
William Dunlap
on Thu, 6 Aug 2009 15:06:08 -0700 writes:
>> -Original Message- From:
>> r-help-boun...@r-project.org
>> [mailto:r-help-boun...@r-project.org] On Behalf Of
>> Giovanni Petris Sent: Thursday, August 06, 2009 3:00 PM
>> To: milton.ru...@gmail.com Cc: r-h...@r-project.org;
>> daniel.gerl...@geodecapital.com Subject: Re: [R] Why is 0
>> not an integer?
>>
>>
>> I ran an instant experiment...
>>
>> > typeof(0) [1] "double" > typeof(-0) [1] "double" >
>> identical(0, -0) [1] TRUE
>>
>> Best, Giovanni
> But 0.0 and -0.0 have different reciprocals
>> 1.0/0.0
>[1] Inf
>> 1.0/-0.0
>[1] -Inf
> Bill Dunlap TIBCO Software Inc - Spotfire Division wdunlap
> tibco.com
yes. {finally something interesting in this boring thread !}
---> diverting to R-devel
In April, I've had a private e-mail communication with John
Chambers [father of S, notably S4, which also brought identical()]
and Bill about the topic,
where I had started suggesting that R should be changed such
that
identical(-0. , +0.)
would return FALSE.
Bill did mention that it does so for (newish versions of) S+
and that he'd prefer that, too,
and John said
>> I agree on having a preference for a bitwise comparison for
>> identical()---that's what the name means after all. But since
>> someone implemented the numerical case as the C == it's probably
>> going to be more hassle than it's worth to change it. But we
>> should make the implementation clear in the documentation.
so in principle, we all agreed that R's identical() should be
changed here, namely by using something like memcmp() instead
of simple '==' , however we haven't bothered to actually
*implement* this change.
I am currently testing a patch which would lead to
identical(0, -0) return FALSE.
I don't think that would be a good idea. Other expressions besides "-0"
calculate the zero with the negative sign bit, e.g. the following sequence:
pos <- 1
neg <- -1
zero <- 0
y <- zero*pos
z <- zero*neg
identical(y, z)
I think most R users would expect the last expression there to be TRUE
based on the previous two lines, given that pos and neg both have finite
values. In a simple case like this y == z would be a better test to
use, but if those were components of a larger structure, identical() is
all we've got, and people would waste a lot of time tracking down why
structures differing only in the sign of zero were not identical, even
though every element tested equal.
Duncan Murdoch
Martin Maechler, ETH Zurich
>> > By the way:
>> >
>> > Are there difference between -0 and 0?
__
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] exec subdirectory of a package
Anyone ?
I guess I'll have to make a package that ships the execute script
Romain
On 08/05/2009 11:32 AM, Romain Francois wrote:
Hello,
WRE contains the following information about the "exec" subdirectory of
a package :
"Subdirectory exec could contain additional executables the package
needs, typically scripts for interpreters such as the shell, Perl, or
Tcl. This mechanism is currently used only by a very few packages, and
still experimental."
I think it would be useful to expand "very few". For example "tcltk"
uses it.
But the real questions are;
- can this be used in conjunction with "R CMD", something like
$ R CMD execute package script parameters
The alternative used in a few packages (Rserve, Roxygen, ...) is to add
a file in ${R_HOME}/bin, but I am not sure this works with binary builds
of packages
- can the script be an R script, in that case would a shebang like this
be enough :
#!/bin/env Rscript
definitely works on (at least my) linux
A very naive "execute" written in R follows.
Romain
#!/bin/env Rscript
args<- commandArgs(TRUE)
if( length(args)< 2 ){
stop( "usage : R CMD execute package script [parameters]\n" )
}
package<- args[1]
script<- args[2]
scriptfile<- file.path( system.file( "exec", script, package = package ) )
if( !file.exists( scriptfile ) ){
stop( sprintf( "file not found: '%s' ", scriptfile ) )
}
trail<- if( length(args)> 2 ) paste( tail( args, -2 ), sep = " " ) else ""
cmd<- sprintf( '"%s" %s', scriptfile, trail )
system( cmd )
--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://tr.im/vzip : Code Snippet : List of CRAN packages
|- http://tr.im/vsK1 : R parser package on CRAN
`- http://tr.im/vshK : Transfer files through Rserve
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Changing the compiler gfortran to ifort
I tried the manual R Installation and Administration to change the gcc compiler to icc and ifort for gfotran. However I could not find the correct path for the R to identify the icc and ifort. In which file I define the change of compiler? Thanks very much!!! Fábio Mathias Corrêa Estatística e Experimentação Agropecuária/UFLA Brazil Veja quais são os assuntos do momento no Yahoo! +Buscados http://br.maisbuscados.yahoo.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] identical(0, -0)
On 07-Aug-09 11:07:08, Duncan Murdoch wrote:
> Martin Maechler wrote:
>>> William Dunlap
>>> on Thu, 6 Aug 2009 15:06:08 -0700 writes:
>> >> -Original Message- From:
>> >> r-help-boun...@r-project.org
>> >> [mailto:r-help-boun...@r-project.org] On Behalf Of
>> >> Giovanni Petris Sent: Thursday, August 06, 2009 3:00 PM
>> >> To: milton.ru...@gmail.com Cc: r-h...@r-project.org;
>> >> daniel.gerl...@geodecapital.com Subject: Re: [R] Why is 0
>> >> not an integer?
>> >>
>> >>
>> >> I ran an instant experiment...
>> >>
>> >> > typeof(0) [1] "double" > typeof(-0) [1] "double" >
>> >> identical(0, -0) [1] TRUE
>> >>
>> >> Best, Giovanni
>>
>> > But 0.0 and -0.0 have different reciprocals
>>
>> >> 1.0/0.0
>> >[1] Inf
>> >> 1.0/-0.0
>> >[1] -Inf
>>
>> > Bill Dunlap TIBCO Software Inc - Spotfire Division wdunlap
>> > tibco.com
>>
>> yes. {finally something interesting in this boring thread !}
>> ---> diverting to R-devel
>>
>> In April, I've had a private e-mail communication with John
>> Chambers [father of S, notably S4, which also brought identical()]
>> and Bill about the topic,
>> where I had started suggesting that R should be changed such
>> that
>> identical(-0. , +0.)
>> would return FALSE.
>> Bill did mention that it does so for (newish versions of) S+
>> and that he'd prefer that, too,
>> and John said
>>
>> >> I agree on having a preference for a bitwise comparison for
>> >> identical()---that's what the name means after all. But since
>> >> someone implemented the numerical case as the C == it's probably
>> >> going to be more hassle than it's worth to change it. But we
>> >> should make the implementation clear in the documentation.
>>
>> so in principle, we all agreed that R's identical() should be
>> changed here, namely by using something like memcmp() instead
>> of simple '==' , however we haven't bothered to actually
>> *implement* this change.
>>
>> I am currently testing a patch which would lead to
>> identical(0, -0) return FALSE.
>>
> I don't think that would be a good idea. Other expressions besides
> "-0"
> calculate the zero with the negative sign bit, e.g. the following
> sequence:
>
> pos <- 1
> neg <- -1
> zero <- 0
> y <- zero*pos
> z <- zero*neg
> identical(y, z)
>
> I think most R users would expect the last expression there to be
> TRUE based on the previous two lines, given that pos and neg both
> have finite values. In a simple case like this y == z would be a
> better test to use, but if those were components of a larger
> structure, identical() is all we've got, and people would waste a
> lot of time tracking down why structures differing only in the
> sign of zero were not identical, even though every element tested
> equal.
>
> Duncan Murdoch
>> Martin Maechler, ETH Zurich
My own view of this is that there may in certain cirumstances be an
interest in distinguishing between 0 and (-0), yet normally most
users will simply want to compare the numerical values.
Therefore I am in favour of revising identical() so that it can so
distinguish; but also of taking the opportunity to give it a parameter
say
identical(x,y,sign.bit=FALSE)
so that the default behaviour would be to see 0 and (-0) as identical,
but with sign.bit=TRUE it would see the difference.
However, I put this forward in ignorance of
a) Any difficulties that this may present in re-coding identical();
b) Any complications that may arise when applying this new form
to complex objects.
Ted.
E-Mail: (Ted Harding)
Fax-to-email: +44 (0)870 094 0861
Date: 07-Aug-09 Time: 14:49:51
-- XFMail --
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Changing the compiler gfortran to ifort
On 8/7/2009 9:43 AM, Fabio Mathias Corrêa wrote: I tried the manual R Installation and Administration to change the gcc compiler to icc and ifort for gfotran. However I could not find the correct path for the R to identify the icc and ifort. In which file I define the change of compiler? That depends on the platform. In Windows, the file to edit is src/gnuwin32/MkRules, where you would need to change the F77 and FLIBS definitions (and perhaps others). Notice that this is not in the "user-customizable" section, so if you do this, you may be on your own to track down the problems it causes. (Revolution Computing has changed compilers successfully, and they might be able to help you, or may already have done what you are thinking of doing.) Other platforms use configure scripts to set all of these things; running ./configure --help in the home directory will tell you lots of options and environment variables to play with. Duncan Murdoch Thanks very much!!! Fábio Mathias Corrêa Estatística e Experimentação Agropecuária/UFLA Brazil Veja quais são os assuntos do momento no Yahoo! +Buscados http://br.maisbuscados.yahoo.com __ 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] options( "menu" )
There are plans for more wide-ranging GUI hooks, so please be patient.
(They are likely to make 2.10.0.)
On Fri, 7 Aug 2009, Romain Francois wrote:
Hello,
The current implementation of the menu function (in utils) makes it difficult
for front-ends to hook in and propose an alternative display.
Can there be something like options( "menu" ) to give control over it in case
graphics = TRUE. The default could be then be factored out of the current
menu :
default.menu <- function( choices, multiple = FALSE, title ){
if(.Platform$OS.type == "windows" || .Platform$GUI == "AQUA") {
res <- select.list(choices = choices, multiple=multiple,
title=title)
return(match(res, choices, nomatch = 0L))
} else if(.Platform$OS.type == "unix"
&& capabilities("tcltk") && capabilities("X11")
&& nzchar(Sys.getenv("DISPLAY"))) {
res <- tcltk::tk_select.list(choices, multiple=multiple,
title=title)
return(match(res, choices, nomatch = 0L))
}
options( menu = default.menu )
... or maybe this should be done at the select.list level
Romain
--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://tr.im/vzip : Code Snippet : List of CRAN packages
|- http://tr.im/vsK1 : R parser package on CRAN
`- http://tr.im/vshK : Transfer files through Rserve
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Brian D. Ripley, rip...@stats.ox.ac.uk
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] identical(0, -0)
> "TH" == Ted Harding
> on Fri, 07 Aug 2009 14:49:54 +0100 (BST) writes:
TH> On 07-Aug-09 11:07:08, Duncan Murdoch wrote:
>> Martin Maechler wrote:
William Dunlap
on Thu, 6 Aug 2009 15:06:08 -0700 writes:
>>> >> -Original Message- From:
>>> >> r-help-boun...@r-project.org
>>> >> [mailto:r-help-boun...@r-project.org] On Behalf Of
>>> >> Giovanni Petris Sent: Thursday, August 06, 2009 3:00 PM
>>> >> To: milton.ru...@gmail.com Cc: r-h...@r-project.org;
>>> >> daniel.gerl...@geodecapital.com Subject: Re: [R] Why is 0
>>> >> not an integer?
>>> >>
>>> >>
>>> >> I ran an instant experiment...
>>> >>
>>> >> > typeof(0) [1] "double" > typeof(-0) [1] "double" >
>>> >> identical(0, -0) [1] TRUE
>>> >>
>>> >> Best, Giovanni
>>>
>>> > But 0.0 and -0.0 have different reciprocals
>>>
>>> >> 1.0/0.0
>>> >[1] Inf
>>> >> 1.0/-0.0
>>> >[1] -Inf
>>>
>>> > Bill Dunlap TIBCO Software Inc - Spotfire Division wdunlap
>>> > tibco.com
>>>
>>> yes. {finally something interesting in this boring thread !}
---> diverting to R-devel
>>>
>>> In April, I've had a private e-mail communication with John
>>> Chambers [father of S, notably S4, which also brought identical()]
>>> and Bill about the topic,
>>> where I had started suggesting that R should be changed such
>>> that
>>> identical(-0. , +0.)
>>> would return FALSE.
>>> Bill did mention that it does so for (newish versions of) S+
>>> and that he'd prefer that, too,
>>> and John said
>>>
>>> >> I agree on having a preference for a bitwise comparison for
>>> >> identical()---that's what the name means after all. But since
>>> >> someone implemented the numerical case as the C == it's probably
>>> >> going to be more hassle than it's worth to change it. But we
>>> >> should make the implementation clear in the documentation.
>>>
>>> so in principle, we all agreed that R's identical() should be
>>> changed here, namely by using something like memcmp() instead
>>> of simple '==' , however we haven't bothered to actually
>>> *implement* this change.
>>>
>>> I am currently testing a patch which would lead to
>>> identical(0, -0) return FALSE.
>>>
>> I don't think that would be a good idea. Other expressions besides
>> "-0"
>> calculate the zero with the negative sign bit, e.g. the following
>> sequence:
>>
>> pos <- 1
>> neg <- -1
>> zero <- 0
>> y <- zero*pos
>> z <- zero*neg
>> identical(y, z)
>>
>> I think most R users would expect the last expression there to be
>> TRUE based on the previous two lines, given that pos and neg both
>> have finite values. In a simple case like this y == z would be a
>> better test to use, but if those were components of a larger
>> structure, identical() is all we've got, and people would waste a
>> lot of time tracking down why structures differing only in the
>> sign of zero were not identical, even though every element tested
>> equal.
identical() *is* not the same as '==' even if you think of a
generalized '==',
and your example is not convincing to me.
Further note that help(identical) has always said
> Description:
>The safe and reliable way to test two objects for being _exactly_
>equal. It returns 'TRUE' in this case, 'FALSE' in every other case.
which really should distinguish -0 and +0
>> Duncan Murdoch
>>> Martin Maechler, ETH Zurich
TH> My own view of this is that there may in certain cirumstances be an
TH> interest in distinguishing between 0 and (-0), yet normally most
TH> users will simply want to compare the numerical values.
TH> Therefore I am in favour of revising identical() so that it can so
TH> distinguish; but also of taking the opportunity to give it a parameter
TH> say
TH> identical(x,y,sign.bit=FALSE)
TH> so that the default behaviour would be to see 0 and (-0) as identical,
TH> but with sign.bit=TRUE it would see the difference.
TH> However, I put this forward in ignorance of
TH> a) Any difficulties that this may present in re-coding identical();
TH> b) Any complications that may arise when applying this new form
TH> to complex objects.
Your proposal would actually need to special case this one case,
rather than my patch which replaces using '==' (in C) for
double by using memcmp() instead, something which is already
used for several other cases there, and hence seems more
consequent and in that way natural.
The one thing even the new code would not differentiate is the
different NaN's (apart from NA) but they are not differentiable
on the R level either, AFAIK, at least AFAIU our language
specifications, we only want two things: NA and NaN
Martin
__
Re: [Rd] identical(0, -0)
On 8/7/2009 10:46 AM, Martin Maechler wrote:
"TH" == Ted Harding
on Fri, 07 Aug 2009 14:49:54 +0100 (BST) writes:
TH> On 07-Aug-09 11:07:08, Duncan Murdoch wrote:
>> Martin Maechler wrote:
William Dunlap
on Thu, 6 Aug 2009 15:06:08 -0700 writes:
>>> >> -Original Message- From:
>>> >> r-help-boun...@r-project.org
>>> >> [mailto:r-help-boun...@r-project.org] On Behalf Of
>>> >> Giovanni Petris Sent: Thursday, August 06, 2009 3:00 PM
>>> >> To: milton.ru...@gmail.com Cc: r-h...@r-project.org;
>>> >> daniel.gerl...@geodecapital.com Subject: Re: [R] Why is 0
>>> >> not an integer?
>>> >>
>>> >>
>>> >> I ran an instant experiment...
>>> >>
>>> >> > typeof(0) [1] "double" > typeof(-0) [1] "double" >
>>> >> identical(0, -0) [1] TRUE
>>> >>
>>> >> Best, Giovanni
>>>
>>> > But 0.0 and -0.0 have different reciprocals
>>>
>>> >> 1.0/0.0
>>> >[1] Inf
>>> >> 1.0/-0.0
>>> >[1] -Inf
>>>
>>> > Bill Dunlap TIBCO Software Inc - Spotfire Division wdunlap
>>> > tibco.com
>>>
>>> yes. {finally something interesting in this boring thread !}
---> diverting to R-devel
>>>
>>> In April, I've had a private e-mail communication with John
>>> Chambers [father of S, notably S4, which also brought identical()]
>>> and Bill about the topic,
>>> where I had started suggesting that R should be changed such
>>> that
>>> identical(-0. , +0.)
>>> would return FALSE.
>>> Bill did mention that it does so for (newish versions of) S+
>>> and that he'd prefer that, too,
>>> and John said
>>>
>>> >> I agree on having a preference for a bitwise comparison for
>>> >> identical()---that's what the name means after all. But since
>>> >> someone implemented the numerical case as the C == it's probably
>>> >> going to be more hassle than it's worth to change it. But we
>>> >> should make the implementation clear in the documentation.
>>>
>>> so in principle, we all agreed that R's identical() should be
>>> changed here, namely by using something like memcmp() instead
>>> of simple '==' , however we haven't bothered to actually
>>> *implement* this change.
>>>
>>> I am currently testing a patch which would lead to
>>> identical(0, -0) return FALSE.
>>>
>> I don't think that would be a good idea. Other expressions besides
>> "-0"
>> calculate the zero with the negative sign bit, e.g. the following
>> sequence:
>>
>> pos <- 1
>> neg <- -1
>> zero <- 0
>> y <- zero*pos
>> z <- zero*neg
>> identical(y, z)
>>
>> I think most R users would expect the last expression there to be
>> TRUE based on the previous two lines, given that pos and neg both
>> have finite values. In a simple case like this y == z would be a
>> better test to use, but if those were components of a larger
>> structure, identical() is all we've got, and people would waste a
>> lot of time tracking down why structures differing only in the
>> sign of zero were not identical, even though every element tested
>> equal.
identical() *is* not the same as '==' even if you think of a
generalized '==',
and your example is not convincing to me.
Fair enough, but after your change, how would one do what
identical(list(pos, neg, zero, y), list(pos, neg, zero, z)) does now?
That seems to me to be a more useful comparison than one that declares
those to be unequal because the signs of y and z differ.
Further note that help(identical) has always said
> Description:
>The safe and reliable way to test two objects for being _exactly_
>equal. It returns 'TRUE' in this case, 'FALSE' in every other case.
which really should distinguish -0 and +0
>> Duncan Murdoch
>>> Martin Maechler, ETH Zurich
TH> My own view of this is that there may in certain cirumstances be an
TH> interest in distinguishing between 0 and (-0), yet normally most
TH> users will simply want to compare the numerical values.
TH> Therefore I am in favour of revising identical() so that it can so
TH> distinguish; but also of taking the opportunity to give it a parameter
TH> say
TH> identical(x,y,sign.bit=FALSE)
TH> so that the default behaviour would be to see 0 and (-0) as identical,
TH> but with sign.bit=TRUE it would see the difference.
TH> However, I put this forward in ignorance of
TH> a) Any difficulties that this may present in re-coding identical();
TH> b) Any complications that may arise when applying this new form
TH> to complex objects.
Your proposal would actually need to special case this one case,
rather than my patch which replaces using '==' (in C) for
double by using memcmp() instead, something which is already
used for several other cases the
Re: [Rd] identical(0, -0)
> "DM" == Duncan Murdoch
> on Fri, 07 Aug 2009 11:25:11 -0400 writes:
DM> On 8/7/2009 10:46 AM, Martin Maechler wrote:
>>> "TH" == Ted Harding
>>> on Fri, 07 Aug 2009 14:49:54 +0100 (BST) writes:
>>
TH> On 07-Aug-09 11:07:08, Duncan Murdoch wrote:
>> >> Martin Maechler wrote:
>> William Dunlap
>> on Thu, 6 Aug 2009 15:06:08 -0700 writes:
>> >>> >> -Original Message- From:
>> >>> >> r-help-boun...@r-project.org
>> >>> >> [mailto:r-help-boun...@r-project.org] On Behalf Of
>> >>> >> Giovanni Petris Sent: Thursday, August 06, 2009 3:00 PM
>> >>> >> To: milton.ru...@gmail.com Cc: r-h...@r-project.org;
>> >>> >> daniel.gerl...@geodecapital.com Subject: Re: [R] Why is 0
>> >>> >> not an integer?
>> >>> >>
>> >>> >>
>> >>> >> I ran an instant experiment...
>> >>> >>
>> >>> >> > typeof(0) [1] "double" > typeof(-0) [1] "double" >
>> >>> >> identical(0, -0) [1] TRUE
>> >>> >>
>> >>> >> Best, Giovanni
>> >>>
>> >>> > But 0.0 and -0.0 have different reciprocals
>> >>>
>> >>> >> 1.0/0.0
>> >>> >[1] Inf
>> >>> >> 1.0/-0.0
>> >>> >[1] -Inf
>> >>>
>> >>> > Bill Dunlap TIBCO Software Inc - Spotfire Division wdunlap
>> >>> > tibco.com
>> >>>
>> >>> yes. {finally something interesting in this boring thread !}
---> diverting to R-devel
>> >>>
>> >>> In April, I've had a private e-mail communication with John
>> >>> Chambers [father of S, notably S4, which also brought identical()]
>> >>> and Bill about the topic,
>> >>> where I had started suggesting that R should be changed such
>> >>> that
>> >>> identical(-0. , +0.)
>> >>> would return FALSE.
>> >>> Bill did mention that it does so for (newish versions of) S+
>> >>> and that he'd prefer that, too,
>> >>> and John said
>> >>>
>> >>> >> I agree on having a preference for a bitwise comparison for
>> >>> >> identical()---that's what the name means after all. But since
>> >>> >> someone implemented the numerical case as the C == it's probably
>> >>> >> going to be more hassle than it's worth to change it. But we
>> >>> >> should make the implementation clear in the documentation.
>> >>>
>> >>> so in principle, we all agreed that R's identical() should be
>> >>> changed here, namely by using something like memcmp() instead
>> >>> of simple '==' , however we haven't bothered to actually
>> >>> *implement* this change.
>> >>>
>> >>> I am currently testing a patch which would lead to
>> >>> identical(0, -0) return FALSE.
>> >>>
>> >> I don't think that would be a good idea. Other expressions besides
>> >> "-0"
>> >> calculate the zero with the negative sign bit, e.g. the following
>> >> sequence:
>> >>
>> >> pos <- 1
>> >> neg <- -1
>> >> zero <- 0
>> >> y <- zero*pos
>> >> z <- zero*neg
>> >> identical(y, z)
>> >>
>> >> I think most R users would expect the last expression there to be
>> >> TRUE based on the previous two lines, given that pos and neg both
>> >> have finite values. In a simple case like this y == z would be a
>> >> better test to use, but if those were components of a larger
>> >> structure, identical() is all we've got, and people would waste a
>> >> lot of time tracking down why structures differing only in the
>> >> sign of zero were not identical, even though every element tested
>> >> equal.
>>
>> identical() *is* not the same as '==' even if you think of a
>> generalized '==',
>> and your example is not convincing to me.
DM> Fair enough, but after your change, how would one do what
DM> identical(list(pos, neg, zero, y), list(pos, neg, zero, z)) does now?
DM> That seems to me to be a more useful comparison than one that declares
DM> those to be unequal because the signs of y and z differ.
Maybe something like
all(mapply(`==`, list(pos, neg, zero, y), list(pos, neg, zero, z)))
## or even
isTRUE(all.equal( list(pos, neg, zero, y), list(pos, neg, zero, z),
tol = 0))
the latter of which is more flexible adaptable at what the user
is really wanting to test.
>> Further note that help(identical) has always said
>>
>> > Description:
>>
>> >The safe and reliable way to test two objects for being _exactly_
>> >equal. It returns 'TRUE' in this case, 'FALSE' in every other case.
>>
>> which really should distinguish -0 and +0
>>
>>
>> >> Duncan Murdoch
>> >>> Martin Maechler, ETH Zurich
>>
TH> My own view of this is that there may in certain cirumstances be an
TH> interest in distinguishing between 0 and (-0), yet normally most
TH> users will simply want to compare the numerical values.
>>
TH> Therefore I am in favou
Re: [Rd] identical(0, -0)
On 8/7/2009 11:41 AM, Martin Maechler wrote:
"DM" == Duncan Murdoch
on Fri, 07 Aug 2009 11:25:11 -0400 writes:
DM> On 8/7/2009 10:46 AM, Martin Maechler wrote:
>>> "TH" == Ted Harding
>>> on Fri, 07 Aug 2009 14:49:54 +0100 (BST) writes:
>>
TH> On 07-Aug-09 11:07:08, Duncan Murdoch wrote:
>> >> Martin Maechler wrote:
>> William Dunlap
>> on Thu, 6 Aug 2009 15:06:08 -0700 writes:
>> >>> >> -Original Message- From:
>> >>> >> r-help-boun...@r-project.org
>> >>> >> [mailto:r-help-boun...@r-project.org] On Behalf Of
>> >>> >> Giovanni Petris Sent: Thursday, August 06, 2009 3:00 PM
>> >>> >> To: milton.ru...@gmail.com Cc: r-h...@r-project.org;
>> >>> >> daniel.gerl...@geodecapital.com Subject: Re: [R] Why is 0
>> >>> >> not an integer?
>> >>> >>
>> >>> >>
>> >>> >> I ran an instant experiment...
>> >>> >>
>> >>> >> > typeof(0) [1] "double" > typeof(-0) [1] "double" >
>> >>> >> identical(0, -0) [1] TRUE
>> >>> >>
>> >>> >> Best, Giovanni
>> >>>
>> >>> > But 0.0 and -0.0 have different reciprocals
>> >>>
>> >>> >> 1.0/0.0
>> >>> >[1] Inf
>> >>> >> 1.0/-0.0
>> >>> >[1] -Inf
>> >>>
>> >>> > Bill Dunlap TIBCO Software Inc - Spotfire Division wdunlap
>> >>> > tibco.com
>> >>>
>> >>> yes. {finally something interesting in this boring thread !}
---> diverting to R-devel
>> >>>
>> >>> In April, I've had a private e-mail communication with John
>> >>> Chambers [father of S, notably S4, which also brought identical()]
>> >>> and Bill about the topic,
>> >>> where I had started suggesting that R should be changed such
>> >>> that
>> >>> identical(-0. , +0.)
>> >>> would return FALSE.
>> >>> Bill did mention that it does so for (newish versions of) S+
>> >>> and that he'd prefer that, too,
>> >>> and John said
>> >>>
>> >>> >> I agree on having a preference for a bitwise comparison for
>> >>> >> identical()---that's what the name means after all. But since
>> >>> >> someone implemented the numerical case as the C == it's probably
>> >>> >> going to be more hassle than it's worth to change it. But we
>> >>> >> should make the implementation clear in the documentation.
>> >>>
>> >>> so in principle, we all agreed that R's identical() should be
>> >>> changed here, namely by using something like memcmp() instead
>> >>> of simple '==' , however we haven't bothered to actually
>> >>> *implement* this change.
>> >>>
>> >>> I am currently testing a patch which would lead to
>> >>> identical(0, -0) return FALSE.
>> >>>
>> >> I don't think that would be a good idea. Other expressions besides
>> >> "-0"
>> >> calculate the zero with the negative sign bit, e.g. the following
>> >> sequence:
>> >>
>> >> pos <- 1
>> >> neg <- -1
>> >> zero <- 0
>> >> y <- zero*pos
>> >> z <- zero*neg
>> >> identical(y, z)
>> >>
>> >> I think most R users would expect the last expression there to be
>> >> TRUE based on the previous two lines, given that pos and neg both
>> >> have finite values. In a simple case like this y == z would be a
>> >> better test to use, but if those were components of a larger
>> >> structure, identical() is all we've got, and people would waste a
>> >> lot of time tracking down why structures differing only in the
>> >> sign of zero were not identical, even though every element tested
>> >> equal.
>>
>> identical() *is* not the same as '==' even if you think of a
>> generalized '==',
>> and your example is not convincing to me.
DM> Fair enough, but after your change, how would one do what
DM> identical(list(pos, neg, zero, y), list(pos, neg, zero, z)) does now?
DM> That seems to me to be a more useful comparison than one that declares
DM> those to be unequal because the signs of y and z differ.
Maybe something like
all(mapply(`==`, list(pos, neg, zero, y), list(pos, neg, zero, z)))
## or even
isTRUE(all.equal( list(pos, neg, zero, y), list(pos, neg, zero, z),
tol = 0))
I think I didn't make my point clearly. I'm not particularly worried
about lists of numbers, I'm worried about signed zeros buried in complex
structures. identical(struc1, struc2) works nicely now for that sort of
comparison; indeed the man page for it says:
A call to 'identical' is the way to test exact equality in 'if'
and 'while' statements, as well as in logical expressions that use
'&&' or '||'. In all these applications you need to be assured of
getting a single logical value.
The description you quote below does contradict this, and it also
contradicts the statement
'identical' sees 'NaN' as different from 'NA_real_', but all
'NaN's are
[Rd] Bug in nlm, found using sem; failure in several flavors (PR#13881)
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
--1660387551-1458482416-1249639718=:2997
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; FORMAT=flowed
Content-ID:
Hello,
There appears to be a bug in the nlm function, which I discovered
when trying to run an SEM. The SEM is not bizarre; the covariance matrix is
solve-able and the eigenvalues are greater than zero, and I do not believe
the "sem" package per se to be the problem (as nlm keeps being the part that
fails, though I can't replicate this with other nlm tasks). I apologize if
I have put too many much information in this message; I'm not a programmer
by trade so I don't really know what's going on here, which hampers my
ability to write consise bug reports.
Here is the code I use:
library(sem)
ice.S <- read.csv("iceS.csv") # attached
rownames(ice.S) <- ice.S[,1]
ice.S[,1] <- NULL
ice.S <- as.matrix(ice.S)
ice.ram <- specify.model("ice.ram") # attached
ice.N <- 342
ice.sem <- sem(ram=ice.ram, S=ice.S, N=ice.N)
...at this point, any number of problems could occur. I have seen the
following.
1) Simple lack of convergence. (might be my model's fault.)
2) Error in nlm(if (analytic.gradient) objective.2 else objective.1, start,
:
type 31 is unimplemented in 'type2char'
3) *** caught segfault ***
address 0xc019c87b, cause 'memory not mapped'
Traceback:
1: nlm(if (analytic.gradient) objective.2 else objective.1, start,
hessian = TRUE, iterlim = maxiter, print.level = if (debug) 2 else 0,
typsize = typsize, ...)
2: sem.default(ram = ram, S = S, N = N, param.names = pars, var.names =
vars, fixed.x = fixed.x, debug = debug, ...)
3: sem(ram = ram, S = S, N = N, param.names = pars, var.names = vars,
fixed.x = fixed.x, debug = debug, ...)
4: sem.mod(ram = ice.ram, S = ice.S, N = ice.N)
5: sem(ram = ice.ram, S = ice.S, N = ice.N)
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: 1
aborting ...
Segmentation fault
swiss:data$
(no core was dumped).
Trying with debug mode provides other interesting errors:
> ice.sem <- sem(ram=ice.ram, S=ice.S, N=ice.N, debug=TRUE)
...gets up to some iteration (not always 15), and then R dies ungracefully,
and exits to the shell:
iteration = 15
Step:
[1] 1.253132e-02 1.183343e-02 -7.651342e-03 -2.490800e-03 2.278938e-03
[6] 3.197431e-04 6.137849e-04 -2.496882e-03 -1.065829e-03 -2.118179e-03
[11] 2.942936e-03 -1.335936e-03 -3.665618e-03 3.090566e-03 8.534956e-04
[16] -1.440421e-03 -5.230877e-04 -1.053686e-04 -9.771005e-04 -4.269216e-04
[21] 7.261694e-05 -1.039668e-03 -8.409151e-03 -3.497456e-03 2.216899e-03
[26] -4.633520e-03 -4.052130e-03 -4.746537e-03 -1.589622e-03 -2.523766e-04
Parameter:
[1] -0.76604614 -1.19639662 0.83456888 0.72540413 0.08482452 0.56180393
[7] 0.50615814 0.55728015 0.83796696 0.88371335 -0.70465116 0.85251098
[13] -0.18346956 0.66857787 0.57012481 0.39116561 0.91237990 0.63951482
[19] 0.26601566 0.29240836 0.44710919 0.94734056 6.52039015 0.02524762
[25] -0.01614603 2.88198219 0.03442452 3.52272237 1.44698423 -0.72964745
Function Value
[1] -15175.94
Gradient:
[1] -2.085412e+07 -3.819717e+07 3.883989e+07 1.352594e+00 -4.283329e+00
[6] -1.437250e+00 -6.558913e-01 1.358276e+00 7.930865e+05 -1.293853e+06
[11] -5.816627e+03 5.908197e+05 -2.705742e+08 -1.194400e+07 -4.007083e+07
[16] -4.143068e+07 -6.159782e-01 1.044274e-01 -8.591048e+00 -2.083471e+00
[21] -7.548753e-01 -5.418994e-01 -2.799228e+02 -1.321739e+07 -3.517728e+07
[26] -7.106654e+02 -7.335293e+06 -7.335285e+05 3.117764e-01 -2.234989e+04
Abort trap
swiss:data$
...I have also seen convergence reached, and nlm then die with this message:
Error in nlm(if (analytic.gradient) objective.2 else objective.1, start,
:
type 27 is unimplemented in 'type2char'
(similar to above, but now referring to type 27)
I have shown this effect (or something similar...never know how it'll fail
next) on the following platforms:
> version
_
platform i386-apple-darwin9.7.0
arch i386
os darwin9.7.0
system i386, darwin9.7.0
status
major 2
minor 9.1
year 2009
month 06
day26
svn rev48839
language R
version.string R version 2.9.1 (2009-06-26)
> sessionInfo()
R version 2.9.1 (2009-06-26)
i386-apple-darwin9.8.0
locale:
en_US.UTF-8/en_US.UTF-8/C/C/en_US.UTF-8/en_US.UTF-8
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] sem_0.9-17
loaded via a namespace (and not attached):
[1] tcltk_2.9.1 tools_2.9.1
(I admit to having compiled this version of R myself (to link to a
hand-compiled ATLAS), though no errors were thrown in the compilation stage.
I compiled using this config string, at first...
./con
[Rd] R patched & devel versions as portable ZIP files
I wonder if it would be possible to provide R patched and development versions for Windows as simple zip files without using any installers. There are more and more free and open source software projects providing such portable versions, among them Python (since V2.5), the new MikTex 2.8, OpenOffice 3, Firefox and Thunderbird, to name a few. Many smaller Windows utilities do the same. When regularly following patched and development version, the installation procedures and writing into the Windows registry all the time makes me feel uneasy. And even with the installation procedure there are subsequent tasks, for example changing the path in the shortcut. Zip files are much better for those running R from an USB stick because otherwise you have to install it on the disk---what maybe you don't want to do---and then copy it over to the stick. I know there are some concerns with R-(D)COM interface and i assume those using it know which versions to install. Thanks Hans Werner Borchers __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug in nlm, found using sem; failure in several flavors (PR#13881)
Adam,
It seems that your attachment didn't make it through.
That aside, my experience with strange errors like those (random type
not implemented ones) has been that you may be looking at a memory
problem on you machine. Given that you can't replicate on another
platform (and the .csv file didn't come through), I would think it
wise to start there.
My 2c. And I love bacon too :)
Jeff
On Fri, Aug 7, 2009 at 1:10 PM, wrote:
> This message is in MIME format. The first part should be readable text,
> while the remaining parts are likely unreadable without MIME-aware tools.
>
> --1660387551-1458482416-1249639718=:2997
> Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; FORMAT=flowed
> Content-ID:
>
> Hello,
>
> There appears to be a bug in the nlm function, which I discovered
> when trying to run an SEM. The SEM is not bizarre; the covariance matrix is
> solve-able and the eigenvalues are greater than zero, and I do not believe
> the "sem" package per se to be the problem (as nlm keeps being the part that
> fails, though I can't replicate this with other nlm tasks). I apologize if
> I have put too many much information in this message; I'm not a programmer
> by trade so I don't really know what's going on here, which hampers my
> ability to write consise bug reports.
>
> Here is the code I use:
>
> library(sem)
> ice.S <- read.csv("iceS.csv") # attached
> rownames(ice.S) <- ice.S[,1]
> ice.S[,1] <- NULL
> ice.S <- as.matrix(ice.S)
> ice.ram <- specify.model("ice.ram") # attached
> ice.N <- 342
> ice.sem <- sem(ram=ice.ram, S=ice.S, N=ice.N)
>
> ...at this point, any number of problems could occur. I have seen the
> following.
>
> 1) Simple lack of convergence. (might be my model's fault.)
> 2) Error in nlm(if (analytic.gradient) objective.2 else objective.1, start,
> :
> type 31 is unimplemented in 'type2char'
> 3) *** caught segfault ***
> address 0xc019c87b, cause 'memory not mapped'
>
> Traceback:
> 1: nlm(if (analytic.gradient) objective.2 else objective.1, start,
> hessian = TRUE, iterlim = maxiter, print.level = if (debug) 2 else 0,
> typsize = typsize, ...)
> 2: sem.default(ram = ram, S = S, N = N, param.names = pars, var.names =
> vars, fixed.x = fixed.x, debug = debug, ...)
> 3: sem(ram = ram, S = S, N = N, param.names = pars, var.names = vars,
> fixed.x = fixed.x, debug = debug, ...)
> 4: sem.mod(ram = ice.ram, S = ice.S, N = ice.N)
> 5: sem(ram = ice.ram, S = ice.S, N = ice.N)
>
> 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: 1
> aborting ...
> Segmentation fault
> swiss:data$
>
> (no core was dumped).
>
> Trying with debug mode provides other interesting errors:
>
>> ice.sem <- sem(ram=ice.ram, S=ice.S, N=ice.N, debug=TRUE)
>
> ...gets up to some iteration (not always 15), and then R dies ungracefully,
> and exits to the shell:
>
> iteration = 15
> Step:
> [1] 1.253132e-02 1.183343e-02 -7.651342e-03 -2.490800e-03 2.278938e-03
> [6] 3.197431e-04 6.137849e-04 -2.496882e-03 -1.065829e-03 -2.118179e-03
> [11] 2.942936e-03 -1.335936e-03 -3.665618e-03 3.090566e-03 8.534956e-04
> [16] -1.440421e-03 -5.230877e-04 -1.053686e-04 -9.771005e-04 -4.269216e-04
> [21] 7.261694e-05 -1.039668e-03 -8.409151e-03 -3.497456e-03 2.216899e-03
> [26] -4.633520e-03 -4.052130e-03 -4.746537e-03 -1.589622e-03 -2.523766e-04
> Parameter:
> [1] -0.76604614 -1.19639662 0.83456888 0.72540413 0.08482452 0.56180393
> [7] 0.50615814 0.55728015 0.83796696 0.88371335 -0.70465116 0.85251098
> [13] -0.18346956 0.66857787 0.57012481 0.39116561 0.91237990 0.63951482
> [19] 0.26601566 0.29240836 0.44710919 0.94734056 6.52039015 0.02524762
> [25] -0.01614603 2.88198219 0.03442452 3.52272237 1.44698423 -0.72964745
> Function Value
> [1] -15175.94
> Gradient:
> [1] -2.085412e+07 -3.819717e+07 3.883989e+07 1.352594e+00 -4.283329e+00
> [6] -1.437250e+00 -6.558913e-01 1.358276e+00 7.930865e+05 -1.293853e+06
> [11] -5.816627e+03 5.908197e+05 -2.705742e+08 -1.194400e+07 -4.007083e+07
> [16] -4.143068e+07 -6.159782e-01 1.044274e-01 -8.591048e+00 -2.083471e+00
> [21] -7.548753e-01 -5.418994e-01 -2.799228e+02 -1.321739e+07 -3.517728e+07
> [26] -7.106654e+02 -7.335293e+06 -7.335285e+05 3.117764e-01 -2.234989e+04
>
> Abort trap
> swiss:data$
>
> ...I have also seen convergence reached, and nlm then die with this message:
>
> Error in nlm(if (analytic.gradient) objective.2 else objective.1, start,
> :
> type 27 is unimplemented in 'type2char'
>
> (similar to above, but now referring to type 27)
>
> I have shown this effect (or something similar...never know how it'll fail
> next) on the following platforms:
>
>> version
> _
> platform i386-apple-darwin9.7.0
> arch i386
> os darwin9.7.0
> system i386, darwin9.7.0
> status
> major 2
> minor 9.1
> year 2009
> month 06
> day 26
>
Re: [Rd] Bug in nlm, found using sem; failure in several flavors (PR#13882)
Adam,
It seems that your attachment didn't make it through.
That aside, my experience with strange errors like those (random type
not implemented ones) has been that you may be looking at a memory
problem on you machine. Given that you can't replicate on another
platform (and the .csv file didn't come through), I would think it
wise to start there.
My 2c. And I love bacon too :)
Jeff
On Fri, Aug 7, 2009 at 1:10 PM, wrote:
> =A0This message is in MIME format. =A0The first part should be readable t=
ext,
> =A0while the remaining parts are likely unreadable without MIME-aware too=
ls.
>
> --1660387551-1458482416-1249639718=3D:2997
> Content-Type: TEXT/PLAIN; CHARSET=3DUS-ASCII; FORMAT=3Dflowed
> Content-ID:
>
> Hello,
>
> =A0 =A0 =A0 =A0There appears to be a bug in the nlm function, which I dis=
covered
> when trying to run an SEM. =A0The SEM is not bizarre; the covariance matr=
ix is
> solve-able and the eigenvalues are greater than zero, and I do not believ=
e
> the "sem" package per se to be the problem (as nlm keeps being the part t=
hat
> fails, though I can't replicate this with other nlm tasks). =A0I apologiz=
e if
> I have put too many much information in this message; I'm not a programme=
r
> by trade so I don't really know what's going on here, which hampers my
> ability to write consise bug reports.
>
> Here is the code I use:
>
> library(sem)
> ice.S <- read.csv("iceS.csv") # attached
> rownames(ice.S) <- ice.S[,1]
> ice.S[,1] <- NULL
> ice.S <- as.matrix(ice.S)
> ice.ram <- specify.model("ice.ram") # attached
> ice.N <- 342
> ice.sem <- sem(ram=3Dice.ram, S=3Dice.S, N=3Dice.N)
>
> ...at this point, any number of problems could occur. I have seen the
> following.
>
> 1) Simple lack of convergence. (might be my model's fault.)
> 2) Error in nlm(if (analytic.gradient) objective.2 else objective.1, star=
t,
> :
> =A0 type 31 is unimplemented in 'type2char'
> 3) =A0*** caught segfault ***
> address 0xc019c87b, cause 'memory not mapped'
>
> Traceback:
> =A01: nlm(if (analytic.gradient) objective.2 else objective.1, start,
> hessian =3D TRUE, iterlim =3D maxiter, print.level =3D if (debug) 2 else =
0,
> typsize =3D typsize, ...)
> =A02: sem.default(ram =3D ram, S =3D S, N =3D N, param.names =3D pars, va=
r.names =3D
> vars, =A0 =A0 fixed.x =3D fixed.x, debug =3D debug, ...)
> =A03: sem(ram =3D ram, S =3D S, N =3D N, param.names =3D pars, var.names =
=3D vars,
> fixed.x =3D fixed.x, debug =3D debug, ...)
> =A04: sem.mod(ram =3D ice.ram, S =3D ice.S, N =3D ice.N)
> =A05: sem(ram =3D ice.ram, S =3D ice.S, N =3D ice.N)
>
> 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: 1
> aborting ...
> Segmentation fault
> swiss:data$
>
> (no core was dumped).
>
> Trying with debug mode provides other interesting errors:
>
>> ice.sem <- sem(ram=3Dice.ram, S=3Dice.S, N=3Dice.N, debug=3DTRUE)
>
> ...gets up to some iteration (not always 15), and then R dies ungracefull=
y,
> and exits to the shell:
>
> iteration =3D 15
> Step:
> =A0[1] =A01.253132e-02 =A01.183343e-02 -7.651342e-03 -2.490800e-03 =A02.2=
78938e-03
> =A0[6] =A03.197431e-04 =A06.137849e-04 -2.496882e-03 -1.065829e-03 -2.118=
179e-03
> [11] =A02.942936e-03 -1.335936e-03 -3.665618e-03 =A03.090566e-03 =A08.534=
956e-04
> [16] -1.440421e-03 -5.230877e-04 -1.053686e-04 -9.771005e-04 -4.269216e-0=
4
> [21] =A07.261694e-05 -1.039668e-03 -8.409151e-03 -3.497456e-03 =A02.21689=
9e-03
> [26] -4.633520e-03 -4.052130e-03 -4.746537e-03 -1.589622e-03 -2.523766e-0=
4
> Parameter:
> =A0[1] -0.76604614 -1.19639662 =A00.83456888 =A00.72540413 =A00.08482452 =
=A00.56180393
> =A0[7] =A00.50615814 =A00.55728015 =A00.83796696 =A00.88371335 -0.7046511=
6 =A00.85251098
> [13] -0.18346956 =A00.66857787 =A00.57012481 =A00.39116561 =A00.91237990 =
=A00.63951482
> [19] =A00.26601566 =A00.29240836 =A00.44710919 =A00.94734056 =A06.5203901=
5 =A00.02524762
> [25] -0.01614603 =A02.88198219 =A00.03442452 =A03.52272237 =A01.44698423 =
-0.72964745
> Function Value
> [1] -15175.94
> Gradient:
> =A0[1] -2.085412e+07 -3.819717e+07 =A03.883989e+07 =A01.352594e+00 -4.283=
329e+00
> =A0[6] -1.437250e+00 -6.558913e-01 =A01.358276e+00 =A07.930865e+05 -1.293=
853e+06
> [11] -5.816627e+03 =A05.908197e+05 -2.705742e+08 -1.194400e+07 -4.007083e=
+07
> [16] -4.143068e+07 -6.159782e-01 =A01.044274e-01 -8.591048e+00 -2.083471e=
+00
> [21] -7.548753e-01 -5.418994e-01 -2.799228e+02 -1.321739e+07 -3.517728e+0=
7
> [26] -7.106654e+02 -7.335293e+06 -7.335285e+05 =A03.117764e-01 -2.234989e=
+04
>
> Abort trap
> swiss:data$
>
> ...I have also seen convergence reached, and nlm then die with this messa=
ge:
>
> Error in nlm(if (analytic.gradient) objective.2 else objective.1, start,
> :
> =A0 type 27 is unimplemented in 'type2char'
>
> (similar to above, but now referring to type 27)
>
> I have shown this effect (or something similar...never know how it'll fai=
l
> next) on the following platforms:
>
>>
Re: [Rd] R patched & devel versions as portable ZIP files
- You can tell the installer not to use the registry. - You can install to a fixed location (e.g. also to the USB stick) Using both options mentioned above means the same as unpacking a zip file over there. Uwe Ligges Hans W Borchers wrote: I wonder if it would be possible to provide R patched and development versions for Windows as simple zip files without using any installers. There are more and more free and open source software projects providing such portable versions, among them Python (since V2.5), the new MikTex 2.8, OpenOffice 3, Firefox and Thunderbird, to name a few. Many smaller Windows utilities do the same. When regularly following patched and development version, the installation procedures and writing into the Windows registry all the time makes me feel uneasy. And even with the installation procedure there are subsequent tasks, for example changing the path in the shortcut. Zip files are much better for those running R from an USB stick because otherwise you have to install it on the disk---what maybe you don't want to do---and then copy it over to the stick. I know there are some concerns with R-(D)COM interface and i assume those using it know which versions to install. Thanks Hans Werner Borchers __ 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] R patched & devel versions as portable ZIP files
On 8/7/2009 3:35 PM, Hans W Borchers wrote: I wonder if it would be possible to provide R patched and development versions for Windows as simple zip files without using any installers. Yes, it would be quite easy to do. I'll set R-devel to do it as of tomorrow's build; let me know if the format is fine for you, and I'll do it for R-patched once the bugs are worked out. Duncan Murdoch There are more and more free and open source software projects providing such portable versions, among them Python (since V2.5), the new MikTex 2.8, OpenOffice 3, Firefox and Thunderbird, to name a few. Many smaller Windows utilities do the same. When regularly following patched and development version, the installation procedures and writing into the Windows registry all the time makes me feel uneasy. And even with the installation procedure there are subsequent tasks, for example changing the path in the shortcut. Zip files are much better for those running R from an USB stick because otherwise you have to install it on the disk---what maybe you don't want to do---and then copy it over to the stick. I know there are some concerns with R-(D)COM interface and i assume those using it know which versions to install. Thanks Hans Werner Borchers __ 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
