Tim, this is not how to write programs. This is how to make a mess of your life, and have lousy programs to boot. Many people like to take pride in their workmanship. And most people come to view their programs later on.

I agree that sometimes what are objectively very small issues can be subjectively quite large. Both for Maple and for other systems, both for good and for ill. In the case of tabs, I suspect that Maplesoft did not see the problem as seriously as you, because (according to JacquesC) the developers tend to use external editors. I do not use such editors, for the same reason as you. For me, though, tabbing is a not an issue, because I rarely indent much. If you are indenting lots, then you are likely writing in an imperative style. Maple provides strong support for that style, but I usually prefer to write in an applicative/functional style (using small procedures and lots of seq, fold, etc.), for which Maple is also nicely adapted. If you have not tried writing applicatively, you might give it a go. If you are used to imperative writing, applicative can take getting used to, but especially for someone with mathematical training, it can become the preferred option.

Bold and a colour significantly different from the regular colour would be good, I think.

restart: sum((1+exp(n))/(exp(n)-1), n = 5 .. infinity); infinity restart: evalf(Sum((1+exp(n))/(exp(n)-1), n = 5 .. infinity)); Float(infinity) restart; _EnvFormal:=true: sum((1+exp(n))/(exp(n)-1), n = 5 .. infinity); sum((1+exp(n))/(exp(n)-1), n = 5 .. infinity) restart: _Envformal:=true: evalf(Sum((1+exp(n))/(exp(n)-1), n = 5 .. infinity)); 2.700548143 restart: _Envformal:=true: evalf(Sum((1+exp(n))/(exp(n)-1), n = 5 .. infinity)); Float(infinity) Note that the last two inputs are identical. Maple does not give (me) consistent results for that input.

I am running Maple under Windows XP SP2; here is the version info: kernelopts(version); Maple 11.01, IBM INTEL NT, Jun 8 2007 Build ID 296069 version(); User Interface: 303882 Kernel: 296069 Library: 296069 For some discussion of the different numbers, see this thread.

Maple 11.01 gives the following. f := k-> sum((1+exp(n))/(exp(n)-1), n = k .. infinity); seq(f(i), i = 1 .. 9);       infinity infinity  infinity infinity  infinity infinity  infinity infinity  infinity _EnvFormal:=true: seq(f(i), i = 1 .. 9);       sum((1+exp(n))/(exp(n)-1), n = 1 .. infinity)  sum((1+exp(n))/(exp(n)-1), n = 2 .. infinity)  sum((1+exp(n))/(exp(n)-1), n = 3 .. infinity)  sum((1+exp(n))/(exp(n)-1), n = 4 .. infinity)  sum((1+exp(n))/(exp(n)-1), n = 5 .. infinity)  sum((1+exp(n))/(exp(n)-1), n = 6 .. infinity)  sum((1+exp(n))/(exp(n)-1), n = 7 .. infinity)  sum((1+exp(n))/(exp(n)-1), n = 8 .. infinity)  sum((1+exp(n))/(exp(n)-1), n = 9 .. infinity) g := k-> evalf(Sum((1+exp(n))/(exp(n)-1), n = k .. infinity)); seq(g(i), i = 1 .. 9);       Float(infinity)  Float(infinity)  Float(infinity)  Float(infinity)  Float(infinity)  Float(infinity)  Float(infinity)  Float(infinity)  Float(infinity) All this is good, I think.

The expression in my document is  `^`(x$n).  It seems odd that this displays differently on some other computers. If I copy/paste the expression as plain text, though, I get the expression that you found.

Pi is not numeric (as defined in Maple). I do not disagree that it might have been better to disallow things like k:=sin-1/2;. I just think that it seems too late now, to make such a change.

Dave, glad you found it worthwhile. Regarding the function h, point 44 also shows that   fsolve(h(x)=2)   fails. Hence the problem is not related to using h-2. The problem can perhaps been seen more clearly via   fsolve(h(x)=2,x). That expression fails with the message “n is in the equation, and is not solved for”—so there is definitely a bug in fsolve. As for operator form and expression input, things like k:=sin-1/2; are pretty common, i.e. a function arithmetically-joined with a numeric constant. The change that you indicate would not be backward-compatible with substantial code!

John, I think it should work that way too (which is why I reported the current behavior as a bug, when I discovered it). It was probably implemented as a convenience, but it makes the semantics too messy. Doug, an extension, as you propose, sounds like a good idea. Except I think the default behavior should be the behavior that (i) most people expect and (ii) has the cleaner semantics—i.e. block=false. I recognize that this would not be upward-compatible, but suspect it would not affect much; if that's wrong, they your proposed default is obviously necessary.

Perhaps the following is relevant. m1:=Matrix([[1.1,2.1,3.1],[4.1,5.1,6.1]]): m2:=Matrix([[1.2,2.2,3.2],[4.2,5.2,6.2]]): m3:=Matrix([[1.3,2.3,3.3],[4.3,5.3,6.3]]): m4:=Matrix([[1.4,2.4,3.4],[4.4,5.4,6.4]]): Matrix([[m1,m2],[m3,m4]]); Matrix(4, 6, {(1, 1) = 1.1, (1, 2) = 2.1, (1, 3) = 3.1, (1, 4) = 1.2, (1, 5) = 2.2, (1, 6) = 3.2, (2, 1) = 4.1, (2, 2) = 5.1, (2, 3) = 6.1, (2, 4) = 4.2, (2, 5) = 5.2, (2, 6) = 6.2, (3, 1) = 1.3, (3, 2) = 2.3, (3, 3) = 3.3, (3, 4) = 1.4, (3, 5) = 2.4, (3, 6) = 3.4, (4, 1) = 4.3, (4, 2) = 5.3, (4, 3) = 6.3, (4, 4) = 4.4, (4, 5) = 5.4, (4, 6) = 6.4}) [The output is a 4 6 Matrix. How do I enter a Matrix in MaplePrimes so that it is displayed normally?] I submitted the above as a bug report in May 2004. Maplesoft replied thus: “At moment, this is the expected behaviour. We may have to adjust our documentation for Matrix and include a similar example.”

Josh, the examples that you give are obviously a bug. I suggest reporting this to Maplesoft technical support (support@maplesoft.com).

Maplesoft has done a lot of good work lately with the document interface. In the long term, it would be nice if there was no need for separate products like Scientific Workplace, because Maple evolved to do everything SciWP does. Could you list the most important functionalities of SciWP that you find are lacking in Maple documents? (This might be helpful for Maplesoft developers.)

Maplesoft has done a lot of good work lately with the document interface. In the long term, it would be nice if there was no need for separate products like Scientific Workplace, because Maple evolved to do everything SciWP does. Could you list the most important functionalities of SciWP that you find are lacking in Maple documents? (This might be helpful for Maplesoft developers.)

I think that is something that should be changed in is. In any case, though, monadic signum should generally be avoided, because signum(0) is commonly unpredictable; use signum(0,x,y), perhaps.