I think that he just ran into a name instead of a string.

> X:="18DBD3547552C73BE4DE87731C500":
> num:=convert(X,decimal,hex);
               num := 8067107224306383990011936212370688

> convert(num,hex,decimal);
                     18DBD3547552C73BE4DE87731C500

> lprint(%);
`18DBD3547552C73BE4DE87731C500`

Procedure `p` can work with names as well as with strings, since `cat` and StringTools:-LengthSplit can also.

acer

That is an interesting notion, Axel -- that the default installation location (folder name) for Maple, with a space in it, might cause problems for using OpenMaple with the default MS compiler. I wonder if there's anything else that the space can cause problems for. It's a nice commonsense tip, to always remove the space when selecting an installation location.

acer

That is an interesting notion, Axel -- that the default installation location (folder name) for Maple, with a space in it, might cause problems for using OpenMaple with the default MS compiler. I wonder if there's anything else that the space can cause problems for. It's a nice commonsense tip, to always remove the space when selecting an installation location.

acer

Thanks, Robert. I think that I had realized that once before, but somehow forgotten it. And I too was tricked by the GUI's !!! button's failure to execute all lines in the Document, which you mention above.

So, Units:-Standard exports its own `=`, which messes with interactive calls to :-add which expects only a call to :-`=` (infix). To get around that problem, Units:-Standard also exports its own add, which passes arguments to :-add but as a Library archive instance that has an call to :-`=` hard-bound.

It'd be brilliant, except that Units:-Standard:-add doesn't have the complete special evaluation rules behaviour that :-add does.

So you work around it by using Units:-Standard:-add along with the usual trick of uneval quotes to get the delay of evaluation. Super.

It seems dangerous for a package to export its own `=`, since that can be used in so many different syntax instances. The exported `=` would have to be very carefully written. Eg,

myeqn := eqnrlhs = eqnrhs;

if A = B then ...

if A = NULL then ...

if NULL = NULL then ...

seq( x, x = L );

LinearSolve(A, B, inplace = true );

# ... others I haven't thought of right now.

I wonder, should the rebound `=` get used in all of those!?

acer

Thanks, Robert. I think that I had realized that once before, but somehow forgotten it. And I too was tricked by the GUI's !!! button's failure to execute all lines in the Document, which you mention above.

So, Units:-Standard exports its own `=`, which messes with interactive calls to :-add which expects only a call to :-`=` (infix). To get around that problem, Units:-Standard also exports its own add, which passes arguments to :-add but as a Library archive instance that has an call to :-`=` hard-bound.

It'd be brilliant, except that Units:-Standard:-add doesn't have the complete special evaluation rules behaviour that :-add does.

So you work around it by using Units:-Standard:-add along with the usual trick of uneval quotes to get the delay of evaluation. Super.

It seems dangerous for a package to export its own `=`, since that can be used in so many different syntax instances. The exported `=` would have to be very carefully written. Eg,

myeqn := eqnrlhs = eqnrhs;

if A = B then ...

if A = NULL then ...

if NULL = NULL then ...

seq( x, x = L );

LinearSolve(A, B, inplace = true );

# ... others I haven't thought of right now.

I wonder, should the rebound `=` get used in all of those!?

acer

As you've surmised, Doug, I'd looked at that very code before.

On the one hand, Units:-Standard:-add has parameters qualified as type uneval. So far, so good. But will the argument x in eval((':-add')(x,op(1,y) = op(2,y)))  get evaluated before being passed on to :-add? That would cause an unspecified rtable reference error, which would get caught and rethrown as a "wrong number (or type)..." error.

> M := <<3>>:
> eval(M[k],k=1);
Error, bad index into Matrix
> try eval(M[k],k=1); catch: error "wrong number..."; end try;
Error, wrong number...

My only suggestion is, why does Units:-Standard:-add exist at all? Does it truly do something useful with the units? (I don't see it.) If not, then maybe it's just a stub. In that case, maybe it could be removed from the package? Or on the immediate practical side, one could always unbind() it right after loading that subpackage.

acer

As you've surmised, Doug, I'd looked at that very code before.

On the one hand, Units:-Standard:-add has parameters qualified as type uneval. So far, so good. But will the argument x in eval((':-add')(x,op(1,y) = op(2,y)))  get evaluated before being passed on to :-add? That would cause an unspecified rtable reference error, which would get caught and rethrown as a "wrong number (or type)..." error.

> M := <<3>>:
> eval(M[k],k=1);
Error, bad index into Matrix
> try eval(M[k],k=1); catch: error "wrong number..."; end try;
Error, wrong number...

My only suggestion is, why does Units:-Standard:-add exist at all? Does it truly do something useful with the units? (I don't see it.) If not, then maybe it's just a stub. In that case, maybe it could be removed from the package? Or on the immediate practical side, one could always unbind() it right after loading that subpackage.

acer

It's great that you had fun programming it.

I hope it's ok to comment. Instead of loading the packages outside of the procedure body using `with`, it would be better form to utilize the `use` or `uses` functionality inside the procedure body.

acer

It's great that you had fun programming it.

I hope it's ok to comment. Instead of loading the packages outside of the procedure body using `with`, it would be better form to utilize the `use` or `uses` functionality inside the procedure body.

acer

See here for a note on this.

acer

See here for a note on this.

acer

Not only is it shorter code than a call to SubVector, the square-bracket "rtable subindexing" is also the direct kernel access which bypasses slower Library code. SubVector just ends up making an rtable subindexing call itself.

Joe showed the same subsop approach earlier, more simply using rtable subindexing. He just left out the dynamic inference of the Vector's length (and might not have made it into an operator). For that, one might use op(1,V) rather than LinearAlgebra:-Dimension. That syntax is so widely used that I don't imagine it will change any time soon.

acer

Not only is it shorter code than a call to SubVector, the square-bracket "rtable subindexing" is also the direct kernel access which bypasses slower Library code. SubVector just ends up making an rtable subindexing call itself.

Joe showed the same subsop approach earlier, more simply using rtable subindexing. He just left out the dynamic inference of the Vector's length (and might not have made it into an operator). For that, one might use op(1,V) rather than LinearAlgebra:-Dimension. That syntax is so widely used that I don't imagine it will change any time soon.

acer

There are two kinds of mutability to consider. Changing an element's value, and changing the size of the structure.

For changing the value of an element, a Vector is often preferred over a list because substituting values into a position of a list involves creation of a whole new list. It is an inefficient use of memory, producing garbage that must be collected. This gets worse as the structure gets large. (It doesn't matter whether one uses subsop, or assigns directly to a list of length <=100.)

For changing the size of the structure, as when entries are removed altogether, using a table can be preferable over using either a Vector or a list. In this case one can avoid the creation of  both new Vector and list final objects (and several intermediary objects, if not done carefully). Again, this can matter more if the size of the structure is very big and if the entries need to be removed one at a time.

> A := Vector[row]([2, 10, 5, 7]);
                              A := [2, 10, 5, 7]
 
> At:=convert(A,table);
                  At := table([1 = 2, 2 = 10, 3 = 5, 4 = 7])
 
> unassign('At[2]');
> eval(At);
                         table([1 = 2, 3 = 5, 4 = 7])

You may be able to remove entries from table At more efficiently (for a very large object).

There are a few ways to convert the final reduced table back to a Vector (perhaps depending on whether you keep track of how many entries are removed).

> Vector[row]([seq(At[op(i)],i in indices(At))]);
                                   [2, 5, 7]

acer

There are two kinds of mutability to consider. Changing an element's value, and changing the size of the structure.

For changing the value of an element, a Vector is often preferred over a list because substituting values into a position of a list involves creation of a whole new list. It is an inefficient use of memory, producing garbage that must be collected. This gets worse as the structure gets large. (It doesn't matter whether one uses subsop, or assigns directly to a list of length <=100.)

For changing the size of the structure, as when entries are removed altogether, using a table can be preferable over using either a Vector or a list. In this case one can avoid the creation of  both new Vector and list final objects (and several intermediary objects, if not done carefully). Again, this can matter more if the size of the structure is very big and if the entries need to be removed one at a time.

> A := Vector[row]([2, 10, 5, 7]);
                              A := [2, 10, 5, 7]
 
> At:=convert(A,table);
                  At := table([1 = 2, 2 = 10, 3 = 5, 4 = 7])
 
> unassign('At[2]');
> eval(At);
                         table([1 = 2, 3 = 5, 4 = 7])

You may be able to remove entries from table At more efficiently (for a very large object).

There are a few ways to convert the final reduced table back to a Vector (perhaps depending on whether you keep track of how many entries are removed).

> Vector[row]([seq(At[op(i)],i in indices(At))]);
                                   [2, 5, 7]

acer