Robin Hankin
# https://stat.ethz.ch/pipermail/r-help/2005-June/074001.html by Heather
Turner
# https://stat.ethz.ch/pipermail/r-devel/2007-June/046217.html by Ben Bolker
# with some further modifications by Petr Savicky
sweep <- function(x, MARGIN, STATS, FUN = "-",
parameter of optim could control, whether
the function to be optimized is fn or the C entry point.
Petr Savicky.
> I don't have an example of that but that does not make it less
> desirable. If one wants to use method 1, 2 or 3 then one can
> use optim with a method= but if one wants to
several, if derivatives
are also available), similar as in the user defined random number
generator. Then, a parameter of optim could control, whether
the function to be optimized is fn or the C entry point.
Petr Savicky.
On Sat, Aug 04, 2007 at 06:56:47PM -0400, Gabor Grothendieck wrote:
>
Thank you for your response. This is a good idea. Although I use
my own packages, some of them using other R API's, I missed
the optimization ones. Thanks again.
Petr Savicky.
On Mon, Aug 06, 2007 at 07:16:11AM -0700, Thomas Lumley wrote:
> On Mon, 6 Aug 2007, Petr Savicky wrote:
>
the link
http://www.cs.cas.cz/~savicky/R-devel/patch-sweep
which is an identical copy.
Petr Savicky.
--- R-devel_2007-08-06/src/library/base/R/sweep.R 2007-07-27
17:51:13.0 +0200
+++ R
with "L-BFGS-B".
[snip]
Could you also include a script, which reproduces the problem? Just
to see under which conditions the problem occurs and how it
looks like exactly.
Petr Savicky.
__
R-devel@r-project.org mailing list
https://stat.ethz
other hand, factors are not typical in cases,
where paste is used to produce a readable message. Hence, it
could be possible to have is.na(u[i]) for those i, for which
some of the vectors v1, ..., vn in
u <- paste(v1,,vn)
is a factor and has NA at i-th position.
Petr Savicky.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
y # [1] NA
identical(x,y) # [1] TRUE
In my opinion, NaN and as.double(NA) should be distinguished as the
help page suggests.
Tested under R version 2.5.1 Patched (2007-08-19 r42638) on Linux (CPU Xeon).
Petr Savicky.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
-1)
1/Im(1/z) # [1] -Inf
z <- complex(real = -1, imaginary = -0)
1/Im(1/z) # [1] -Inf (*)
Platform 3 (Xeon):
z <- complex(real = -1)
1/Im(1/z) # [1] -Inf
z <- complex(real = -1, imaginary = -0)
1/Im(1/z) # [1] Inf (*)
So, besides the f
> > dump("y", file="y.R")
> > remove("y")
> > source("y.R")
> > y
> [1] 0
> > 1/y
> [1] Inf
It works the same in my installations. Moreover, "save" preserves
-ve zeros even with ascii=TRUE, which is more sim
> I think that the problem is due to how double number are store by the C
> compiler.
Not C compiler, but the hardware.
Petr Savicky.
> If it may be usefull, I have written to small function (Unique and isEqual)
> which can deal with this problem of the double numbers.
>
> I als
ion may be add. In my opinion,
the best way to do this could be to add a comment to RNG_Init in src/main/RNG.c,
saying, for example:
If you need to undo the initial scrambling in user_unif_init, use
seed = 3602842457U * (seed - 2358491998U);
Petr Savicky.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
afford this due to memory.
So, I can only stop if NAMED is not 0.
I appreciate, if anybody could give me advice on the above things.
Petr Savicky.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
u) # 1 (OK)
nrow(u)
.Call("getnamed",u) # 2 (why?)
u <- matrix(as.integer(1),nrow=5,ncol=3) + as.integer(0)
.Call("getnamed",u) # 1 (OK)
ncol(u)
.Call("getnamed",u) # 2 (so, ncol does the same)
Is this a bug?
Petr Savicky.
5g
gc() # 774m
So, the object duplicates, but nothing more.
The main part of my previous email (question concerning
a possible bug in the behavior of nrow(a) and ncol(a))
remains open.
Petr Savicky.
__
R-devel@r-project.org mailing list
https:/
a <- matrix(1:6,nrow=2)
nrow(a,a) # Error in nrow(a, a) : unused argument(s) (1:6)
dim(a,a) # Error: 2 arguments passed to 'dim' which requires 1
May be, also other solutions exist.
Petr Savicky.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
n NAMED may be dropped from 2 to 1? How much would this increase
the complexity of gc()?
Thank you in advance for your kind reply.
Petr Savicky.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
rol of duplication could help.
The tools may be, for example, some function, which allows a simple
query to the NAMED status of a given object on R level and
modifying some of the built-in functions to be more careful with
NAMED attribute. A possible strengthening of gc() would, of course, be
very useful here. I think about an explicit use of it, not about
the automatical runs. So, for safety reasons, the "NAMED reduction"
could be done by a different function, not the default gc() itself.
Petr Savicky.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
5
[3,] 2147483646.0 2147483646 2147483646
[4,] 2147483646.5 2147483646 2147483646
[5,] 2147483647.0 2147483647 2147483647
[6,] 2147483647.5 2147483647 2147483647
[7,] 2147483648.0 NA NA
Petr Savicky.
__
R-devel@r-project.o
mp; 0x8000) != 0);
+ if(!notallzero)
+ for (j = 2; j <= 624; j++)
if(RNG_Table[RNG_kind].i_seed[j] != 0) {
notallzero = 1;
break;
Petr Savicky.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
nd the patch to R-devel, if the proposed
solution is of the sort, which could be considered.
Petr Savicky.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Hi All:
The p-value of Spearman's rank correlation test is calculated using algorithm
AS 89. However, the way how AS 89 is used incures error, which may be an order
of magnitude larger than the error of the original algorithm.
In case of no ties AS 89 expects an even value of the statistic
S =
Hi All:
help(cor.test) claims
For Spearman's test, p-values are computed using algorithm AS 89.
Algorithm AS 89 was introduced by the paper
D. J. Best & D. E. Roberts (1975), Algorithm AS 89: The Upper Tail
Probabilities of Spearman's rho. Applied Statistics, Vol. 24, No. 3, 377-379.
Table
> > seq(0,1,0.1)==0.4
> [1] FALSE FALSE FALSE FALSE TRUE FALSE FALSE FALSE FALSE FALSE FALSE
> > seq(0,1,0.1)==0.6
> [1] FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE
> > seq(0,1,0.1)==0.8
> [1] FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE TRUE FALSE FALSE
>
> What is w
On Mon, Mar 16, 2009 at 06:36:53AM -0700, Daniel Murphy wrote:
> Hello:I am trying to match the value 0.3 in the sequence seq(.2,.3). I get
> > 0.3 %in% seq(from=.2,to=.3)
> [1] FALSE
As others already pointed out, you should use seq(from=0.2,to=0.3,by=0.1)
to get 0.3 in the sequence. In order to
On Mon, Mar 16, 2009 at 07:39:23PM -0400, Stavros Macrakis wrote:
...
> Let's look at the extraordinarily poor behavior I was mentioning. Consider:
>
> nums <- (.3 + 2e-16 * c(-2,-1,1,2)); nums
> [1] 0.3 0.3 0.3 0.3
>
> Though they all print as .3 with the default precision (which is
> normal and
On Tue, Mar 17, 2009 at 10:15:39AM +0100, Wacek Kusnierczyk wrote:
...
> there's one more curiosity about factors, in particular, ordered factors:
>
> ord <- as.ordered(nums); ord
> # [1] 0.300 0.3 0.3
> 0.300
> # Levels: 0.30
On Tue, Mar 17, 2009 at 10:04:39AM -0400, Stavros Macrakis wrote:
...
> 1) Factor allows repeated levels, e.g. factor(c(1),c(1,1,1)), with no
> warning or error.
Yes, this is a confusing behavior, since repeated levels are never meaningful.
> 2) Even from distinct inputs, factor of a numeric vect
On Tue, Mar 24, 2009 at 02:45:57PM +0100, Uwe Ligges wrote:
> >gives the custom error message "nruns must be a power of 2.", which is
> >generated in the first check within function FrF2:
> >
> >if (!is.null(nruns)){
> > k <- floor(log2(nruns))
> > if (!2^k==nruns) stop("nruns must
On Tue, Mar 24, 2009 at 07:41:31AM -0700, Ulrike Grömping wrote:
> > Probably, k is needed also later. Assumig that 2^k works correctly,
> > the following could be sufficient
> >
> >if (!is.null(nruns)){
> > k <- round(log2(nruns))
> > if (!2^k==nruns) stop("nruns must be a power o
On Wed, Apr 22, 2009 at 04:30:36PM -0400, Stavros Macrakis wrote:
[snip]
> Now consider 1e40, which has the property
> that floor(x)==x==ceiling(x), which you might think characterizes an
> integer; but it also has the property that x+1 == x. Similarly for
> 1/3 * 1e40.
[snip]
The number 1/3 * 1
On Thu, Apr 23, 2009 at 11:37:37AM +0200, Martin Maechler wrote:
[snip]
> TP> To test whether a value is an integer value, you can so something
> like this:
>
> >> is.wholenumber <- function(x, tolerance = .Machine$double.eps^0.5)
> TP> return(abs(x - round(x)) < tolerance)
> >>
In R-2.10.0, the development version, function as.factor() uses 17 digit
precision for conversion of numeric values to character type. This
is very good for the consistency of the resulting factor, however,
i expect that people will complain about, for example, as.factor(0.3)
being
[1] 0.2999
On Mon, May 04, 2009 at 05:39:52PM +0200, Martin Maechler wrote:
[snip]
> Let me quickly expand the tasks we have wanted to address, when
> I started changing factor() for R-devel.
>
> 1) R-core had unanimously decided that R 2.10.0 should not allow
>duplicated levels in factors anymore.
>
>
On Mon, May 04, 2009 at 07:28:06PM +0200, Peter Dalgaard wrote:
> Petr Savicky wrote:
> > For this, we get
> >
> > > convert(0.3)
> > [1] "0.3"
> > > convert(1/3)
> > [1] "0." # 16 digits suf
On Tue, May 05, 2009 at 11:27:36AM +0200, Peter Dalgaard wrote:
> I know. The point was rather that if you are not careful with rounding,
> you get the some of the bars wrong (you get 2 or 3 small bars very close
> to each other instead of one longer one). Computed p values from
> permutation tests
101 - 136 of 136 matches
Mail list logo
