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...
Cheers--
Greg
On Fri, Apr 2, 2010 at 5:42 PM, Simon King <[email protected]> wrote:
> Hi!
>
> On 3 Apr., 00:30, G B <[email protected]> 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 [email protected]
> To unsubscribe from this group, send email to
> [email protected]<sage-support%[email protected]>
> 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 [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-support
URL: http://www.sagemath.org