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_len(n))}
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*Inf=NaN.
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
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
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
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 see
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:
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
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, Oleg
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 behaviour
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
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 are not
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 incorrectly defined? I
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 -
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
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:
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
OlegS works,
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
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
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
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 correctly, but
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.
__
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, 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,
24 matches
Mail list logo
