On Nov 9, 2008, at 3:32 PM, William Stein wrote:

> On Sun, Nov 9, 2008 at 3:07 PM, William Stein <[EMAIL PROTECTED]>  
> wrote:
>> On Sun, Nov 9, 2008 at 2:04 PM, Justin C. Walker <[EMAIL PROTECTED]>  
>> wrote:
>>>
>>> Hi,
>>>
>>> On Nov 9, 2008, at 13:27 , [EMAIL PROTECTED] wrote:
>>>
>>>> Hello I tried the folowing three links (from sage-devel) on my
>>>> computer as well as on sagenb.com
>>                                         ^^^^^^^^^^^^^^^^^
>>
>> That's a good hint.  I just tried this on sagenb.org, and indeed
>> in sage-3.1.4 in the *notebook* implicit multiplication is broken.
>> I've made this
>>
>>  http://trac.sagemath.org/sage_trac/ticket/4485
>>
>> Note implicit multiplication still works fine on the command line.
>>
>> It's possible implicit multiplication never worked in the notebook; I
>> have no idea.   I'll try for a few minutes right now to fix this.
>> William
>
> OK, I've thought about it, and see now that there is no way
> that implicit multiplication was ever even *implemented*
> for the notebook!    Just to illustrate what is going on, note
> that if in the notebook you type
>
>    implicit_multiplication(True)
>    preparse('3x')
>
> you get as output
>
>    'Integer(3)*x'
>
> which illustrates that the implicit_multiplication command works fine
> in the actual Sage worksheet process.   The problem is that the
> preparsing of the input for each cell of the notebook is *not* done in
> that subprocess!  It's done by the worksheet server process itself,
> before the input is ever sent to the subprocess.

That is really strange--I occasionally use implicit_multiplication  
from the command line, but never remember turning it on when I'm in  
the notebook.

> There are some approaches to fixing this and I'm not happy really
> about any of them:
>
>   1. Make it so the whole notebook server has an
> implicit_multiplication mode.  This is absurd since some users might
> want it and some not.  Alternatively, make it so the notebook server
> has a mode flag for each worksheet.  That's bad too since that mode
> can't be set via user input (by typing in cells) unless we fully parse
> all input before passing it on for evaluation -- i.e., that's a stupid
> idea which will result in great pain.  The other option, would be to
> have some GUI checkbox or something, and just give an error if one
> types in the input box "implicit_multiplication".  This would be
> inconsistent and maybe busy, but would probably work.  The
> inconsistency would be huge, since, e.g., if somebody writes a 30 line
> script like this:
>   ...
>   implicit_multiplication(True)
>   ...
>   3x + 1
>   ...
> and just *pastes* it into the notebook, it will suddenly not work.
> Which will be really annoying.

I don't like this option much...

>   2. Change how the Sage notebook evaluates code blocks.  Instead of
> preparsing input before sending it off to be evaluated by the
> worksheet subprocess, somehow send a chunck of non-preparsed code off,
> and a command that says "preparse this then evaluate it".

This could work, but would change how we handle syntax errors. I'm  
not sure how it would work either for large blocks.

>   3. Make sage query the subprocess for its implicit_multiplication
> state before every single evaluation -- this would be idiotic and slow
> down the server a lot.  Not an option.

I agree, -1.

> I think 2 is the best option, but it will not be easy to implement,
> and making this change scares me. It feels like the sort of change
> that could introduce numerous subtle bugs, and result in nontrivial
> degredation in functionality -- for example, maybe source code ??
> inspection of user-defined functions in the notebook might no longer
> work.
>
> Incidentally, here is a workaround to make it so you can input an
> expression using implicit multiplication in the notebook.
>
> implicit_multiplication(True)
> sage_eval('3x^3 + 4/5 x + 1', globals())
> 3*x^3 + 4*x/5 + 1
>
> I'm not going to do anything further on this without some feedback
> from Robert Bradshaw (who implemented implicit multiplication)
> and/or Mike Hansen who I think knows the relevant part of the
> notebook code well enough to have a comment about what
> I wrote above.

One of the problems is that the preparser operates in chunks, so if  
"implicit_multiplication(x)" sits half way through a chunk, one would  
have to split the chunk in half at that point and evaluate the first  
half of the chunk to decide how to do the rest. Also, this means that  
implicit_multiplication won't work in a file.

I think what should happen is all preprocessing happens on the  
notebook side, and the underlying sage process has preprocessing  
turned off (and always gets fed already preprocessed code). Options  
like implicit multiplication and (eventually?) auto-creation of  
undeclared variable names (or any others that come up) would be  
available as checkboxes in the notebook. Calling  
implicit_multiplication(...) from the notebook would result in an  
error (i.e. the underlying sage process would throw an error if it is  
called when preparsing is turned off). Essentially, the preparser  
state would be held entirely by the notebook. On this note, the  
"preparse" command should take an optional implicit_multiplication  
flag. This is kind of a variation on option 1, with a sensible error  
thrown in the hypothetical 30-line script.

- Robert


--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---

Reply via email to