[Rd] Hmisc_3.0-1.zip (PR#8005)
Full_Name: Guy Horev Version: 2.0.1 OS: WinXP Submission from: (NULL) (192.114.161.178) It seems that the file Hmisc_3.0-1.zip in CRAN is corrupted, it should be 1.8M but only 1.47M are saved, when trying to install localy or from the net the following message apears: Error in file(file, "r") : unable to open connection In addition: Warning messages: 1: error 1 in extracting from zip file 2: cannot open file `Hmisc/DESCRIPTION' other packages works fine __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Hmisc_3.0-1.zip (PR#8005)
[EMAIL PROTECTED] wrote: > Full_Name: Guy Horev > Version: 2.0.1 > OS: WinXP > Submission from: (NULL) (192.114.161.178) > > > It seems that the file Hmisc_3.0-1.zip in CRAN is corrupted, it should be 1.8M And it is, at least on the CRAN master in Vienna. Uwe Ligges > but only 1.47M are saved, when trying to install localy or from the net the > following message apears: > Error in file(file, "r") : unable to open connection > In addition: Warning messages: > 1: error 1 in extracting from zip file > 2: cannot open file `Hmisc/DESCRIPTION' > > other packages works fine > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Sweave resource leak: leftover temp files (PR#7998)
This is actually a Windows bug. Those files are unlink()ed, and it seems
Windows is not respecting that (not an unknown phenomenon). I have tried
a few workarounds, and am about to commit one that seems to work.
No files are left over on a decent operating system, e.g. Solaris or FC3
Linux.
On Fri, 8 Jul 2005 [EMAIL PROTECTED] wrote:
> Harold, I've taken a closer look at your example and I'd call this an
> Sweave bug. It creates tempfiles each time you run it, and doesn't
> delete them at the end. For example:
>
> > list.files(tempdir())
> character(0)
> > testfile <- system.file("Sweave", "Sweave-test-1.Rnw", package = "utils")
> > Sweave(testfile, out="junk.tex")
> Writing to file junk.tex
> Processing code chunks ...
> 1 : print term verbatim
> 2 : term hide
> 3 : echo print term verbatim
> 4 : term verbatim
> 5 : echo term verbatim
> 6 : echo term verbatim eps pdf
> 7 : echo term verbatim eps pdf
>
> You can now run LaTeX on 'junk.tex'
> > list.files(tempdir())
> [1] "Rf10523" "Rf13872" "Rf17129" "Rf2055" "Rf2203" "Rf2403" "Rf27095"
> [8] "Rf2892" "Rf31415" "Rf5290" "Rf6251" "Rf6482" "Rf7055" "Rf724"
> > Sweave(testfile, out="C:/temp/junk.tex")
> Writing to file C:/temp/junk.tex
> Processing code chunks ...
> 1 : print term verbatim
> 2 : term hide
> 3 : echo print term verbatim
> 4 : term verbatim
> 5 : echo term verbatim
> 6 : echo term verbatim eps pdf
> 7 : echo term verbatim eps pdf
>
> You can now run LaTeX on 'C:/temp/junk.tex'
> > list.files(tempdir())
> [1] "Rf10523" "Rf12679" "Rf1311" "Rf13484" "Rf13872" "Rf17129" "Rf17288"
> [8] "Rf2055" "Rf21774" "Rf2203" "Rf23417" "Rf2403" "Rf27095" "Rf2892"
> [15] "Rf29444" "Rf31128" "Rf31415" "Rf32520" "Rf3338" "Rf5290" "Rf5551"
> [22] "Rf6251" "Rf6482" "Rf7055" "Rf724" "Rf7543" "Rf758" "Rf7673"
> > unlink(list.files(tempdir(),full=T))
> > list.files(tempdir())
> character(0)
>
> Harold: a workaround for this would be to wrap your Sweave call in
> something like this:
>
> keep <- list.files(tempdir(), full=TRUE) # keep previous temp files
>
> ... Call Sweave here ...
>
> temps <- list.files(tempdir(), full=TRUE)
> unlink(temps[!(temps %in% keep)]) # delete the newly created ones
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
--
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] Computer algebra in R - would that be an idea??
>From time to time people request symbolic computations beyond what D() and >deriv() etc can provide. A brief look at the internet shows that there are >many more or less developed computer algebra packages freely available. >Therefore, I wondered if it would be an idea to try to 'integrate' one of >these packages in R, which I guess can be done in more or less elegant ways... >I do not know any of the computer algebra people around the World, but perhaps >some other people from the R-community do and would be able to/interested in >establishing such a connection... Just and idea; comments appreciated :-) Søren = Søren Højsgaard, MSc, PhD (Statistics),Phone: +45 8999 1703 Head of Statistics and Decision Theory Research Group, Fax: +45 8999 1300 Danish Institute of Agricultural Sciences [EMAIL PROTECTED] Research Centre Foulum, DK-8830 Tjele, Denmark http://genetics.agrsci.dk/~sorenh Time flies like an arrow, fruit flies like a banana __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Sweave resource leak: leftover temp files (PR#7998)
Prof Brian Ripley wrote:
> This is actually a Windows bug. Those files are unlink()ed, and it seems
> Windows is not respecting that (not an unknown phenomenon). I have tried
> a few workarounds, and am about to commit one that seems to work.
I guess you mean the C unlink, since I don't see the R unlink being
called.
Generally deletes fail on Windows when files are locked, e.g. open for
reading or writing. I haven't seen Windows file deletes fail in other
circumstances, so I suspect this was an R, MinGW or MSVCRT bug rather
than a Windows bug.
Duncan Murdoch
>
> No files are left over on a decent operating system, e.g. Solaris or FC3
> Linux.
>
> On Fri, 8 Jul 2005 [EMAIL PROTECTED] wrote:
>
>
>>Harold, I've taken a closer look at your example and I'd call this an
>>Sweave bug. It creates tempfiles each time you run it, and doesn't
>>delete them at the end. For example:
>>
>>
>>>list.files(tempdir())
>>
>>character(0)
>>
>>>testfile <- system.file("Sweave", "Sweave-test-1.Rnw", package = "utils")
>>>Sweave(testfile, out="junk.tex")
>>
>>Writing to file junk.tex
>>Processing code chunks ...
>> 1 : print term verbatim
>> 2 : term hide
>> 3 : echo print term verbatim
>> 4 : term verbatim
>> 5 : echo term verbatim
>> 6 : echo term verbatim eps pdf
>> 7 : echo term verbatim eps pdf
>>
>>You can now run LaTeX on 'junk.tex'
>>
>>>list.files(tempdir())
>>
>> [1] "Rf10523" "Rf13872" "Rf17129" "Rf2055" "Rf2203" "Rf2403" "Rf27095"
>> [8] "Rf2892" "Rf31415" "Rf5290" "Rf6251" "Rf6482" "Rf7055" "Rf724"
>>
>>>Sweave(testfile, out="C:/temp/junk.tex")
>>
>>Writing to file C:/temp/junk.tex
>>Processing code chunks ...
>> 1 : print term verbatim
>> 2 : term hide
>> 3 : echo print term verbatim
>> 4 : term verbatim
>> 5 : echo term verbatim
>> 6 : echo term verbatim eps pdf
>> 7 : echo term verbatim eps pdf
>>
>>You can now run LaTeX on 'C:/temp/junk.tex'
>>
>>>list.files(tempdir())
>>
>> [1] "Rf10523" "Rf12679" "Rf1311" "Rf13484" "Rf13872" "Rf17129" "Rf17288"
>> [8] "Rf2055" "Rf21774" "Rf2203" "Rf23417" "Rf2403" "Rf27095" "Rf2892"
>>[15] "Rf29444" "Rf31128" "Rf31415" "Rf32520" "Rf3338" "Rf5290" "Rf5551"
>>[22] "Rf6251" "Rf6482" "Rf7055" "Rf724" "Rf7543" "Rf758" "Rf7673"
>>
>>>unlink(list.files(tempdir(),full=T))
>>>list.files(tempdir())
>>
>>character(0)
>>
>>Harold: a workaround for this would be to wrap your Sweave call in
>>something like this:
>>
>>keep <- list.files(tempdir(), full=TRUE) # keep previous temp files
>>
>>... Call Sweave here ...
>>
>>temps <- list.files(tempdir(), full=TRUE)
>>unlink(temps[!(temps %in% keep)]) # delete the newly created ones
>>
>>__
>>R-devel@r-project.org mailing list
>>https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Sweave resource leak: leftover temp files (PR#7998)
On Tue, 12 Jul 2005, Duncan Murdoch wrote:
> Prof Brian Ripley wrote:
>> This is actually a Windows bug. Those files are unlink()ed, and it seems
>> Windows is not respecting that (not an unknown phenomenon). I have tried a
>> few workarounds, and am about to commit one that seems to work.
>
> I guess you mean the C unlink, since I don't see the R unlink being called.
Yes, I do, but the R unlink calls the C unlink and so has the same
problem.
> Generally deletes fail on Windows when files are locked, e.g. open for
> reading or writing. I haven't seen Windows file deletes fail in other
> circumstances, so I suspect this was an R, MinGW or MSVCRT bug rather than a
> Windows bug.
But unlink() is required by POSIX to work when files are open, so it is a
MSVCRT `feature' (and that is part of Windows since Win95 OSR2). Indeed,
there is nothing in the MSDN documentation on unlink() that says anything
about not working if files are `locked'.
If people use the same name and arg sequence of a standard library call
and partially implement it without saying so or mentioning the
restrictions I believe it is perfectly reasonable to call that a bug.
>
> Duncan Murdoch
>>
>> No files are left over on a decent operating system, e.g. Solaris or FC3
>> Linux.
>>
>> On Fri, 8 Jul 2005 [EMAIL PROTECTED] wrote:
>>
>>
>>> Harold, I've taken a closer look at your example and I'd call this an
>>> Sweave bug. It creates tempfiles each time you run it, and doesn't
>>> delete them at the end. For example:
>>>
>>>
list.files(tempdir())
>>>
>>> character(0)
>>>
testfile <- system.file("Sweave", "Sweave-test-1.Rnw", package = "utils")
Sweave(testfile, out="junk.tex")
>>>
>>> Writing to file junk.tex
>>> Processing code chunks ...
>>> 1 : print term verbatim
>>> 2 : term hide
>>> 3 : echo print term verbatim
>>> 4 : term verbatim
>>> 5 : echo term verbatim
>>> 6 : echo term verbatim eps pdf
>>> 7 : echo term verbatim eps pdf
>>>
>>> You can now run LaTeX on 'junk.tex'
>>>
list.files(tempdir())
>>>
>>> [1] "Rf10523" "Rf13872" "Rf17129" "Rf2055" "Rf2203" "Rf2403" "Rf27095"
>>> [8] "Rf2892" "Rf31415" "Rf5290" "Rf6251" "Rf6482" "Rf7055" "Rf724"
>>>
Sweave(testfile, out="C:/temp/junk.tex")
>>>
>>> Writing to file C:/temp/junk.tex
>>> Processing code chunks ...
>>> 1 : print term verbatim
>>> 2 : term hide
>>> 3 : echo print term verbatim
>>> 4 : term verbatim
>>> 5 : echo term verbatim
>>> 6 : echo term verbatim eps pdf
>>> 7 : echo term verbatim eps pdf
>>>
>>> You can now run LaTeX on 'C:/temp/junk.tex'
>>>
list.files(tempdir())
>>>
>>> [1] "Rf10523" "Rf12679" "Rf1311" "Rf13484" "Rf13872" "Rf17129" "Rf17288"
>>> [8] "Rf2055" "Rf21774" "Rf2203" "Rf23417" "Rf2403" "Rf27095" "Rf2892"
>>> [15] "Rf29444" "Rf31128" "Rf31415" "Rf32520" "Rf3338" "Rf5290" "Rf5551"
>>> [22] "Rf6251" "Rf6482" "Rf7055" "Rf724" "Rf7543" "Rf758" "Rf7673"
>>>
unlink(list.files(tempdir(),full=T))
list.files(tempdir())
>>>
>>> character(0)
>>>
>>> Harold: a workaround for this would be to wrap your Sweave call in
>>> something like this:
>>>
>>> keep <- list.files(tempdir(), full=TRUE) # keep previous temp files
>>>
>>> ... Call Sweave here ...
>>>
>>> temps <- list.files(tempdir(), full=TRUE)
>>> unlink(temps[!(temps %in% keep)]) # delete the newly created ones
>>>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>>
>>
>>
>
>
--
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] Sweave resource leak: leftover temp files (PR#7998)
On 7/12/2005 8:58 AM, Prof Brian Ripley wrote:
> On Tue, 12 Jul 2005, Duncan Murdoch wrote:
>
>> Prof Brian Ripley wrote:
>>> This is actually a Windows bug. Those files are unlink()ed, and it seems
>>> Windows is not respecting that (not an unknown phenomenon). I have tried a
>>> few workarounds, and am about to commit one that seems to work.
>>
>> I guess you mean the C unlink, since I don't see the R unlink being called.
>
> Yes, I do, but the R unlink calls the C unlink and so has the same
> problem.
>
>> Generally deletes fail on Windows when files are locked, e.g. open for
>> reading or writing. I haven't seen Windows file deletes fail in other
>> circumstances, so I suspect this was an R, MinGW or MSVCRT bug rather than a
>> Windows bug.
>
> But unlink() is required by POSIX to work when files are open, so it is a
> MSVCRT `feature' (and that is part of Windows since Win95 OSR2). Indeed,
> there is nothing in the MSDN documentation on unlink() that says anything
> about not working if files are `locked'.
>
> If people use the same name and arg sequence of a standard library call
> and partially implement it without saying so or mentioning the
> restrictions I believe it is perfectly reasonable to call that a bug.
This is documented in the API call DeleteFile. I wouldn't call MSVCRT
part of Windows, but I guess this is the same thing as saying that Linux
is the kernel, not the whole collection of things you get in a Linux
distribution.
Windows provides a different mechanism for this, the
FILE_FLAG_DELETE_ON_CLOSE flag to CreateFile(). Your patch has solved
the problem, so I can't see that it would be worthwhile using this, but
one way to implement the POSIX behaviour would be to open a file with
this flag, then immediately close it. As long as all other handles to
the file are eventually closed the file should be deleted.
Duncan
>
>>
>> Duncan Murdoch
>>>
>>> No files are left over on a decent operating system, e.g. Solaris or FC3
>>> Linux.
>>>
>>> On Fri, 8 Jul 2005 [EMAIL PROTECTED] wrote:
>>>
>>>
Harold, I've taken a closer look at your example and I'd call this an
Sweave bug. It creates tempfiles each time you run it, and doesn't
delete them at the end. For example:
> list.files(tempdir())
character(0)
> testfile <- system.file("Sweave", "Sweave-test-1.Rnw", package = "utils")
> Sweave(testfile, out="junk.tex")
Writing to file junk.tex
Processing code chunks ...
1 : print term verbatim
2 : term hide
3 : echo print term verbatim
4 : term verbatim
5 : echo term verbatim
6 : echo term verbatim eps pdf
7 : echo term verbatim eps pdf
You can now run LaTeX on 'junk.tex'
> list.files(tempdir())
[1] "Rf10523" "Rf13872" "Rf17129" "Rf2055" "Rf2203" "Rf2403" "Rf27095"
[8] "Rf2892" "Rf31415" "Rf5290" "Rf6251" "Rf6482" "Rf7055" "Rf724"
> Sweave(testfile, out="C:/temp/junk.tex")
Writing to file C:/temp/junk.tex
Processing code chunks ...
1 : print term verbatim
2 : term hide
3 : echo print term verbatim
4 : term verbatim
5 : echo term verbatim
6 : echo term verbatim eps pdf
7 : echo term verbatim eps pdf
You can now run LaTeX on 'C:/temp/junk.tex'
> list.files(tempdir())
[1] "Rf10523" "Rf12679" "Rf1311" "Rf13484" "Rf13872" "Rf17129" "Rf17288"
[8] "Rf2055" "Rf21774" "Rf2203" "Rf23417" "Rf2403" "Rf27095" "Rf2892"
[15] "Rf29444" "Rf31128" "Rf31415" "Rf32520" "Rf3338" "Rf5290" "Rf5551"
[22] "Rf6251" "Rf6482" "Rf7055" "Rf724" "Rf7543" "Rf758" "Rf7673"
> unlink(list.files(tempdir(),full=T))
> list.files(tempdir())
character(0)
Harold: a workaround for this would be to wrap your Sweave call in
something like this:
keep <- list.files(tempdir(), full=TRUE) # keep previous temp files
... Call Sweave here ...
temps <- list.files(tempdir(), full=TRUE)
unlink(temps[!(temps %in% keep)]) # delete the newly created ones
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>>
>>
>>
>
__
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/12/05, Søren Højsgaard <[EMAIL PROTECTED]> wrote: > >From time to time people request symbolic computations beyond what D() and > >deriv() etc can provide. A brief look at the internet shows that there are > >many more or less developed computer algebra packages freely available. > >Therefore, I wondered if it would be an idea to try to 'integrate' one of > >these packages in R, which I guess can be done in more or less elegant > >ways... I do not know any of the computer algebra people around the World, > >but perhaps some other people from the R-community do and would be able > >to/interested in establishing such a connection... Coincidentally I asked the yacas developer about this just yesterday: http://sourceforge.net/mailarchive/forum.php?thread_id=7711431&forum_id=2216 __ 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/12/2005 10:57 AM, Gabor Grothendieck wrote: > On 7/12/05, Søren Højsgaard <[EMAIL PROTECTED]> wrote: >> >From time to time people request symbolic computations beyond what D() and >> >deriv() etc can provide. A brief look at the internet shows that there are >> >many more or less developed computer algebra packages freely available. >> >Therefore, I wondered if it would be an idea to try to 'integrate' one of >> >these packages in R, which I guess can be done in more or less elegant >> >ways... I do not know any of the computer algebra people around the World, >> >but perhaps some other people from the R-community do and would be able >> >to/interested in establishing such a connection... > > > Coincidentally I asked the yacas developer about this just yesterday: > http://sourceforge.net/mailarchive/forum.php?thread_id=7711431&forum_id=2216 It sounds like developing an R package to act as a wrapper would be the best approach. I didn't see documentation for their API (the exports of their DLL), but I didn't spend long looking. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] allocation of large matrix failing
Hello, this is probably something silly which I am doing, but I cannot
understand why this allocation is not happening.
Here is a my C code which tries to allocate a list of size 333559, and
then a matrix of size 8*333559
I thought I might be running into memory problems, but R is not even
using that much (I start R with
more memory and it stays constant) Also, I start R as I normally do and
I allocate a matrix of that size
and it returns instantly, so I am inclined to think that this is not a
memory/GC issue, but I submit it
may be.
int numHits = seq.GetNumberHits();
Rprintf("numHits:%d\n", numHits);
Rprintf("before allocation...\n");
SEXP oligos, matrix;
PROTECT(oligos = NEW_LIST(numHits));
Rprintf("allocated oligo list...\n");
PROTECT(matrix = NEW_INTEGER(numHits*8));
Rprintf("entering looop...\n");
entering sequence loop.
numHits:333559
before allocation...
allocated oligo list...
It hangs here everytime (never printing "entering loop..." - i have
waited like 10 minutes). If I remove the 8 then it completes.
Essentially I want to allocate a vector of that length and then
dimension it into a matrix, but I cannot see why this does not work.
debian 2.6
R 2.1.0
Thanks as always for any insight.
jim
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Spurious output like in R-devel
I have noticed spurious message of the form
when developing code for the Matrix package and testing under R-devel.
These messages are not present when testing under R-2.1.1
I have not reported this because I didn't know if it was caused by my
code in the Matrix package or some other code. Today I checked the
newly uploaded vcd package under R-devel and got the same symptoms.
Try
library('vcd')
example(mosaic')
to reproduce the problem. If you want to see the same problem in the
Matrix package run
R-devel CMD check Matrix
and look at the output in Matrix.Rcheck/tests/lmer.Rout
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] allocation of large matrix failing
James,
On Jul 12, 2005, at 5:05 PM, James Bullard wrote:
> Hello, this is probably something silly which I am doing, but I
> cannot understand why this allocation is not happening.
I suspect it's something else - the code you sent us works without
problems for me:
> .C("foo",as.integer(333559))
numHits:333559
before allocation...
allocated oligo list...
entering looop...
[[1]]
[1] 333559
> gc()
used (Mb) gc trigger (Mb) max used (Mb)
Ncells 162348 4.4 35 9.4 35 9.4
Vcells 60528 0.51453055 11.1 1562032 12.0
I have also tested it with 100-times larger vector and it works as well:
> .C("foo",as.integer(33355900))
numHits:33355900
before allocation...
allocated oligo list...
entering looop...
[[1]]
[1] 33355900
> gc()
used (Mb) gc trigger (Mb) max used (Mb)
Ncells 162526 4.4 35 9.4359.4
Vcells 60536 0.5 120333512 918.1 150162111 1145.7
This was on both Debian Linux and OS X, but that shouldn't really
matter I suppose... (and I don't see why it should fail). If you
overdo it with the size you can get "Error: cannot allocate vector of
size xxx", but it won't hang, either.
Cheers,
Simon
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Spurious output like in R-devel
On 7/12/05, Duncan Temple Lang <[EMAIL PROTECTED]> wrote: > Hi Doug. > > I noticed this also after the recent change to the > code to handle missing PACKAGE arguments for > .C/.Call/.Fortran routines. > There is a line in the dotcode.c (1510) that > has a call to Rf_PrintValue(env) and that is > what is causing it. > > I haven't had a chance to get to this for the last week or so but > am doing so now. Thanks Duncan. In my code it turns out that the two .Call calls that were producing the spurious output did not have PACKAGE = "Matrix". Once I fixed that I no longer got the spurious output. __ 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??
I would use such a symbolic math package for R. I have dreamt of an open-source solution with functionality similar to mathStatica. http://www.mathstatica.com/ Is yacas the best system to consider? What about Maxima http://maxima.sourceforge.net/, which is also GPL, or maybe Axiom http://savannah.nongnu.org/projects/axiom, which has a modified BSD license? Cheers, Simon. At 01:25 AM 13/07/2005, Duncan Murdoch wrote: >On 7/12/2005 10:57 AM, Gabor Grothendieck wrote: > > On 7/12/05, Søren Højsgaard <[EMAIL PROTECTED]> wrote: > >> >From time to time people request symbolic computations beyond what > D() and deriv() etc can provide. A brief look at the internet shows that > there are many more or less developed computer algebra packages freely > available. Therefore, I wondered if it would be an idea to try to > 'integrate' one of these packages in R, which I guess can be done in more > or less elegant ways... I do not know any of the computer algebra people > around the World, but perhaps some other people from the R-community do > and would be able to/interested in establishing such a connection... > > > > > > Coincidentally I asked the yacas developer about this just yesterday: > > > http://sourceforge.net/mailarchive/forum.php?thread_id=7711431&forum_id=2216 > >It sounds like developing an R package to act as a wrapper would be the >best approach. I didn't see documentation for their API (the exports of >their DLL), but I didn't spend long looking. > >Duncan Murdoch > >__ >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 email: Simon.Blomberg_at_anu.edu.au F: +61 2 6125 0757 CRICOS Provider # 00120C __ 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??
Personally, I like Maxima better than Yacas, but in both cases the solution (at least a minimal one) should be doable: A small program which pipes R commands into a terminal running Maxima/Yacas and taking the output back into R. I am not much into the technical details, but isn't that what can be done with the COM automatation server on Windows?? (I don't know what the equivalent would be on unix?). Best regards Søren Fra: Simon Blomberg [mailto:[EMAIL PROTECTED] Sendt: on 13-07-2005 01:52 Til: Duncan Murdoch; Gabor Grothendieck Cc: Søren Højsgaard; r-devel@stat.math.ethz.ch Emne: Re: [Rd] Computer algebra in R - would that be an idea?? I would use such a symbolic math package for R. I have dreamt of an open-source solution with functionality similar to mathStatica. http://www.mathstatica.com/ Is yacas the best system to consider? What about Maxima http://maxima.sourceforge.net/, which is also GPL, or maybe Axiom http://savannah.nongnu.org/projects/axiom, which has a modified BSD license? Cheers, Simon. At 01:25 AM 13/07/2005, Duncan Murdoch wrote: >On 7/12/2005 10:57 AM, Gabor Grothendieck wrote: > > On 7/12/05, Søren Højsgaard <[EMAIL PROTECTED]> wrote: > >> >From time to time people request symbolic computations beyond what > D() and deriv() etc can provide. A brief look at the internet shows that > there are many more or less developed computer algebra packages freely > available. Therefore, I wondered if it would be an idea to try to > 'integrate' one of these packages in R, which I guess can be done in more > or less elegant ways... I do not know any of the computer algebra people > around the World, but perhaps some other people from the R-community do > and would be able to/interested in establishing such a connection... > > > > > > Coincidentally I asked the yacas developer about this just yesterday: > > > http://sourceforge.net/mailarchive/forum.php?thread_id=7711431&forum_id=2216 > >It sounds like developing an R package to act as a wrapper would be the >best approach. I didn't see documentation for their API (the exports of >their DLL), but I didn't spend long looking. > >Duncan Murdoch > >__ >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 email: Simon.Blomberg_at_anu.edu.au F: +61 2 6125 0757 CRICOS Provider # 00120C __ 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??
I don't know which free system is best. I have mainly used Yacas but my needs to date have been pretty minimal so I suspect any of them would have worked. Eric's COM solution, once I have it figured out, will likely get me to the next step on Windows. I did some googling around and found this: http://www.koders.com/python/fidDCC1B0FBFABC770277A28835D5FFADC9D25FF54E.aspx which is a python interface to Yacas which may give some ideas on how to interface it to R. On 7/12/05, Søren Højsgaard <[EMAIL PROTECTED]> wrote: > Personally, I like Maxima better than Yacas, but in both cases the solution > (at least a minimal one) should be doable: A small program which pipes R > commands into a terminal running Maxima/Yacas and taking the output back into > R. I am not much into the technical details, but isn't that what can be done > with the COM automatation server on Windows?? (I don't know what the > equivalent would be on unix?). > Best regards > Søren > > > > Fra: Simon Blomberg [mailto:[EMAIL PROTECTED] > Sendt: on 13-07-2005 01:52 > Til: Duncan Murdoch; Gabor Grothendieck > Cc: Søren Højsgaard; r-devel@stat.math.ethz.ch > Emne: Re: [Rd] Computer algebra in R - would that be an idea?? > > > > I would use such a symbolic math package for R. I have dreamt of an > open-source solution with functionality similar to mathStatica. > http://www.mathstatica.com/ Is yacas the best system to consider? What > about Maxima http://maxima.sourceforge.net/, which is also GPL, or maybe > Axiom http://savannah.nongnu.org/projects/axiom, which has a modified BSD > license? > > Cheers, > > Simon. > > At 01:25 AM 13/07/2005, Duncan Murdoch wrote: > >On 7/12/2005 10:57 AM, Gabor Grothendieck wrote: > > > On 7/12/05, Søren Højsgaard <[EMAIL PROTECTED]> wrote: > > >> >From time to time people request symbolic computations beyond what > > D() and deriv() etc can provide. A brief look at the internet shows that > > there are many more or less developed computer algebra packages freely > > available. Therefore, I wondered if it would be an idea to try to > > 'integrate' one of these packages in R, which I guess can be done in more > > or less elegant ways... I do not know any of the computer algebra people > > around the World, but perhaps some other people from the R-community do > > and would be able to/interested in establishing such a connection... > > > > > > > > > Coincidentally I asked the yacas developer about this just yesterday: > > > > > http://sourceforge.net/mailarchive/forum.php?thread_id=7711431&forum_id=2216 > > > >It sounds like developing an R package to act as a wrapper would be the > >best approach. I didn't see documentation for their API (the exports of > >their DLL), but I didn't spend long looking. > > > >Duncan Murdoch > > > >__ > >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 email: Simon.Blomberg_at_anu.edu.au > F: +61 2 6125 0757 > CRICOS Provider # 00120C > > > > > __ 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??
Another approach might be to construct a wrapper for Aldor code, along the lines of .Fortran and .C. Aldor is the extension language for AXIOM http://www.aldor.org/, and there is a symbolic algebra library available for Aldor http://www-sop.inria.fr/cafe/Manuel.Bronstein/algebra, which ships with the Aldor compiler. Of course, I am much better at thinking up these ideas than implementing them myself. :-) Simon. At 11:36 AM 13/07/2005, Gabor Grothendieck wrote: >I don't know which free system is best. I have mainly used Yacas >but my needs to date have been pretty minimal so I suspect >any of them would have worked. > >Eric's COM solution, once I have it figured out, will likely get me >to the next step on Windows. I did some googling around and >found this: > >http://www.koders.com/python/fidDCC1B0FBFABC770277A28835D5FFADC9D25FF54E.aspx > >which is a python interface to Yacas which may give some ideas >on how to interface it to R. > > >On 7/12/05, Søren Højsgaard <[EMAIL PROTECTED]> wrote: > > Personally, I like Maxima better than Yacas, but in both cases the > solution (at least a minimal one) should be doable: A small program which > pipes R commands into a terminal running Maxima/Yacas and taking the > output back into R. I am not much into the technical details, but isn't > that what can be done with the COM automatation server on Windows?? (I > don't know what the equivalent would be on unix?). > > Best regards > > Søren > > > > > > > > Fra: Simon Blomberg [mailto:[EMAIL PROTECTED] > > Sendt: on 13-07-2005 01:52 > > Til: Duncan Murdoch; Gabor Grothendieck > > Cc: Søren Højsgaard; r-devel@stat.math.ethz.ch > > Emne: Re: [Rd] Computer algebra in R - would that be an idea?? > > > > > > > > I would use such a symbolic math package for R. I have dreamt of an > > open-source solution with functionality similar to mathStatica. > > http://www.mathstatica.com/ Is yacas the best system to consider? What > > about Maxima http://maxima.sourceforge.net/, which is also GPL, or maybe > > Axiom http://savannah.nongnu.org/projects/axiom, which has a modified BSD > > license? > > > > Cheers, > > > > Simon. > > > > At 01:25 AM 13/07/2005, Duncan Murdoch wrote: > > >On 7/12/2005 10:57 AM, Gabor Grothendieck wrote: > > > > On 7/12/05, Søren Højsgaard <[EMAIL PROTECTED]> wrote: > > > >> >From time to time people request symbolic computations beyond what > > > D() and deriv() etc can provide. A brief look at the internet shows that > > > there are many more or less developed computer algebra packages freely > > > available. Therefore, I wondered if it would be an idea to try to > > > 'integrate' one of these packages in R, which I guess can be done in more > > > or less elegant ways... I do not know any of the computer algebra people > > > around the World, but perhaps some other people from the R-community do > > > and would be able to/interested in establishing such a connection... > > > > > > > > > > > > Coincidentally I asked the yacas developer about this just yesterday: > > > > > > > > http://sourceforge.net/mailarchive/forum.php?thread_id=7711431&forum_id=2216 > > > > > >It sounds like developing an R package to act as a wrapper would be the > > >best approach. I didn't see documentation for their API (the exports of > > >their DLL), but I didn't spend long looking. > > > > > >Duncan Murdoch > > > > > >__ > > >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 email: Simon.Blomberg_at_anu.edu.au > > F: +61 2 6125 0757 > > CRICOS Provider # 00120C > > > > > > > > > > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
