#9650: Adding support for differential forms
-----------------------------------+----------------------------------------
Reporter: jvkersch | Owner: burcin
Type: enhancement | Status: needs_work
Priority: major | Milestone: sage-4.5.3
Component: symbolics | Keywords: forms, functions, symbolics
Author: Joris Vankerschaver | Upstream: N/A
Reviewer: Niles Johnson | Merged:
Work_issues: diff() |
-----------------------------------+----------------------------------------
Comment(by niles):
Replying to [comment:30 jason]:
> I think it's fine to let the explicit conversion SR(q) work---by
default, explicitly converting to SR just wraps the object as above, and I
think is supported for every Sage object, whether or not it makes "sense".
Do you see someplace that the conversion to an SR object is implicit?
That would be a problem.
>
I agree with Jason; I usually think of `SR` as "the nothing ring", or "the
everything ring", depending on your point of view. The problem with
`diff(q)` previously returning 0 has to do with `SR(q).vars()` being
empty. That is, when converting to `SR`, the variables of `q` are not
noticed. If you wanted to be overly fancy, you could try to implement
something so that the variables of `q` are created and recognized when one
does `SR(q)`, but this seems pretty pointless to me.
Also, Joris, I completely agree on your decision to raise an error for
additional arguments to `diff`.
As for the method inheritance problem, I'm of two minds. This problem has
come up for me (and probably others) too, and stems from wanting to
inherit most of the functionality of another class, but not all of the
methods. The technically correct thing to do is write a new master class,
inherit from that, and rewrite the other class also inheriting from the
new master class -- this will probably take a while, and has the potential
to raise subtle bugs. The laziest thing to do is ignore the problem --
this will probably be fine for most users, and confusing for some. A
middle road is to go through all of the inherited methods and make sense
out of the ones you can. For those you can't, override the method to
raise `NotImplementedError` or something similar, with a nice message
about how this doesn't make sense for your class.
For this ticket, I'd be in support of raising `NotImplementedError`s for
all of the broken inherited methods, and writing a new ticket to implement
those that can be.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/9650#comment:32>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
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-trac?hl=en.
