Dear list,
I installed R 2.3.1 on a solaris machine. The first time, I used the
wrong option --enable-shlib, the installation went smoothly (glitch
1), but of course did not generate libR.so. So, I ran ./configure
again with --enable-R-shlib, make and make install went well but still
there was no
> Why guess? There are accurate statements in the R-admin manual,
I read the manual 2 years ago, and the info I got was still correct.
> and the RH RPM change was discussed on this list in 2006:
> https://stat.ethz.ch/pipermail/r-devel/2006-January/036118.html
I simply do not know RPMs have bee
> then either build your own with correct options or talk to your
> distribution's packaging team.
It seems that my knowledge about this option is outdated. When I
first encountered this problem two years ago, the R/rpm distribution
came with no libR.so. I was told that --enable-R-shlib would lea
> That is not true, almost all binaries come with R as shared library -
> it is in fact the default on Mac OS X and Windows. Most Linux
> distributions provide a shared library binary as well.
This would be good news. But at least, under linux,
./configure --help
--enable-R-shlibbuild t
Dear list,
To operate R from python via a Python package rpy, R has to be
compiled with --enable-R-shlib. This is troublesome since none of the
binary distributions (except for windows?) is built with this option
so rpy users have to build R from source. This can be quite a
challenge, especially
> I was wondering
> what is the difference between rpy and RSPython.
The main difference is that rpy does one-way communication, is simpler
than RSPython, than is easier to use.
> So I have a question for you - why rpy instead of RSPython? Have you
> tried both, and can you give a comparison of p
On 1/9/06, Prof Brian Ripley <[EMAIL PROTECTED]> wrote:
> How is Rpy calling R? Presumably R is running single-threaded, and the
> problem is likely to be that Rpy is using blocking I/O on the R process
> and hence blocking the GUI callbacks that drive the window.
>
> The not-so-simple answer is n
Dear list,
Rpy is a python module that provides python interface to R. The
following simple commands
>>> from rpy import *
>>> r.plot(0)
is supposed to create a window that displays the result of plot(0).
However, we observe that
1. Under *nix, rpy+R+python work as expected
2. Under windows, p
This problem was brought up by Xu Neng <[EMAIL PROTECTED]> in the rpy-list.
Remember the old times when computer guys thought the year 2000 was
too far away to be worried? In my case, the dates like "-06-6" and
"-09-09" are used as special missing codings for dates.
If R cannot handle d
> Well, bug, if you really want to call it a bug that you cannot represent
> the year . ;-)
So I guess we need a warning message and a line in help(as.Date)?
Bo
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Under linux and windows,
> as.Date("-06-06")
[1] "-06-06"
> as.Date("-07-07")
[1] "1970-01-01"
>
Feature? Bug? help(as.Date) does not mention this case.
Bo.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-dev
> You chose to report just one extremely favourable example, < ignore>
> I do think you are being `careless with the truth'.
I chose to report whatever I got and whatever I felt the result was. It was not
a scientific report and it was up to you (the R-team) to validate my result and
make further
> It seems the distribution used for your tests is maximally favourable to
> your proposal (not uncommon in papers, but not very honest).
I did not have time to do a thorough test. I was simply reporting what
I had done so any implied dishonesty is unfair to me.
> Changing how this is done wil
> There was a couple of posts about this recently:
>
> https://stat.ethz.ch/pipermail/r-devel/2005-April/subject.html
>
I am too new to this list to see these discussions. They are quite interesting!
Certainly I was not aware of the big differences between C++/Python
OOP and S3/S4 OOP. This exp
> SWIG is a very nice idea. ...
SWIG is a wonderful tool that makes wrapping C++ code super-easy. I
can write pure C++ code and even test them by writing a main()
function. Then, using a simple interface file, all my C++ classes
becomes Python (shadow) classes like magic. It will take much more
t
> > * Wrap C++ class hierarchy. Virtual functions need to be supported.
> > (SWIG can generate Python shadow classes that behave almost exactly
> > like the underlying C++ classes)
>
> This is hard to do in R, because the R object model is quite different
> from that of C++ (whereas Python's is mo
by objects, not functions. (I notice that manuals of
R libraries are simple function references.)
Many thanks in advance.
--
Bo Peng
Department of Statistics
Rice University
http://bp6.stat.rice.edu:8080/
__
R-devel@r-project.org mailing list
https
tion. Since this method is the only one mentioned in Knuth's
book, I have no
idea about other alternatives.
Attached is a slightly improved version of the alias method. It may be
helpful to people
having similar problems.
Thanks.
--
Bo Peng
Department of Statistics
Rice University
d the new function. I will do so if you
(the developers) think that this has the potential to be incorporated
into R.
Thanks.
Bo Peng
Department of Statistics
Rice University
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
On 6/21/05, Vadim Ogranovich <[EMAIL PROTECTED]> wrote:
> In his "Introduction to Probability Models" Sheldon Ross describes (sec
> 11.4.1, 8th edition) the alias method for such weighted sampling.
> It is based on some decomposition of the original distribution (the
> weights) into a mixture of tw
Dear list,
A while ago, Vadim asked opinions on improving efficiency of sample()
with prob, e.g. sample with replacement with weight. (
https://stat.ethz.ch/pipermail/r-devel/2004-September/030844.html ) He
did not post what he ended up with this problem though.
I am having exactly the same prob
21 matches
Mail list logo