On Wed, Mar 5, 2008 at 11:45 AM, Carl Witty <[EMAIL PROTECTED]> wrote:
>
> On Mar 4, 10:59 am, Jason Grout <[EMAIL PROTECTED]> wrote:
> > This morning I tried to copy a matrix output, edit it, and create a new
> > matrix. It was frustrating because there seemed to be no way to easily
> > cut and paste output into input. This afternoon a person I was showing
> > Sage to also had the same concern.
>
> I like the idea of a _sage_init_ method, but implementing it could be
> a lot of work depending on the exact specification.
>
> Jason presumably wants output that's easy to read (since he wants to
> edit it and paste it back in). William (from IRC last night) wants
> output that can be evaluated with sage_eval to get the original value
> back.
>
> These goals are difficult to reconcile; the big problem is that
> sage_eval only takes a single expression. This means that _sage_init_
> on a polynomial must return things like:
> "GF(17)['x,y']('3*x^2*y^3')"
> or
> "GF(17)(3)*GF(17)['x,y'].gen(0)^2*GF(17)['x,y'].gen(1)^3"
> or
> "(lambda R: (lambda x,y: 3*x^2*y^3)(*R.gens()))(GF(17)['x,y'])"
> none of which are very nice.
>
> Options I see include:
>
> 1) Give up on having the output work in the initial environment (as
> used by sage_eval); instead, assume that generators (polynomial
> variables, etc.) are available in the environment.
>
> 2) Modify sage_eval so that it can process a sequence of statements
> followed by an expression; then _sage_init_ could return
> """
> R1 = GF(17)
> R2 = R1['x,y']
> x, y = R2.gens()
> 3*x^2*y^3
> """
>
> 3) Live with ugly output like the above examples, with lots of
> repeated work, or ugly nested lambdas, or ugly nested strings.
>
> Another question is whether floating-point numbers should read back to
> the exact same value, or whether it's OK to lose the bottom few bits
> (my vote is for "exact same value", of course).
>
> My vote is for option 2), modify sage_eval and have _sage_init_
> potentially produce a sequence of statements followed by an
> expression; and I'd be interested in helping to implement that option.
+1
I really like option 2 as well, but only with a lot more discussion and
thought. The "single expression" requirement
is particularly hard to do on nontrivial things. Even with other interfaces,
e.g., _magma_init_, we're going to have to change this soon I think.
(BTW, I've been funded to greatly enhance the Sage/Magma interface,
and have been thinking some about this problem as a result.)
I'm not sure that 2 as suggested is the best idea. It might be better
to have *two* methods _sage_init_setup_ and _sage_init_ where setup
returns a block of code that sets of the environment
where the sage_init works. Or maybe _sage_init_ should return a 2-tuple.
This is just brainstorming.
William
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
