The new parameter-processing looks exactly like what I need. Thank you! :D As for :=, it appears that it does call evaln, which would then be the source of the problem. I can see why it calls evaln; if I were to do this: [>a:=b: [>a:=4: I would expect a to have the value 4, not b. It feels like (and by "feels like," I mean that I think this is true, but I need to do more research) the phrase "evaluates as" or "evaluates to" has different meanings depending on which help file is being read. That has lead to other confusions on my part in the past.

Our TTY has consistently produced interesting results. I've looked through what we do, but unfortunately I can't say much else because of the proprietary nature of the routines we use. :( Oh well.

This exercise came about when I pondered if I could use a symbol or name passed through as an optional argument for a procedure to define a variable local to that procedure with the same name. For (a poor and quick) example of something along the lines of what I had hoped to do: [>are_these_numbers_equal := proc(a,b) local tol; if nargs>2 and type(args[3], name=realcons) and lhs(args[3])='tol' then lhs(args[3])=rhs(args[3]);fi; if a<>b then if assigned('tol') and abs(a-b)<tol then return "True enough"; else return "False"; fi; else return "True"; fi; end proc; I intimated near the end of my post that I had thought that the locations of the same symbol a (global versus local) was what probably was bringing about an error. This is apparently exactly the case. The error concerning "invalid left hand side in assignment" is not due to any other assignment in the worksheet. Do this: [>restart; [> QQQ := q = 4; [> lhs(QQQ) := rhs(QQQ);

Maple 11. I was surprised, too, to see `:=`(T,7) actually assign the value 7 to T. Original testing in Maple worksheet modes showed this not to be the case, so when we were writing text files to later be piped into TTY Maple, I made sure to add a line changing the naturally-occurring `:=` operators to assign. This produced errors when variable names were re-used. In an attempt to counter those errors, I simply removed the line replacing the `:=` operators with assign, and the `:=` operators work perfectly. If it is a mistake to expect evalb() to return true when asked to compare a global and local which use the same symbol, why is it not a mistake to expect verify( , symbol) to return true when comparing the exact same global and local which use the same symbol? What you have called a side-effect is what I call a bug. A line in a procedure with no explicit global binding has a global bearing. --Schivnorr

I came back to this comment to look at the solutions given by Maple to the cubic equation x^3-3*x+1=0. Okay, sure, no problem. S := [solve( x^3-3*x+1=0, x )]; In playing around with these solutions, I was rather surprised to find such a large discrepancy in the output of the following commands: evalf( S ); evalf( simplify(S) ); I guess evalf() is a little sensitive.

I came back to this comment to look at the solutions given by Maple to the cubic equation x^3-3*x+1=0. Okay, sure, no problem. S := [solve( x^3-3*x+1=0, x )]; In playing around with these solutions, I was rather surprised to find such a large discrepancy in the output of the following commands: evalf( S ); evalf( simplify(S) ); I guess evalf() is a little sensitive.

My problem is that I can spend hours at a time and not find a consistent way to reproduce an error. That's one reason I come to these boards; to put my problems out there and see if anyone else can make it or has seen it do the same.

I can tell that something is wrong when Maple starts giving odd answers or otherwise behaving in peculiar manners. To see that UTF-8 text encoding is the culprit, I open the worksheet (.mw standard worksheet file) in a text editor. In the body of the file, around the text in question, you'll see something like ... I don't have an example handy at the moment, but that is what to look for. Note, though, that the first line of the .mw worksheet will likely have an encoding="UTF-8" tag. That is normal.

S := [solve(whatever)]; S1 := map(allvalues,S); remove(has, S1, I); Though, I guess this method cannot guarantee that an I is not hiding somewhere...

S := [solve(whatever)]; S1 := map(allvalues,S); remove(has, S1, I); Though, I guess this method cannot guarantee that an I is not hiding somewhere...

I'd love a way to customize away that poll on the left-hand side, as well as other items on either side.

Yeah, it looked like zero=zero. Makes a whole lot more sense for "Oh" = 0. As for use, I always thought that use had to be followed by a package or module. Then again, I've only seen it used in this way, and have not yet read its help page. It seems that the documentation would merit a review. Thank you.

It looked like zero=zero. My mistake. And yes, getting rid of big-O order terms like that makes a lot of sense (and using that evaluation is something of which I probably would not have thought). Hmm, I will have to look into this 'let binding.' Sounds like it could be useful. Thank you :) And thanks again for the nod to my leaf.

Where does this come from? I've never seen it, and it intrigues me... This is also looks similar to something I saw someone (I believe either you or Jacques) post recently, about using eval(%,0=0); Might they be related?

Aye, this is all true and serves the same purpose as the for loop I mentioned. It's great that you mention them explicitly--thank you--I usually am not troubled to optimize my coding to such a level; I tend to find something that works, latch on to it, and try to make it work better if needed later. :)