On Tue, 22 Apr 2008, Martin Maechler wrote:
> I've committed my proposal, and am interested in feedback,
> notably additional relevant examples.
I tried the following test and the axes
looked right in 2.6.2 and the r45453
(right after your change to plot.R).
They looked bad (all were 2,4,6,8,10,
On 4/22/2008 1:29 PM, Gabor Grothendieck wrote:
> Its not clear to me at this point what and where the proposed
> or already made change is but here
> is a test that should produce a year/month style rather than
> numeric style X axis:
>
> library(zoo)
> z <- zoo(1:12, as.yearmon(2000 + 1:12/12))
On Tue, Apr 22, 2008 at 1:45 PM, Duncan Murdoch <[EMAIL PROTECTED]> wrote:
> > defined for POSIX and Date classes only.
> >
zoo defines Axis methods for the yearmon and yearqtr classes and potentially
other time/date classes will need Axis methods.
__
R
On 4/22/2008 1:37 PM, Sklyar, Oleg (MI London) wrote:
> To Martin:
>
> sorry, you are right, my fault. Your SVN fix for axisLocal seems to
> solve the problems for numerics.
> However, the problem remains for POSIXct:
>
> plot(Sys.time()+runif(100,1,7200))
>
> (for me it plots time on y correctl
To Martin:
sorry, you are right, my fault. Your SVN fix for axisLocal seems to
solve the problems for numerics.
However, the problem remains for POSIXct:
plot(Sys.time()+runif(100,1,7200))
(for me it plots time on y correctly, but labeling of index x axis and
xlab="Index" are wrong/missing). I w
Its not clear to me at this point what and where the proposed
or already made change is but here
is a test that should produce a year/month style rather than
numeric style X axis:
library(zoo)
z <- zoo(1:12, as.yearmon(2000 + 1:12/12))
plot(z)
On Tue, Apr 22, 2008 at 1:18 PM, Duncan Murdoch <[EM
There seem to be nonlinearities in the time-space continuum, so this
message arrived several hours after Martin's, even though both have the
same timestamp. Please test his, and see if you can break it. I'd
guess not, it looks simple enough, but not too simple.
And for the future:
Please tes
> "OlegS" == Sklyar, Oleg \(MI London\) <[EMAIL PROTECTED]>
> on Tue, 22 Apr 2008 17:34:24 +0100 writes:
OlegS> Hi all:
OlegS> following the previous discussion, it looks like plot(x) with y=NULL
OlegS> still does not work correctly. If one tries for example plot(1:5) it
Full_Name: Russell Lenth
Version: 2.6.2
OS: Windows XP Pro
Submission from: (NULL) (128.255.132.36)
The poly() function allows a higher-degree polynomial than it should, when
raw=FALSE.
For example, consider 5 distinct 'x' values, each repeated twice. we can fit a
polynomial of degree 8:
=
Hi all:
following the previous discussion, it looks like plot(x) with y=NULL
still does not work correctly. If one tries for example plot(1:5) it
works, but already for plot(runif(100)) it does not. I posted the
proposed correction for plot.POSIXct and plot.POSIXlt before. Please
voice your opinio
Hello all,
I hope I have found the right place for my question.
There are different kinds of p-values for one-sided and two-sided
tests, for example mid p-value [1], minimum-likelihood p-value [2] or
conditional two-sided p-value [3].
I tried to find out what kind of p-value is implemented in R w
Ok, so what's wrong with the following fix for plot(x) that would
actually fix what needs to be fixed instead of changing plot.default?
Fix means reverting plot.default in 2.7.0 to what it was (if testing in
2.7.0, copy and paste the OLD plot.default into the .GlobalEnv):
plot.POSIXct <- function(
> "OlegS" == Sklyar, Oleg \(MI London\) <[EMAIL PROTECTED]>
> on Tue, 22 Apr 2008 14:44:01 +0100 writes:
OlegS> So if plot(x) produced rubbish in 2.6.2 in sense of axis formatting
OlegS> would not that mean that either plot.POSIXct or in fact Axis.POSIXct
is
OlegS> incorre
On Tue, Apr 22, 2008 at 9:24 AM, Duncan Murdoch <[EMAIL PROTECTED]> wrote:
> On 4/22/2008 9:08 AM, Sklyar, Oleg (MI London) wrote:
> > Duncan,
> >
> > looking further, what has changed from 2.6.2 into 2.7.0 are the
> > following two lines in plot.default, which I think were logical before
> > and a
So if plot(x) produced rubbish in 2.6.2 in sense of axis formatting
would not that mean that either plot.POSIXct or in fact Axis.POSIXct is
incorrectly defined? I will have a look at those to see if I can find a
fix.
Anyway, it does not seem to have any sense to argue any further, because
for me d
On 4/22/2008 9:08 AM, Sklyar, Oleg (MI London) wrote:
> Duncan,
>
> looking further, what has changed from 2.6.2 into 2.7.0 are the
> following two lines in plot.default, which I think were logical before
> and are not really logical now:
I believe it is behaving as documented now, so the behavio
Lines 69/70 in plot.R of graphics:
xy$x and xy$y should have stayed as x and y
Dr Oleg Sklyar
Technology Group
Man Investments Ltd
+44 (0)20 7144 3803
[EMAIL PROTECTED]
> -Original Message-
> From: Gabor Grothendieck [mailto:[EMAIL PROTECTED]
> Sent: 22 April 2008 14:12
> To: Sklyar, O
This also affects Axis.yearmon and Axis.yearqtr in the
zoo package which worked in R 2.6.2 and now don't work
properly. It seems more logical to define plot.whatever
to handle the object in question, i.e. we do define plot.zoo,
whereas only the Axis method ought to be required for the
X and Y coo
Duncan,
looking further, what has changed from 2.6.2 into 2.7.0 are the
following two lines in plot.default, which I think were logical before
and are not really logical now:
plot.R: plot.default (2.6.2):
if (axes) {
localAxis(x, side=1, ...)
localAxis(y, side=2, ...)
}
plot.R: p
Thanks Duncan,
this might explain why Axis.MyClass is never called.
However, it is really not only illogical to define plot.MyClass instead
of Axis.MyClass if the only thing I want is formatting of the axis, but
it is also broken in R 2.7.0 and here is why.
Let's forget about MyClass and take PO
On 22/04/2008 7:25 AM, Sklyar, Oleg (MI London) wrote:
> Following my previous post on S3 method despatch, I put debug messages
> in the code of Axis, Axis.default and plot.default in graphics/R/axis.R
> and graphics/R/plot.R to print the class of x, at and y on plot. After
> recompiling R, what I
Following my previous post on S3 method despatch, I put debug messages
in the code of Axis, Axis.default and plot.default in graphics/R/axis.R
and graphics/R/plot.R to print the class of x, at and y on plot. After
recompiling R, what I see is that x *lost* its class attribute (at least
for classes
Full_Name: Liqun Xing
Version: 2.6.2
OS: Solaris 9
Submission from: (NULL) (76.182.91.82)
When first time launch X11(), it was fine. However, when closed the X11 windon
by clicking the close button, or closed it off by command Dev.off() and launched
the X11() again, got segfault, and asking for e
Dear developers:
I have observed a change in the behaviour of S3 method despatch (as I
guess related to namespaces) between 2.6.2 and yesterday's 2.7.0 RC and
would be grateful if you could comment on that:
the 'Axis' function in the 'graphics' namespace calls
UseMethod("Axis",x), internally to d
>> I definitely do agree with you.
>> Basically, I see two different ways to proceed:
>>
>>1. one could first check if there are any 0 in the vector and then
>> return 0 without computing the product
>>
>
> That would fail for prod(0,Inf), which should return the same
> thing as 0*I
Interesting problem this.
My take on it would be that the "true" value depends
on how fast the "0" approaches 0 and how fast the "n"
approaches infinity.
Consider
f1 <- function(n){prod(1/n , seq_len(n))}
f2 <- function(n){prod(1/factorial(n) , seq_len(n))}
f3 <- function(n){prod(n^(-n) , seq_le
26 matches
Mail list logo
