Re: [Rd] Computer algebra in R - would that be an idea??
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.
Rob
On Jul 14, 2005, at 5:21 PM, Søren Højsgaard wrote:
> Perhaps, this is the wrong mailing list, but I've been thinking
> about calling e.g. maxima from R through some kind of wrapper. On
> windows, maxima can be invoked through a file called maxima.bat
> which opens a simple 'dos terminal' in which maxima is running. A
> simple way of interfacing R and maxima would be through a function
> which 'copies' a text string into such a dos terminal with maxima
> running and copies the output back into R. That particular task is
> something which one might want to be able to do with several other
> programs too... A way of doing this would be through the system()
> and/or shell() functions where input and output can be redirected
> to/from the program called, e.g. maxima. The problem is, that system
> ()/shell() will start maxima, execute the submitted code and
> terminate maxima. As I understand it, RDCOMClient provides a way of
> getting a 'handle' on such a program provided that the program is
> written in a specific way - something to do with COM. However, I
> wonder if it would be possible to write a general R function, (e.g.
> called dynamicshell()) which would provide a handle on such an
> application and to which one could send commands and retrieve
> output without shutting the application down. That is, essentially,
> a programatic form of 'copy and paste' in two directions... Is
> there anything in the way R is constructed that prevents that such
> a function could be written, and if so can anyone explain to me why
> and/or point me to a reference explaining why.
>
> Best regards
> Søren
>
>
>
> Fra: Simon Blomberg [mailto:[EMAIL PROTECTED]
> Sendt: on 13-07-2005 04:42
> Til: Gabor Grothendieck; Søren Højsgaard
> Cc: Duncan Murdoch; r-devel@stat.math.ethz.ch
> Emne: 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
Re: [Rd] Computer algebra in R - would that be an idea??
Hi,
Maybe sending an R expression and getting an R expression back
for a 'suitable subset' of expressions is ok initially. Suitable could
cover 3 levels:
1) Mapping of names and standard functions, e.g. pi to Pi and
sin(x) to Sin(x) etc.
2) It would be nice if we can use threading of functions, which will
require
converting R lists, vectors, matrices etc to yacas lists.
3) And finally, what about functions such as apply, quote, etc.?
Not sure how to get around the superfluous parse step when
calling an R function, e.g. yacas(rExp). Rebuilding the original
argument to pass to yacas with reparse(substitute(rExp)) again
might again be ok initially.
Earlier I asked the question on where to do the back and forth
translation of R expressions to yacas statements. At that time I
focused on R or C++. The latter likely if its done using the
parsed tree.
Two other possibilities might be to 'redo' yacas to make yacas much
closer to R (examples that come to mind is all cases of sin(x) in R to
Sin(x) in yacas - as in 1) above -, although as Gabor indicated, CForm
helps on the way back). The 2nd option is adding a whole bunch of Rules
to the yacas scripts to do this, e.g '10 # sin(x) <-- Sin(x)'. Not
sure if
adding a special low level generic object to yacas would help here.
As rules in yacas are global, all of these substitutions could be
collected
in 1 or a few yacas scripts read in when R's yacas function starts the
yacas_client.
I do work on Mac, have helped Simon and Stefano occasionally with
the Mac OS GUI. If you have a yacas version as an Xcode project,
that would
make playing around and trying some of above steps easier. I've
looked at the
Mac OS GUI version of Yacas, seems based on an older version and
vanilla 1.0.57
compiles fine on Mac OS. My guess is, if possible, we want a single
approach
across the different platforms.
Rob
On Jul 17, 2005, at 8:29 AM, Ayal Pinkus wrote:
>> Using this instead of Tcl_Eval() gives some efficiency gain, but more
>> importantly, it avoids the "quoting hell" associated with the
>> construction of the relevant command strings.
> Interesting. You are not the first person asking this, actually.
>
> I chose for the C API as it is nice and clean, no name mangling issues
> while switching to a new gcc compiler, and it allows people to use it
> from C also. Back then, I thought all people would want to do is
> send a
> string and receive one back.
>> Since both R and Yacas are "Lisp under the hood" languages (and Tcl
>> too for that matter), it is a fairly good guess that their parse
>> trees
>> are similar, and that it would be a fairly simple task to translate
>> back and forth between them. Well, between suitable subsets, at
>> least.
>> R's parse trees can in principle contain arbitrary R objects, but in
>> this context, we might only need constants, names, operators, and
>> function calls.
On Jul 15, 2005, at 6:25 AM, Peter Dalgaard 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.
>
> 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.
On Jul 15, 2005, at 3:44 AM, Gabor Grothendieck wrote:
> 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
> system("echo 'WriteString(CForm(Integrate(x)1/x))' | yacas_client")
In> WriteString(CForm(Integrate(x)1/x))
log(x)
Out> True
In>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R crashes in Mac OS 10.4 when Find is used (PR#9192)
Matt, This is not an R bug or r-devel issue. The proper email list is R-SIG- Mac. Maybe the 1st step we can try is to install the latest version of the R.app, which you can find at http://r.research.att.com/ . Can you please download the nightly build of just the R.app GUI and see if the problem still occurs? I have tried many times on my system and can't reproduce the problem. Thanks, Rob On Aug 31, 2006, at 7:42 AM, [EMAIL PROTECTED] wrote: > Full_Name: Matt Fantle > Version: 1.16 > OS: Mac OS 10.4.7 > Submission from: (NULL) (128.118.174.213) > > > Problem: R crashes when 'Command-f' is pressed to begin "Find" > Frequency: This problem is intermittant. Once R crashes, the only > solution is > to restart R and try to Find again. There is no regularity to the > problem. If > R is opened by double-clicking on a ".R" file, the problem might be > there. If R > is opened by double-clicking the application or alias, the problem > may also > still be there. > > Log report: > OS Version: 10.4.7 (Build 8J135) > Report Version: 4 > > Command: R > Path:/Applications/R.app/Contents/MacOS/R > Parent: WindowServer [60] > > Version: 1.16 (3198) > > PID:474 > Thread: 0 > > Exception: EXC_BREAKPOINT (0x0006) > Code[0]:0x0001 > Code[1]:0x9295f120 > > > Thread 0 Crashed: > 0 com.apple.Foundation 0x9295f120 _NSRaiseError + 264 > 1 com.apple.AppKit 0x937c9274 -[NSCarbonMenuImpl > performActionWithHighlightingForItemAtIndex:] + 160 > 2 com.apple.AppKit 0x937c8ce4 -[NSMenu > performKeyEquivalent:] + 272 > 3 com.apple.AppKit 0x937c88c4 -[NSApplication > _handleKeyEquivalent:] > + 220 > 4 com.apple.AppKit 0x936d2408 -[NSApplication > sendEvent:] + 2944 > 5 org.R-project.R 0xb730 -[RController > handleReadConsole:] + 88 > (RController.m:869) > 6 org.R-project.R 0x0002c0b8 Re_ReadConsole + 108 > (Rcallbacks.m:137) > 7 org.R-project.R 0x0003223c run_REngineRmainloop + 300 > (Rinit.c:341) > 8 org.R-project.R 0x0002aa1c -[REngine runREPL] + 68 > (REngine.m:167) > 9 org.R-project.R 0x0001d340 main + 680 (main.m:101) > 10 org.R-project.R 0x2e8c _start + 340 (crt.c:272) > 11 org.R-project.R 0x2d34 start + 60 > > Thread 1: > 0 libSystem.B.dylib 0x9000b268 mach_msg_trap + 8 > 1 libSystem.B.dylib 0x9000b1bc mach_msg + 60 > 2 com.apple.CoreFoundation 0x907dbb78 __CFRunLoopRun + 832 > 3 com.apple.CoreFoundation 0x907db47c CFRunLoopRunSpecific + 268 > 4 com.apple.Foundation 0x92939598 -[NSConnection > sendInvocation:] + 1468 > 5 com.apple.Foundation 0x92938034 -[NSObject > (NSForwardInvocation) > forward::] + 408 > 6 libobjc.A.dylib 0x90a430b0 _objc_msgForward + 176 > 7 com.apple.Foundation 0x9293839c -[NSDistantObject > methodSignatureForSelector:] + 268 > 8 com.apple.Foundation 0x92937f04 -[NSObject > (NSForwardInvocation) > forward::] + 104 > 9 libobjc.A.dylib 0x90a430b0 _objc_msgForward + 176 > 10 org.R-project.R 0xacc0 -[RController readThread:] > + 2436 > (RController.m:613) > 11 com.apple.Foundation 0x92944194 forkThreadForFunction + 108 > 12 libSystem.B.dylib 0x9002bc28 _pthread_body + 96 > > Thread 2: > 0 libSystem.B.dylib 0x9002c2e8 semaphore_wait_signal_trap > + 8 > 1 libSystem.B.dylib 0x90030dcc pthread_cond_wait + 480 > 2 com.apple.Foundation 0x9294b300 -[NSConditionLock > lockWhenCondition:] + > 68 > 3 com.apple.AppKit 0x9376a708 -[NSUIHeartBeat > _heartBeatThread:] + > 324 > 4 com.apple.Foundation 0x92944194 forkThreadForFunction + 108 > 5 libSystem.B.dylib 0x9002bc28 _pthread_body + 96 > > Thread 3: > 0 libSystem.B.dylib 0x9000b268 mach_msg_trap + 8 > 1 libSystem.B.dylib 0x9000b1bc mach_msg + 60 > 2 com.apple.CoreFoundation 0x907dbb78 __CFRunLoopRun + 832 > 3 com.apple.CoreFoundation 0x907db47c CFRunLoopRunSpecific + 268 > 4 com.apple.Foundation 0x9296b69c > +[NSURLConnection(NSURLConnectionInternal) _resourceLoadLoop:] + 264 > 5 com.apple.Foundation 0x92944194 forkThreadForFunction + 108 > 6 libSystem.B.dylib 0x9002bc28 _pthread_body + 96 > > Thread 4: > 0 libSystem.B.dylib 0x9000b268 mach_msg_trap + 8 > 1 libSystem.B.dylib 0x9000b1bc mach_msg + 60 > 2 com.apple.CoreFoundation 0x907dbb78 __CFRunLoopRun + 832 > 3 com.apple.CoreFoundation 0x907db47c CFRunLoopRunSpecific + 268 > 4 com.apple.Foundation 0x9296c7dc +[NSURLCache > _diskCacheSyncLoop:] + > 152 > 5 com.apple.Foundation 0x92944194 forkThreadForFunction + 108 > 6 libSystem.B.dylib 0x9002bc28 _pthread_body + 96 > > Thread 5: > 0 libSystem.B.dylib 0x9000b268 mach_msg_trap + 8 > 1 libSystem.B.dylib 0x9000b1bc mach_msg + 60 > 2 com.apple.CoreFoundation 0x907dbb78 __CFRunLoopRun + 8
