On Nov 7, 2008, at 4:53 AM, Burcin Erocal wrote: [...]
>>> Going back to your example, f(5,y) would just return a symbolic >>> expression, so >>> >>> sage: f(x,y)=2*x+3*y >>> sage: plot( f(5,y), (y, -10,10)) >>> >>> would be equivalent to >>> >>> sage: plot( 10+3*y, (y, -10,10)) >>> >>> which would just work. >>> >>> The current syntax allows this: >>> >>> sage: f(x,y) = a*x + b*y >>> sage: f(5) >>> b*y + 5*a >>> sage: f(5)(5) >>> b*y + 25 >>> >>> >>> I think the last line should be a syntax error. >> >> >> I agree, since f was explicitly defined with variables x and y. >> >> f(5) should return a function g(y) = b*y+5*a >> >> I think this could be easily changed (just return a function that has >> explicit variables, rather than just a symbolic expression). > > I would still like to check that the length of the arguments match, > and > raise an error if they don't. So, continuing the above example, > > sage: f(5) > > should raise an error. I agree here. > It might be better if > > sage: f(5, None) This makes sense to me, but would be quite strange to the "average calculus student" (where the average is over the the undergrads that I have interacted with). > or > > sage: f(5,y) > > returned the function g(y) = b*y+5*a. What about f(5,a), would it be a function of a? Or f(y,5)? Or is there somehow special casing going on when the variable name plugged in matches the name of the expected argument (I'd rather let f(...) have the same return type no matter what the arguments are). > On Nov 7, 2008, at 9:58 AM, kcrisman wrote: > >> I feel like by letting f=x^2 be available instead of f(x)=x^2, we are >> lowering the bar to use of Sage; the more conventions like this to >> remember, the harder it is to use - not because people can't use it, >> but because the frustration quotient (especially in a big class) is >> high enough to drop it, since there are better things to do with >> one's >> time than have to explain this sort of thing again and again. It >> doesn't mean I personally would stop using Sage, just that I might >> not >> use it as often as I would like in a class. However, I am glad it's >> being discussed - it is interesting to learn about the different >> reasons for such things. >> >> The real issue is that someone who has the option of getting a site >> license for something else (or using an existing one) might decide to >> use that instead of Sage - not because of this per se, but because >> they weigh "larger user base and program I am familiar with, even if >> it has minor annoyances" or whatever against "various minor >> annoyances, including this one, in program I'm not very familiar >> with" >> - even if both programs have the same behavior, which I don't know >> since I don't have the opportunity to use them. >> >> So if the goal of Sage is to compete with them, which for now (and >> hopefully in the future too!) may mean needing to be even better than >> them, then part of that should be to allow things like this. It is a >> minor annoyance to somebody either way, but it seems like this is a >> case where it's a minor annoyance (as opposed to the major annoyance >> of all letters being predefined as variables) for some, where the >> other way would be a slightly more major annoyance for others. At >> least, that's how I view it, both in my research and teaching. So >> far, I think Sage has done a pretty good job balancing these things, >> as someone else said earlier in the thread. I think this is *the* key point that needs to be addressed here. I doubt people are going to avoid using Sage because symbolic expressions are callable. However, I could see a lot of people wondering why sage: f = x^2 sage: f(2) or sage: plot(f, -10, 10) does not work, and finding it easier to go with a system that "just works" (for them) than worry about always distinguishing between callable vs. non-callable expressions (or, worrying about teaching such a distinction to their calculus 101 students). It seems that the core objections are about Sage's automatic resolution of ambiguity. When I write x=var(x); f = x^2, (almost) all of us agree what f(2) should be. But if I write f = a*x^2, f(2) now has additional ambiguity, and in particular the interpretation "2*x^2" is arguably the "wrong" one (though reverse-alphabetic or some other ordering is potentially just as bad and even more confusing). I would propose that *single variable* expressions behave like callables in one variable, there is no ambiguity as to the ordering, so one should be able to call, integrate, differentiate, plot, etc. with them without having to specify the variable. On trying to use a expression with more than one indeterminate, an error should be raised with a clear explanation the ambiguity and of how to define a mulit-variate function. The f(x=5) syntax should still be available as all ambiguity is resolved. - Robert --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com 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://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
