[TxMt] problem with R interaction [was math bundle feature request]

[Charilaos Skiadas]

On Dec 8, 2006, at 2:39 PM, janssen at ccr.jussieu.fr wrote:

> Thanks this is doing it -
> Actually I only need to deal with floats using scientific notation  
> and powers,
> logs, etc., which is all available in ruby (but not quite in the  
> math bundle,
> where I would have expected it). Are trigonometric functions  
> available in Ruby
> too? cos(0.5) is not working for me using Ruby.
>
> How would I go to make a decent shortcut for the Execute Line as  
> Ruby command?
> ^-Shft-E is already used in the Latex bundle - I can certainly use  
> the bundle
> editor to select another short cut for it, but is this recommended  
> or are there
> better solutions.
>
No no you should not be using the "Executre Line as Ruby" command.  
You should instead create a new command with the text I had pasted,  
and then Kevin corrected. You create a new command via the Bundle  
editor.
The command I and Kevin are talking about doesn't just execute the  
current line in Ruby. It "imports" the Math "module", which means  
that instead of having to type Math.cos(0.2) you can type simply cos 
(0.2). That's why cos(0.2) was not working for you via the Execute  
Line as Ruby command, while Math.cos(0.2) would have worked.

As far as shortcut goes, in general a lot of ctrl+ combinations are  
available, they are reserved for user use. Of course you can also  
assign it the same shortcut as the math calculation commands, and  
then you'll be seeing it as an extra option in the popup.

>> You don't need to know anything about Ruby, in fact the command I   
>> mentioned in the previous email computes 1/1e-1 just fine. All  
>> you  have to do is look up the names of the standard commands in  
>> that ruby  help page I linked to, so that you know what to call,  
>> i.e. that log()  is for logarithms log10() for base 10 logarithms  
>> etc. If you give us  a list of the kind of simple math you want to  
>> do, and how ideally you  would like to type them in, we can offer  
>> a better suggestion I think  (though I am fairly certain that the  
>> ruby command as it stands will  already cover most if not all of  
>> them).
>>
>>> JJ
>>
> And yes, Haris, 100^2 <> 0. You actually pointed it out - it is not  
> the
> different functions that cause the problem. There appear many  
> things to go on
> at the same time, and shame on me, I was not careful enough when  
> reporting to
> the list. Here is a set of lines that were selected in Textmate and  
> then
> evaluated through R via the Console command:
>
> I made a mistake by typing e-1 instead of 1e-1. This way R could  
> not interpret
> what I meant. But in addition, the selected region gets somehow  
> corrupted. It
> seems that the first character is suppressed when transferred to R.  
> Leading to
> 00 in one case which gives the correct result 0^2=0. When there is  
> an empty
> space in front of the number it gets transferred completely and  
> 100^2=10000.
> THis must lead to an error message in case of a 1e-1 at the  
> beginning of a
> line, because e-1 cannot be interpreted ...
>
> May be this can be confirmed by others, or is it me again?

Ah you are using the R Console command. That requires you are in  
"console mode", which means your line should start with ">" followed  
by a space, in addition to scope requirements. So the command kills  
the first two characters before sending the input to R. It's the  
killing of those characters that is causing the problem in your case  
I'd bet.

In general right now all these R commands are a bit of a really  
really ugly hack. Because of the complete lack of applescript support  
from the part of R.app, we have to use system events, which means  
that, in order to find out the result of the computation, we have to  
"tell the system to tell us the contents of the scroll view of the  
first window of the application whose name is R.app", or something  
ridiculous close to that. We have to do this before we send the input  
to R.app. Then we have to send the input to R, and then we have to do  
the same thing, and read the new output. Finally, we have to take the  
difference of the two outputs to see what the new stuff that was  
added is. As you can imagine, this is completely ridiculous and  
should be avoided as much as possible, until we find a better way to  
talk to R. That's mainly why I am strongly suggesting using some  
other way.

> JJ

Haris