[sage-devel] Re: coercion error: calling functions with vector inputs
On 27-Oct-09, at 3:17 PM, Jason Grout wrote:
I was looking at how to make my calc 3 calculations easier to
understand
by calling a multivariable function with a vector input. I ended up
with a coercion error. I'm not that familiar with how to work with
the
coercion system. Would it be easy to make the call f(r) work below?
Thanks,
Jason
sage: var('t')
t
sage: r=vector([t,t^2])
sage: f(x,y)=x^2+y
sage: f(r)
This isn't really a coercion error. f expects two inputs; you've
given it one. Try f(*r).
Fixing this means adding yet another special case; I vote strongly
against. (BTW, all my work these days involves symbolic functions of
vector inputs, so I've dealt with this a lot and still believe adding
a special case is a bad idea.)
Nick
--~--~-~--~~~---~--~~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: coercion error: calling functions with vector inputs
Nick Alexander wrote:
On 27-Oct-09, at 3:17 PM, Jason Grout wrote:
I was looking at how to make my calc 3 calculations easier to
understand
by calling a multivariable function with a vector input. I ended up
with a coercion error. I'm not that familiar with how to work with
the
coercion system. Would it be easy to make the call f(r) work below?
Thanks,
Jason
sage: var('t')
t
sage: r=vector([t,t^2])
sage: f(x,y)=x^2+y
sage: f(r)
This isn't really a coercion error. f expects two inputs; you've
given it one. Try f(*r).
Fixing this means adding yet another special case; I vote strongly
against. (BTW, all my work these days involves symbolic functions of
vector inputs, so I've dealt with this a lot and still believe adding
a special case is a bad idea.)
Why do you think that f, which is a function from R^2-R^1, should not
naturally be able to take inputs that live in R^2?
Thanks,
Jason
--
Jason Grout
--~--~-~--~~~---~--~~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: coercion error: calling functions with vector inputs
Why do you think that f, which is a function from R^2-R^1, should not naturally be able to take inputs that live in R^2? I don't. But that's not the way that Python works, and the existing implementation tries to make f(x, y) look like a Python function of two variables. I would be fine if it instead made f(x, y) a function accepting one variable (a vector in R^2) -- but that's even stranger in the more common case when you really want a function from, say R x C - C. Then you'd need to say f([x, y]) or something equally nutty. Nick --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: coercion error: calling functions with vector inputs
On Oct 27, 7:34 pm, Nick Alexander ncalexan...@gmail.com wrote: Why do you think that f, which is a function from R^2-R^1, should not naturally be able to take inputs that live in R^2? I don't. But that's not the way that Python works, and the existing implementation tries to make f(x, y) look like a Python function of two variables. I would be fine if it instead made f(x, y) a function accepting one variable (a vector in R^2) -- but that's even stranger in the more common case when you really want a function from, say R x C - C. Then you'd need to say f([x, y]) or something equally nutty. But this seems like an easy case to catch, and is very mathematically natural and user-friendly, esp. for going back and forth between matrix stuff and calculus stuff like one often does in sophomore-level courses. Certainly we shouldn't *require* a tuple or list as input - that would be silly, I agree. - kcrisman --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: coercion error: calling functions with vector inputs
Nick Alexander wrote: Why do you think that f, which is a function from R^2-R^1, should not naturally be able to take inputs that live in R^2? I don't. But that's not the way that Python works, and the existing implementation tries to make f(x, y) look like a Python function of two variables. I would be fine if it instead made f(x, y) a function accepting one variable (a vector in R^2) -- but that's even stranger in the more common case when you really want a function from, say R x C - C. Then you'd need to say f([x, y]) or something equally nutty. Okay, you've got a point with the R x C - C case. However, I think mathematical convention and easy of use would be enough to justify the special case: v=vector(...) # n dimensional f(...)=... # f takes n numbers f(v) # behaves like f(*v) Note that we already do that for things like parametric_plot, derivatives, etc. So it sounds like we would just come down on opposite sides of this issue. Does someone else want to vote? Thanks, Jason -- Jason Grout --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: coercion error: calling functions with vector inputs
On Tue, Oct 27, 2009 at 5:28 PM, Jason Grout
jason-s...@creativetrax.com wrote:
Nick Alexander wrote:
Why do you think that f, which is a function from R^2-R^1, should not
naturally be able to take inputs that live in R^2?
I don't. But that's not the way that Python works, and the existing
implementation tries to make f(x, y) look like a Python function of
two variables. I would be fine if it instead made f(x, y) a function
accepting one variable (a vector in R^2) -- but that's even stranger
in the more common case when you really want a function from, say R x
C - C. Then you'd need to say f([x, y]) or something equally nutty.
Okay, you've got a point with the R x C - C case. However, I think
mathematical convention and easy of use would be enough to justify the
special case:
v=vector(...) # n dimensional
f(...)=... # f takes n numbers
f(v) # behaves like f(*v)
Note that we already do that for things like parametric_plot,
derivatives, etc.
So it sounds like we would just come down on opposite sides of this
issue. Does someone else want to vote?
Before voting, may I register some concerns?
1. Recall your example:
sage: t = var('t')
sage: r=vector([t,t^2])
sage: f(x,y)=x^2+y
sage: f(r)
boom.
If we make f(r) work (as you propose), note that the following will
still not work, and can never ever be made to work:
sage: t = var('t')
sage: r=vector([t,t^2])
sage: f=lambda x,y: x^2+y
sage: f(r)
boom!
and equally:
sage: def f(x,y): return x^2+y
sage: f(r)
boom.
There is already a lot of confusion that results from the difference
between callable symbolic expressions (symbolic functions) and
Python functions. I'm worried that Jason's proposal would add yet
another point of confusion.
2. A second concern is that at some point we will enhance symbolic
expressions to more naturally take vectors as input (I played with
Bill Furnish's symbolics rewrite and remember it being good at this
sort of thing, and it being natural for expressing certain things).
Then the following will work:
sage: t=var('t')
sage: f(x,y) = 2*x + 3*y
sage: r=vector([t,t^2]); s = vector([t,sin(t)])
sage: f(r,r)
(5*t, 2*t^2 + 3*sin(t))
and this already does work:
sage: f = lambda x, y: 2*x + 3*y
sage: f(r,s)
(5*t, 2*t^2 + 3*sin(t))
You are proposing that we have in the first case above:
sage: f(r)
3*t^2 + 2*t
That is unsettling at best.
I think what you really want is something *like* this:
sage: f(x) = 2*x[0] + 3*x[1]
sage: r=vector([t,t^2])
sage: f(r)
3*t^2 + 2*t
Something like the above could certainly be implemented in the context
of the pynac-based symbolics, though I doubt it would be trivial. I
can't see how we'll avoid having to do this at some point tough. I
would love hear from Burcin on this.
As a test one could imagine defining a new symbolic function get
which takes two inputs, say get(x,i). It simplifies to return x[i] if
x has a __getitem__ method and otherwise just stays as get(x,i).
Then we could try
sage: f(x) = 2*get(x,0) + 3*get(x,1)
-- William
--~--~-~--~~~---~--~~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: coercion error: calling functions with vector inputs
William Stein wrote:
Before voting, may I register some concerns?
1. Recall your example:
sage: t = var('t')
sage: r=vector([t,t^2])
sage: f(x,y)=x^2+y
sage: f(r)
boom.
If we make f(r) work (as you propose), note that the following will
still not work, and can never ever be made to work:
sage: t = var('t')
sage: r=vector([t,t^2])
sage: f=lambda x,y: x^2+y
sage: f(r)
boom!
and equally:
sage: def f(x,y): return x^2+y
sage: f(r)
boom.
There is already a lot of confusion that results from the difference
between callable symbolic expressions (symbolic functions) and
Python functions. I'm worried that Jason's proposal would add yet
another point of confusion.
These are great examples. Given these two examples, I think Nick (and
you?) are right that the resulting confusion would be worse than
teaching students that to pass a vector, they need to either dismantle
the vector into components f(*r), or define the function to actually
take a vector like f(v)=v[0]*2+v[1]^2 (once we have the necessary
changes; see below).
So I officially withdraw my proposal. Thanks for the discussion.
2. A second concern is that at some point we will enhance symbolic
expressions to more naturally take vectors as input (I played with
Bill Furnish's symbolics rewrite and remember it being good at this
sort of thing, and it being natural for expressing certain things).
Then the following will work:
sage: t=var('t')
sage: f(x,y) = 2*x + 3*y
sage: r=vector([t,t^2]); s = vector([t,sin(t)])
sage: f(r,r)
(5*t, 2*t^2 + 3*sin(t))
You can sort of manipulate this to get it to work, since you can convert
a matrix to a symbolic expression:
sage: f(x,y) = 2*x + 3*y
sage: r=matrix([[t,t^2]]); s = matrix([[t,sin(t)]])
sage: f(SR(r), SR(r))
[ 5*t 5*t^2]
sage: f(SR(r), SR(s))
[ 5*t 2*t^2 + 3*sin(t)]
so it looks like all you need to do is
* Make vectors behave like matrices, so that SR(vector([1,2])) works
* automatically cast symbolic function arguments to SR
Thanks,
Jason
--
Jason Grout
--~--~-~--~~~---~--~~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: coercion error: calling functions with vector inputs
Note that we already do that for things like parametric_plot, derivatives, etc. And it's a continual pain in the ass. Telling the difference between a list, tuple, sequence, iterator, vector, multiple arguments, etc... in Python, it's just all so inconsistent. But it seems like the feature is wanted, so no matter how inconsistent and buggy it all is, we'll add it. Nick --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: coercion error: calling functions with vector inputs
Nick Alexander wrote: Note that we already do that for things like parametric_plot, derivatives, etc. And it's a continual pain in the ass. Telling the difference between a list, tuple, sequence, iterator, vector, multiple arguments, etc... in Python, it's just all so inconsistent. But it seems like the feature is wanted, so no matter how inconsistent and buggy it all is, we'll add it. Actually, in thinking about this more, I think I was wrong in saying this conversation was like what happens for parametric_plot and derivatives. In the case of parametric_plot, we treat a vector as a list, so parametric_plot(v,...) is the same as parametric_plot(list(v),...). In the case of derivatives, we do things component-wise, so diff(v,...) is treated as v.apply_map(lambda x: diff(x,...)). Wow; both of those cases are not only not like what we are talking about now, but they are also not even like each other. Sorry! Jason -- Jason Grout --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: coercion error: calling functions with vector inputs
On Tue, Oct 27, 2009 at 9:04 PM, Nick Alexander ncalexan...@gmail.com wrote: Note that we already do that for things like parametric_plot, derivatives, etc. And it's a continual pain in the ass. Telling the difference between a list, tuple, sequence, iterator, vector, multiple arguments, etc... in Python, it's just all so inconsistent. But it seems like the feature is wanted, so no matter how inconsistent and buggy it all is, we'll add it. Nick Nick, I just want to personally thank you for your comments in this thread (and others!). I think they were extremely helpful and clarifying, at least to me, in understanding the issue being discussed and coming up with several examples to... show you are in fact right. If it hadn't been for your comments, we could very well have ended up making an incorrect design decision. Thanks, William --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: coercion error: calling functions with vector inputs
William Stein wrote: I just want to personally thank you for your comments in this thread (and others!). I think they were extremely helpful and clarifying, at least to me, in understanding the issue being discussed and coming up with several examples to... show you are in fact right. If it hadn't been for your comments, we could very well have ended up making an incorrect design decision. Indeed! You've shown remarkable insight in having clean, elegant design. Jason -- Jason Grout --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
