[Rd] R v2.1.0 patched (>2005-05-09) for Windows?
I'm trying to troubleshoot a case where R crashes on Windows. It does
not occur at all with my R v2.1.0 patched (2005-05-09), but happens on R
v2.1.1 (patched or non-patched) in many different cases. The R
v2.2.0dev (2005-07-15) also got this problem (although it won't crash on
the below example). I previously reported this
(https://stat.ethz.ch/pipermail/r-devel/2005-June/033772.html) and
Duncan Murdoch kindly offered to look into the problem, but it is
tricky. Now I would like to track down in what patched R v2.1.0 the
problem first occurs and are now looking for reports from newer version,
but pre-Rv2.1.1.
If you've got R v2.1.0 patched for Windows *after 2005-05-09*, could you
please try the following in that version of R?
install.packages("R.oo")
library(R.oo)
author <- "dummy"
rdocFile <- system.file("misc", "Exception.R", package="R.oo")
cat("# Empty example code\n", file="Exception.Rex")
Rdoc$compile(rdocFile, destPath=tempdir())
print("successful!")
If you see "successful!", that version is "ok", otherwise R will crash
(or alternatively incorrectly complain about an invalid regular
expression; rerun and it will crash the 2nd time). I would appreciate a
lot if you report to me what you get and what is your version of R?
Thanks a lot!
Note that this is most likely *not* due to R.oo (no native code) - my
wild guess is that it has to do with a memory leak in the code for
environments or regular expressions.
Thanks
Henrik Bengtsson
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R v2.1.0 patched (>2005-05-09) for Windows?
> "HenrikB" == Henrik Bengtsson <[EMAIL PROTECTED]>
> on Fri, 15 Jul 2005 10:01:05 +0200 writes:
HenrikB> I'm trying to troubleshoot a case where R crashes on Windows. It
does
HenrikB> not occur at all with my R v2.1.0 patched (2005-05-09), but
happens on R
HenrikB> v2.1.1 (patched or non-patched) in many different cases. The R
HenrikB> v2.2.0dev (2005-07-15) also got this problem (although it won't
crash on
HenrikB> the below example). I previously reported this
HenrikB> (https://stat.ethz.ch/pipermail/r-devel/2005-June/033772.html) and
HenrikB> Duncan Murdoch kindly offered to look into the problem, but it is
HenrikB> tricky. Now I would like to track down in what patched R v2.1.0
the
HenrikB> problem first occurs and are now looking for reports from newer
version,
HenrikB> but pre-Rv2.1.1.
HenrikB> If you've got R v2.1.0 patched for Windows *after 2005-05-09*,
could you
HenrikB> please try the following in that version of R?
HenrikB> install.packages("R.oo")
HenrikB> library(R.oo)
HenrikB> author <- "dummy"
HenrikB> rdocFile <- system.file("misc", "Exception.R", package="R.oo")
HenrikB> cat("# Empty example code\n", file="Exception.Rex")
HenrikB> Rdoc$compile(rdocFile, destPath=tempdir())
HenrikB> print("successful!")
HenrikB> If you see "successful!", that version is "ok", otherwise R will
crash
HenrikB> (or alternatively incorrectly complain about an invalid regular
HenrikB> expression; rerun and it will crash the 2nd time). I would
appreciate a
HenrikB> lot if you report to me what you get and what is your version of
R?
HenrikB> Thanks a lot!
HenrikB> Note that this is most likely *not* due to R.oo (no
HenrikB> native code) - my wild guess is that it has to do
HenrikB> with a memory leak in the code for environments or
HenrikB> regular expressions.
but why would that only affect Windows ??
I've tried your example code also in Linux, and indeed I do see
quite some memory growth of the R process, particularly if I run
for(i in 1:40) Rdoc$compile(rdocFile, destPath=tempdir())
## which takes a few minutes
my R process size grows considerably (50% - 100% depending on
the measure I use in 'ps').
So I can confirm that your guess about memory leakage {or
something close} seems quite on target.
But please don't ask me to dig further here - not for the time
being, at least.
BTW, I get 10 warnings, both in R 2.1.0 and in 2.1.1 patched
(see below) --- but that's probably something not really
relevant here.
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Adjusted p-values with TukeyHSD (patch)
We will incorporate a version of this in R-devel and hence 2.2.0. A bit more work needs to be done on printing: whereas the existing three columns are in comparable units, the p values are not and so get printed to silly accuracies (as can be seen in your example). You also need to explain what "p adj" is. On Fri, 15 Jul 2005, Fernando Henrique Ferraz P. da Rosa wrote: >Dear R-developeRs, > >Attached follows a patch against svn 34959 that adds the > printing of p-values to the TukeyHSD.aov function in stats package. I > also updated the corresponding documentation file and added a 'see also' > reference to the simint function of the multcomp package. > >As it was already brought up in a previous thread [1] in R-help, > one can obtain the adjusted p-values using the multcomp package and its > simint function. The problem is that currently the simint function > scales very badly for a large number of contrasts (> 15). While the output > of TukeyHSD is almost instantaneous, simint may take more than half an > hour to process 19 contrasts. > >As a toy example, try: > >y <- rnorm(500) >A <- gl(5,100) >system.time(h1 <- TukeyHSD((aov(y ~ A >system.time(h2 <- simint(y ~ A,type="Tukey")) > >Here I got: >[1] 0.09 0.01 0.10 0.00 0.00 >[1] 26.87 0.03 27.10 0.00 0.00 > >For a small number of contrasts they're equivalent, for example: > >data(warpbreaks) >fm1 <- aov(breaks ~ wool + tension, data = warpbreaks) >tHSD <- TukeyHSD(fm1, "tension", ordered = FALSE) >print(tHSD) >mcHSD <- simint(breaks ~ wool + tension, data = warpbreaks, > whichf="tension", type="Tukey") >summary(mcHSD) > >I also attached the complete function (mTukeyHSD.R) to this > message, in case the patch is not accepted and someone else needs to do > the same thing. In any case, I think the reference to the multcomp > package in the TukeyHSD help page should be considered even if the patch > to the function is not accepted. > > Thank you, > > References > [1] http://tolstoy.newcastle.edu.au/R/help/05/05/4599.html > > -- > Fernando Henrique Ferraz P. da Rosa > http://www.ime.usp.br/~feferraz > -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Computer algebra in R - would that be an idea??
On 7/15/05, Rob J Goedman <[EMAIL PROTECTED]> wrote: > I wonder how difficult it would be to translate expressions back and > forth from R to yacas in either R > or C++. And maybe strip 'In>' and 'Out>' like parts. Not sure how generally this works but see my prior post: http://tolstoy.newcastle.edu.au/R/help/04/03/1299.html __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Computer algebra in R - would that be an idea??
About a year ago there was a discussion about interfacing R with J on the J forum, the best method seemed to be that outlined in this vector article http://www.vector.org.uk/archive/v194/finn194.htm and use J instead of APL http://www.jsoftware.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R v2.1.0 patched (>2005-05-09) for Windows?
On 7/15/2005 4:01 AM, Henrik Bengtsson wrote:
> I'm trying to troubleshoot a case where R crashes on Windows. It does
> not occur at all with my R v2.1.0 patched (2005-05-09), but happens on R
> v2.1.1 (patched or non-patched) in many different cases. The R
> v2.2.0dev (2005-07-15) also got this problem (although it won't crash on
> the below example). I previously reported this
> (https://stat.ethz.ch/pipermail/r-devel/2005-June/033772.html) and
> Duncan Murdoch kindly offered to look into the problem, but it is
> tricky. Now I would like to track down in what patched R v2.1.0 the
> problem first occurs and are now looking for reports from newer version,
> but pre-Rv2.1.1.
>
> If you've got R v2.1.0 patched for Windows *after 2005-05-09*, could you
> please try the following in that version of R?
>
> install.packages("R.oo")
> library(R.oo)
> author <- "dummy"
> rdocFile <- system.file("misc", "Exception.R", package="R.oo")
> cat("# Empty example code\n", file="Exception.Rex")
> Rdoc$compile(rdocFile, destPath=tempdir())
> print("successful!")
>
> If you see "successful!", that version is "ok", otherwise R will crash
> (or alternatively incorrectly complain about an invalid regular
> expression; rerun and it will crash the 2nd time). I would appreciate a
> lot if you report to me what you get and what is your version of R?
> Thanks a lot!
>
> Note that this is most likely *not* due to R.oo (no native code) - my
> wild guess is that it has to do with a memory leak in the code for
> environments or regular expressions.
I'll do a series of builds to try this out and determine the date.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Computer algebra in R - would that be an idea??
> "bry" == bry <[EMAIL PROTECTED]> > on Fri, 15 Jul 2005 14:16:46 +0200 writes: bry> About a year ago there was a discussion about interfacing R with J on the J bry> forum, the best method seemed to be that outlined in this vector article bry> http://www.vector.org.uk/archive/v194/finn194.htm (which is interesting to see for me, if I had known that my posted functions would make it to an APL workshop... BTW: Does one need special plugins / fonts to properly view the APL symbols ? ) bry> and use J instead of APL bry> http://www.jsoftware.com well, I've learned about J as the ASCII-variant of APL, and APL used to be my first `beloved' computer language (in high school!) -- but does J really provide computer algebra in the sense of Maxima , Maple or yacas... ?? (and no, please refrain from flame wars about APL vs .. vs .., it's hard to refrain for me, too...) Martin Maechler, ETH Zurich __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Computer algebra in R - would that be an idea??
Rob J Goedman <[EMAIL PROTECTED]> writes:
> A really simple way to play with R & yacas is by using the examples
> in the subdir
> 'embed' of yacas-1.0.57.
>
> After building yacas (on Mac OS in my case):
>
> > res<-system("~/Projects/yacas-1.0.57/embed/example2", intern=T)
> > res
> [1] "Cos(x);"
>
> or
>
> > res<-system("~/Projects/yacas-1.0.57/embed/example1 'D(x){{Sin
> (x),Cos(x)}, {Sin(2*x),-Cos(x)}}'", intern=T)
> > res
> [1] "Input> D(x){{Sin(x),Cos(x)}, {Sin(2*x),-Cos(x)}}"
> [2] "Output> {{Cos(x),-Sin(x)},{2*Cos(2*x),Sin(x)}};"
>
> or
>
> > system("yacas -pc --execute '[Echo(D(x)Sin(x));Exit();]'")
> Cos(x)
>
> or
>
> > system("echo 'Example()' | yacas_client")
> In> Example()
> Current example : Integrate(x,a,b)Sin(x);
>
> Integrate a function.
>
> Out> Cos(a)-Cos(b)
> In>
> > system("echo 'Type(%)' | yacas_client")
> In> Type(%)
> Out> "-"
> In>
>
> This last example does show the yacas server stays alive between
> calls from R. yacas_client is a script.
> Maybe that approach also works for maxima?
>
> I wonder how difficult it would be to translate expressions back and
> forth from R to yacas in either R
> or C++. And maybe strip 'In>' and 'Out>' like parts.
You could also just do what those examples do and embed the whole
enchillada in R. The slightly bad news is that the yacas_eval
interface is text-based, which means that to handle an R expression
via yacas you're going through a deparse-parse-operate-deparse-parse
sequence. It would be nicer if you could just convert parse trees
between the two languages. The good news is that there's a Lisp route
(see example3), which should make the parser/deparser coding somewhat
easier.
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Computer algebra in R - would that be an idea??
Just a note to point out that Martin's R implementation of APL's "take" function was pretty neat. Could we preserve it for posterity somewhere in the R distribution? Failing that, it would complement subsums() of the magic package very nicely. best wishes Robin On 15 Jul 2005, at 14:14, Martin Maechler wrote: >> "bry" == bry <[EMAIL PROTECTED]> >> on Fri, 15 Jul 2005 14:16:46 +0200 writes: >> > > bry> About a year ago there was a discussion about interfacing > R with J on the J > bry> forum, the best method seemed to be that outlined in this > vector article > bry> http://www.vector.org.uk/archive/v194/finn194.htm > > (which is interesting to see for me, > if I had known that my posted functions would make it to an APL > workshop... > BTW: Does one need special plugins / fonts to properly view > the APL symbols ? ) > > > bry> and use J instead of APL > > bry> http://www.jsoftware.com > > well, I've learned about J as the ASCII-variant of APL, and APL > used to be my first `beloved' computer language (in high school!) > -- but does J really provide computer algebra in the sense of > Maxima , Maple or yacas... ?? > > (and no, please refrain from flame wars about APL vs .. vs .., > it's hard to refrain for me, too...) > > Martin Maechler, ETH Zurich > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Robin Hankin Uncertainty Analyst National Oceanography Centre, Southampton European Way, Southampton SO14 3ZH, UK tel 023-8059-7743 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] help.search of precedence is empty
Doing
help.search('precedence')
comes up empty. A fix would be to have the title:
Operator Syntax and Precedence
instead of
Operator Syntax
Patrick Burns
[EMAIL PROTECTED]
+44 (0)20 8525 0696
http://www.burns-stat.com
(home of S Poetry and "A Guide for the Unwilling S User")
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] help.search of precedence is empty
> "PatBurns" == Patrick Burns <[EMAIL PROTECTED]>
> on Fri, 15 Jul 2005 14:58:14 +0100 writes:
PatBurns> Doing
PatBurns> help.search('precedence')
PatBurns> comes up empty. A fix would be to have the title:
PatBurns> Operator Syntax and Precedence
PatBurns> instead of
PatBurns> Operator Syntax
very good idea.
Where as in general one should rather use a
\concept{...}
entry in order to make the page searchable for new `concepts',
in the present case, adding the "and Precedence" seems more
natural and I've just done it to R-devel.
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] Passing character strings from C code to R
Reading the posting guide would have shown you that R-help was quite
inappropriate, so I have moved this to R-devel.
allocString does not allocate a character vector, which is what you
want to set as an attribute (not a 'string', whatever that is). (It
creates a CHARSXP, a type that should not be user-visible directly and for
which STRING_ELT is inappropriate.)
You want something like (PROTECTS omitted):
Str = allocVector(STRSXP, 1);
SET_STRING_ELT(Str, 0, mkChar(comment));
There are many similar examples in the R sources for you to browse. There
is even a shortcut that manages the PROTECTS,
Str = mkString(comment);
(That allocString and mkString return different types indicate why I wrote
`whatever that is': the term is too loose to be useful.)
So you could just have
if(comment && strlen(comment)
setAttrib(Ret, install("com"), mkString(comment));
if(comment) Free(comment);
On Fri, 15 Jul 2005, Tuszynski, Jaroslaw W. wrote:
> Hi,
>
> I have a C code which produces array of integers and potentially a string,
> and I have problems passing the string out. Here is the relevant part of the
> code:
>
> 1 PROTECT(Ret = allocVector(INTSXP, n));
> 2 ret = (int*) INTEGER(Ret); /* get pointer to R's Ret */
> 3 for(i=0; i 4 Free(data);
> 5 i=1;
> 6 if (comment) { // comment was found
> 7 n = strlen(comment);
> 8 if(n>0) {// and it actually have some length
> 9Rprintf(" '%s' %i\n", comment, n);
> 10 PROTECT(Str = allocString(n+1));
> 11 str = CHAR(STRING_ELT(Str, 0));
> 12 strcpy(str, comment);
> 13 Rprintf(" '%s' %i\n", str, n);
> 14 setAttrib(Ret, install("comm"), Str);
> 15 i=2;
> 16 }
> 17 Free(comment);
> 18 }
> 20 UNPROTECT(i);
>
> Print statement in line 9 gives right results, but program crashes before
> print statement in line 13.
> Any ideas to what am I doing wrong?
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] documentation for filter() (PR#8010)
Full_Name: Landon Sego Version: 2.1.1 OS: Windows Submission from: (NULL) (128.173.70.25) In the Details section of the documentation for filter(), it says: The convolution filter is 'y[i] = f[1]*x[i+o] + ... + f[p]*x[i+o-p-1]' Correct me if I'm wrong, but I think it should be: 'y[i] = f[1]*x[i+o] + ... + f[p]*x[i+o-p+1]' For example: consider a 2 sided convolution with a filter that has length p=3 and the filter is applied to the i=6th observation. In this case, o=1. Then we would have 'y[6] = f[1]*x[6+1] + f[2]*x[6+1-1] + f[3]*x[6+1-3+1]' = f[1]*x[7] + f[2]*x[6] + f[3]*x[5]' __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] S4 generics "missing"
Thank you, Lars, for persisting on this topic of
missing S4 generics!
[I'm diverting this away from the original bug report;
since this is really about future features rather than R bugs.]
Unfortunately it's not as easy as you might think.
o One reason is the fact that currently it is still necessary
for bootstrapping reasons that R "can run" with only the 'base'
package loaded, i.e. "methods" not available. This makes
it sometimes hard to S4-ize base functions.
o Then there have been performance issues hindering the
S4-ification of ``everything''.
Note that e.g. S4 classes , functions methods, etc are not really
proper C-level SEXPs which would speed up (and lead to clean
up) of the "methods" code base.
o One other problem is with function like cbind() which have
a signature starting with '...' : The need to be changed
before you can define methods for them.
We've recently started to discuss this issue within R core,
with constructive proposals by John Chambers, and I have been
strongly considering indeed to try the case of
cbind() and rbind() in particular.
I also hope that some of these issues will be addressed during
this summer and will eventually lead to much improved S4
facilities in R.
Martin Maechler, ETH Zurich
> "lars" == lars <[EMAIL PROTECTED]>
> on Fri, 15 Jul 2005 01:26:50 +0200 (CEST) writes:
lars> Hi,
lars> I ran into another internal function that is missing S4 dispatch. It
is
lars> the binary operator ":". Looking at the code, I see that it is
actually
lars> a common problem. Other candidates are operators like "~", "&&", "||"
lars> and functions like: "length<-", "row", "col", "unlist", "cbind", etc.
It
lars> would for instance be nice to be able to write a matrix class that
has
lars> the same operators and functions as the built-in class. In general, I
lars> think that all the operators and functions associates with built-in
lars> types like vectors, lists, matrices and data frames should have S4
dispatch.
lars> Thanks,
lars> Lars
lars> lars wrote:
>> Hi,
>>
>> OK, if you try to explicitly make them generic, you are told that they
>> are implicitly already generic:
>>
>> > setGeneric("is.finite", function(from, ...)
>> standardGeneric("is.finite"))
>> Error in setGeneric("is.finite", function(from, ...)
>> standardGeneric("is.finite")) :
>> "is.finite" is a primitive function; methods can be defined, but
>> the generic function is implicit, and can't be changed.
>>
>> If you query about its genericness before you define you own generic,
>> you get:
>>
>> > isGeneric("is.finite")
>> [1] FALSE
>>
>> But after you define you own generic, you get:
>>
>> > setMethod("is.finite", signature(x="TS"),
>> + function(x) {
>> + Data(x) = callNextMethod()
>> + x
>> + })
>> [1] "is.finite"
>>
>> > isGeneric("is.finite")
>> [1] TRUE
>>
>> This all makes some sense, but I am not familiar enough with he
>> internals to explain exactly why it is done this way. I think you will
>> fine that 'is.nan' behave exactly the same way.
>>
>> Thanks,
>> Lars
>>
>>
>> Prof Brian Ripley wrote:
>>
>>> These functions are not generic according to the help page.
>>> The same page says explicitly that is.nan is generic.
>>>
>>> Where did you get the (false) idea that they were generic?
>>>
>>> On Thu, 16 Jun 2005 [EMAIL PROTECTED] wrote:
>>>
Full_Name: Lars Hansen
Version: 2.1.0
OS: SunOS 5.8
Submission from: (NULL) (207.66.36.189)
Hi,
S4 method displacth does not work for the two generic functions
'is.finite' and 'is.infinite'. It turns out that the C functions
'do_isfinite' and 'do_isinfinite' in src/main/coerce.c are missing a
call to 'DispatchOrEval' (see do_isnan). Added in the call fixed the
problem. My functions no look like this:
Form coerce.c:
SEXP do_isfinite(SEXP call, SEXP op, SEXP args, SEXP rho)
{
SEXP ans, x, names, dims;
int i, n;
if (DispatchOrEval(call, op, "is.finite", args, rho, &ans, 1, 1))
return(ans);
checkArity(op, args);
...
SEXP do_isinfinite(SEXP call, SEXP op, SEXP args, SEXP rho)
{
SEXP ans, x, names, dims;
double xr, xi;
int i, n;
if (DispatchOrEval(call, op, "is.infinite", args, rho, &ans, 1, 1))
return(ans);
checkArity(op, args);
...
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/li
Re: [Rd] [R] Passing character strings from C code to R
Thanks,
That fixed the problem.
Jarek
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Friday, July 15, 2005 11:11 AM
To: Tuszynski, Jaroslaw W.
Cc: r-devel@stat.math.ethz.ch
Subject: Re: [R] Passing character strings from C code to R
Reading the posting guide would have shown you that R-help was quite
inappropriate, so I have moved this to R-devel.
allocString does not allocate a character vector, which is what you want to
set as an attribute (not a 'string', whatever that is). (It creates a
CHARSXP, a type that should not be user-visible directly and for which
STRING_ELT is inappropriate.)
You want something like (PROTECTS omitted):
Str = allocVector(STRSXP, 1);
SET_STRING_ELT(Str, 0, mkChar(comment));
There are many similar examples in the R sources for you to browse. There
is even a shortcut that manages the PROTECTS,
Str = mkString(comment);
(That allocString and mkString return different types indicate why I wrote
`whatever that is': the term is too loose to be useful.)
So you could just have
if(comment && strlen(comment)
setAttrib(Ret, install("com"), mkString(comment));
if(comment) Free(comment);
On Fri, 15 Jul 2005, Tuszynski, Jaroslaw W. wrote:
> Hi,
>
> I have a C code which produces array of integers and potentially a
> string, and I have problems passing the string out. Here is the
> relevant part of the
> code:
>
> 1 PROTECT(Ret = allocVector(INTSXP, n));
> 2 ret = (int*) INTEGER(Ret); /* get pointer to R's Ret */
> 3 for(i=0; i 4 Free(data);
> 5 i=1;
> 6 if (comment) { // comment was found
> 7 n = strlen(comment);
> 8 if(n>0) {// and it actually have some length
> 9Rprintf(" '%s' %i\n", comment, n);
> 10 PROTECT(Str = allocString(n+1));
> 11 str = CHAR(STRING_ELT(Str, 0));
> 12 strcpy(str, comment);
> 13 Rprintf(" '%s' %i\n", str, n);
> 14 setAttrib(Ret, install("comm"), Str);
> 15 i=2;
> 16 }
> 17 Free(comment);
> 18 }
> 20 UNPROTECT(i);
>
> Print statement in line 9 gives right results, but program crashes
> before print statement in line 13.
> Any ideas to what am I doing wrong?
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Computer algebra in R - would that be an idea??
> > "bry" == bry <[EMAIL PROTECTED]>
>> on Fri, 15 Jul 2005 14:16:46 +0200 writes:
>
> bry> About a year ago there was a discussion about interfacing R
>with J on the J
> bry> forum, the best method seemed to be that outlined in this
>vector article
> bry> http://www.vector.org.uk/archive/v194/finn194.htm
>
>(which is interesting to see for me,
> if I had known that my posted functions would make it to an APL
> workshop...
> BTW: Does one need special plugins / fonts to properly view
> the APL symbols ? )
>
>
> bry> and use J instead of APL
>
> bry> http://www.jsoftware.com
>
>well, I've learned about J as the ASCII-variant of APL, and APL
>used to be my first `beloved' computer language (in high school!)
>-- but does J really provide computer algebra in the sense of
>Maxima , Maple or yacas... ??
I wonder if at this point it would be useful to think about how a
symbolic algebra system might be used by R users, and whether that
would affect the choice of system. For example, Maxima and yacas seem
to be mostly concerned with "getting the job done", which might be
all that the data analyst or occasional user needs. However,
mathematical statisticians might be more concerned with developing
new mathematics. For example, commutative algebra has been found to
be very useful in the theory of experimental design (e.g. Pistone,
Riccomagno, Wynn (2000) Algebraic Statistics: Computational
Commutative Algebra in Statistics. Chapman & Hall). Now, Maxima can
already do the necessary calculations (ie Groebner bases of
polynomials), but as far as I know, yacas cannot. But who knows where
the next breakthrough will come from? In that case Axiom might be
more useful and appropriate, as it is largely used by research
mathematicians. We would then need a mechanism for the development of
new data structures in R that could potentially match Axiom's rich
and extensible type system. I guess some mechanism that relies on S4
classes would be necessary. Of course, there is nothing to stop us
developing packages for more than one system ("We are R. We will
assimilate you!"). I have no idea how to do any of this: I'm just
floating ideas here. :-)
Cheers,
Simon.
>
>(and no, please refrain from flame wars about APL vs .. vs ..,
> it's hard to refrain for me, too...)
>
>Martin Maechler, ETH Zurich
>
>__
>R-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-devel
--
Simon Blomberg, B.Sc.(Hons.), Ph.D, M.App.Stat.
Centre for Resource and Environmental Studies
The Australian National University
Canberra ACT 0200
Australia
T: +61 2 6125 7800
F: +61 2 6125 0757
CRICOS Provider # 00120C
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
