These aren't really different techniques. They're just ways of getting various effects, and may be used together or not.

You can save both procedures and modules to library archives ("repositories").

And you can keep distinct procedures' sources in separate text files, or in separate worksheets. The same goes for whole modules.

But you cannot keep the source of different module members (individual exports or locals of the same module) in separate worksheets if you intend to merge them using $include. (You might be able to use `read`, but then you could not use $define.) You can, however, keep those individual module members' sources in separate text files and merge them with those preprocessor directives.

Those directives are thus most useful for managing sources of large modules, if one wants to keep all individual members' sources separate.

You also mentioned wanting to "define" some variable's value in a separate file. For that, $define and $include are great. Also, these serve very well to keep common definitions centrally defined (just like C header files can do).

The stuff about text files being safer against corruption, and better for revision control, still holds I believe. That's not important for everyone, perhaps. And plaintext can be shared/viewed even when Maple is not available. That too, may not be important to everyone.

With the commandline interface, you can load/save sources in batch mode, or do other nifty shell scripty things to them.

acer

Alec's suggestion is about Maple, not Mapleprimes. Start Maple itself. Type in

?zip

and read the Examples section.

The last example on that help-page is this,

> zip(`[]`,[1,2,3] ,[4,5,6]);
 
                           [[1, 4], [2, 5], [3, 6]]

acer

Alec's suggestion is about Maple, not Mapleprimes. Start Maple itself. Type in

?zip

and read the Examples section.

The last example on that help-page is this,

> zip(`[]`,[1,2,3] ,[4,5,6]);
 
                           [[1, 4], [2, 5], [3, 6]]

acer

> one := 1/((x*Dd-x^2*Dcj)*sqrt(x^2-1)):
> two := int(one,x) assuming x>1, Dd>0, Dcj>0, Dcj>Dd:
> three := simplify(%):
> four := subs({x = sqrt(1+Zeta^2)}, three):
> five := simplify(four) assuming Zeta>=0:

> lprint(five);
-(Dcj*arctan((-Dcj+(1+Zeta^2)^(1/2)*Dd)/(-Dd^2+Dcj^2)^(1/2)/Zeta)+arctan(1/
Zeta)*(-Dd^2+Dcj^2)^(1/2))/(-Dd^2+Dcj^2)^(1/2)/Dd

> kernelopts(version);
             Maple 11.02, X86 64 LINUX, Nov 9 2007 Build ID 330022

You're probably better off using some name other than capital Zeta (which is a function, and may be why `simplify` ran into a recusrion limit error when the assumption didn't match the right name). Using zeta instead of Zeta, it seemed ok with or without the assumption.

acer

> one := 1/((x*Dd-x^2*Dcj)*sqrt(x^2-1)):
> two := int(one,x) assuming x>1, Dd>0, Dcj>0, Dcj>Dd:
> three := simplify(%):
> four := subs({x = sqrt(1+Zeta^2)}, three):
> five := simplify(four) assuming Zeta>=0:

> lprint(five);
-(Dcj*arctan((-Dcj+(1+Zeta^2)^(1/2)*Dd)/(-Dd^2+Dcj^2)^(1/2)/Zeta)+arctan(1/
Zeta)*(-Dd^2+Dcj^2)^(1/2))/(-Dd^2+Dcj^2)^(1/2)/Dd

> kernelopts(version);
             Maple 11.02, X86 64 LINUX, Nov 9 2007 Build ID 330022

You're probably better off using some name other than capital Zeta (which is a function, and may be why `simplify` ran into a recusrion limit error when the assumption didn't match the right name). Using zeta instead of Zeta, it seemed ok with or without the assumption.

acer

Most of the Maple math library code has been written over a span of 20+ years. So it doesn't have a truly uniform style. The style of several different authors can be detected in different parts -- a bit like the "fist" of a Morse code sender.

It might be fun to try and guess clumps of library code written by the same author. (Like detecting the supposed author "Q" of parts of the NT.)

The `int/cook` routine(s) are not new, relatively speaking. Are there more bugs in old or new code?

More seriously, it might be nice to have a form of code comment that can survive being saved to a .mla archive, being loaded from archive, and passed to print or eval.

acer

Most of the Maple math library code has been written over a span of 20+ years. So it doesn't have a truly uniform style. The style of several different authors can be detected in different parts -- a bit like the "fist" of a Morse code sender.

It might be fun to try and guess clumps of library code written by the same author. (Like detecting the supposed author "Q" of parts of the NT.)

The `int/cook` routine(s) are not new, relatively speaking. Are there more bugs in old or new code?

More seriously, it might be nice to have a form of code comment that can survive being saved to a .mla archive, being loaded from archive, and passed to print or eval.

acer

It may be possible to contrive alternative names for a snark.

I recall seeing both a French and a German translation of Jabberwocky in The Annotated Alice. The French name was given as le Jaseroque, and the German as der Jammerwoch.

This page indicates that someone thought that Snark remains the same in French, but becomes Schnark in German. (But, what's wrong with Snarque)?

acer

It may be possible to contrive alternative names for a snark.

I recall seeing both a French and a German translation of Jabberwocky in The Annotated Alice. The French name was given as le Jaseroque, and the German as der Jammerwoch.

This page indicates that someone thought that Snark remains the same in French, but becomes Schnark in German. (But, what's wrong with Snarque)?

acer

What you're seeing in E looks like premature evaluation. (Is striving to change p.e. tilting at windmills? I'm not sure.)

Presumably your point is that you want E to be C, without having to set Digits to 20 beforehand. While an uneval (or evaln) argument to a procedure, like sin(Pi) can be prevented from evaluating, the 1/6. inside sin(Pi/6.) is another story.

> pe := proc(x::uneval) lprint(x); x; end proc:

> pe(sin(Pi));
sin(Pi)
                                    sin(Pi)
 
> pe(Pi/6.);
.1666666667*Pi
                                0.1666666667 Pi

acer

What you're seeing in E looks like premature evaluation. (Is striving to change p.e. tilting at windmills? I'm not sure.)

Presumably your point is that you want E to be C, without having to set Digits to 20 beforehand. While an uneval (or evaln) argument to a procedure, like sin(Pi) can be prevented from evaluating, the 1/6. inside sin(Pi/6.) is another story.

> pe := proc(x::uneval) lprint(x); x; end proc:

> pe(sin(Pi));
sin(Pi)
                                    sin(Pi)
 
> pe(Pi/6.);
.1666666667*Pi
                                0.1666666667 Pi

acer

After those changes E will still come out the same.

> unprotect(`*`);
> `*`:=(a,b)->a*b:
> protect(`*`);
> `&/`:=(a,b)->b(a):
> C := sin( Pi/6 ) &/ evalf[20];
                          C := 0.50000000000000000000
 
> C := sin( Pi/6. ) &/ evalf[20];
                          C := 0.50000000009068996821

One might label automatic simplification as one form of p.e.

note. Alec's response was edited while I was composing the above reply, and the first 5 input lines above removed. Sorry, Alec! I suppose that it was realized that automatic simplification cannot be turned off by us mortals.

acer

After those changes E will still come out the same.

> unprotect(`*`);
> `*`:=(a,b)->a*b:
> protect(`*`);
> `&/`:=(a,b)->b(a):
> C := sin( Pi/6 ) &/ evalf[20];
                          C := 0.50000000000000000000
 
> C := sin( Pi/6. ) &/ evalf[20];
                          C := 0.50000000009068996821

One might label automatic simplification as one form of p.e.

note. Alec's response was edited while I was composing the above reply, and the first 5 input lines above removed. Sorry, Alec! I suppose that it was realized that automatic simplification cannot be turned off by us mortals.

acer

This is so nice and simple. Much more Maple-like than my `&N` above.

It's a pity about the parentheses, sometimes necessary on account of Maple's immutable operator precedence rules. Now maybe it'd be far too much effort, but could one write an analyzer/replacer that took input and inserted brackets so as to force a particular choice of alternative operator precedence rules? I'm not sure whether ToInert could work easily. Perhaps converting a procedure's evaln argument to a string might be a start.

ps. I believe that it is possible to treat top-level input as if it were an evaln parameter of a procedure (for 1D input, at least). The hint is to look closely at the source of the Warnings package on mapleapps.

acer

This is so nice and simple. Much more Maple-like than my `&N` above.

It's a pity about the parentheses, sometimes necessary on account of Maple's immutable operator precedence rules. Now maybe it'd be far too much effort, but could one write an analyzer/replacer that took input and inserted brackets so as to force a particular choice of alternative operator precedence rules? I'm not sure whether ToInert could work easily. Perhaps converting a procedure's evaln argument to a string might be a start.

ps. I believe that it is possible to treat top-level input as if it were an evaln parameter of a procedure (for 1D input, at least). The hint is to look closely at the source of the Warnings package on mapleapps.

acer