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
Got it. Thank you all.
On Mon, Mar 16, 2009 at 4:39 PM, Stavros Macrakis wrote:
> The factor approach is horrifically ugly and dangerous.
>
> Even if it didn't have the extraordinarily poor behavior documented
> below, it simply isn't well-defined what it should do. The explicit
> approximation
I run R on MS Windows. In R2.9.0dev, I type ?base to get "R help for package
base" to open. I then select ".First" from the list of contents, getting a page
headed: "Initialization at Start of an R Session". About half way down there is
a sentence:
The command-line flag --vanilla implies --no-
Hi
> I have seen a lot of problems from people trying to compile R with
> MKL. So I am writing my experience in case it helps and to ask one
> question. I installed R-2.8.1.patched in Ubuntu 9.04 (gcc 4.3.3) using
> MKL 10.1.1.019.
Do you use gcc and gfortran?
> I configured correctly (following
The factor approach is horrifically ugly and dangerous.
Even if it didn't have the extraordinarily poor behavior documented
below, it simply isn't well-defined what it should do. The explicit
approximation route is far far preferable in every way: more
predictable, more controllable, and even (th
I have a matrix whose columns were filled with values which were functions
of cvseq<-seq(.2,.3,by=.1) (and a row value of mode integer). To do a lookup
for cv=.3 later, I wanted to match(.3,cvseq), which gave me NA, hence my
question. I thought R would match .3 in cvseq within .Machine$double.eps,
Petr Savicky wrote:
> 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=
Hi,
I receive the following error when I try to install cluserSim package on
Sparc Solaris 10 using Sun Studio 12:
I have compiled and installed a 64 bit version of R.
CC -xtarget=native64 -I/opt/R-2.8.1/lib/R/include
-I/opt/SUNWhpc/HPC8.1/sun/include -I/usr/sfw/include -I/opt/csw/include
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
rgl_0.84-1.tar.gz compiled and installed successfully on our system.
Solaris 10 sparc, Sun Studio 12.
Thank you very much!
--
Mohammad Nikseresht
Duncan Murdoch wrote:
On 3/16/2009 11:38 AM, Mohammad Nikseresht wrote:
I downloaded source tarball this morning from:
http://cran.at.r-project.or
On 3/16/2009 11:38 AM, Mohammad Nikseresht wrote:
I downloaded source tarball this morning from:
http://cran.at.r-project.org/
It is rgl_0.84.tar.gz but it does contain a math.h!
where can I find version 0.84-1?
It's on R-forge. You can download it as
http://r-forge.r-project.org/src/contrib/
Thanks for the report. I meant to have R_isMissing always return
FALSE for active binding but had it returning TRUE intead. Fixed now
in R-devel.
luke
On Sun, 15 Mar 2009, Roger D. Peng wrote:
The following code produces an error in current R-devel
f <- function(value) {
if(!missing(
I downloaded source tarball this morning from:
http://cran.at.r-project.org/
It is rgl_0.84.tar.gz but it does contain a math.h!
where can I find version 0.84-1?
Thanks
--
Mohammad Nikseresht
Duncan Murdoch wrote:
On 3/16/2009 9:31 AM, Mohammad Nikseresht wrote:
Hi,
Unfortunately I still get
Well, first of all, seq(from=.2,to=.3) gives c(0.2), so I assume you
really mean something like seq(from=.2,to=.3,by=.1), which gives
c(0.2, 0.3).
%in% tests for exact equality, which is almost never a good idea with
floating-point numbers.
You need to define what exactly you mean by "in" for flo
Duncan Murdoch wrote:
> On 3/16/2009 9:36 AM, 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
>> Yet
>>> 0.3 %in% c(.2,.3)
>> [1] TRUE
>> For arbitrary sequences, this "invisible .3" has been problema
In addition to the work Luke is doing there is Ra:
http://www.milbo.users.sonic.net/ra
On Sun, Mar 15, 2009 at 11:25 AM, Florian Gross wrote:
> Hi everybody,
>
> I'm currently working towards my Master's degree as a student of Computer
> Science at the University of Saarbrücken and highly intere
On 3/16/2009 9:36 AM, 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
Yet
0.3 %in% c(.2,.3)
[1] TRUE
For arbitrary sequences, this "invisible .3" has been problematic. What is
the best way to work around thi
On 3/16/2009 9:31 AM, Mohammad Nikseresht wrote:
Hi,
Unfortunately I still get the same errors:
CC -xtarget=native64 -I/opt/R-2.8.1/lib/R/include -I/usr/sfw/include
-I/opt/csw/include -DHAVE_PNG_H -I/usr/include/libpng12 -DHAVE_FREETYPE
-Iext/ftgl -I/usr/sfw/include/freetype2 -I/usr/sfw/inclu
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
Yet
> 0.3 %in% c(.2,.3)
[1] TRUE
For arbitrary sequences, this "invisible .3" has been problematic. What is
the best way to work around this?
Thank you.
Dan
[[alternative HTML
Hi,
Unfortunately I still get the same errors:
CC -xtarget=native64 -I/opt/R-2.8.1/lib/R/include -I/usr/sfw/include
-I/opt/csw/include -DHAVE_PNG_H -I/usr/include/libpng12 -DHAVE_FREETYPE
-Iext/ftgl -I/usr/sfw/include/freetype2 -I/usr/sfw/include -Iext
-I/opt/SUNWhpc/HPC8.1/sun/include -I/usr
There is ongoing work on developing a byte code compiler for R. A
preliminary implementation is available and the corresponding byte
code engine is part of the R distribution. The initial engine has
been a useful proof of concept but is in the process of being
rewritten from scratch, in part wit
Dear R developers,
I observed that the html help page index entry "Read overview or browse
directory" for package vignettes is missing in recent R-devel.
This happened on two independent computers (WinXP Prof. SP3, German)
with R-devel compiled from sources svn rev. 48125 resp. 48128
It's the
David,
2.3.1 is a bit old to be reporting bugs -- we do ask people to check that their
problem is still present in a contemporary version of R. However, your data do
still give the same output in R 2.7.2 (which is not current, but was current
less than a year ago).
I've tidied up the code to
Please report bugs in packages to the package maintainer, NOT to r-bugs.
-thomas
On Sun, 15 Mar 2009 sar...@um.ac.ir wrote:
Full_Name: Majid Sarmad
Version: 2.8.1
OS: Linux / Windows
Submission from: (NULL) (194.225.128.135)
With thanks to Alberto Viglione, in HW.tests function of hom
Thomas Lumley wrote:
>
> Wacek,
>
> In this case I think the *tmp* dates from the days before backticks,
> when it was not a legal name (it still isn't) and it was much, much
> harder to use illegal names, so the collision issue really didn't exist.
>
thanks for the explanation.
> You're right ab
somewhat one the side,
l = list(1)
l[[2]]
# error, index out of bounds
l[2][[1]]
# NULL
that is, we can't extract from l any element at an index exceeding the
list's length (if we could, it would have been NULL or some sort of
_NA_list), but we can extract a sublist at an
On Sun, 15 Mar 2009, Wacek Kusnierczyk wrote:
Stavros Macrakis wrote:
Well, that's one issue. But another is that there should be a
specification addressed to users, who should not have to understand
internals.
this should really be taken seriously.
Well, the lack of such a specificatio
Berwin A Turlach wrote:
>
>> '*tmp*' = 0
>> `*tmp*`
>> # 0
>>
>> x = 1
>> names(x) = 'foo'
>> `*tmp*`
>> # error: object "*tmp*" not found
>>
>> `*ugly*`
>>
>
> I agree, and I am a bit flabbergasted. I had not expected that
> something like this would happen and I am indeed not aware of anyth
Wacek,
In this case I think the *tmp* dates from the days before backticks, when it
was not a legal name (it still isn't) and it was much, much harder to use
illegal names, so the collision issue really didn't exist.
You're right about the documentation.
-thomas
On Sun, 15 Mar 2009,
On Sun, 15 Mar 2009, Stavros Macrakis wrote:
The semantics of [ and [[ don't seem to be fully specified in the
Reference manual. In particular, I can't find where the following
cases are covered:
cc <- c(1); ll <- list(1)
cc[3]
[1] NA
OK, RefMan says: If i is positive and exceeds length(x
30 matches
Mail list logo
