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