Prof Brian Ripley wrote:
>You may if you prefer use Visual C++ to make the DLLs (unless they use
>Fortran source!). First build the import library Rdll.lib by
>
> make R.exp
> lib /def:R.exp /out:Rdll.lib
>
>
>
This requires building R from the source. There are a lot of things
Hi,
Given factors x and y, c(x,y) does not seem to return a useful result :
> x
[1] a b c d e
Levels: a b c d e
> y
[1] d e f g h
Levels: d e f g h
> c(x,y)
[1] 1 2 3 4 5 1 2 3 4 5
>
Is there a case for a new method c.factor as follows? Does something
similar exist already? Is there a bette
Hi,
I need to collapse a list into a string and then reparse it back into the
list. Normally when I need to do this I simply use write.csv and
read.csv, but I need to do this in memory within R rather than writing out
to file. Are there any bespoke commands that any knows of that does
so
On Tuesday 14 November 2006 12:00 pm, Tom McCallum wrote:
> Hi,
>
> I need to collapse a list into a string and then reparse it back into the
> list. Normally when I need to do this I simply use write.csv and
> read.csv, but I need to do this in memory within R rather than writing out
> to file.
This comes from a posting on R-help where
the poster found that str(.) didn't work on
/ 1
even though / 1 looked like a valid "its" object.
Here is a very short script demonstrating the issue :
##--
setClass("mynum", representation = "numeric")
x <- new("mynum", pi)
This approach won't work in very many cases (but then nor will write.csv).
The safest way I know is to use serialize() and unserialize(). Next to
that, deparse(control="all") and parse(text=) are quite good and give a
human-readable character representation.
If fidelity is not the main issue,
"Tom McCallum" <[EMAIL PROTECTED]> writes:
> Hi,
>
> I need to collapse a list into a string and then reparse it back into the
> list. Normally when I need to do this I simply use write.csv and
> read.csv, but I need to do this in memory within R rather than writing out
> to file.
> Are
On Tue, 2006-11-14 at 11:51 -0600, Marc Schwartz wrote:
> On Tue, 2006-11-14 at 16:36 +, Matthew Dowle wrote:
> > Hi,
> >
> > Given factors x and y, c(x,y) does not seem to return a useful result :
> > > x
> > [1] a b c d e
> > Levels: a b c d e
> > > y
> > [1] d e f g h
> > Levels: d e f g h
Well, R has managed without a factor method for c() for most of its decade
of existence (not that it originally had factors as we know them).
I would argue that factors are best viewed as an enumeration type, and
anything which silently changes their level set is a bad idea. I can see
a case f
On Tue, 2006-11-14 at 16:36 +, Matthew Dowle wrote:
> Hi,
>
> Given factors x and y, c(x,y) does not seem to return a useful result :
> > x
> [1] a b c d e
> Levels: a b c d e
> > y
> [1] d e f g h
> Levels: d e f g h
> > c(x,y)
> [1] 1 2 3 4 5 1 2 3 4 5
> >
>
> Is there a case for a new m
I have made the change to the threshold calculation (R_VSize instead
of R_NSize for the vector heap) in R-patched and R-devel. Seems to
have negligible impact on the standard tests and VR scripts.
Best,
luke
On Thu, 9 Nov 2006, Vladimir Dergachev wrote:
> On Thursday 09 November 2006 12:21 pm,
On Tue, 14 Nov 2006, Prof Brian Ripley wrote:
> Well, R has managed without a factor method for c() for most of its decade
> of existence (not that it originally had factors as we know them).
>
> I would argue that factors are best viewed as an enumeration type, and
> anything which silently chang
On Tuesday 14 November 2006 12:28 pm, Prof Brian Ripley wrote:
> This approach won't work in very many cases (but then nor will write.csv).
>
> The safest way I know is to use serialize() and unserialize(). Next to
> that, deparse(control="all") and parse(text=) are quite good and give a
> human-r
Hi,
I just updated to svn rev 39899 on a SuSE 10.1/x86_64 system and I get
the following error when configuring R:
checking for X... libraries /usr/X11R6/lib64, headers /usr/X11R6/include
checking for gethostbyname... yes
checking for connect... yes
checking for remove... yes
checking for shmat..
Apparently Scheme is clever and can turn certain apparently recursive
function calls into into non-recursive evaluations.
Does R do anything like that? I could find no reference to it in the
language manual.
What I'm wondering is whether there are desirable ways to express
recursion in R.
Thank
See:
http://finzi.psych.upenn.edu/R/Rhelp02a/archive/73651.html
On 11/14/06, Ross Boylan <[EMAIL PROTECTED]> wrote:
> Apparently Scheme is clever and can turn certain apparently recursive
> function calls into into non-recursive evaluations.
>
> Does R do anything like that? I could find no refe
Hi,
I would like to be able to create new environments from package C
code. AFAICT, this isn't allowed since both NewEnvironment and
R_NewHashedEnv are declared in Defn.R.
If exposing this isn't controvertial, I would submit a patch.
However, I'm not sure where the declarations should go (Rdefin
On Tue, 14 Nov 2006, Vladimir Dergachev wrote:
> On Tuesday 14 November 2006 12:28 pm, Prof Brian Ripley wrote:
>> This approach won't work in very many cases (but then nor will write.csv).
>>
>> The safest way I know is to use serialize() and unserialize(). Next to
>> that, deparse(control="all"
On Tue, 14 Nov 2006, Seth Falcon wrote:
> Hi,
>
> I would like to be able to create new environments from package C
> code. AFAICT, this isn't allowed since both NewEnvironment and
> R_NewHashedEnv are declared in Defn.R.
NewEnvironment is currently exposed as Rf_NewEnvironment.
R_NewHashedEnv i
Full_Name: Jonathan Tuke
Version: 2.4.0
OS: Mac OS X 10.4.8
Submission from: (NULL) (203.173.46.189)
I am writing C code to implement in R. I am using R CMD SHLIB and then
dyn.load("file.so"). The function I then call with .C("function"). Since I
installed the latest R version, I have found that
20 matches
Mail list logo
