[Rd] changed behaviour of 'get' in 2.8.0: request for unchange
There is an unannounced and non-backwards-compatible change to the behaviour of
'get' in R2.8.0. 'get'ting a missing value now causes an error, whereas
hitherto it's just returned a "missing" object. For example, in R2.8.0 this
happens:
test> getto <- function( x) get( 'x', sys.frame(1))
test> getto()
Error in get("x", sys.frame(1)) :
argument "x" is missing, with no default
whereas in R2.7.1 this happens:
test> getto()
test>
i.e. a "missing" object.
While I can see some reason to the change, the error always would have gotten
triggered eventually if it actually mattered-- and the new behaviour is
inconsistent with other extraction functions:
test> getto2 <- function(x) sys.frame(1)$x
test> getto2()
test>
and the same goes for '[['.
'mget' also returns a missing object, rather than tripping an error.
The new 'get' breaks code in packages 'mvbutils' and 'debug'. At least 54
separate functions in those packages use 'get', so there'd be a fair bit of
work in checking & changing all these to 'mget'! (Not to mention the entire
rest of my code body...)
Is it possible to 'get' the old behaviour back?
Mark Bravington
CSIRO Mathematics & Information Science
CSIRO Marine Lab
Hobart
Australia
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Problem with "plflatex wrapper.tex"
Hi, All:
I encountered problems running "pdflatex wrapper.tex", as
suggested on "www.r-project.org" -> Newsletter -> (near the bottom of
the page). After 220 lines of seemingly successful processing, I got an
error copied below. I hit a few times, and the "pdflatex"
finished, apparently successfully.
Comments?
Thanks,
Spencer
##
! LaTeX Error: Something's wrong--perhaps a missing \item.
See the LaTeX manual or LaTeX Companion for explanation.
Type H for immediate help.
...
l.151 ... Gentleman(1996)]{R:Ihaka+Gentleman:1996}
?
##
Complete copy of "Command Prompt" contents:
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
C:\Documents and Settings\spencerg>d:
D:\>cd spencerg
D:\spencerg>cd statmtds
D:\spencerg\statmtds>cd R
D:\spencerg\statmtds\R>cd Rnews
D:\spencerg\statmtds\R\Rnews>pdflatex wrapper.tex
This is pdfTeX, Version 3.1415926-1.40.9 (MiKTeX 2.7)
Running pdftex...
This is pdfTeX, Version 3.1415926-1.40.9 (MiKTeX 2.7) (INITEX)
entering extended mode
("d:\Program Files\MiKTeX 2.7\tex\latex\config\pdflatex.ini"
("C:\Documents and Settings\All Users\Application
Data\MiKTeX\2.7\tex\generic\c
onfig\pdftexconfig.tex")
("d:\Program Files\MiKTeX 2.7\tex\latex\base\latex.ltx"
("d:\Program Files\MiKTeX 2.7\tex\latex\00miktex\texsys.cfg")
./texsys.aux found
[EMAIL PROTECTED] set to: ./.
Assuming \openin and \input
have the same search path.
Defining UNIX/DOS style filename parser.
catcodes, registers, compatibility for TeX 2, parameters,
LaTeX2e <2005/12/01>
hacks, control, par, spacing, files, font encodings, lengths,
Local config file fonttext.cfg used
("d:\Program Files\MiKTeX 2.7\tex\latex\00miktex\fonttext.cfg"
("d:\Program Files\MiKTeX 2.7\tex\latex\base\fonttext.ltx"
=== Don't modify this file, use a .cfg file instead ===
("d:\Program Files\MiKTeX 2.7\tex\latex\base\omlenc.def")
("d:\Program Files\MiKTeX 2.7\tex\latex\base\t1enc.def")
("d:\Program Files\MiKTeX 2.7\tex\latex\base\ot1enc.def")
("d:\Program Files\MiKTeX 2.7\tex\latex\base\omsenc.def")
("d:\Program Files\MiKTeX 2.7\tex\latex\base\t1cmr.fd")
("d:\Program Files\MiKTeX 2.7\tex\latex\base\ot1cmr.fd")
("d:\Program Files\MiKTeX 2.7\tex\latex\base\ot1cmss.fd")
("d:\Program Files\MiKTeX 2.7\tex\latex\base\ot1cmtt.fd")))
Local config file fontmath.cfg used
("d:\Program Files\MiKTeX 2.7\tex\latex\00miktex\fontmath.cfg"
("d:\Program Files\MiKTeX 2.7\tex\latex\base\fontmath.ltx"
=== Don't modify this file, use a .cfg file instead ===
("d:\Program Files\MiKTeX 2.7\tex\latex\base\omlcmm.fd")
("d:\Program Files\MiKTeX 2.7\tex\latex\base\omscmsy.fd")
("d:\Program Files\MiKTeX 2.7\tex\latex\base\omxcmex.fd")
("d:\Program Files\MiKTeX 2.7\tex\latex\base\ucmr.fd")))
Local config file preload.cfg used
=
("d:\Program Files\MiKTeX 2.7\tex\latex\base\preload.cfg"
("d:\Program Files\MiKTeX 2.7\tex\latex\base\preload.ltx")) page nos.,
x-ref,
environments, center, verbatim, math definitions, boxes, title, sectioning,
contents, floats, footnotes, index, bibliography, output,
===
Local configuration file hyphen.cfg used
===
("d:\Program Files\MiKTeX 2.7\tex\generic\babel\hyphen.cfg"
("d:\Program Files\MiKTeX 2.7\tex\generic\hyphen\hyphen.tex")
("d:\Program Files\MiKTeX 2.7\tex\generic\hyphen\dumyhyph.tex")
("d:\Program Files\MiKTeX 2.7\tex\generic\hyphen\zerohyph.tex")
("d:\Program Files\MiKTeX
2.7\tex\generic\hyph-utf8\loadhyph\loadhyph-de-1901.t
ex" German Hyphenation Patterns (Traditional Orthography)
("d:\Program Files\MiKTeX 2.7\tex\generic\hyphen\dehypht.tex"
German Traditional Hyphenation Patterns `dehypht' Version 3.2a <1999/03/03>
(Formerly known under the name `ghyph31' and `ghyphen'.)))
("d:\Program Files\MiKTeX
2.7\tex\generic\hyph-utf8\loadhyph\loadhyph-de-1996.t
ex" German Hyphenation Patterns (Reformed Orthography)
("d:\Program Files\MiKTeX 2.7\tex\generic\hyphen\dehyphn.tex"
New German Hyphenation Patterns `dehyphn' Rev.31 <2001-05-07> (WaS)))
("d:\Program Files\MiKTeX
2.7\tex\generic\dehyph-exptl\dehypht-x-2008-06-18.tex
" Using an 8-bit TeX engine.
("d:\Program Files\MiKTeX
2.7\tex\generic\dehyph-exptl\dehypht-x-2008-06-18.pat
"
German Hyphenation Patterns (Traditional Orthography) `dehypht-x'
2008-06-18 (W
L)))
("d:\Program Files\MiKTeX
2.7\tex\generic\dehyph-exptl\dehyphn-x-2008-06-18.tex
" Using an 8-bit TeX engine.
("d:\Program Files\MiKTeX
2.7\tex\generic\dehyph-exptl\dehyphn-x-2008-06-18.pat
"
German Hyphenation Patterns (Reformed Orthography, 2006) `dehyphn-x'
2
Re: [Rd] normalizePath bug (PR#13199)
No, it's working fine if the file is there, and as I mentioned before, I
can just normalize the path, and then append the file name at the end
using the file.path function.
Thanks for your help.
On Thu, 23 Oct 2008 14:24:42 -0400, Duncan Murdoch <[EMAIL PROTECTED]>
wrote:
On 10/23/2008 1:59 PM, Joseph Haykov wrote:
Actually, it's a new file that I plan on writing to, so while the
directory C:\\DOCUME~1\\JOSEPH~1\\LOCALS~1\\Temp\\RtmpolZ4Vy exists,
the file file72ae2cd6.txt does not. However, this was working fine in
version 2.6.2. If you're saying that the reason why this doesn't work
is because the file does not exist, I can easily work around the issue.
That's a likely cause. 2.7.0 changed the method of normalizing the
path, and it now relies on Windows API calls to do it. However, up to
2.8.0 it wasn't checking for an error return from those. I've fixed
that now, so your string now gives me
>
normalizePath("C:\\DOCUME~1\\JOSEPH~1\\LOCALS~1\\Temp\\RtmpolZ4Vy\\file72ae2cd6.txt")
Error in normalizePath(path) : Unable to normalize element 1
The Windows docs don't list all possible reasons for an error return, so
I'm not sure that's what you saw, but it does seem likely. Please do
let me know if creating the file is not sufficient to get it to work for
you.
Duncan Murdoch
Best regards,
Joe Haykov
On Thu, 23 Oct 2008 13:49:42 -0400, Duncan Murdoch
<[EMAIL PROTECTED]> wrote:
On 10/23/2008 10:45 AM, [EMAIL PROTECTED] wrote:
Full_Name: Joseph Haykov
Version: 2.8.0
OS: Windows
Submission from: (NULL) (216.189.177.202)
normalizePath("C:\\DOCUME~1\\JOSEPH~1\\LOCALS~1\\Temp\\RtmpolZ4Vy\\file72ae2cd6.txt")
returns: "\0354xl|\a\001 $v\001¨y8"
instead of returning:
"C:\\Documents and Settings\\Joseph Haykov\\Local
Settings\\Temp\\RtmpolZ4Vy\\file72ae2cd6.txt"
By the way, this works correctly in version 2.6.2
I see the problem, and will look into it. It first started failing
in 2.7.0; it's not a new bug.
But I'm not sure it's a bug, since that directory doesn't exist on my
system, and the function is documented to give undefined results in
that case. Does that file exist on your system?
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] RCMD SHLIB: static libraries and f77 libraries on Windows
Dear R-devel, I am converting some stand-alone programs (mixed C and F77) to R functions. I've run into two issues that I haven't been able to resolve. I've looked at the R-exts manual and Readme files, but haven't found answers. (1) Can I link to a (Win32) static library? Is there some option to RCMD SHLIB that allows this? I've triedRCMD SHLIB myprog.c -l mylib.a but it doesn't work. Perhaps setting the flag LDFLAGS? If so, how do I do this? Perhaps using MakeVar/MakeFile? Failing this, is there a way to use a wildcard on a link , e.g. RCMD SHLIB myprog.c *.o, instead of having to list ~100 object files? (2) I'm using some legacy F77 code in the project, and it calls some gcc library functions: G77_exit_0, s_cat, F77_aloc, etc. These used to be in gcc libraries libg2c.a and libgcc.a, which were part of MinGW. They don't seem to be in the MinGW that comes with Rtools. Have they be replaced, and if so, what are the appropriate libraries? If this is documented, or if there is an example somewhere, please let me know. Thanks,John ... John P. Nolan Math/Stat Department 227 Gray Hall American University 4400 Massachusetts Avenue, NW Washington, DC 20016-8050 [EMAIL PROTECTED] 202.885.3140 voice 202.885.3155 fax http://academic2.american.edu/~jpnolan ... [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] normalizePath bug (PR#13199)
Actually, it's a new file that I plan on writing to, so while the
directory C:\\DOCUME~1\\JOSEPH~1\\LOCALS~1\\Temp\\RtmpolZ4Vy exists, the
file file72ae2cd6.txt does not. However, this was working fine in version
2.6.2. If you're saying that the reason why this doesn't work is because
the file does not exist, I can easily work around the issue.
Best regards,
Joe Haykov
On Thu, 23 Oct 2008 13:49:42 -0400, Duncan Murdoch <[EMAIL PROTECTED]>
wrote:
On 10/23/2008 10:45 AM, [EMAIL PROTECTED] wrote:
Full_Name: Joseph Haykov
Version: 2.8.0
OS: Windows
Submission from: (NULL) (216.189.177.202)
normalizePath("C:\\DOCUME~1\\JOSEPH~1\\LOCALS~1\\Temp\\RtmpolZ4Vy\\file72ae2cd6.txt")
returns: "\0354xl|\a\001 $v\001¨y8"
instead of returning:
"C:\\Documents and Settings\\Joseph Haykov\\Local
Settings\\Temp\\RtmpolZ4Vy\\file72ae2cd6.txt"
By the way, this works correctly in version 2.6.2
I see the problem, and will look into it. It first started failing in
2.7.0; it's not a new bug.
But I'm not sure it's a bug, since that directory doesn't exist on my
system, and the function is documented to give undefined results in that
case. Does that file exist on your system?
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Getting the panel location of a xyplot matrix using a mouse click in a GDCanvas
On Thu, Oct 23, 2008 at 12:26 PM, Daniel Kornhauser
<[EMAIL PROTECTED]> wrote:
> Hi:
>
> I would like to find out the panel of a xyplot matrix where a mouse clicked.
>
> I know this functionality is already bundled in trellis.focus but I can't
> use it because I am coding a stand alone application in Java using with
> GDCanvas as a graphics device.
>
> I tried calling trellis.focus from Java with:
> re.eval("t = trellis.focus()"));
> However it did not work for an embedded GDCanvas. The above call to the
> trellis.focus() returns null no matter where I click.
>
> (Side note: the functionality must be implemented in the GDCanvas because
> trellis.focus does work correctly in JGR)
>
> I wish to handle all the user GUI events in Java to evaluate different
> commands in an Rengine.
> With a GDCanvas, it's straightforward to get the x y position of a mouse
> click with the standard e.getX() and e.getY()
> So my handler would look like:
>public void mouseClicked(MouseEvent e) {
>System.out.println("Clicked" + e.getX() + " " + e.getY());
>System.out.println(re.eval("t = trellis.focus()"));
>System.out.println(re.eval("t"));
> // I would update the panel here ...
>}
>
> I am only using Java because:
> - I am proficient in Java GUI programmer
> - It is multiplatform
>
> Another way of posing the question is:
> Given the coordinates from grid.location how can I find out the plane of an
> xyplot matrix where the user clicked.
>
> I have tried to figure out how to do it from code using trellis.clickFocus,
> but I have have only been playing with R for a week, so I am quite lost
> reading R code.
The approach in trellis.clickFocus should get you close. One important
point is that
clickLoc <- grid.locator("npc")
returns the location in NPC, whereas your e.getX() and e.getY() would
be in device coordinates. help(grconvertX) should tell you how to make
the conversion.
-Deepayan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Getting the panel location of a xyplot matrix using a mouse click in a GDCanvas
Hi:
I would like to find out the panel of a xyplot matrix where a mouse clicked.
I know this functionality is already bundled in trellis.focus but I can't
use it because I am coding a stand alone application in Java using with
GDCanvas as a graphics device.
I tried calling trellis.focus from Java with:
re.eval("t = trellis.focus()"));
However it did not work for an embedded GDCanvas. The above call to the
trellis.focus() returns null no matter where I click.
(Side note: the functionality must be implemented in the GDCanvas because
trellis.focus does work correctly in JGR)
I wish to handle all the user GUI events in Java to evaluate different
commands in an Rengine.
With a GDCanvas, it's straightforward to get the x y position of a mouse
click with the standard e.getX() and e.getY()
So my handler would look like:
public void mouseClicked(MouseEvent e) {
System.out.println("Clicked" + e.getX() + " " + e.getY());
System.out.println(re.eval("t = trellis.focus()"));
System.out.println(re.eval("t"));
// I would update the panel here ...
}
I am only using Java because:
- I am proficient in Java GUI programmer
- It is multiplatform
Another way of posing the question is:
Given the coordinates from grid.location how can I find out the plane of an
xyplot matrix where the user clicked.
I have tried to figure out how to do it from code using trellis.clickFocus,
but I have have only been playing with R for a week, so I am quite lost
reading R code.
I tried to look up to in the code of JGR and came out emplty handed.
This is my first post so I hope I did not break any rules ...
Thanks !
Daniel
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] normalizePath bug (PR#13199)
On 10/23/2008 1:59 PM, Joseph Haykov wrote:
Actually, it's a new file that I plan on writing to, so while the
directory C:\\DOCUME~1\\JOSEPH~1\\LOCALS~1\\Temp\\RtmpolZ4Vy exists, the
file file72ae2cd6.txt does not. However, this was working fine in version
2.6.2. If you're saying that the reason why this doesn't work is because
the file does not exist, I can easily work around the issue.
That's a likely cause. 2.7.0 changed the method of normalizing the
path, and it now relies on Windows API calls to do it. However, up to
2.8.0 it wasn't checking for an error return from those. I've fixed
that now, so your string now gives me
>
normalizePath("C:\\DOCUME~1\\JOSEPH~1\\LOCALS~1\\Temp\\RtmpolZ4Vy\\file72ae2cd6.txt")
Error in normalizePath(path) : Unable to normalize element 1
The Windows docs don't list all possible reasons for an error return, so
I'm not sure that's what you saw, but it does seem likely. Please do
let me know if creating the file is not sufficient to get it to work for
you.
Duncan Murdoch
Best regards,
Joe Haykov
On Thu, 23 Oct 2008 13:49:42 -0400, Duncan Murdoch <[EMAIL PROTECTED]>
wrote:
On 10/23/2008 10:45 AM, [EMAIL PROTECTED] wrote:
Full_Name: Joseph Haykov
Version: 2.8.0
OS: Windows
Submission from: (NULL) (216.189.177.202)
normalizePath("C:\\DOCUME~1\\JOSEPH~1\\LOCALS~1\\Temp\\RtmpolZ4Vy\\file72ae2cd6.txt")
returns: "\0354xl|\a\001 $v\001¨y8"
instead of returning:
"C:\\Documents and Settings\\Joseph Haykov\\Local
Settings\\Temp\\RtmpolZ4Vy\\file72ae2cd6.txt"
By the way, this works correctly in version 2.6.2
I see the problem, and will look into it. It first started failing in
2.7.0; it's not a new bug.
But I'm not sure it's a bug, since that directory doesn't exist on my
system, and the function is documented to give undefined results in that
case. Does that file exist on your system?
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] normalizePath bug (PR#13199)
On 10/23/2008 10:45 AM, [EMAIL PROTECTED] wrote:
Full_Name: Joseph Haykov
Version: 2.8.0
OS: Windows
Submission from: (NULL) (216.189.177.202)
normalizePath("C:\\DOCUME~1\\JOSEPH~1\\LOCALS~1\\Temp\\RtmpolZ4Vy\\file72ae2cd6.txt")
returns: "\0354xl|\a\001 $v\001¨y8"
instead of returning:
"C:\\Documents and Settings\\Joseph Haykov\\Local
Settings\\Temp\\RtmpolZ4Vy\\file72ae2cd6.txt"
By the way, this works correctly in version 2.6.2
I see the problem, and will look into it. It first started failing in
2.7.0; it's not a new bug.
But I'm not sure it's a bug, since that directory doesn't exist on my
system, and the function is documented to give undefined results in that
case. Does that file exist on your system?
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] normalizePath bug (PR#13199)
Full_Name: Joseph Haykov
Version: 2.8.0
OS: Windows
Submission from: (NULL) (216.189.177.202)
normalizePath("C:\\DOCUME~1\\JOSEPH~1\\LOCALS~1\\Temp\\RtmpolZ4Vy\\file72ae2cd6.txt")
returns: "\0354xl|\a\001 $v\001¨y8"
instead of returning:
"C:\\Documents and Settings\\Joseph Haykov\\Local
Settings\\Temp\\RtmpolZ4Vy\\file72ae2cd6.txt"
By the way, this works correctly in version 2.6.2
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Potential improvement to boxplot when outline=FALSE is set? (PR#13196)
Hi. I have recently noticed that when using boxplot with outline=FALSE, the default ylim (xlim if horizontal=TRUE) might be improved on. The default can result in much wasted display and hard to read plots. A simple snippet of test code is given below that illustrates the issue along with a suggested improvement. Thanks ever so much for your wonderful and ongoing contributions to the open source community. ## Demonstration code to illustrate that when outline=FALSE in ## boxplots, ylim (or xlim when horizontal=TRUE is set) might be ## better set. set.seed(12345) x <- rchisq(1,df=1) par(mfrow=c(2,1)) ## Default wastes much graphics display space... boxplot(x,outline=FALSE) ## This simple modification can rectify the situation... ylim=c(max(min(x),quantile(x,.25)-1.5*IQR(x)), min(max(x),quantile(x,.75)+1.5*IQR(x))) boxplot(x,outline=FALSE,ylim=ylim) ## End of demonstration code Note that when using lists, the one would compute, say, max(min(x),quantile(x,.25)-1.5*IQR(x)) for each element of the list and take the minimum over each of these to get the lower bound for ylim (xlim if horizontal=FALSE). Thanks for giving this your consideration. -- Jeff -- Professor J. S. Racine Phone: (905) 525 9140 x 23825 Department of EconomicsFAX:(905) 521-8232 McMaster Universitye-mail: [EMAIL PROTECTED] 1280 Main St. W.,Hamilton, URL: http://www.economics.mcmaster.ca/racine/ Ontario, Canada. L8S 4M4 `The generation of random numbers is too important to be left to chance' __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Can't open files containing russian letters in path (PR#13195)
Full_Name: Arkady Sherman Version: 2.8.0 OS: Windows XP sp3 ntfs file system Submission from: (NULL) (158.195.166.129) Freshly installed version 2.7.2 works well, but 2.8.0 can't open files with russian letters in its names. In error messages the letters are replaced with different symbols. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 2.8.0 qqnorm produces error with object of class zoo?
Based on the quote that Peter gave:
o New generic function xtfrm() as an auxiliary helper for
sort(), order() and rank(). This should return a numeric
vector that sorts in the same way as its input. The default
method supports any class with ==, > and is.na() methods but
specific methods can be much faster.
As a side-effect, rank() will now work better on classed
objects, although possibly rather slowly.
it seems that it was the intention to have rank(x) use x only via xtfrm(x)
but that is not, in fact, how it works as defining xtfrm.zoo still
results in the
discussed error.
On Thu, Oct 23, 2008 at 5:13 AM, Pfaff, Bernhard Dr.
<[EMAIL PROTECTED]> wrote:
> Dear Achim, Gabor, Jeff, Peter and remaining list-subscribers,
>
> first, please accept my apologies for having started this thread. Given the
> avalanche of responses (some off-list) and the associated time stamps, some
> of you have almost pulled an all-nighter about this topic. I might have not
> have started this thread in the first place, if I would have known this.
>
> I agree with Achim's view that a "not working for zoo objects" strategy is
> preferable compared to a "half-working for zoo objects" strategy. I do not
> have either a problem by employing coredata(z) when necessary. Now, Gabor,
> you pointed out nicely that the culprit, namely that order() resides on top
> of xtfrm whereas rank() does not (this was voiced by you in an email to Peter
> and R-Devel, hence I inlucde these recipients again in this thread and the
> reason for doing this is also motivated by the following proposition):
>
> You further pointed out that the problems wrt to rank and zoo-objects could
> be solved if rank() would, like order() does, reside on top of xtfrm. My
> question/proposal would then be to follow this approach, i.e. use xtfrm in
> rank. Now, I am not that deep into R nor an expert to judge whether this
> would cause problems/breaking existing R code in other instances; hence I
> appreciate feedback if this would be a feasible/desirable change in R-Devel.
>
>
> Best,
> Bernhard
>
>>-Ursprüngliche Nachricht-
>>Von: Gabor Grothendieck [mailto:[EMAIL PROTECTED]
>>Gesendet: Donnerstag, 23. Oktober 2008 02:36
>>An: Peter Dalgaard
>>Cc: Pfaff, Bernhard Dr.; [EMAIL PROTECTED]
>>Betreff: Re: [Rd] R 2.8.0 qqnorm produces error with object of
>>class zoo?
>>
>>I don't think its hopeless. order works ok provided the
>>underlying class
>>defines an xtfrm method. I think rank should follow that
>>route too. Its
>>arguably the inconsistency between rank and order (order but not the
>>rank uses xtfrm) that causes the inconsistent behavior between the two.
>>If rank were also built on top of xtfrm then it would work as
>>desired as
>>well.
>>
>>On Wed, Oct 22, 2008 at 5:03 PM, Peter Dalgaard
>><[EMAIL PROTECTED]> wrote:
>>> Gabor Grothendieck wrote:
And one other point.
z <- zoo(1:4)
.gt(z, 1, 2)
fails because z[1] and z[2] are at different time points so
z[1] == z[2]
is logical(0) because when zoo compares objects it aligns them
first.
>>>
>>> Yes, that was the point that I was trying to make. Well,
>>arguably it doesn't
>>> "fail", it just does what it is supposed to do. Things would
>>"work" with [[
>>> or a preceding unclass(z), but that would break comparisons
>>involving, say,
>>> POSIXlt objects. So you're sort of stuck between a rock and
>>a hard place.
>>>
On Wed, Oct 22, 2008 at 2:19 PM, Gabor Grothendieck
<[EMAIL PROTECTED]> wrote:
>
> Yes, I noticed that but rank is not generic. An xtfrm.zoo
> method has been added to zoo on R-Forge but rank still
> fails:
>
>> R.version.string
>
> [1] "R version 2.8.0 Patched (2008-10-21 r46766)"
>>
>> packageDescription("zoo")$Version
>
> [1] "1.5-3"
>>
>> library(zoo)
>> # next line adds xtfrm zoo method
>> xtfrm.zoo <- coredata
>> z <- zoo(1:4)
>> order(z) # ok
>
> [1] 1 2 3 4
>>
>> qqnorm(z) # ok
>> rank(z) # error
>
> Error in if (xi == xj) 0L else if (xi > xj) 1L else -1L :
> argument is of length zero
>
>
(If the MIME type is wrong, then that will happen.)
Anyways, the root cause seems to be the new function
>>.gt() which is
related to
o New generic function xtfrm() as an auxiliary helper for
sort(), order() and rank(). This should return a numeric
vector that sorts in the same way as its input.
>>The default
method supports any class with ==, > and is.na()
>>methods but
specific methods can be much faster.
As a side-effect, rank() will now work better on classed
objects, although possibly rather slowly.
Here, "better" may be in the eyes of the beholder, for
>
Re: [Rd] Possible GPL Violation (Ian Fellows)
The law books were more interesting than the girlfriend...
Ouch!!!
But this does raise one of the issues I have with the GPL and the GPL family of
licenses - the constant confusion around what is and what is not permissible.
It's a gray area (possibly deliberately so), and most coversations end up with
numerous opinions being offered, all prefixed with "IANAL, but..". It's that
and the perception that the GPL ismore about ideology than software that lead
me to prefer BSD-type licenses for pretty much everything.
IANAL, IMHO, etc etc.
Rory
Rory Winston
RBS Global Banking & Markets
Office: +44 20 7085 4476
***
The Royal Bank of Scotland plc. Registered in Scotland No 90312. Registered
Office: 36 St Andrew Square, Edinburgh EH2 2YB.
Authorised and regulated by the Financial Services Authority
This e-mail message is confidential and for use by the=2...{{dropped:22}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 2.8.0 qqnorm produces error with object of class zoo?
Dear Achim, Gabor, Jeff, Peter and remaining list-subscribers,
first, please accept my apologies for having started this thread. Given the
avalanche of responses (some off-list) and the associated time stamps, some of
you have almost pulled an all-nighter about this topic. I might have not have
started this thread in the first place, if I would have known this.
I agree with Achim's view that a "not working for zoo objects" strategy is
preferable compared to a "half-working for zoo objects" strategy. I do not
have either a problem by employing coredata(z) when necessary. Now, Gabor, you
pointed out nicely that the culprit, namely that order() resides on top of
xtfrm whereas rank() does not (this was voiced by you in an email to Peter and
R-Devel, hence I inlucde these recipients again in this thread and the reason
for doing this is also motivated by the following proposition):
You further pointed out that the problems wrt to rank and zoo-objects could be
solved if rank() would, like order() does, reside on top of xtfrm. My
question/proposal would then be to follow this approach, i.e. use xtfrm in
rank. Now, I am not that deep into R nor an expert to judge whether this would
cause problems/breaking existing R code in other instances; hence I appreciate
feedback if this would be a feasible/desirable change in R-Devel.
Best,
Bernhard
>-Ursprüngliche Nachricht-
>Von: Gabor Grothendieck [mailto:[EMAIL PROTECTED]
>Gesendet: Donnerstag, 23. Oktober 2008 02:36
>An: Peter Dalgaard
>Cc: Pfaff, Bernhard Dr.; [EMAIL PROTECTED]
>Betreff: Re: [Rd] R 2.8.0 qqnorm produces error with object of
>class zoo?
>
>I don't think its hopeless. order works ok provided the
>underlying class
>defines an xtfrm method. I think rank should follow that
>route too. Its
>arguably the inconsistency between rank and order (order but not the
>rank uses xtfrm) that causes the inconsistent behavior between the two.
>If rank were also built on top of xtfrm then it would work as
>desired as
>well.
>
>On Wed, Oct 22, 2008 at 5:03 PM, Peter Dalgaard
><[EMAIL PROTECTED]> wrote:
>> Gabor Grothendieck wrote:
>>>
>>> And one other point.
>>>
>>> z <- zoo(1:4)
>>> .gt(z, 1, 2)
>>>
>>> fails because z[1] and z[2] are at different time points so
>>>
>>> z[1] == z[2]
>>>
>>> is logical(0) because when zoo compares objects it aligns them
>>> first.
>>
>> Yes, that was the point that I was trying to make. Well,
>arguably it doesn't
>> "fail", it just does what it is supposed to do. Things would
>"work" with [[
>> or a preceding unclass(z), but that would break comparisons
>involving, say,
>> POSIXlt objects. So you're sort of stuck between a rock and
>a hard place.
>>
>>>
>>> On Wed, Oct 22, 2008 at 2:19 PM, Gabor Grothendieck
>>> <[EMAIL PROTECTED]> wrote:
Yes, I noticed that but rank is not generic. An xtfrm.zoo
method has been added to zoo on R-Forge but rank still
fails:
> R.version.string
[1] "R version 2.8.0 Patched (2008-10-21 r46766)"
>
> packageDescription("zoo")$Version
[1] "1.5-3"
>
> library(zoo)
> # next line adds xtfrm zoo method
> xtfrm.zoo <- coredata
> z <- zoo(1:4)
> order(z) # ok
[1] 1 2 3 4
>
> qqnorm(z) # ok
> rank(z) # error
Error in if (xi == xj) 0L else if (xi > xj) 1L else -1L :
argument is of length zero
>>> (If the MIME type is wrong, then that will happen.)
>>>
>>> Anyways, the root cause seems to be the new function
>.gt() which is
>>> related to
>>>
>>> o New generic function xtfrm() as an auxiliary helper for
>>> sort(), order() and rank(). This should return a numeric
>>> vector that sorts in the same way as its input.
>The default
>>> method supports any class with ==, > and is.na()
>methods but
>>> specific methods can be much faster.
>>>
>>> As a side-effect, rank() will now work better on classed
>>> objects, although possibly rather slowly.
>>>
>>> Here, "better" may be in the eyes of the beholder, for
>>>
>>>
dax[3]==dax[6]
>>> Data:
>>> logical(0)
>>>
>>> Index:
>>> integer(0)
>>>
>>> and accordingly
>>>
>>>
rank(dax)
>>> Error in if (xi == xj) 0L else if (xi > xj) 1L else -1L :
>>> argument is of length zero
>>>
>>> which is the error that you are seeing.
>>>
>>> What to do about it is a bit dubious. Obviously, we
>don't want to
>>> "fix"
>>> .gt() so that it automatically unclasses objects, and I
>assume that
>>> zoo
>>> has its reasons for not wanting to compare series with different
>>> indices. So I suppose that either the user must
>unclass, or zoo define
>>> rank.zoo.
>>>
>> Actually qqnorm does not use rank but it does use order
>and with the
>> xtfrm.zoo method I mentioned qqnorm works with zoo;
