On Monday 17 December 2007 15:07, Robert Bradshaw wrote: > > It is so not obvious that f(2) and f(1) are different in any major > > way. I can > > imagine situations like the above cropping up in much more subtle > > ways and > > being totally inscrutable. So, in short, I believe that the > > current design > > makes __call__ nearly useless for serious programming beyond one- > > liners. > > However, if we had to make things callable explicitly, the variables, > > variable order and all such things are perfectly clear. > > FYI, there is a way to make explicitly callable functions. > > sage: f(x) = x*sin(0) > sage: f(3) > > or > > sage: g = x*sin(0) > sage: f = g.function(x) > sage: f > x |--> 0
Yes, I am aware of that. And, so yes, I'll retract the "makes __call__ nearly useless" from my statement. I was speaking more of the effect that the current design lulls people into a false sense of having robust code -- when, in fact, a different choice of parameter could just leave them with less variables than they thought and make __call__ "break". As I think about this more, I'm just plum left perplexed about the design: On Monday 17 December 2007 11:41, William Stein wrote: > This change was introduced because people often do the following > by accident: > > sage: a = (sqrt(2) + 17)(x+2) > sage: a > sqrt(2) + 17 I realize that this is a very common mistake -- for me too -- but I'm not really buying it as an argument for a design change. Because the following snippet illustrates that we can just as easily make the same silly mistake here: sage: f=x sage: f(2) 2 Maybe, I wanted 2*x -- who's to know? You just gotta learn that sage doesn't *do* implicit multiplication! Anyhow, this really isn't a huge deal to me. However, if the the current design stands, I've just got to remember that the implicit "__call__ability" of symbolic expression needs to be handled with extreme care ... or just not used at all. Unfortunately, that makes plot and friends very hard to use! With regard to plot, I'd suggest the following design change to avoid requiring use "implicit promotion" to a callable function: sage: plot(x^2,x=(1,2)) Now, this invokes the other scenerio I hate in which "x" is used as python object and as a str key to dictionary (via keywords). I think it is the lesser of the two evils because the code below just frightens me: sage: plot(t^2,xmin=1,xmax=2) Rhetorical question: What is 'x' in xmin when I'm using the variable 't'? sage: plot(t^2,t=(1,2)) That feels much better to me and indicates that the variable t should be one replaced -- i.e. sooner or later we will have a call like (t^2).subs(t=...) -- Joel --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
