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
-~----------~----~----~----~------~----~------~--~---
