On Mon, 4 Dec 2006, Joel B. Mohler wrote:
>
> On Mon, Dec 04, 2006 at 09:46:18AM -0800, Robert Bradshaw wrote:
>>
>> I think we are thinking of these indetermanents wrongly--they are
>> dummy variables and have should really have no context outside of the
>> function definition. Another problem is that, if we say f = sin(a)+cos
>> (x), then f(1,2) is ambiguous. Here's what I think should happen:
>> f = sin(x) should be illegal (though I'm not sure how to throw an
>> informative error here). Instead one should have to type f(x) = sin
>> (x). This would be pre-parsed to something like
>>
>> with inject_indetermanents('x'):
>> f = sin(x)
>>
>> Here inject_indetermanents would be assign x to an indetermanent that
>> knows both its name (for printing) and its position (in the tuple if
>> f is called with multiple arguments, and x is recursively called down
>> the tree). It would be a morphism of the category of sets and always
>> act as the identity function on __call__. It could, say, know how to
>> differentiate itself (return 1 if the variable with respect to
>> integration matches self.name, 0 (or dx/dother) otherwise. It would
>> support addition, exponentiation, etc. via a generic "sum" class that
>> takes two functions and returns a function. Coercible into R[x], etc.
>>
>> (I'm not sure how contexts work, perhaps the all the indetermanents
>> in the block would have to be wrapped... this is still doable via
>> regular expressions...)
>>
>> Any comments?
>
> I like this proposal a great deal. It fixes all of my complaints that
> I've been bringing up about polynomial rings. It is however very
> difficult to actually implement this with-out pre-parser logic. I'm
> not certain how much of a downside that is.
Yes, though at least here the preparser rule is stateless and simple. The
"pythonic" way of defining functions is
def f(x):
return x - sin(x)
or even
f = lambda x: x - sin(x)
which doesn't allow us to do, say, (symbolic) calculus on the returned
object--we'd probably want the returned result to be an instance of
ElementaryFunction. It seems reasonable to use the preparser to create a
simple, intuitive way of defining _mathematical_ functions.
Also, this could co-exist with whatever (predefined or not) values are
assigned to x.
> One other downside is that these indeterminants would not be
> elements in the polynomial ring and so it seems that they would not
> benefit from the speed of the polynomial arithmetic architecture. That
> is to say, you could have polynomials in sage which don't know they
> are polynomials so I guess all the computation would use the most
> naive methods of computation and not utilize the heavily optimized
> polynomial code. This would be rather sad.
This is true, but I think that if someone wants the full speed and
functionality of polynomials one should create the object as a polynomial
(or at least cast it into such a ring--this should be fully supported).
Also, polynomials (currently) are always stored in their expanded version,
which may or may not be desired (I'm thinking of calculus students here).
> However, if you want to make a decently usable calculus interface, I
> think you will have to make some sacrifices of this nature.
>
> --
> Joel
>
> >
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to [email protected]
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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~----------~----~----~----~------~----~------~--~---
