May I suggest a minor addition to the existing help page for ?plotmath, ...
immediately following:
"Note that bold, italic and bolditalic do not apply to symbols, and hence not
to the Greek symbols such as mu which are displayed in the symbol font. They
also do not apply to numeric constants."
Hi,
I can't reproduce the error with a fully updated CentOS 6 with R-core
and R-devel installed from
http://www.nic.funet.fi/pub/mirrors/fedora.redhat.com/pub/epel/6/x86_64/.
Here is the sessionInfo from my CentOS 6 system where installation of
kernlab was successful:
sessionInfo()
R version 3.0.
Hi Dirk,
Thank you very much, your answers are always helpful and point me to the
right direction.
And I also hope the C++11 proposal (
https://stat.ethz.ch/pipermail/r-devel/2013-October/067677.html) will be
approved soon. :-)
Simon
On 11/03/2013 09:54 PM, Dirk Eddelbuettel wrote:
> On 3 Nove
I used to worry about the order of evaluation of on.exit expressions and
thought that maybe we needed named on.exit expression so you could
remove particular on.exit expressions. However, now I think I can almost
always
avoid such considerations and make code clearer by making a new function cal
I'd like to echo Whit's sentiment and hopefully warm up this thread.
C++11's new features and functionality give R users low-level tools (like
threads, mutexes, futures, date-time, and atomic types) that work across
platforms and wouldn't require other external libraries like boost.
Romain, will y
Hi everyone,
I am trying to install kernlab package, but failed many times by now on
CentOS 6 operating system. FYI, I have no problem with this package
installation on windows platform.
Here is the error message:
trying URL 'http://cran.wustl.edu/src/contrib/kernlab_0.9-18.tar.gz'
Content ty
Before trying to submit a patch(*) to on.exit(), I'd like to check
whether there is an interest in enhancing on.exit(..., add=TRUE) such
that it is possible to specify whether the added expression should be
added before or after already recorded expression. The default is now
to add it after, but
Thanks. I should not try adjusting code after some hours of proofreading.
Making that change gave a suitable time difference.
Best, JN
On 13-11-03 03:46 PM, Henrik Bengtsson wrote:
> tfor <- cmpfun(tfor)
> twhile <- cmpfun(twhile)
>
> /Henrik
>
>
> On Sun, Nov 3, 2013 at 11:55 AM, Prof J C
On Sun, Nov 3, 2013 at 2:16 AM, Peter Meilstrup
wrote:
> eval() tends to be able to convince normal functions of where they are
> executing, but primitive functions use different methods to get their
> evaluation context and aren't as easily fooled.
Brilliant wording :)
> It turns out do.call()
tfor <- cmpfun(tfor)
twhile <- cmpfun(twhile)
/Henrik
On Sun, Nov 3, 2013 at 11:55 AM, Prof J C Nash (U30A) wrote:
> My bad to not give details. I'm comparing (though not quite directly) to
> results in the posting
> http://rwiki.sciviews.org/doku.php?id=tips:rqcasestudy.
>
> What prompted the
My bad to not give details. I'm comparing (though not quite directly) to
results in the posting
http://rwiki.sciviews.org/doku.php?id=tips:rqcasestudy.
What prompted the query was a write up of "for" versus "while" loops,
where there was a speedup using compiler for one of these. I had the
example
On 13-11-03 2:15 PM, Prof J C Nash (U30A) wrote:
I had a bunch of examples of byte code compiles in something I was
writing. Changed to 3.0.2 and the advantage of compiler disappears. I've
looked in the NEWS file but do not see anything that suggests that the
compile is now built-in. Possibly I'v
I had a bunch of examples of byte code compiles in something I was
writing. Changed to 3.0.2 and the advantage of compiler disappears. I've
looked in the NEWS file but do not see anything that suggests that the
compile is now built-in. Possibly I've just happened on a bunch of
examples where it doe
On 3 November 2013 at 11:35, Simon wrote:
| Hi,
|
| Recently, I made an R package that used the C++ library Boost.Thread
(http://www.boost.org/doc/libs/1_54_0/doc/html/thread.html) for multithreading.
Previously, I have posted a question at stackoverflow
(http://stackoverflow.com/questions/19
Hi,
Recently, I made an R package that used the C++ library Boost.Thread
(http://www.boost.org/doc/libs/1_54_0/doc/html/thread.html) for multithreading.
Previously, I have posted a question at stackoverflow
(http://stackoverflow.com/questions/19651954/is-it-possible-to-build-an-r-package-which
eval() tends to be able to convince normal functions of where they are
executing, but primitive functions use different methods to get their
evaluation context and aren't as easily fooled. It turns out do.call()
works better on primitive functions, and it will work for "on.exit".
However I wasn't a
16 matches
Mail list logo
