Dear all,
I am so glad to hear that the implicit substitutions are going to go! It
is so much clearer to write e.g.
var('a b c x')
f = a*x^2 + b*x + c
f(x=4,a=1,b=3,c=2)
rather than
f(1,3,2,4)
to get the desired result. Most people I know got burned with implicit
assumptions in Fortran until they learned to always put 'implicit none'
at the top of their code.
While talking about substitutions, could someone have a look at thread
http://groups.google.com/group/sage-support/browse_thread/thread/0f1086c43611242a?
It seems that subs(locals()) still causes problems and I am sure you are
the right people to fix it. Sorry for distracting from the issue at hand. :)
All the best,
Stan
William Stein wrote:
> On Thu, Feb 26, 2009 at 8:38 PM, Carl Witty <carl.wi...@gmail.com> wrote:
>
>> On Thu, Feb 26, 2009 at 8:06 PM, kcrisman <kcris...@gmail.com> wrote:
>>
>>>> Consider this:
>>>> sage: E = (x+3)*sin(x)
>>>> sage: E(5)
>>>> 8*sin(5)
>>>> sage: E.subs(x=5)
>>>> 8*sin(5)
>>>>
>>>> So E(5) is treated as a shorthand for E.subs(x=5).
>>>>
>>>> Now if we consider:
>>>> sage: var('f x')
>>>> (f, x)
>>>> sage: f(x+3)
>>>> x + 3
>>>> sage: f.subs(f=x+3)
>>>> x + 3
>>>>
>>>> it's the exact same thing.
>>>>
>>>> This causes trouble in other situations, as well; if you wanted
>>>> multiplication, but you left off the '*' symbol:
>>>> sage: x(x+1)
>>>> x + 1
>>>> sage: x.subs(x=x+1)
>>>> x + 1
>>>>
>>> This would only be ambiguous for current Sage behavior if
>>> ImplicitMultiplication=True, correct (if even there)? Just checking;
>>> perhaps there are other places this notation occurs I haven't seen,
>>> and I would be very interested in that if it were the case.
>>>
>> I'm not sure what you're trying to say here. Are you saying that
>> since x(x+1) has no other useful meaning, we might as well make it
>> mean x+1?
>>
>>
>>>> I've argued before that this shorthand should be removed because it's
>>>> too confusing, but I haven't managed to convince enough people, so
>>>> it's still there. (The shorthand isn't there in the new, Pynac-based
>>>> symbolics, so when we switch over to that system, this particular
>>>> source of confusion will be gone.)
>>>>
>>> Hmm, I didn't know that. So I tried it.
>>>
>>> sage: f=x^2
>>> sage: f(2)
>>> 4
>>> sage: y=var('y',ns=1)
>>> sage: g=y^2
>>> sage: g(2)
>>> <long error message telling me subs doesn't work here>
>>>
>>> So does that mean that this particular shorthand for subs will never
>>> reappear in Pynac, or just that as currently implemented it doesn't
>>> use it? It doesn't look all that difficult to do a check for
>>> 'unambiguity' ala Robert's comment:
>>> sage: g.variables()==1
>>> True
>>> and then do something like
>>> sage: temp=g.variables()[0]
>>> sage: g.subs(temp=2)
>>> 4
>>> in the symbolic/expression.pyx code. Or am I missing something? I
>>> understand the point about multi-variable situations.
>>>
>> I hope that the shorthand does not come back, but I don't know that
>> any sort of final decision has been made. I don't think it's
>> technically difficult to implement, I just think it's a bad idea.
>>
>
> I also think it is a bad idea, and I believe that Burcin and I decided
> (as a "final decision") that the shorthand will not be in the new
> Pynac. I think it was a condition for Burcin to keep working on the
> new Pynac in fact :-).
>
> I'm amazed that implicit calling of symbolic expressions is still in
> Sage. I knew that it absolutely *had* to go while watching repeatedly
> the problems it causes in the high school students in a summer course
> I taught using Sage over a year ago.
>
>
>>> Anyway, as several have commented, this discussion has taken place
>>> many times before, but having to use
>>> sage: f(x)=x^2
>>> instead of
>>> sage: f=x^2
>>> many times for single-variable symbolic expressions could be very
>>> annoying in the long run, IMHO. Let's not be stultified by trying to
>>> solve computer problems when this is mathematical software; the
>>> distinction between symbolic and callable-symbolic seems different to
>>> me than e.g. formal power series versus actually convergent ones.
>>> FWIW.
>>>
>> I don't understand this paragraph at all. What problem are you
>> talking about? The problem I see is that people are confused when
>> x(x+1) gives them (x+1); I wouldn't call that a computer problem
>> exactly.
>>
>
> Just out of curiosity, do you think we should also get rid of this?
>
> sage: R.<x> = ZZ[]
> sage: x(x+1)
> x + 1
>
> -- William
>
> >
>
--
________________________________________
Stan Schymanski
Scientist
Max Planck Institute for Biogeochemistry
Postfach 10 01 64
D-07701 Jena
Phone: +49.3641.576264
Fax: +49.3641.577274
WWW: http://www.bgc-jena.mpg.de/~sschym
Biospheric Theory and Modelling Group
http://www.bgc-jena.mpg.de/bgc-theory/
_________________________________________
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
