Re: [Rd] wishlist -- names gives slotnames (PR#7410)
> "ElizP" == Elizabeth Purdom <[EMAIL PROTECTED]>
> on Thu, 9 Dec 2004 19:28:40 +0100 (CET) writes:
ElizP> Full_Name: Elizabeth Purdom Version: 1.9.1 OS:
ElizP> Windows XP Submission from: (NULL) (171.64.102.199)
ElizP> It would be nice if names(obj) would give slot names
ElizP> as well. Since for many people slots are new, the
ElizP> first thing that happens is you try to access what's
ElizP> in them and can't find how to do it.
Thank you for your thoughts,..
but
``As with everything, use str() ''
--- but you need at least R 2.0.0; your R 1.9.1 is too old for
this (and probably, in general for posting to R-bugs !)
E.g.
library(stats4)
example(mle)
str(fit2)
gives
Formal class 'mle' [package "stats4"] with 8 slots
..@ call : language mle(minuslogl = ll2)
..@ coef : Named num [1:2] 3.22 1.12
.. ..- attr(*, "names")= chr [1:2] "lymax" "lxhalf"
..@ fullcoef : Named num [1:2] 3.22 1.12
.. ..- attr(*, "names")= chr [1:2] "lymax" "lxhalf"
<...>
Now if you don't know much about S4 classes, you see the word
"slot" in the first line of str()'s output and
hopefully try
help(slot)
This will tell you about slotNames().
ElizP> If you don't know that slotNames() exists, it can be
ElizP> very frustrating. Moreover, if you don't even know
ElizP> that the objects has slots (or that such things
ElizP> exist), it's extremely confusing.
I agree that it might be confusing {but do use str() .. }
ElizP> exist), it's extremely confusing. It just looks like
ElizP> nothing is there (you get NULL).
The same happens if you do length(..) of an S4 object; that
gives 0; so at least names() and length() are consistent ;-)
I'm not so sure if inames() should be extended to S4 classes
that way; in any case if it's done, length() should also
give the same as length(names()).
I'm CC'ing John Chambers, the masterminder of S4, to make sure we
get his comments on this.
ElizP> If needed, you could have a message that says that
ElizP> these are slots and should be accessed with "@".
It seems you are thinking about list()s and their names.
Note that atomic vector have names too and these are not accessed
with "$" either. So I wouldn't see the need for such a message.
Martin
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Broken Korean Language in New vesrion of R 2.0.1 (PR#7411)
Full_Name: Yoon Dong Lee Version: R 2.0.1 OS: Windows Submission from: (NULL) (203.252.165.51) Dear the manager; Recently, I found a small but big new bug in R 2.0.1. Korean Language is shown as broken in R Gui terminal. R 1.9.1 had not the problem, but R 2.0.1 makes the problem. Korean is one of 2-byte character system, and is supported in Unicode (of 3 byte). I don't know why new version of R makes new problem. Please fix this bug for all Korean using population, more than 1/60 of the world population. If you need more detail report, please ask to me via e-mail. If you let me know your address, I can send the pictures illustrating the bug. Sincerely yours. YDL __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Recent acquisition equals twice the power.
Haven't you liked walking? Don't you frequently dislike shaving? [[alternative HTML version deleted]] __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] pausing between plots - waiting for graphics input
On Wed, 01 Dec 2004 10:32:57 +1300, Paul Murrell <[EMAIL PROTECTED]> wrote : >Hi > > >Duncan Murdoch wrote: >> On Wed, 01 Dec 2004 08:55:27 +1300, Paul Murrell >> <[EMAIL PROTECTED]> wrote : >> >> >>>This sounds like the general problem of being able to capture keyboard >>>input on a graphics device (a key-stroke equivalent of dev_locator). >>>Robert has been keen on this for a while too. I've now committed the getGraphicsEvent function with mouse and keyboard support. So far only the windows screen device knows how to work with it, because that's all I've got. It's in the R-devel build I just uploaded, which should be downloadable by tomorrow. If someone wants to write support for other platforms, I'd be happy to help. I imagine the implementation will change a bit when we do the first one, because I don't know the other platforms at all, and have probably made some Windows-centric assumptions. But at least it's a starting point. Here's a quick summary of how it currently looks: The device is assumed to be based on the NewDevDesc structure. There are new fields canGenXXX to indicate that it can generate mouse or keyboard events; getGraphicsEvent aborts if you try to set an event on a device that doesn't support them. When getGraphicsEvent is active, it sets a gettingEvent field to TRUE, saves its environment into eventRho, and calls the getEvent callback. This callback is supposed to run an event loop, looking for user input. When it sees an event that it is supposed to handle, it calls a doMouseXXX or doKeybd function, and those translate the message into an R call to call the handler, and put the result in eventResult. The whole process can be aborted if the user interrupts (e.g. by hitting Esc in Rgui); in that case, another callback called onExit is called to clean up. Comments are welcome. Duncan Murdoch __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] wishlist -- names gives slotnames (PR#7410)
Full_Name: Elizabeth Purdom Version: 1.9.1 OS: Windows XP Submission from: (NULL) (171.64.102.199) It would be nice if names(obj) would give slot names as well. Since for many people slots are new, the first thing that happens is you try to access what's in them and can't find how to do it. If you don't know that slotNames() exists, it can be very frustrating. Moreover, if you don't even know that the objects has slots (or that such things exist), it's extremely confusing. It just looks like nothing is there (you get NULL). If needed, you could have a message that says that these are slots and should be accessed with "@". Thanks, Elizabeth __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Modulus Bug (PR#7409)
On Thu, 9 Dec 2004, Thomas Lumley wrote:
> On Thu, 9 Dec 2004 [EMAIL PROTECTED] wrote:
>
> > This is nothing to do with integers: 1e18 and 11 are doubles here.
> >
> > It is a result of rounding error: 1e18/11 is not representable accurately,
> > and this should have been a warning to you that your calculations were
> > unreasonable.
>
> It was -- the poster originally asked about large integer representations
> and said he was planning to use other software for large integers.
Ah, but that's not in this bug report.
> At the time I said that the fact %% didn't give some sort of error or
> warning was a bug, and was planning to return either a warning or NA or
> NaN if
>abs(x1)>1/.Machine$double.eps
>
> -thomas
I've done that (a warning) but it needed caching .Machine at C level to
make it reasonably efficient. I've also done a second pass to ensure
the result is within range (even if possible nonsense).
>
> > The C code is
> >
> > double myfmod(double x1, double x2)
> > {
> > double q = x1 / x2;
> > return x1 - floor(q) * x2;
> > }
> >
> > We can improve the answer, but what you are doing is fundamentally flawed
> > and it is hard to detect whether rounding error has affected this. A
> > warning rather than an error seems appropriate.
> >
> > If you really want to do things like this, try the gmp package (which
> > seems to give the wrong answer here) or a more appropriate calculator.
> >
> >
> > On Thu, 9 Dec 2004 [EMAIL PROTECTED] wrote:
> >
> >> R Developers,
> >>
> >> 100 %% 11
> >> [1] -32
> >>
> >> I now understand that integers cannot be larger than
> >> .Machine$integer.max, but because the above produces a result than is
> >> patently wrong instead of an error, I'm reporting this as a bug.
> >
> > --
> > Brian D. Ripley, [EMAIL PROTECTED]
> > 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
> >
> > __
> > [EMAIL PROTECTED] mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
>
--
Brian D. Ripley, [EMAIL PROTECTED]
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
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] webpage link (to MacOSX check summaries) is broken (PR#7405)
On Dec 6, 2004, at 12:42 PM, Kurt Hornik wrote: smyth writes: The link to "MacOS X check summary" on the page http://cran.r-project.org/src/contrib/PACKAGES.html is broken. Gordon, Thanks but ... this is really not a bug in R, but a problem with CRAN. Stefano: the link points to http://cran.r-project.org/bin/macosx/r-devel/check/ checkSummaryOSX.html where did this go? I'll set it up again. I was travelling these days not able to do anything. surely not a bug in R Stefano Best -k __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Modulus Bug (PR#7409)
On Thu, 9 Dec 2004 [EMAIL PROTECTED] wrote:
This is nothing to do with integers: 1e18 and 11 are doubles here.
It is a result of rounding error: 1e18/11 is not representable accurately,
and this should have been a warning to you that your calculations were
unreasonable.
It was -- the poster originally asked about large integer representations
and said he was planning to use other software for large integers.
At the time I said that the fact %% didn't give some sort of error or
warning was a bug, and was planning to return either a warning or NA or
NaN if
abs(x1)>1/.Machine$double.eps
-thomas
The C code is
double myfmod(double x1, double x2)
{
double q = x1 / x2;
return x1 - floor(q) * x2;
}
We can improve the answer, but what you are doing is fundamentally flawed
and it is hard to detect whether rounding error has affected this. A
warning rather than an error seems appropriate.
If you really want to do things like this, try the gmp package (which
seems to give the wrong answer here) or a more appropriate calculator.
On Thu, 9 Dec 2004 [EMAIL PROTECTED] wrote:
R Developers,
100 %% 11
[1] -32
I now understand that integers cannot be larger than
.Machine$integer.max, but because the above produces a result than is
patently wrong instead of an error, I'm reporting this as a bug.
--
Brian D. Ripley, [EMAIL PROTECTED]
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
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
RE: [Rd] Problem with read.xport() from foreigh package (PR#7389)
Have you looked at the latest version of foreign, 0.8-2? The issue has
already been resolved, AFAIK.
On Thu, 9 Dec 2004, Werner Engl wrote:
Dear R-devel list,
This is to confirm Prof. Ripley's analysis of the
read.xport issue.
The section on missing data in TS140 is pertinent
to numeric variables only. In SAS, character
variables are of fixed length (between 1 and 200
for the xport format). Shorter strings are padded
with trailing blanks when assigned to a variable.
An uninitialized character variable is stored as
all blanks in the xport format file. This is the
only representation of 'missing' data for SAS
character variables. 'Special missing' codes
(.A to .Z and ._) are available for numeric
variables only.
Please find enclosed a patch to the
R-2.0.1/src/library/Recommended/foreign/SASxport.c
file and a xport file that I used for testing. The
xport file was created by SAS V8.2 on Linux, but
should be plattform and version independent (except
for the header information). I have simply commented
out the code lines that try to detect missing character
values.
The code in SASxport.c already does a good job in
removing trailing blanks from character values.
For missing character data (all blanks) the result
is the empty string (""), which is fine for me.
There is no equivalent to the R missing character
representation in SAS (as far as I know).
The enclosed gzipped tar file contains:
diff_SASxport_c.txt diff for SASxport.c
xptchar1.xpttest file in xport format
xptchar.sas trivial SAS program used to
generate xptchar1.xpt
xptchar_SAS_System_Viewer9_1.csvxptchar1.xpt
converted to comma separated file using SAS
System Viewer 9.1 (on Win XP)
With the patch applied, read.xport produces the same
data frame from xptchar1.xpt as read.csv does from
xptchar_SAS_System_Viewer9_1.csv (tested on i386 Linux
with R Version 2.0.1) except that read.csv converts empty
strings to NAs. As explained above, the empty string is
closer to the meaning of an all-blanks value in SAS.
There is renewed interest in this old data format in
the pharmaceutical industry, because the US Food and
Drug Administration requests clinical and
pre-clinical data to be submitted in this format. I
spent some time analyzing the xport file format to
be sure of what is actually submitted to FDA with
these files.
Thank you for considering this patch (and for the
great R system, of course)!
Best regards,
Werner Engl
_
Werner Engl, PhD, CStat
Senior Manager, Biostatistics
Baxter AG, Vienna, Austria
e-mail: [EMAIL PROTECTED]
--- Please disregard any text below this line ---
--
GMX DSL-Netzanschluss + Tarif zum supergünstigen Komplett-Preis!
--
Brian D. Ripley, [EMAIL PROTECTED]
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__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
RE: [Rd] Problem with read.xport() from foreigh package (PR#7389)
Dear R-devel list,
This is to confirm Prof. Ripley's analysis of the
read.xport issue.
The section on missing data in TS140 is pertinent
to numeric variables only. In SAS, character
variables are of fixed length (between 1 and 200
for the xport format). Shorter strings are padded
with trailing blanks when assigned to a variable.
An uninitialized character variable is stored as
all blanks in the xport format file. This is the
only representation of 'missing' data for SAS
character variables. 'Special missing' codes
(.A to .Z and ._) are available for numeric
variables only.
Please find enclosed a patch to the
R-2.0.1/src/library/Recommended/foreign/SASxport.c
file and a xport file that I used for testing. The
xport file was created by SAS V8.2 on Linux, but
should be plattform and version independent (except
for the header information). I have simply commented
out the code lines that try to detect missing character
values.
The code in SASxport.c already does a good job in
removing trailing blanks from character values.
For missing character data (all blanks) the result
is the empty string (""), which is fine for me.
There is no equivalent to the R missing character
representation in SAS (as far as I know).
The enclosed gzipped tar file contains:
diff_SASxport_c.txt diff for SASxport.c
xptchar1.xpttest file in xport format
xptchar.sas trivial SAS program used to
generate xptchar1.xpt
xptchar_SAS_System_Viewer9_1.csvxptchar1.xpt
converted to comma separated file using SAS
System Viewer 9.1 (on Win XP)
With the patch applied, read.xport produces the same
data frame from xptchar1.xpt as read.csv does from
xptchar_SAS_System_Viewer9_1.csv (tested on i386 Linux
with R Version 2.0.1) except that read.csv converts empty
strings to NAs. As explained above, the empty string is
closer to the meaning of an all-blanks value in SAS.
There is renewed interest in this old data format in
the pharmaceutical industry, because the US Food and
Drug Administration requests clinical and
pre-clinical data to be submitted in this format. I
spent some time analyzing the xport file format to
be sure of what is actually submitted to FDA with
these files.
Thank you for considering this patch (and for the
great R system, of course)!
Best regards,
Werner Engl
_
Werner Engl, PhD, CStat
Senior Manager, Biostatistics
Baxter AG, Vienna, Austria
e-mail: [EMAIL PROTECTED]
--- Please disregard any text below this line ---
--
GMX DSL-Netzanschluss + Tarif zum supergünstigen Komplett-Preis!
PR7389_we20041209.tar.gz
Description: GNU Zip compressed data
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Modulus Bug (PR#7409)
This is nothing to do with integers: 1e18 and 11 are doubles here.
It is a result of rounding error: 1e18/11 is not representable accurately,
and this should have been a warning to you that your calculations were
unreasonable.
The C code is
double myfmod(double x1, double x2)
{
double q = x1 / x2;
return x1 - floor(q) * x2;
}
We can improve the answer, but what you are doing is fundamentally flawed
and it is hard to detect whether rounding error has affected this. A
warning rather than an error seems appropriate.
If you really want to do things like this, try the gmp package (which
seems to give the wrong answer here) or a more appropriate calculator.
On Thu, 9 Dec 2004 [EMAIL PROTECTED] wrote:
> R Developers,
>
> 100 %% 11
> [1] -32
>
> I now understand that integers cannot be larger than
> .Machine$integer.max, but because the above produces a result than is
> patently wrong instead of an error, I'm reporting this as a bug.
--
Brian D. Ripley, [EMAIL PROTECTED]
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
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
