deprecating calling of symbolic expressions without variable names
Carl Witty
http://groups.google.com/group/sage-devel/browse_thread/thread/b1a03f8fc8ae8fcd/553773d7ba600ae7#553773d7ba600ae7
, I'm writing a patch to deprecate calling symbolic expressions
without variable names.
In the course of writing the patch, and subsequent discussions with
Jason and Burcin, some issues have come up; I just wanted to report on
what we've decided and give people a chance to object.
1) Piecewise functions:
With my initial patch,
sage: f = Piecewise([[(-1,1),1/2+x-x^3]])
doesn't work (that is, you get deprecation errors when you call f);
Burcin suggested an optional variable argument to Piecewise, so you
could type this instead:
sage: f = Piecewise([[(-1,1),1/2+x-x^3]], x)
2) plotting
A lot of the plotting code is willing to pick variable names (in
alphabetical order) if names aren't given in the plot ranges.
For instance, this is a doctest in plot.py:
sage: f = sin(x^2 + y^2)*cos(x)*sin(y)
sage: c = contour_plot(f, (-4, 4), (-4, 4), plot_points=100)
This will be deprecated, but any of the following will work:
sage: c = contour_plot(f, (x, -4, 4), (y, -4, 4), plot_points=100)
sage: c = contour_plot(f.function(x, y), (-4, 4), (-4, 4), plot_points=100)
sage: c = contour_plot(lambda x,y: f(x=x,y=y), (-4, 4), (-4, 4),
plot_points=100)
3) plotting single-variable expressions
As a special exception to the above rule, plots that want a
single-argument function will also accept a single-variable
expression; the following code will continue to work:
sage: plot(sin(x), (-3, 3))
As far as I know, this will be the only place in all of Sage where a
symbolic expression is automatically promoted to a function without
the user specifying a variable name (without a deprecation warning).
4) fast_float
The fast_float code assigns variable names in alphabetical order if
the variable names are not explicitly given. This will be deprecated.
Carl
William Stein
>
> As discussed at
> http://groups.google.com/group/sage-devel/browse_thread/thread/b1a03f8fc8ae8fcd/553773d7ba600ae7#553773d7ba600ae7
> , I'm writing a patch to deprecate calling symbolic expressions
> without variable names.
>
> In the course of writing the patch, and subsequent discussions with
> Jason and Burcin, some issues have come up; I just wanted to report on
> what we've decided and give people a chance to object.
>
> 1) Piecewise functions:
> With my initial patch,
> sage: f = Piecewise([[(-1,1),1/2+x-x^3]])
> doesn't work (that is, you get deprecation errors when you call f);
> Burcin suggested an optional variable argument to Piecewise, so you
> could type this instead:
> sage: f = Piecewise([[(-1,1),1/2+x-x^3]], x)
sage: f(x) = Piecewise([[(-1,1),1/2+x-x^3]])
should work.
Also "Piecewise" suggests "piecewise *function*" so maybe they *have*
to be a function? It's not a peicewise symbolic expression!
>
> 2) plotting
> A lot of the plotting code is willing to pick variable names (in
> alphabetical order) if names aren't given in the plot ranges.
> For instance, this is a doctest in plot.py:
> sage: f = sin(x^2 + y^2)*cos(x)*sin(y)
> sage: c = contour_plot(f, (-4, 4), (-4, 4), plot_points=100)
> This will be deprecated, but any of the following will work:
I'm strongly against deprecating anything like this for plotting,
since there are clear labeled axes in the plot.
> sage: c = contour_plot(f, (x, -4, 4), (y, -4, 4), plot_points=100)
> sage: c = contour_plot(f.function(x, y), (-4, 4), (-4, 4), plot_points=100)
> sage: c = contour_plot(lambda x,y: f(x=x,y=y), (-4, 4), (-4, 4),
> plot_points=100)
>
> 3) plotting single-variable expressions
> As a special exception to the above rule, plots that want a
> single-argument function will also accept a single-variable
> expression; the following code will continue to work:
> sage: plot(sin(x), (-3, 3))
> As far as I know, this will be the only place in all of Sage where a
> symbolic expression is automatically promoted to a function without
> the user specifying a variable name (without a deprecation warning).
>
> 4) fast_float
> The fast_float code assigns variable names in alphabetical order if
> the variable names are not explicitly given. This will be deprecated.
>
> Carl
>
> >
>
--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org
Jason Grout
> On Sat, Mar 14, 2009 at 10:29 AM, Carl Witty <carl....@gmail.com> wrote:
>> 2) plotting
>> A lot of the plotting code is willing to pick variable names (in
>> alphabetical order) if names aren't given in the plot ranges.
>> For instance, this is a doctest in plot.py:
>> sage: f = sin(x^2 + y^2)*cos(x)*sin(y)
>> sage: c = contour_plot(f, (-4, 4), (-4, 4), plot_points=100)
>> This will be deprecated, but any of the following will work:
>
> -1
>
> I'm strongly against deprecating anything like this for plotting,
> since there are clear labeled axes in the plot.
>
>> sage: c = contour_plot(f, (x, -4, 4), (y, -4, 4), plot_points=100)
>> sage: c = contour_plot(f.function(x, y), (-4, 4), (-4, 4), plot_points=100)
>> sage: c = contour_plot(lambda x,y: f(x=x,y=y), (-4, 4), (-4, 4),
>> plot_points=100)
>>
I'm just as strongly for the deprecation. The axes are *not* clearly
labeled: it's not clear which axis is which because there are no
variable names next to the axes. Even if we fixed that issue, though,
it is not clear to the user how to switch the axes if they are opposite
from what they want. contour_plot(f, (x,-4,4), (y,-4,4)) makes it
intuitive that if you want to swap roles of the axes, you swap the
ranges. Explicit is better than implicit, I feel, in this case.
Thanks,
Jason
William Stein
Well then we disagree. There is a very standard convention in math to
have the x axis in one spot, then the y-axis.
William
Jason Grout
What happens when you have variables u and v? Or a and b? Or t and s
(oops, I mean s and t; I forgot the alphabetical order; see? it's easy
to mess up; but t is often the x-axis, regardless of what the other
variable is called, even if it is alphabetically smaller... :). What
about variables some_long_name and some_long_mame? It's much harder
then to figure out which gets magically picked as the x-axis.
Regardless, I assume that we agree that the contour plot should have
variable names next to the axes? I was pretty surprised to see that it
didn't.
Jason
Carl Witty
> On Sat, Mar 14, 2009 at 10:29 AM, Carl Witty <carl....@gmail.com> wrote:
>> 1) Piecewise functions:
>> With my initial patch,
>> sage: f = Piecewise([[(-1,1),1/2+x-x^3]])
>> doesn't work (that is, you get deprecation errors when you call f);
>> Burcin suggested an optional variable argument to Piecewise, so you
>> could type this instead:
>> sage: f = Piecewise([[(-1,1),1/2+x-x^3]], x)
>
> This seems reasonable, maybe. Also
>
> sage: f(x) = Piecewise([[(-1,1),1/2+x-x^3]])
>
> should work.
>
> Also "Piecewise" suggests "piecewise *function*" so maybe they *have*
> to be a function? It's not a peicewise symbolic expression!
Certainly functions are allowed there; my initial patch changed doctests like
sage: f = Piecewise([[(-1,1),1/2+x-x^3]])
to
sage: f = Piecewise([[(-1,1),(1/2+x-x^3).function(x)]])
but that's quite a syntactic overhead, especially if you've got lots
of functions in the list. I like Burcin's shortcut.
sage: f(x) = Piecewise([[(-1,1),1/2+x-x^3]])
is tricky; at least with the current implementation, that means that
Piecewise(...) (with expressions, not functions) has to be allowable
as a symbolic expression. I was going to put the deprecation warning
for this case in the piecewise constructor (so you get the deprecation
warning when you make the piecewise function, not when you call it);
allowing f(x) = Piecewise(...) breaks that, as well. So how strongly
do you feel about f(x) = Piecewise(...)?
Carl
Carl Witty
So as a compromise, we could add another special case: plots that want a
two-argument function will also accept an expression in the variables
x and y, but for expressions in any other variables the user has to
specify the axes.
Carl
William Stein
order. It's not ambiguous and it is useful.
> Regardless, I assume that we agree that the contour plot should have
> variable names next to the axes? I was pretty surprised to see that it
> didn't.
>
> Jason
William Stein
>
> On Sat, Mar 14, 2009 at 10:49 AM, William Stein <wst...@gmail.com> wrote:
>> On Sat, Mar 14, 2009 at 10:29 AM, Carl Witty <carl....@gmail.com> wrote:
>>> 1) Piecewise functions:
>>> With my initial patch,
>>> sage: f = Piecewise([[(-1,1),1/2+x-x^3]])
>>> doesn't work (that is, you get deprecation errors when you call f);
>>> Burcin suggested an optional variable argument to Piecewise, so you
>>> could type this instead:
>>> sage: f = Piecewise([[(-1,1),1/2+x-x^3]], x)
>>
>> This seems reasonable, maybe. Also
>>
>> sage: f(x) = Piecewise([[(-1,1),1/2+x-x^3]])
>>
>> should work.
>>
>> Also "Piecewise" suggests "piecewise *function*" so maybe they *have*
>> to be a function? It's not a peicewise symbolic expression!
>
> Certainly functions are allowed there
No, I meant that the output of Piecewise is supposed to be a
"piecewise *function*", so
> sage: f = Piecewise([[(-1,1),1/2+x-x^3]])
this should be a ValueError.
> to
> sage: f = Piecewise([[(-1,1),(1/2+x-x^3).function(x)]])
> but that's quite a syntactic overhead, especially if you've got lots
> of functions in the list. I like Burcin's shortcut.
>
> sage: f(x) = Piecewise([[(-1,1),1/2+x-x^3]])
>
> is tricky; at least with the current implementation, that means that
> Piecewise(...) (with expressions, not functions) has to be allowable
> as a symbolic expression.
Which is weird...
> I was going to put the deprecation warning
> for this case in the piecewise constructor (so you get the deprecation
> warning when you make the piecewise function, not when you call it);
> allowing f(x) = Piecewise(...) breaks that, as well. So how strongly
> do you feel about f(x) = Piecewise(...)?
I definitely like that.
Honestly, I wouldn't mine Piecewise working like it used to and figure
out how to make a function from each input... since Piecewise makes no
sense if each expression isn't a function.
-- William
Burcin Erocal
Jason Grout <jason...@creativetrax.com> wrote:
I agree with Jason here. I think the variables should be specified
explicitly.
William, shall we treat the case where the only variables in the
expression is x and y specially, and allow not specifying the variables
for the axis then? I think this makes the notation confusing and
inconsistent.
Burcin
Jason Grout
Thanks for trying to come up with a compromise. However, I think
special-casing the variables "x" and "y" would be way more confusing
than either of the options.
Thanks,
Jason
William Stein
I have never ever even once heard of somebody complaining or being
serious confused because these pop up a plot:
sage:
sage: plot(sin(u), (-3,3))
sage: plot3d(x^2 + y^2, (0,3), (-2,3))
I have frequently seen and heard of people being confused by
sage: x(5)
5
Just for historical perspective, when plot was written there was no
symbolic ring in sage and no symbolic variables, so putting (x,0,3)
made no sense...
-- William
Jason Grout
That makes sense, given the history. We have them now, so we can be
better about that sort of thing.
From #sage-devel IRC:
[13:48] <wstein2> I would now consider proposing that now that we have
symbolics we try to renormalize things to be very similar to mathematica
again.
[13:48] <jason--> I agree.
[snip..]
[13:48] <wstein2> If you propose it on sage-devel, i'll write back and
agree, conceeding my point.
To be clear, I think we are agreeing that Carl Witty's proposal point
(2) is okay.
Thanks,
Jason
Burcin Erocal
The latter option also seems harmless when seen only in that context,
but more complicated examples lead to problems. Many people got
confused with that syntax over time, so we decided to deprecate it.
It is a similar situation for the plot commands. Many people have
complained about the inconsistencies in Sage's plotting interface.
Looking at MMA's plot commands, only this syntax is accepted:
Plot[Sin[x], {x, 0, Pi}]
Note the explicit variable name.
I think we should try to make the syntax uniform for all the plot
functions, and ask the user to specify the variable in every case.
(This means deprecating the xmin/xmax parameters of the plot function
as well.)
Thanks.
Burcin
William Stein
Yep, I concede my point. But I would like there to be a more general project
to normalize the plotting syntax to be more consistent with Mathematica.
In particular, xmin/xmax also would have to be deprecated and replaced by
Mathematica's plot_ranges...
William
Jason Grout
Also, on IRC, the "xmin", "xmax", "ymin", and "ymax" parameters were
brought up. These get confusing when different variables are used. A
more MMA-oriented way to do these is to make names that don't assume the
names "x" and "y". It would be great to change these to maybe something
like:
hmin, hmax for horizontal min/max
vmin,vmax for vertical min/max
MMA has a PlotRange option that sets the horizontal and vertical ranges
(i.e., PlotRange->{-2,2} for vertical range of a Plot, or PlotRange->{
{-2,2}, {-3,3}} for Show ).
I think having a plot_range option with similar semantics to the MMA one
would be okay too.
Thanks,
Jason
Jaap Spies
> In particular, xmin/xmax also would have to be deprecated and replaced by
> Mathematica's plot_ranges...
>
As a *former* Maple user I would prefer the syntax plot(expr, var = a..b)
Just joking, I can live with the proposal als long as it is (var, a, b)
and not {var, a, b}
Jaap
William Stein
+1 -- at a bare minimum we should have plot_range. I would I think
be happy having only that.
xmin/xmax should stick around for a long time (deprecated-ish) though,
since they have been used in so much existing code!
william
-- William
Joel B. Mohler
> > William, shall we treat the case where the only variables in the
> > expression is x and y specially, and allow not specifying the variables
> > for the axis then? I think this makes the notation confusing and
> > inconsistent.
>
> I have never ever even once heard of somebody complaining or being
> serious confused because these pop up a plot:
>
> sage:
> sage: plot(sin(u), (-3,3))
> sage: plot3d(x^2 + y^2, (0,3), (-2,3))
>
> I have frequently seen and heard of people being confused by
>
> sage: x(5)
> 5
Evidently, you didn't listen to me approximately 1.5 years ago then. I've
been ardently opposed to the fast-and-loose handling of variables in plot &
friends ever since I started using them. Most of my concrete complaints have
been fixed by the addition of syntax like
sage: parametric_plot((1,t),(t,-12,12))
where the key point is the allowance of 't' in the range tuple.
However, if you are going to make a special case for 'x' and 'y', then, I
don't know what you'd do with this
sage: plot(1,(y,-5,5))
which currently produces a horizontal line from -5 to 5. I don't know what it
should do.
The following a truly sick collection of results (sage 3.3):
sage: var('t,x,y')
(t, x, y)
sage: parametric_plot((1,x),(t,-12,12)) # a vertical line
sage: parametric_plot((1,x),(y,-12,12)) # a vertical line
Yes, those last examples are pathological and stupid, but they should give me
an error so at least I know I'm stupid.
--
Joel
William Stein
Please note that later in the above thread I conceded that I'm wrong,
and now agree with you.
William
Jason Grout
Specifying a variable in every case doesn't work for us. If f is a
python function, or a "function" (in that it has a specified order of
variables), it makes it so that we still need to support (-2,2) syntax.
Jason
Nick Alexander
>
> Plot[Sin[x], {x, 0, Pi}]
>
> Note the explicit variable name.
>
> I think we should try to make the syntax uniform for all the plot
> functions, and ask the user to specify the variable in every case.
> (This means deprecating the xmin/xmax parameters of the plot function
> as well.)
Very strong +1 to this.
Nick
kcrisman
> > Looking at MMA's plot commands, only this syntax is accepted:
>
> > Plot[Sin[x], {x, 0, Pi}]
>
> > Note the explicit variable name.
>
> > I think we should try to make the syntax uniform for all the plot
> > functions, and ask the user to specify the variable in every case.
> > (This means deprecating the xmin/xmax parameters of the plot function
> > as well.)
>
> Specifying a variable in every case doesn't work for us. If f is a
> python function, or a "function" (in that it has a specified order of
> variables), it makes it so that we still need to support (-2,2) syntax.
in one variable like
sage: plot(sin(x),0,pi)
or even
sage: plot(sin,0,pi)
And
sage: plot(1,(y,-5,5))
sage: plot(1,-5,5)
actually seem quite reasonable plotting a horizontal line, which they
do; the variable happens to be y in the first case and (implicitly) x
in the second, but whatever; this information is internal to the
plot. I assume that part 3) of Carl's proposal stands.
I do agree that xmin etc. as names make no sense in the long run,
though pretty much every nonobvious plot ever probably used them...
that might need a 1 year deprecation. It also seems useful to me to
create a plot once, but then have the option of viewing it over many
different ranges, so that it isn't recomputed each time, though
whether that would be an option for plot or show I don't know.
Going back to Jason's point:
> Specifying a variable in every case doesn't work for us. If f is a
> python function, or a "function" (in that it has a specified order of
> variables), it makes it so that we still need to support (-2,2) syntax.
expression with only one reasonable variable choice, it could be
integrated etc? E.g.
sage: integrate(x^2)
x^3/3
sage: integrate(x^2,0,1)
1/3
would still work? (I guess that would involve turning it into a
function internally if it were a symbolic expression?) Again,
removing this sort of unambiguous (and easy/intuitive) thing seems
unreasonable to me. We would be making Sage harder to use for entry-
level users for no particular reason other than pedantry.
If these things stuck around, I guess I could live with f=x^2 yielding
an error upon f(3), though the commonsense idea to me is that if
someone attempted
sage: f=x^2
sage: f(3)
9
sage: f
x |--> x^2
would occur, so that again in an unambiguous one-variable setting a
symbolic expression f would be changed into a one-variable function,
maybe even with a warning message printed out so that foolish freshmen
would never confuse elements of symbolic rings with functions again!
Would such an idea have any traction at all? It doesn't sound
particularly hard to check for.
Incidentally, I have to say that it's weird to be put in the position
of being on the overly pragmatic side of things in this discussion;
that almost never happens to me.
- kcrisman
Rob Beezer
forever forgetting the * for multiplication, but I'm glad the implicit-
multiplication feature has to be consciously turned on - and I don't
plan on ever turning it on. ;-)
I don't want to reopen the debate over the variable 'x' being pre-
defined, but maybe the following proposal/example would be useful.
Consider the new user who happily plots with the variable x several
times, and then tries
sage: parametric_plot( (t,t^2), 0, 1)
to get back
NameError: name 't' is not defined
Wouldn't it be clearer if the error message read
NameError: name 't' is not defined, try var('t') beforehand
or something similar?
Perhaps as Carl deprecates common anticipated behaviors he'd be open
to having his patch adjust the permanent error messages (not just the
deprecation warnings) to give advice on the correct syntax/usage when
possible. I'm starting to see some of this in Ubuntu Linux and the
error messages are giving hints that took me hours to discover on my
own a couple years ago.
Rob
Burcin Erocal
With a little python magic, we can work around this.
sage: def f(x,y):
....: return x + x*y
....:
sage: f.func_code.co_argcount
2
sage: f.func_code.co_varnames
('x', 'y')
We could write a wrapper that takes a python function, and returns
another one that takes keyword arguments. Then the plotting code would
use this wrapper as a preprocessor before doing anything with python
functions.
Cheers,
Burcin
kcrisman
> Wouldn't it be clearer if the error message read
>
> NameError: name 't' is not defined, try var('t') beforehand
>
> or something similar?
>
> Perhaps as Carl deprecates common anticipated behaviors he'd be open
> to having his patch adjust the permanent error messages (not just the
> deprecation warnings) to give advice on the correct syntax/usage when
> possible. I'm starting to see some of this in Ubuntu Linux and the
> error messages are giving hints that took me hours to discover on my
> own a couple years ago.
assuming that this particular error message is usually the right
response to this NameError. That's when I see it, but I assume there
are other times this NameError also appears. Otherwise this sounds
like a ticket to open.
> With a little python magic, we can work around this.
> sage: def f(x,y):
> ....: return x + x*y
> ....:
> sage: f.func_code.co_argcount
> 2
> sage: f.func_code.co_varnames
> ('x', 'y')
>
> We could write a wrapper that takes a python function, and returns
> another one that takes keyword arguments. Then the plotting code would
> use this wrapper as a preprocessor before doing anything with python
> functions.
there should be options, consistency should be possible if we can do
it.
But it just seems weird to me to choose consistency as the overriding
factor, to the point of deprecating *unambiguous* functionality that
already exists and does not cause problems (e.g. plot(x^2,0,1) or
integrate(x^2,0,1) ).
- kcrisman
Ronan Paixão
I agree. As a member of the non-math-teacher part of this list, I must
agree that plot(some_single_var_function_or_expression, 0, 1) should be
considered as valid input.
I believe that as Sage wants to take over the world, it shouldn't be
usable only by Math professionals, but also common people like me, which
don't even know what is a Symbolic Ring is.
OK, I concede that the docs could help with that, and that consistency
is desirable, but that doesn't mean we should always copy Mma. Do we
want to be better or just a clone to it? What exactly is the user target
of Sage? Only math teachers doesn't count as "the whole world" for me.
By the way, to be more explicit, I think the better option would be to
allow single-variable functions or expressions to be plotted directly
without the need (but allowing) to use variable specification in the
range, regardless if the variable is x or anything else, provided
there's only one.
About the xmax, xmin, etc, I think the vmax, vmin, hmax, hmin proposed
before could be used at least for cartesian plots, since vertical and
horizontal directions are common for any used variable. I don't believe
there could be much confusion about that if it's properly described in
the documentation (including plot docstrings). Also, that whould allow
easy porting of old code. Anyway, the xmin, ymax, etc *shouldn't* be
that much confusing anyway, since one must remember that, for example,
Matlab uses semilogy/semilogx functions to specify which axis
(vertical/horizontal) is the logarithmic one (Mma doesn't even have a
way to plot a linear-log plot, at least from a quick glance of the
online docs and not counting more elaborate hacks which I wouldn't
know).
Jason Grout
>
> I agree. As a member of the non-math-teacher part of this list, I must
> agree that plot(some_single_var_function_or_expression, 0, 1) should be
> considered as valid input.
The original proposal by Carl said this would work (see point 3).
(well, he had parentheses around the range, but it was the same idea).
As far as I understand, you are agreeing with the original proposal, then.
Carl: how about also making numerical_integral also have the same
exception? I believe it falls in the same sort of category as plot does
in this situation.
Jason
kcrisman
with an alternately specified variable, e.g.
sage: numerical_integral(x^2,x,0,1)
which currently throws an error of having specified integration
algorithm of 1. This is an example where the current behavior doesn't
allow simply slapping "numerical_" in front of something with only one
variable, so it's not even possible to *be* consistent the way it's
currently written. That would be easy to fix, though, as an option
for input.
Also, just for clarification - maybe I'm misinterpreting something -
will Carl's proposal allow
sage: integrate(x^2)
x^3/3
or not?
sage: y=var('y',ns=1)
Current ns behavior requires
sage: f(y)=y^2
sage: integrate(f)
y |--> y^3/3
while directly doing
sage: integrate(y^2)
---------------------------------------------------------------------------
TypeError Traceback (most recent call
last)
TypeError: cannot coerce type '<type
'sage.symbolic.expression.Expression'>' into a SymbolicExpression.
Of course, the current error is because we haven't done the switch to
Pynac for everything yet. Why this would not still be valid input (to
echo Ronan) after the switch is mystifying to me - again, or perhaps I
have misinterpreted the deprecation proposal.
- kcrisman
Jason Grout
>
>>> I agree. As a member of the non-math-teacher part of this list, I must
>>> agree that plot(some_single_var_function_or_expression, 0, 1) should be
>>> considered as valid input.
>> The original proposal by Carl said this would work (see point 3).
>> (well, he had parentheses around the range, but it was the same idea).
>> As far as I understand, you are agreeing with the original proposal, then.
>>
>> Carl: how about also making numerical_integral also have the same
>> exception? I believe it falls in the same sort of category as plot does
>> in this situation.
>
> In fact, it is somewhat annoying that one can't do numerical_integral
> with an alternately specified variable, e.g.
> sage: numerical_integral(x^2,x,0,1)
> which currently throws an error of having specified integration
> algorithm of 1. This is an example where the current behavior doesn't
> allow simply slapping "numerical_" in front of something with only one
> variable, so it's not even possible to *be* consistent the way it's
> currently written. That would be easy to fix, though, as an option
> for input.
>
> Also, just for clarification - maybe I'm misinterpreting something -
> will Carl's proposal allow
>
> sage: integrate(x^2)
> x^3/3
>
> or not?
That should work, as it is just asking for the integral of a symbolic
expression. Similarly, diff should work, etc. Those functions do not
require the expression to be callable.
With Carl's patch on the trac ticket:
sage: integrate(x^2)
x^3/3
>
> sage: y=var('y',ns=1)
>
> Current ns behavior requires
>
> sage: f(y)=y^2
> sage: integrate(f)
> y |--> y^3/3
>
> while directly doing
>
> sage: integrate(y^2)
> ---------------------------------------------------------------------------
> TypeError Traceback (most recent call
> last)
> TypeError: cannot coerce type '<type
> 'sage.symbolic.expression.Expression'>' into a SymbolicExpression.
>
> Of course, the current error is because we haven't done the switch to
> Pynac for everything yet. Why this would not still be valid input (to
> echo Ronan) after the switch is mystifying to me - again, or perhaps I
> have misinterpreted the deprecation proposal.
Yes, the above error looks like it's from pynac not being finished, not
from specific design choice.
Jason
Joel B. Mohler
> sage: integrate(y^2)
> ---------------------------------------------------------------------------
> TypeError Traceback (most recent call
> last)
> TypeError: cannot coerce type '<type
> 'sage.symbolic.expression.Expression'>' into a SymbolicExpression.
>
> Of course, the current error is because we haven't done the switch to
> Pynac for everything yet. Why this would not still be valid input (to
> echo Ronan) after the switch is mystifying to me - again, or perhaps I
> have misinterpreted the deprecation proposal.
Here's my reason for wanting it deprecated. It's fragile in the face of
unexpected input (I don't like being lulled into a false sense that my code
works when suddenly it wouldn't work for a constant input):
sage: f=x
sage: # many lines of code
sage: integrate(f)
x^2/2
sage: f=1
sage: # many lines of code
sage: integrate(f) # what does this mean?
... hangs maxima ...
sage: integrate(f,x) # what does this mean?
Now, the fact that the "integrate(1)" hangs maxima is probably a bug all it's
own.
--
Joel
Joel B. Mohler
> On Monday 16 March 2009 12:27:10 pm kcrisman wrote:
> > sage: integrate(y^2)
> > -------------------------------------------------------------------------
> > last)
> > TypeError: cannot coerce type '<type
> > 'sage.symbolic.expression.Expression'>' into a SymbolicExpression.
> >
> > Of course, the current error is because we haven't done the switch to
> > Pynac for everything yet. Why this would not still be valid input (to
> > echo Ronan) after the switch is mystifying to me - again, or perhaps I
> > have misinterpreted the deprecation proposal.
>
> Here's my reason for wanting it deprecated. It's fragile in the face of
> unexpected input (I don't like being lulled into a false sense that my code
> works when suddenly it wouldn't work for a constant input):
>
> sage: f=x
> sage: # many lines of code
> sage: integrate(f)
> x^2/2
>
> sage: f=1
> sage: # many lines of code
> sage: integrate(f) # what does this mean?
> ... hangs maxima ...
> sage: integrate(f,x) # what does this mean?
>
> Now, the fact that the "integrate(1)" hangs maxima is probably a bug all
> it's own.
Sorry for the self reply, amend that second example to clarify my intent:
sage: f=1
sage: # many lines of code
sage: integrate(f) # what does this mean?
...
sage: integrate(f,x)
x
Perhaps I should also say that I actually found the original versions of plot
outright confusing because I *didn't* have to specify the variable.
Mathematically, it's supposed to be a dummy variable so it should have to be
specified. Maybe I'm just silly and pedantic, but the fact that it
automatically "dummified" my variable confused me. I do realized that these
things can be done in a well-defined way, but the fact that the 0 variable
case was (and is) a source of bugs leads me to believe that no one really
understood this at the start and that didn't give me confidence in the
design.
But I think the decision is already made so I apologize for the dead-horse
beating. My only motivation was to answer the question about why it's
deprecated (from my point of view, which may be totally weird).
--
Joel
William Stein
I'm definitely OK with this discussion continuing, and I greatly
appreciate your feedback! And by the way, "welcome back" to Sage,
since I hadn't heard from you must on sage-devel in a while.
-- William
Carl Witty
This seems like an excellent reason to deprecate
integrate(SYMBOLIC_EXPR), and I would vote in favor of doing so, but
my patch won't do it. (My patch is about deprecating __call__, and
things that invoke __call__ or the equivalent; symbolic integration
doesn't call the expression.)
Note that plot(1, (5, 7)) and numerical_integral(1, (5, 7)) don't have
the same problem, and I'm currently not planning to deprecate them.
(It's not always entirely clear who was agreeing to what proposal, but
I get the impression that this is a compromise everybody can live
with.)
Carl
Robert Bradshaw
These are my thoughts too, though I see the pros and cons. For
example, is "y + x - y" a function of one variable? Things should be
*much* tighter than the are now though.
> About the xmax, xmin, etc, I think the vmax, vmin, hmax, hmin proposed
> before could be used at least for cartesian plots, since vertical and
> horizontal directions are common for any used variable.
Personally, I would expect xmin, xmax, etc. well before I would
expect hmin, hmax... even if I'm graphing something that doesn't have
an x. Imagine graphing h(x).
- Robert
kcrisman
> Sorry for the self reply, amend that second example to clarify my intent:
> sage: f=1
> sage: # many lines of code
> sage: integrate(f) # what does this mean?
> ...
> sage: integrate(f,x)
> x
>
> Perhaps I should also say that I actually found the original versions of plot
> outright confusing because I *didn't* have to specify the variable.
> Mathematically, it's supposed to be a dummy variable so it should have to be
> specified. Maybe I'm just silly and pedantic, but the fact that it
> automatically "dummified" my variable confused me. I do realized that these
> things can be done in a well-defined way, but the fact that the 0 variable
> case was (and is) a source of bugs leads me to believe that no one really
> understood this at the start and that didn't give me confidence in the
> design.
thoughts were exactly the opposite - that it doesn't matter what the
'dummy' variable is, so if there is only one possibility you might as
well take the one that's there, e.g. in "1" we take the only
predefined variable "x" as the one.
sage: integrate(1)
x
is probably the correct answer, to be honest.
But as you say, dead horses, and I'm verging on that too now.
- kcrisman