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

Reply via email to