MaplePrimes - answers and comments on Question, changing pronumeral results in different results

table reference

acer — Wed, 06 Feb 2013 09:06:20 Z

Your subscripted thetac is a table reference. You sheet is doing the 2D Math input equivalent of this 1D input,

`&theta;c`:=1:

`&theta;c`;

                               1

`&theta;c`[deg]:=4:

`&theta;c`;
                            &theta;c

By assigning to the table entry you clobber the previously assigned value of the base name. You can get around this by making the 2D Math input of the subscripted thetac[deg] instead be a unique name (so that it does not collide with base name thetac). To do this, highlight all of your subscripted thetac[deg] input, on the left hand side of that assignment statement, and use the right-click context-menu action 2-D Math -> Convert To -> Atomic Identifier.

If you do this then you'll have to make sure that you also use the same atomic identifier whenever you use it or refer to it later. You could repeat the context-menu action each time, or cut & paste it from earlier.

acer

Hi Acer, thanks very much. I dont know much

AppOptGrp — Wed, 06 Feb 2013 09:21:47 Z

Hi Acer,

thanks very much.

I dont know much about tables and have just looked them up.

Can you please tell me why this thetac acts like a table reference?

Is it a reserved name? I just ask because the other theta pronumerals dont seem to behave this way.

Thanks again.

martin

subscripted

acer — Wed, 06 Feb 2013 10:11:03 Z

@AppOptGrp The issue is not with the so-called pronumerals. It is with subscripted names.

Let's take the simpler example of base name `H`. When you enter the subscripted in 2D Math input the underlying object H[deg] is, by default, a table reference.

Your issue is like this, then,

By assigning to H[deg] you bring about a reassignment to `H` itself, which clobbers the previous assignment of 4 to `H`. The new assignment to just `H` is that of a table.

eval(H);

                           table([deg = 3])

In the table-reference form of subscipting the subscripting index is mutable. You can change it. The next example had 1D output, but in the Standard GUI the output will appear with subscripted names.

foo:=Y[x];

                              Y[x]

subs(x=77,foo);

                             Y[77]

A workaround to your issue is to instead use another form of subscripting, in which the entire subscripted object is just one big name. It can be an immutable name, by which I mean that the subscript is unchangeable. It is a new, unique name all to itself. This new name is called an Atomic Identifier -- Atomic because it's a whole unchanging thing, and Identifier because it's a name.

Underneath, this name is a complicated thing, all between single left-quotes (name quotes). Enter the following, and you can see the markup, as the output gets rendered as a subscripted thing.

bar := `#msub(mi("Y"),mi(x))`;

subs(x=77,bar);

Notice that `subs` did nothing to it, just as subs(x=77,vwxyz) wouldn't output vw77yz either!

The context-menu action described in my Answer above converts table reference Y[x] into such a complicated name, behind the scenes. It is a new name which happens to get typeset nicely, as a subscripted thing.

That complicated Atomic Identifier is unrelated to the base name `Y` of the earlier table, and assigning to the Atomic Identifier will not cause any new assignment to the table's base name `Y`, and so won't clobber any previous assignment to `Y`.

convert/identifier

acer — Wed, 06 Feb 2013 12:22:55 Z

I don't know whether it's useful here, but one can write and use an extension to the programmatic convert mechanism for this. It might not be useful for this particular case, since the right-click context-menu acts nicely in place on a 2D Math table-reference input. Also (except in Maple 16 where it's weird?) there is the subliteral entry on the Layout palette which allows one to enter such atomic subscripted names.

Anyway, using this code,

Download convertidentifier.mw

Thanks very much acer, for your detailed

AppOptGrp — Wed, 06 Feb 2013 13:53:48 Z

Thanks very much acer, for your detailed response. It seems that I was misunderstanding the fundamental error.

Thanks for taking the time to clearly correct this. It made a big positive difference.

(seems like I cant vote to my own questions, otherwise i would)

Thanks

Martin