On 03/02/2016 11:45 AM, Nils Bruin wrote:
> 
> It's easy to explain "expressions do not support calling syntax. You
> need a function for that".
> It's hard to explain "expressions don't really support calling, except
> in some edge cases that you will initially encounter most".
> By having the muddling exceptions, you make it harder for novice users
> to start learning the difference between a symbolic expression and a
> symbolic function; a difference they'll need later anyway.
> If you don't want to talk about functions at all, just use "subs".
> 

I went back and looked at all of the piecewise code I wrote during that
era. I was able to fix it all to avoid the DeprecationWarnings (thanks).

But, proposing that we get rid of symbolic expressions in piecewise
functions is stronger than the proposal to get rid of unnamed arguments.
This works, and accounts for just about every use of piecewise() you'll
find, even the ones in the Sage library:

  sage: f = piecewise([[(-1,1),x]])
  sage: f.plot()

The proposal would require,

  sage: f = piecewise([[(-1,1), x.function(x)]])

which is a little weird and not used anywhere that I've seen. Some other
odd cases that I ran into were,

  f = cos(x).function(x)

and of course the constants,

  f = SR(1).function(x)

But overall I agree that forcing piecewise() to take functions creates a
better mental model. It just may be harder to get rid of than the
unnamed-argument function call syntax alone.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Reply via email to