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

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

@Carl Love But that is not a comprehensive solution that can be automatically applied easily. It's easy to accomodate any given dependency/assignment chain, but that does not mean that all unknown chains will so easily be automatically handled.

And grouping variables in a set does not help with the posted question's request for handling "specific variables". Knowing about memory used by sets of names such as {a,b,c,d} doesn't tell us which is which in an assignment chain, say, or which are/is primarily responsible for the allocation.

We still don't know what the Asker really wants, though, and why.

@Carl Love But that is not a comprehensive solution that can be automatically applied easily. It's easy to accomodate any given dependency/assignment chain, but that does not mean that all unknown chains will so easily be automatically handled.

And grouping variables in a set does not help with the posted question's request for handling "specific variables". Knowing about memory used by sets of names such as {a,b,c,d} doesn't tell us which is which in an assignment chain, say, or which are/is primarily responsible for the allocation.

We still don't know what the Asker really wants, though, and why.

@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,

H:=4;

                               4

H[deg]:=3;

                               3
H;

                               H

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`.

@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,

H:=4;

                               4

H[deg]:=3;

                               3
H;

                               H

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`.

It's not really clear what the Asker hopes to ascertain with such measurements.

Matlab was mentioned, and perhaps all that's needed is measurement of hardware float rtables' memory allocations.

If symbolic objects' memory storage sizes are the desired knowledge, then is it important to avoid duplicate counting? In the example below, the "size" of `c` is counted twice, once when measuring `c` and once again when measuring `a`. But we know that the long list is only being stored once in Maple, due to its uniquification process.

> a:=b+c:

> c:=[seq(cat(x,i),i=1..10^4)]:

> length(a);
                                     58905

> length(c);
                                     58897

> length(sprintf("%m", eval(a)));
                                     78910

> length(sprintf("%m", eval(c)));
                                     78899

Maybe the Asker was originally trying to do something else, such as optimize code with respect to memory use (in which case using procedures and Maple's profiling tools might be a better all round approach).

We may need the Asker to clarify what's really wanted.

acer

It's not really clear what the Asker hopes to ascertain with such measurements.

Matlab was mentioned, and perhaps all that's needed is measurement of hardware float rtables' memory allocations.

If symbolic objects' memory storage sizes are the desired knowledge, then is it important to avoid duplicate counting? In the example below, the "size" of `c` is counted twice, once when measuring `c` and once again when measuring `a`. But we know that the long list is only being stored once in Maple, due to its uniquification process.

> a:=b+c:

> c:=[seq(cat(x,i),i=1..10^4)]:

> length(a);
                                     58905

> length(c);
                                     58897

> length(sprintf("%m", eval(a)));
                                     78910

> length(sprintf("%m", eval(c)));
                                     78899

Maybe the Asker was originally trying to do something else, such as optimize code with respect to memory use (in which case using procedures and Maple's profiling tools might be a better all round approach).

We may need the Asker to clarify what's really wanted.

acer

Comments which relate to the programming or mathematics of such escape fractals are welcome as followups to this post.

But comments with little or no relevant substance, such as simple links to galleries of images with some mathematical background, are not welcome, and I may delete them.

acer

Here is a higher resolution version of one of those, produced at 1600 pixels in width (34sec on my machine, compiled and multithreaded) and scaled down to 800 pixels wide for insertion here.

acer

Are you running 16.02, and do you have the ability to run (or reinstall) 16.01? See here and here.

For this particular example, the curve can be revealed with,

  subsindets(A,[undefined,undefined],z->NULL);

but that (and related simple attempts at replacements) won't be a general workaround (as it may wrongly connect points).

acer

As written, the 2-dimensional rtable entries of V are of type Array rather than of type Matrix. It's not clear from the original post which is wanted or needed, and perhaps it won't matter. But for some uses it will matter, eg. behaviour w.r.t. the `.` operator, or in a release before Maple 16 when the LinearAlgebra package got coercion, etc. If it matters, then this aspect can be efficiently toggled in-place on the V[i], ie.

for i from 1 to 5 do rtable_options(V[i],subtype=Matrix); end do:

After doing so V[i] will be a Matrix instead of a 2-dimensional Array, and V[i][..,k] will be a column Vector instead of a 1-dimensional Array.

acer

As written, the 2-dimensional rtable entries of V are of type Array rather than of type Matrix. It's not clear from the original post which is wanted or needed, and perhaps it won't matter. But for some uses it will matter, eg. behaviour w.r.t. the `.` operator, or in a release before Maple 16 when the LinearAlgebra package got coercion, etc. If it matters, then this aspect can be efficiently toggled in-place on the V[i], ie.

for i from 1 to 5 do rtable_options(V[i],subtype=Matrix); end do:

After doing so V[i] will be a Matrix instead of a 2-dimensional Array, and V[i][..,k] will be a column Vector instead of a 1-dimensional Array.

acer

I have submitted this as a bug report against `solve`.

acer

I have submitted this as a bug report against `solve`.

acer