[sage-devel] Re: deprecating calling of symbolic expressions without variable names
Ronan Paixão wrote: 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 --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: deprecating calling of symbolic expressions without variable names
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?
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
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: deprecating calling of symbolic expressions without variable names
kcrisman wrote:
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
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: deprecating calling of symbolic expressions without variable names
On Monday 16 March 2009 12:27:10 pm kcrisman wrote: 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 --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: deprecating calling of symbolic expressions without variable names
On Monday 16 March 2009 02:51:30 pm Joel B. Mohler wrote: On Monday 16 March 2009 12:27:10 pm kcrisman wrote: 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. 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 --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: deprecating calling of symbolic expressions without variable names
On Mon, Mar 16, 2009 at 12:03 PM, Joel B. Mohler j...@kiwistrawberry.us wrote: On Monday 16 March 2009 02:51:30 pm Joel B. Mohler wrote: On Monday 16 March 2009 12:27:10 pm kcrisman wrote: 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. 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). 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 --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: deprecating calling of symbolic expressions without variable names
On Mar 15, 2009, at 7:29 PM, Ronan Paixão wrote:
Em Dom, 2009-03-15 às 17:11 -0700, kcrisman escreveu:
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.
This is an excellent idea no matter what is happening with variables,
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.
Certainly it makes sense to make this *possible*! Sure - absolutely,
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) ).
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.
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
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: deprecating calling of symbolic expressions without variable names
On Sat, 14 Mar 2009 14:10:32 -0500
Jason Grout jason-s...@creativetrax.com wrote:
Burcin Erocal wrote:
On Sat, 14 Mar 2009 11:45:13 -0700
William Stein wst...@gmail.com wrote:
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.)
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.
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
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: deprecating calling of symbolic expressions without variable names
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.
This is an excellent idea no matter what is happening with variables,
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.
Certainly it makes sense to make this *possible*! Sure - absolutely,
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
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: deprecating calling of symbolic expressions without variable names
Em Dom, 2009-03-15 às 17:11 -0700, kcrisman escreveu:
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.
This is an excellent idea no matter what is happening with variables,
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.
Certainly it makes sense to make this *possible*! Sure - absolutely,
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) ).
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).
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: deprecating calling of symbolic expressions without variable names
On Sat, Mar 14, 2009 at 10:29 AM, Carl Witty carl.wi...@gmail.com wrote: 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) 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! 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) 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). +1 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. +1 -- it's _fast_float_ anyways, so mainly for internal use. Carl -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: deprecating calling of symbolic expressions without variable names
William Stein wrote: On Sat, Mar 14, 2009 at 10:29 AM, Carl Witty carl.wi...@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 --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: deprecating calling of symbolic expressions without variable names
On Sat, Mar 14, 2009 at 11:09 AM, Jason Grout jason-s...@creativetrax.com wrote: William Stein wrote: On Sat, Mar 14, 2009 at 10:29 AM, Carl Witty carl.wi...@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. 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 --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: deprecating calling of symbolic expressions without variable names
William Stein wrote: On Sat, Mar 14, 2009 at 11:09 AM, Jason Grout jason-s...@creativetrax.com wrote: William Stein wrote: On Sat, Mar 14, 2009 at 10:29 AM, Carl Witty carl.wi...@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. Well then we disagree. There is a very standard convention in math to have the x axis in one spot, then the y-axis. 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 --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: deprecating calling of symbolic expressions without variable names
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.wi...@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 --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: deprecating calling of symbolic expressions without variable names
On Sat, Mar 14, 2009 at 11:18 AM, Jason Grout jason-s...@creativetrax.com wrote: William Stein wrote: On Sat, Mar 14, 2009 at 11:09 AM, Jason Grout jason-s...@creativetrax.com wrote: William Stein wrote: On Sat, Mar 14, 2009 at 10:29 AM, Carl Witty carl.wi...@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. Well then we disagree. There is a very standard convention in math to have the x axis in one spot, then the y-axis. 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. As long as there are clear labels I'm very fine with alphabetical 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. That would be a very good idea. Jason -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: deprecating calling of symbolic expressions without variable names
On Sat, Mar 14, 2009 at 11:18 AM, Jason Grout jason-s...@creativetrax.com wrote: William Stein wrote: Well then we disagree. There is a very standard convention in math to have the x axis in one spot, then the y-axis. 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. 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 --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: deprecating calling of symbolic expressions without variable names
On Sat, Mar 14, 2009 at 11:27 AM, Carl Witty carl.wi...@gmail.com wrote: 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.wi...@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 --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: deprecating calling of symbolic expressions without variable names
On Sat, 14 Mar 2009 13:18:40 -0500 Jason Grout jason-s...@creativetrax.com wrote: William Stein wrote: On Sat, Mar 14, 2009 at 11:09 AM, Jason Grout jason-s...@creativetrax.com wrote: William Stein wrote: On Sat, Mar 14, 2009 at 10:29 AM, Carl Witty carl.wi...@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. Well then we disagree. There is a very standard convention in math to have the x axis in one spot, then the y-axis. 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. 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 --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: deprecating calling of symbolic expressions without variable names
Carl Witty wrote: On Sat, Mar 14, 2009 at 11:18 AM, Jason Grout jason-s...@creativetrax.com wrote: William Stein wrote: Well then we disagree. There is a very standard convention in math to have the x axis in one spot, then the y-axis. 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. 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. 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 --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: deprecating calling of symbolic expressions without variable names
On Sat, Mar 14, 2009 at 11:37 AM, Burcin Erocal bur...@erocal.org wrote: On Sat, 14 Mar 2009 13:18:40 -0500 Jason Grout jason-s...@creativetrax.com wrote: William Stein wrote: On Sat, Mar 14, 2009 at 11:09 AM, Jason Grout jason-s...@creativetrax.com wrote: William Stein wrote: On Sat, Mar 14, 2009 at 10:29 AM, Carl Witty carl.wi...@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. Well then we disagree. There is a very standard convention in math to have the x axis in one spot, then the y-axis. 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. 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. 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 --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: deprecating calling of symbolic expressions without variable names
William Stein wrote: On Sat, Mar 14, 2009 at 11:37 AM, Burcin Erocal bur...@erocal.org wrote: On Sat, 14 Mar 2009 13:18:40 -0500 Jason Grout jason-s...@creativetrax.com wrote: William Stein wrote: On Sat, Mar 14, 2009 at 11:09 AM, Jason Grout jason-s...@creativetrax.com wrote: William Stein wrote: On Sat, Mar 14, 2009 at 10:29 AM, Carl Witty carl.wi...@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. Well then we disagree. There is a very standard convention in math to have the x axis in one spot, then the y-axis. 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. 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. 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... 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 --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: deprecating calling of symbolic expressions without variable names
On Sat, 14 Mar 2009 11:45:13 -0700
William Stein wst...@gmail.com wrote:
On Sat, Mar 14, 2009 at 11:37 AM, Burcin Erocal bur...@erocal.org
wrote:
On Sat, 14 Mar 2009 13:18:40 -0500
Jason Grout jason-s...@creativetrax.com wrote:
William Stein wrote:
On Sat, Mar 14, 2009 at 11:09 AM, Jason Grout
jason-s...@creativetrax.com wrote:
William Stein wrote:
On Sat, Mar 14, 2009 at 10:29 AM, Carl Witty
carl.wi...@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.
Well then we disagree. There is a very standard convention in
math to have the x axis in one spot, then the y-axis.
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.
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.
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
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
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: deprecating calling of symbolic expressions without variable names
On Sat, Mar 14, 2009 at 11:52 AM, Jason Grout jason-s...@creativetrax.com wrote: William Stein wrote: On Sat, Mar 14, 2009 at 11:37 AM, Burcin Erocal bur...@erocal.org wrote: On Sat, 14 Mar 2009 13:18:40 -0500 Jason Grout jason-s...@creativetrax.com wrote: William Stein wrote: On Sat, Mar 14, 2009 at 11:09 AM, Jason Grout jason-s...@creativetrax.com wrote: William Stein wrote: On Sat, Mar 14, 2009 at 10:29 AM, Carl Witty carl.wi...@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. Well then we disagree. There is a very standard convention in math to have the x axis in one spot, then the y-axis. 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. 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. 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... 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. 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 --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: deprecating calling of symbolic expressions without variable names
Jason Grout wrote:
William Stein wrote:
On Sat, Mar 14, 2009 at 11:37 AM, Burcin Erocal bur...@erocal.org wrote:
On Sat, 14 Mar 2009 13:18:40 -0500
Jason Grout jason-s...@creativetrax.com wrote:
William Stein wrote:
On Sat, Mar 14, 2009 at 11:09 AM, Jason Grout
jason-s...@creativetrax.com wrote:
William Stein wrote:
On Sat, Mar 14, 2009 at 10:29 AM, Carl Witty
carl.wi...@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.
Well then we disagree. There is a very standard convention in math
to have the x axis in one spot, then the y-axis.
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.
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.
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...
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.
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
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: deprecating calling of symbolic expressions without variable names
William Stein wrote:
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
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: deprecating calling of symbolic expressions without variable names
On Sat, Mar 14, 2009 at 12:07 PM, Jason Grout
jason-s...@creativetrax.com wrote:
Jason Grout wrote:
William Stein wrote:
On Sat, Mar 14, 2009 at 11:37 AM, Burcin Erocal bur...@erocal.org wrote:
On Sat, 14 Mar 2009 13:18:40 -0500
Jason Grout jason-s...@creativetrax.com wrote:
William Stein wrote:
On Sat, Mar 14, 2009 at 11:09 AM, Jason Grout
jason-s...@creativetrax.com wrote:
William Stein wrote:
On Sat, Mar 14, 2009 at 10:29 AM, Carl Witty
carl.wi...@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.
Well then we disagree. There is a very standard convention in math
to have the x axis in one spot, then the y-axis.
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.
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.
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...
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.
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.
+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
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: deprecating calling of symbolic expressions without variable names
On Saturday 14 March 2009 02:45:13 pm William Stein wrote:
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
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: deprecating calling of symbolic expressions without variable names
On Sat, Mar 14, 2009 at 12:10 PM, Joel B. Mohler j...@kiwistrawberry.us wrote:
On Saturday 14 March 2009 02:45:13 pm William Stein wrote:
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.
Please note that later in the above thread I conceded that I'm wrong,
and now agree with you.
William
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: deprecating calling of symbolic expressions without variable names
Burcin Erocal wrote:
On Sat, 14 Mar 2009 11:45:13 -0700
William Stein wst...@gmail.com wrote:
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.)
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
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: deprecating calling of symbolic expressions without variable names
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.)
Very strong +1 to this.
Nick
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: deprecating calling of symbolic expressions without variable names
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.
Yes, it seems pointless to *remove* unambiguous simpler syntax options
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.
Can one make a similar argument about integration - that if one has an
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
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: deprecating calling of symbolic expressions without variable names
I would vote for consistency over convenience every time. I am
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
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
