#7377: Symbolic Ring to Maxima via EclObject
-----------------------------------------------------------------------+----
Reporter: nbruin |
Owner: nbruin
Type: enhancement |
Status: needs_work
Priority: major |
Milestone: sage-feature
Component: symbolics |
Keywords:
Author: Nils Bruin, Jean-Pierre Flori |
Upstream: N/A
Reviewer: Jean-Pierre Flori, François Bissey, Karl-Dieter Crisman |
Merged:
Work_issues: |
-----------------------------------------------------------------------+----
Comment(by kcrisman):
> * The advice currently is wrong! Why would "...>0" be the right thing?
That just propagates a kind of halfbrained trial-and-error mathematics
that I cannot bring myself to endorse. The proper advice is for the user
to read up on the assume(...) facility.
Then you did not read the words, "for example". And the 'trial-and-error
mathematics' comment may then be aimed at Maxima as well, especially when
it asks all kinds of questions and the result is always the same. (rjf
would no doubt comment that this is undecidable.) Perhaps the user
really didn't consider whether `x>0` until just then, and might as well
try all possibilities. That certainly happens in real life.
This is the best we have to deal with it right now, and until Maxima stops
asking such questions, what else can one do? The error message gives the
syntax, not the mathematics. Can you think of a different way to phrase
it that makes it clear we aren't actually suggesting `x>0` in reality?
Saying to read up on assume() is sort of like telling people to read the
man page; totally useless if you do not already have an idea that such a
thing exists. Read `assume?` if you don't believe me. Obviously that
could be improved, but it would be strange to put things about integrals
and limits at the top of that file (where they'd need to be to catch
attention), and there is no reason not to give a maximally helpful error
message right off the bat.
> In fact, currently, the advice already leads to errors
> sage: my_symbolic_n=SR.var('n')
> sage: limit(x^my_symbolic_n,x=oo)
> TypeError: Computation failed since Maxima requested additional
constraints (try the command 'assume(n>0)' before integral or limit
evaluation, for example):
> Is n positive, negative, or zero?
> sage: assume(n>0)
> AttributeError: 'bool' object has no attribute 'assume'
> sage: n
> <function numerical_approx at 0x18e0410>
>You CANNOT assume that the print name corresponds with the python
variable bound to your object and sage SHOULD NOT propagate such
assumptions in its error messages. It's nice to make a program accessible
to starters but not at the expense of allowing them to progress to
experienced users.
Nothing here is stopping someone from advancing to being experienced.
This problem occurs other places than here - see many discussions on sage-
devel about print names not coinciding, or about var() being annoying in
general. If someone knows anything about what you are saying, they will
be plenty experienced to realize that this message isn't talking about
'their' n.
Sorry if I sound irked. But there is a place for such lawyering -
lawyering over a minor thing which would make Sage more friendly to
beginners and which doesn't actually harm the advanced users - and that
place is not in a program that is trying to become a 'viable replacement
for Mathematica and Maple'. I've seen this over and over, and can't
figure out who this is hurting in many such cases.
Anyway, I hope we can come to some reasonable compromise on this. The
current suggestion would make a very common error message less useful.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/7377#comment:100>
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.
