That's an interesting link. I'm still curious to know why subs/eval probe the deep structure rather than the op structure. Or why there isn't a subs/eval command that does operate on the op-structure. Toby

In my defence, I guess I have only used eval(..., 1=2) whimsically. Thanks for your remark on the data structure of 2x - that is illuminating. So I guess the answer to my original question of "why do eval/subs operate on the internal structure rather than the structure as revealed by op" is probably efficiency. I note in passing that the help pages from subs are perhaps misleading since they suggest that what is important is the op-structure of the the object being substituted in, which seems to be only partly true in effect. Your square root example seems rather different to me - once one understands that eval/subs do syntactic substitution, whether it is operating on the op-structure or the deeper structure you would not expect that to work. Thanks again Toby

John, Thanks. Yes, as soon as one is aware of this issue there is always a more sensible way of doing things. I was really just wondering if there was a good reason why subs/eval work on the structure as revealed by dismantle rather than as revealed by op/ToInert, given the possibility of counter-intuitive results.

Just put the single line assume(k::positive,T::positive,h::positive,c::positive); before the original code and it just does it, straight off, no polylogarithms or anything! Toby

Just put the single line assume(k::positive,T::positive,h::positive,c::positive); before the original code and it just does it, straight off, no polylogarithms or anything! Toby

My impression was that it was a glitch in our mail servers - it has now been corrected. If it is this, you can tell by opening the mailed worksheet in a decent text editor - the worksheet will look OK but very long lines will all be broken at the same point. Toby

My impression was that it was a glitch in our mail servers - it has now been corrected. If it is this, you can tell by opening the mailed worksheet in a decent text editor - the worksheet will look OK but very long lines will all be broken at the same point. Toby

I had a similar problem. It was caused by our Uni mailer deciding (because of the xml format, I think) that the worksheet is a text file and then attaching it without encoding or checking line length. If the worksheet has very long lines (>1000 chars - which it can have if it contains plots or 2D maths) then they get truncated/broken in the mailer.

I had a similar problem. It was caused by our Uni mailer deciding (because of the xml format, I think) that the worksheet is a text file and then attaching it without encoding or checking line length. If the worksheet has very long lines (>1000 chars - which it can have if it contains plots or 2D maths) then they get truncated/broken in the mailer.

Thanks Acer, It had not occurred to me to use _EnvAllSolutions. I did not realise that it applied to this sort of thing - it is odd, given that it is not a question of multiple solutions - there's only one correct one. In fact, the help pages suggest that it (or the equivalent AllSolutions options in int) only do something for parameters that occur in the endpoints, not in the integrand. I suppose then that the result is in line with the general philosophy of returning generic solutions unless Maple is told otherwise. Maple is right too that there are two special cases m=n and m=-n (the second you (and I) forgot). Interesting that Maple picks up the assuming of m=n in your example, but not if it is used without _EnvAllSolutions:=true; just adding that assume to my original code has no effect. Toby

I suspect the easy answer to what you probably want to ask is this: diff( (x-1)^2/x, x ); Toby

I suspect the easy answer to what you probably want to ask is this: diff( (x-1)^2/x, x ); Toby

If that is the reason - and it looks to be so - then bug or not it is pretty poor. After all piecewise is a basic part of the system and the fact that these examples plot wrongly and evaluate wrongly under evalhf is an example of the sort of failure that my anti-Maple colleagues take great pleasure in pointing out. I do wonder if Maple might be better if more time was spent on getting this sort of thing right and less was spent on fancy interface "improvements".

If that is the reason - and it looks to be so - then bug or not it is pretty poor. After all piecewise is a basic part of the system and the fact that these examples plot wrongly and evaluate wrongly under evalhf is an example of the sort of failure that my anti-Maple colleagues take great pleasure in pointing out. I do wonder if Maple might be better if more time was spent on getting this sort of thing right and less was spent on fancy interface "improvements".

That's what I was trying to say, but after a couple of glasses of Burgundy.....