On Sat, Apr 3, 2010 at 12:41 PM, G B <g.c.b.at.w...@gmail.com> wrote:
> Thanks for the detailed response, Simon. Please understand that I'm not > being critical of Sage-- quite the contrary, I'm excited about what it might > offer me once I master it. > > I think you touch on one key to the problem-- I'm not a mathematician, I'm > an engineer. While most of the world would certainly accuse us of being > sloppy dressers, mathematicians are one of the few groups that can > legitimately accuse us of being sloppy thinkers. I think that brand of > sloppy thinking is what is at issue here, and when I say "work around" I > mean "become tolerant of". > > Sage has already encouraged me to learn more about ring theory than I ever > would have needed otherwise, but getting completely different results when > executing plot(f(x),(x,0,2*pi)) vs. executing plot(f,(0,2*pi)) started > playing on my patience a bit and has me wondering if I'm simply using an > irreconcilably wrong tool for the job. I think the intention of both of > those statements is the same, and thus should yield the same result, and my > suspicion is that the reason they don't is an artifact of the plumbing, but > I may be missing something. > > It's not the f(x)=sin(x)+T.get_random_element() form that troubles me > though, for the record, I did try 'f(x)=sin(x)+T.get_random_element(x)'. > Expectedly, it doesn't like having an unwanted argument shoved down its > throat. > > What still feels awkward to me is how constructs like this behave: > var('x') > T=RealDistribution('gaussian',1) > f=lambda x: T.get_random_element() > g(x)=sin(x)+f(x) > > To my mind, the way that is handled is particularly confusing. > [f(1),f(2),f(3)] --> [-0.568652852118, 0.912307924442, 1.35997405644] > > but, > [g(1),g(2),g(3)] --> [sin(1) - 0.176035204293, sin(2) - 0.176035204293, > sin(3) - 0.176035204293] > > In other words, calling f repeatedly gives different results each time, but > calling g repeatedly does not. > > That may be a case where the parenthetical syntax conspires with the > overloaded meanings of "function" to expose my sloppy thinking, but it also > kind of looks like a trap waiting to be triggered. > > If sin(x) and f(x) are fundamentally different entities, and my engineering > mind isn't completely convinced that they should be, then the syntax should > prevent the construction of g in such a manner. Either execution of f > should be deferred until g is called with a parameter, as I would expect, or > an error should be thrown for providing illegal arguments to operator '+'. > If I want g(x) defined as sin(x) plus the result of f(x) as x is defined at > the definition of g, then the syntax should highlight that by forcing > something like g(x)=sin(x) + `f(x)` > > > Am I making sense, or just digging my credibility hole deeper? In my > defense, I've only had a couple days of playtime with the system so far... > > First, to clear things up: Yes, f and g are two fundamentally different. `f` is a Python function, while `g` is a symbolic expression, which is a Python object. What follows is an explanation of what happens. If it is already clear to you, please ignore it. ============================================== When you call f(x), you are calling f with symbolic expression `x`, which, by Python semantics, is eagerly evaluated, and thus, with: f = lambda x: sin(x) + T.get_random_element() which, by the way, is (almost) equivalent to defining it as: def f(x): return sin(x) + T.get_random_element() `sin(x)` evaluates and returns a symbolic expression, and `T.get_random_element()` evaluates and returns a random element. Note that expressions in the function are not evaluated until it is called, unlike as with the symbolic expression case. Thus, when you call: plot(f(x), (x, 0, 2*pi)) You actually call it with: plot(sin(x) + <random number, say, 0.1234>, (x, 0, 2*pi)) Leading to your problem. Calling it this way: plot(f, (x,0,2*pi)) on the other hand, tells the plot function to call `f` for n times in the given range, and so T.get_random_element() is called n times, instead of just once. g(x) is a symbolic function, and when defined as: g(x) = sin(x) and called as g(x), will return the symbolic expression sin(x), as `sin` is a symbolic function, and returns a symbolic expression. However, when defined, as it was initially, as: g(x) = sin(x) + T.get_random_element() T.get_random_element() is also evaluated, and, being a normal (Python) function, returns a random number, not a symbolic expression that returns a random number. Effectively, it is called with: g(x) = sin(x) + <random number [say, 1.234]> Symbolic expressions are defined such that operations performed on them (addition, etc.) return another symbolic expression that represents the performed operation, in this case, sin(x) + <random number>. There is no way to distinguish internally between: g(x) = sin(x) + 1.234 and g(x) = sin(x) + T.get_random_element() ====================================== Your proposition of adding syntax to distinguish between eager and lazy evaluation in symbolic functions makes sense to me. I think it would be helpful to people unused to these semantics, and should be easy to do in the preparser. I would do it the other way around, though, with: g(x) = sin(x) + `T.get_random_element()` getting T.get_random_element only evaluated on calling g(x), as it would change current semantics and introduce backwards incompatibilities. Yours, Tim Cheers-- > Greg > > On Fri, Apr 2, 2010 at 5:42 PM, Simon King <simon.k...@nuigalway.ie>wrote: > >> Hi! >> >> On 3 Apr., 00:30, G B <g.c.b.at.w...@gmail.com> wrote: >> > That did it. I found the section in the tutorial explaining the >> > different interpretations of functions more fully, and while I don't >> > quite have my head around it, I think I understand the problem at a >> > basic level to be that my f(x) is a symbolic expression, but >> > get_random_element() is a Python function, and there's some odd >> > interaction under the hood. >> >> I think that's a wrong description of what is happening. You talk >> about the line >> f(x)=sin(x)+T.get_random_element() >> >> In that line, f is to be defined (in particular, at that point, f(x) >> is not a symbolic expression, yet). >> >> So, let's look at the right hand side of it. sin(x) is a symbolic >> expressioon. T.get_random_element() is, in contrast to what you state, >> *not* a Python function --- T.get_random_element() is a number. And of >> course, when you add a number to a symbolic expression, you get a >> shift and not a noise. >> >> I don't find this an odd interaction at all. >> >> What you probably had in mind was that T.get_random_element *without* >> the brackets is a Python function (or actually a method). Adding an >> *unevaluated* Python function to a symbolic expression should result >> in an error - everything else would probably be a really odd >> interaction, because this means to add things that have a completely >> different meaning. >> >> > Is this something that will ever be able to be worked around... >> >> What do you mean by "work around" in this case? >> >> You seem to believe that "f(x)=sin(x)+T.get_random_element()" makes >> sense as a mathematical definition of adding noise to sin(x). >> But here I disagree: You can mathematically add functions that have >> the same range, but this is obviously not the case for sin(x) and >> T.get_random_element() (the latter is even not referring to x). >> >> But when a statement does not make mathematical sense, you can not >> expect to work around it in any computer algebra system. >> >> > Is Sage doomed to have these similar but not quite >> > compatible entities ... >> >> They are totally different. >> >> > everything will begin to play >> > more nicely? >> >> What do you consider "nice"? I believe that it would certainly *not* >> be nice to have a computer algebra system that interpretes >> f(x)=sin(x)+T.get_random_element() >> in the way you suggested. I am mathematician, and as a referee of a >> research paper I would complain about such a line. >> >> By the way, there is already quite an effort done behind the scenes in >> order to make sense of the line >> f(x)=sin(x) >> Again, it is a definition, but on the left hand side you have two >> things, namely f and x. But x also appears on the right hand side. >> >> > My concern is that, as a newbie, I'm carefully double checking each >> > step of my calculation because I know that I don't know what I'm >> > doing-- but eventually I'm liable to gain confidence, lose track of >> > these various function types, and not realize that the results I'm >> > getting are incorrect. >> >> Don't worry. It is normal to commit errors when programming. But you >> can be confident that you will invent more and more subtle errors as >> your programming skills improve. :) >> >> Best regards >> Simon >> >> -- >> To post to this group, send email to sage-support@googlegroups.com >> To unsubscribe from this group, send email to >> sage-support+unsubscr...@googlegroups.com<sage-support%2bunsubscr...@googlegroups.com> >> For more options, visit this group at >> http://groups.google.com/group/sage-support >> URL: http://www.sagemath.org >> >> To unsubscribe, reply using "remove me" as the subject. >> > > -- > To post to this group, send email to sage-support@googlegroups.com > To unsubscribe from this group, send email to > sage-support+unsubscr...@googlegroups.com<sage-support%2bunsubscr...@googlegroups.com> > For more options, visit this group at > http://groups.google.com/group/sage-support > URL: http://www.sagemath.org > -- To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to sage-support+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-support URL: http://www.sagemath.org