be that some memory is not correctly allocated or
initialised. Or is it something like an object with storage mode
"integer" being passed to a double? But then, why doesn't it show on
linux?
Happy bug hunting. If my guess is correct, then I have no idea how to
track down such th
in which I would do so.
Plenty of users, including me, are happy using the latter forms and,
hence, never have to bother with understanding these implementation
details or have to bother about them.
Your mileage obviously varies, but that is when you have to learn about
these internal details. If you call functions because of their
side-effects, you better learn what the side-effects are exactly.
Cheers,
Berwin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
ternals,
Simon can probably speak for himself, but according to my reading he
has not suggested anything similar to what you suggest he suggested. :)
> and this would be a really bad thing to say..
No problems, since he did not say anything vaguely similar to what you
suggest he said.
Ch
ted
out, this would be quite undesirable from a memory management and
performance point of view. Image that every time you modify a (name)
component of a large object a new copy of that object is created.
> cheers, and thanks for the discussion.
You are welcome.
Cheers,
Berwin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
ther
'names<-' was called using infix syntax or prefix syntax.
Thus, I guess you want to start a discussion with R Core whether it is
worthwhile to change the parser such that it keeps track on whether a
function was used with infix notation or prefix notation and to
provide for most (all?) assignment operators implementations that use
destructive semantics if the infix version was used and always copy if
the prefix notation is used.
Cheers,
Berwin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
) <- 'foo'
once they are parsed, produce exactly the same parse tree and that it
becomes impossible to tell from the parse tree whether originally the
infix syntax or the prefix syntax was used. In fact, the last sentence
in section 10.1.2 strongly suggests to me that the parse tree
, you would either have to
> have the same result in both cases (because the same parse tree is
> interpreted), [...]
Sorry, looks as if I was too fast (again).
'names<-'(x,'foo') should create (more or less) a parse tree equivalent
to that ex
On Fri, 13 Mar 2009 11:43:55 +0100
Wacek Kusnierczyk wrote:
> Berwin A Turlach wrote:
>
> > And it is documented behaviour.
>
> sure!
Glad to see that we agree on this.
> > Read section 2.1.10 ("Environments") in the R
> > Language Definition,
>
improve
your familiarity with the documentation. Simon's answers provided
already more details and I provided you with pointers to what I believe
to be relevant documentation. It's now up to you whether, and how, you
want to digest this information/documentation. And some questions are
not answered by the documentation and you will have to look into the
code to get the answers to those questions.
The ultimate documentation is the source code which is freely available
(not sure whom I am paraphrasing here).
Best wishes,
Berwin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
behaviour could change
without warning.
> i have indeed learned what prefix 'names<-' does and now i know that
> the surprising behaviour is due to the observability of the internal
> optimization.
>
> thanks to simon, peter, and you for your answers which allowed me to
> learn this ugly detail.
You are welcome.
Cheers,
Berwin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
G'day Wacek,
On Sun, 15 Mar 2009 21:01:33 +0100
Wacek Kusnierczyk wrote:
> Berwin A Turlach wrote:
> >
> > Obviously, assuming that R really executes
> > *tmp* <- x
> > x <- "names<-"('*tmp*', value=c("a",&qu
urably with the output of yacas or bc.
The current version of R-devel, with this patch applied, passes "make
check FORCE=FORCE" on my machine. The cut-off point for switching
between the two evaluation schemes was chosen arbitrarily.
I hope this patch will proof to be useful and w
ion about compiled
help, but couldn't find anything that described how to get compiled
help working for packages in a library that is on another drive than R
is. So our question is also whether this is possible?
Thanks for any advice that you might be able to offer.
Cheers,
Berwin
__
>>>>> "BK" == Bernd Kriegstein <[EMAIL PROTECTED]> writes:
BK> void pico ( double *y, int n, int m )
^
Everything is passed from R to C as pointer, so these should be
pointers.
Hope th
I
believe it is a fair price to pay to make my life as developer
easier. ;-))
If you want to distribute binary copies (e.g. for the various version
of Windows that exists) of your package, then you need of course all
the tools that are necessary to handle vignettes.
Cheers,
Berwin
ase is additive or multiplicative).
I didn't check this either, but here are some results on including a 6
page pdf file (extracts from looking at the .tar.gz file produced by
the build process). First, the old solution with a separate PDF file
and a dummy vignette:
drwxr-xr-x berwin/berwin
stions (or following the discussions) on r-help and r-devel? ;-))
More seriously, as Duncan pointed out in his reply, this is a
relatively new feature and few packages support it. But I guess
sooner or later this feature will be advertised more widely, if only
because of it being aga
s[j]', then the 'i'-th element of the result is 'j'. If no
match is found for 'x[i]' in 'levels', then the 'i'-th element of
the result is set to 'NA'.
Note in particular the part on "then the 'i'
case - site - Pop, possum) :
PCA applies only to numerical variables
On my machine, `make check FORCE=FORCE' succeeds with this patch and,
as far as I can tell, no modification of the help pages would be
necessary.
Cheers,
Berwin
Index: src/library/stats/R/princomp.R
+ dist:climb, hills)
Standard deviations:
[1] 29655.128279 3.101566
Rotation:
PC1 PC2
dist -0.000154139 -0.99988
dist:climb -0.99988 0.000154139
Cheers,
Berwin
Index: src/library/stats/R/princomp.R
===
t;
for me). To create PostScript pictures with reasonalbe tight bounding
boxes that are suitable to be included in a LaTeX document you should
specify `paper=special' and then define your plotting area via the
'height' and 'width' argument.
Hope this helps.
Cheers,
dify match.fun() and submitting a patch, I
wanted to ask whether such a change would be accepted? Is there an
argument that I don't see that the first case should always result in
an error and not be silently resolved?
Cheers,
Berwin
__
R-d
nherits) : variable "bar" of mode "function"
was not found
in: match.fun(FUN)
Of course, other people might have other tastes. :)
Please consider applying this patch (or a variation) to r-devel.
Thanks.
Cheers,
Berwin
Index: src/library/base/R/match.fun.R
=
ot;3.75\n"
> sprintf('%1.20g\n', 3.15)
[1] "3.1499112\n"
> sprintf('%1.20g\n', 3.7500)
[1] "3.75\n"
> sprintf('%1.20g\n', 3.1500)
[1] "3.1499112\n"
I know, I shou
t; dat <- c(14, 39, 70, 11, 38, 20, 37, 15, 41, 74, 74, 34, 48, 51)
> stem(dat)
The decimal point is 1 digit(s) to the right of the |
0 | 145
2 | 04789
4 | 181
6 | 044
> stem(dat, scale=2)
The decimal point is 1 digit(s) to the right of the |
1 | 145
2 | 0
3 | 4789
4
. It seems the command 'si$LAPACK <- ""' introduces an extra
line in the output of 'capture.output(si)' which then leads to an error
message in 'which(osi != osi.noLA)'.
Sorry, but I do not have any good idea/suggestion how this issue could
be fixed.
101 - 126 of 126 matches
Mail list logo
