I should have caught that RealRange automatically simplifies like that! Thanks for pointing it out. First, I'll see if I can pass Will, that is far enough away as it is. And kudos for passing Tom 4!

An indexed variable is indeed a map from a discrete countable set into an arbitrary range. This is is isomorphic to a labelled co-product. An array is more like a cartesian product from an (ordered) discrete set and a 'value' domain. Maple does not know about infinite arrays -- it uses negative values to index ``from the right'' instead of the usual ``from the left''. Long, long ago (before my time, but I read the archives), Maple had a decent notation for assigning to the remember table. In fact, this is in Maple's own documentation! In ?updates,v40 (ie the What's New from Maple 4.0 from 1985) we can read

Previously, when the remember option was specified in a procedure,
     all computed values were automatically remembered.  In addition,
     it was possible to remember a particular result by an explicit
     call of the form  remember( f(x) = y );  but ONLY if the function
     f had option remember. 

See that method of 'remembering'? And then, already in Maple 4.1, a horrible design mistake:

Remember function replaced by assignment to a function call.

(again from the What's New in Maple 4.1, from 1986). That really was a horrible decision.

That is a nice summary of all the previous posts on this topic. Minor peeve: for summary worksheets, I tend to remove all references to %, even though I use % all the time interactively.

RealRangeUnion:=proc(L::list) local L2;
    L2:=map(a->`if`(a::realcons, RealRange(a,a), a), L);
    op(OrProp(op(L2)));
end proc:

This OrProp and its behaviour are under-documented, as far as I know (ie I don't think anyone who has not read the source code for assume could have come up with this). This is really unfortunate, because this functionality is useful and frequently asked for. Actually, more unfortunate still is the fact that there are probably 3 completely different ways to achieve this [which means that, inside Maple, there is ``feature duplication'', which means extra maintenance cost for Maplesoft]. Pet peeve: Maple procedures always return the last thing evaluated, so you last 2 lines

sol := solve(1=eq,x);
RETURN(sol);

should really be just

solve(1=eq,x); 

Second peeve: why 'RETURN' when 'return' exists (and is better)? Where did you learn that? Last thing: I did not know about this feature of convert/relation! Thank you for showing me this.

But if 2D math is too different from 1D math, won't that be a problem too? Though I guess that is rather moot, since it already is so different that maybe it simply doesn't matter if it is yet more different. Maybe there is still a chance to ``fix'' 2D math with respect to indexing/subscripts where there is no chance to ``fix'' it in core Maple. You know, if 2D math was used as a way to do real evolution (by which I mean fixing some design mistakes of the past), I might start using it more often.

With which I agree. Of course, that is not recent at all, it's been that way ever since Maple has had a pretty-printer, which is over 20 years now. So I don't think that this particular design mistake (of conflating subscripts and table indexing) will ever be fixed.

Maple should not be changing things from one ``semantics'' to another like that! I would definitely call this a bug.

Maple should not be changing things from one ``semantics'' to another like that! I would definitely call this a bug.

Maple is strongest at symbolic computation. And so you can take a look at your model directly to see its behaviour. First, let's abstract out the basepipe[n] value(s), and just assume it is a positive real number a. Let's abstract out S too, keep it as a positive integer. So what is your model?

 restart;  assume(S::posint,a>0):
> simplify(sum(a^(S-j)*exp(-a)/factorial(S-j), j = 0 .. S));

                          GAMMA(S~ + 1, a~)
                          -----------------
                            GAMMA(S~ + 1)

And voila, an incomplete GAMMA function! So what's the point? You can then just visualize your results:

 > ans := %:
plot3d(ans,a=0..2,S=1..10,axes=boxed);

(I don't show the plot here).

I posted a comment in another thread about this issue, without first reading this one. Interesting how people get caught by this maple-ism. Alex is correct, this was a short-sighted ``feature'', trying to overload semantics with display in incompatible ways. Hopefully there is a keyboard short-cut for this, as Joe asks, otherwise it really is way too much work to click around like that for any non-trivial expression. Cute idea with the macro. I should explore that some more, because it likely will break in all sorts of nifty ways, since this crosses the barrier between the GUI and the kernel in several ways, and that often is a bumpy ride! Especially since this is such a new GUI feature and macros are a very old (but under-used) kernel feature. Battle of the clashing decades.

I posted a comment in another thread about this issue, without first reading this one. Interesting how people get caught by this maple-ism. Alex is correct, this was a short-sighted ``feature'', trying to overload semantics with display in incompatible ways. Hopefully there is a keyboard short-cut for this, as Joe asks, otherwise it really is way too much work to click around like that for any non-trivial expression. Cute idea with the macro. I should explore that some more, because it likely will break in all sorts of nifty ways, since this crosses the barrier between the GUI and the kernel in several ways, and that often is a bumpy ride! Especially since this is such a new GUI feature and macros are a very old (but under-used) kernel feature. Battle of the clashing decades.

omega[0] is not ``atomic'', it is a composition of a name and an index. More precisely here is the low-level representation:

 > ToInert(omega[0]);

  _Inert_TABLEREF(_Inert_NAME("omega"),

        _Inert_EXPSEQ(_Inert_INTPOS(0)))

> dismantle(omega[0]);

TABLEREF(3)
   NAME(5): omega
   EXPSEQ(2)
      INTPOS(2): 0

so the omega is clearly visible as something that can be substituted in to. Now, mathematicians often see \omega and \omega_{0} as completely different variables. There is a way in the Maple 11 2D editor to do this (ie make \omega_{0} an atomic name), but I have not learned the details yet... So this is neither wrong nor right, you have just run into one of Maple's unfortunate overloading features where table references (a semantic feature) are overloaded with subscripting (a display feature), where the semantics/display features are not in sync.

You need to use &lt; rather than <. Also, you have many non-maple notations in there: 1) it is rhs, not RHS 2) you can't just an indexed name in the left hand side of an arrow-function. 3) modern loops use 'end do', not 'od' -- which obsolete manual do you have?

We are not seers, with that little information, I don't think anyone here will be able to help you. Be more precise about your problem (what you have, what you need, etc), and you will get lots of help.

We are not seers, with that little information, I don't think anyone here will be able to help you. Be more precise about your problem (what you have, what you need, etc), and you will get lots of help.