On 5/9/07, Justin C. Walker <[EMAIL PROTECTED]> wrote: > > > > On May 9, 2007, at 4:59 PM, Bobby Moretti wrote: > > On 5/9/07, Justin C. Walker <[EMAIL PROTECTED]> wrote: > [snip] > >> This is the part that I didn't really get until now. > >> The calculus package is a great addition. It seems to 'just work'. > > > > Thanks :). We tried to emulate the feel of language-level literals > > for doing > > symbolics. > > Seems pretty sweet to me. > > > I have a few concerns (cf. the Principal above), since this package > >> is affected by what you change during a session, but overall, I > >> like it. > > Here's an example of what I'm hinting at: > >> > >>> sage: f=c*x > >>> sage: diff(f,c) > >>> x > >>> sage: diff(f,x) > >>> c > >>> sage: c=3 > >>> sage: type(c) > >>> <type 'sage.rings.integer.Integer'> > >>> sage: type(f) > >>> <class 'sage.calculus.calculus.SymbolicArithmetic'> > >>> sage: diff(f,c) > >>> ..... > >>> <type 'exceptions.ValueError'>: must supply an explicit variable > >>> for an expression containing more than one variable > [snip] > > This is indeed a caveat of doing what we're doing. I too had my > > initial > > doubts about this, but I think it works pretty well in practice. > > Can you > > think of a way around this design? > > After a bit of thought (including some time spent when this was > discussed a while back), I can't come up with anything that works as > well as what you have, and avoids some of these gotchas. > > > Also, this same error could come up anywhere in SAGE. The > > following, while a > > bit contrived, is nonetheless possible for a novice user to input: > > > > sage: Integer = 2 > > Ewww..."Oops, shot myself in the wrong foot" :-}
The only thing that occurs to me is a "protect" mechanism of some > sort. It's easy to overdo such things, so I'm not seriously > suggesting it; just tossing it into the hopper... > - perhaps cutting back on the variables that are symbolic variables > by default. > - if a symbolic variable is used in this way (i.e., as a symvar), > protect it by > default (and provide unprotect() to override). > > In general, we can't provide a general purpose programming language > (and SAGE is one) and avoid this kind of thing. I think the real > concern should be whether this aspect conflicts too badly with the > desire to provide a sort of "calculus calculator" for the mathematics > fan who has no interest in, or ability for, programming (and > therefore will not understand the import of some of his typing until > after his computations blow chunks...). > > I suspect this will not be an issue, but it is worth thinking through > a few times. William is sitting next to me here, and he thinks that a protect mechanism is worth exploring. He and I agree that this may end up actually being a serious issue for some people. Justin > > -- > Justin C. Walker, Curmudgeon-At-Large, Director > Institute for the Enhancement of the Director's Income > -------- > The path of least resistance: > it's not just for electricity any more. > -------- > > > > > > > -- Bobby Moretti [EMAIL PROTECTED] --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-support@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-support URLs: http://sage.math.washington.edu/sage/ and http://sage.scipy.org/sage/ -~----------~----~----~----~------~----~------~--~---
