These ideas seem to suffer from skewness, either in placement of the values toward an endpoint or in respect to the distribution of the size of the jumps (while the combinat solutions apparently don't).

acer

Very nice.

Can it stay so simple, while getting the ability to restrict the maximum stepsize as the submitter mentioned in a postscript?

acer

Very nice.

Can it stay so simple, while getting the ability to restrict the maximum stepsize as the submitter mentioned in a postscript?

acer

If you add the location of your new .mla Library archive to libname, then you ought to be able to access its contents. The ?libname help-page gives examples (Unix, but easy to adjust for MS-Windows style paths).

The command to modify the read-write permissions of a Library archive is LibraryTools:-WriteMode. Trying to use that on Maple's own installed archives would generally be a very bad idea.

Adding custom written prodecures to private archives, and reusing them after augmenting libname, is common practice. There should be no need to overwrite anything in Maple's own archives (even patches and fixes aren't implemented as direct in-place edits, but are pushed out as alternate versions in a new archive which gets found first by having a higher internal access-priority).

acer

If you add the location of your new .mla Library archive to libname, then you ought to be able to access its contents. The ?libname help-page gives examples (Unix, but easy to adjust for MS-Windows style paths).

The command to modify the read-write permissions of a Library archive is LibraryTools:-WriteMode. Trying to use that on Maple's own installed archives would generally be a very bad idea.

Adding custom written prodecures to private archives, and reusing them after augmenting libname, is common practice. There should be no need to overwrite anything in Maple's own archives (even patches and fixes aren't implemented as direct in-place edits, but are pushed out as alternate versions in a new archive which gets found first by having a higher internal access-priority).

acer

Names commonly returned by anames(user), in which you are not interested, can be removed from your inquiry.

> T:=5*Unit(degF):
> setattribute('T',"temperature"):
> L:=[4,5]:
> V:=Vector(L):
> setattribute('h',"height"):
> eqn:=T*h:

> p:=proc() local x;
>   seq([x,whattype(eval(x)),[attributes([x][1])]],
>       x in {anames('user')} minus {'lasterror','lastexception',:-p});
> end proc:

> p();
 [L, list, []], [T, *, ["temperature"]], [V, Vector[column], []], [eqn, *, []]

Note that name `h` is not reported, since it has not been assigned a value.

acer

Names commonly returned by anames(user), in which you are not interested, can be removed from your inquiry.

> T:=5*Unit(degF):
> setattribute('T',"temperature"):
> L:=[4,5]:
> V:=Vector(L):
> setattribute('h',"height"):
> eqn:=T*h:

> p:=proc() local x;
>   seq([x,whattype(eval(x)),[attributes([x][1])]],
>       x in {anames('user')} minus {'lasterror','lastexception',:-p});
> end proc:

> p();
 [L, list, []], [T, *, ["temperature"]], [V, Vector[column], []], [eqn, *, []]

Note that name `h` is not reported, since it has not been assigned a value.

acer

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

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