@sand15 My suggestion entails having all your source in plaintext files. After that, their text would never get re-imported back into any worksheet format (whether Maple Notation or otherwise).

Suppose you have an entire module, M, whose source definition is in the text file srcM.mpl . In that case you could, in either the GUI or the commandline interface, "load" that module with the command,

 read "srcM.mpl";

Having loaded the module in any session, you could then call it's exports (or itself, it is is an appliable module. That would cover both the interactive application as well as any unit testing.

I don't understand how Shift-Enter issues would come into that.

If procedure in module M also call procedures from outside M (user-defined top-level procs, or exports of user-defined module N, say) then you would load both before executing. Eg.

 read "srcM.mpl";
 read "srcN.mpl";

Another way would be to use LibraryTools to save(lib) both M and N to the same .mla Library archive. A worksheet's Startup Code could contain either the simple read statements, or a statement that appends to libname (so as to pick up any .mla archive).

I usually have a very small text file (of Maple code) which:
1) sets the Maple include path
2) reads the module defn files (which may contain $include directives)
3) saves to .mla archive
And then I just need to augment libname to get the package into play. If it's very useful then I may even end up putting the .mla into a toolbox folder, so that libname is augmented automatically, upon normal launch of the GUI or commandline interfaces.

The key thing is that, once my source gets migrated to plaintext then it never gets put pack, literally as code, into any worksheet.

Having said all the above, I'm afraind that I don't understand your comment about WorksheetToMapleText and difficulties with references from within a module to other user-defined procedures. And I'm afraid that I also don't understand the comments about Shift-Enter, after using the menubar's File->Export as..., because the format to export to is plaintext (ie. .mpl or .txt, but certainly not some other .mw variant or anything with input prompts).

I forgot to mention it before but additional benefits of plaintext files are A) the stand-alone Maple language Syntax Checker mint can be used easily and to its full power, and B) plaintext files are extremely well protected against file-corruption when using mature editors such as vi, emacs, etc.

As far as Carl's comment goes, yes of course you don't necessarily have to split up module sources into seperate files for each procedure. If you do, then the $include directive (and includepath) is very handy. That's a matter of taste. I find that as my project gets large, and the revision histories get long, then it helps me to make sense of the revision diffs if I don't have to visually process too much at once. This aspect is colored by your choice of revision control tool, naturally.

Or, without parametrizing by `t`,

restart;

z:=a+b*I:

C:=abs(z+3-2*I) + abs(z-3-8*I) = 6*sqrt(2):

# Key observation, the constraint allows the problem
# to be represented as univariate problem.

eq:=isolate(evalc(C),a);

                eq := a = b - 5

# The univariate expression to be optimized, now with
# only the simple bounds on `b` as remaining constraints.

expr:=evalc(abs(eval(z,eq)));

                          2    2 1/2
          expr := ((b - 5)  + b )

simplify( [ maximize( expr, b=2..8, location) ] ):

# Beautify
op(1,%), op([2,1,1,..],%), eval(eq, op([2,1,1],%));

             1/2
           73   , b = 8, a = 3

simplify( [ minimize( expr, b=2..8, location) ] ):

# Beautify
op(1,%), op([2,1,1,..],%), eval(eq, op([2,1,1],%));

             1/2
          5 2
        ------, b = 5/2, a = -5/2
           2

# Alternative way, by getting the extreme points of
# the univariate problem.

Student:-Calculus1:-ExtremePoints( expr, b=2..8 );

                   [2, 5/2, 8]

simplify( [seq([expr,'b'=b,eq],b=%)] )[];

       1/2
    [13   , b = 2, a = -3],

          1/2
       5 2
    [------, b = 5/2, a = -5/2],
       2

       1/2
    [73   , b = 8, a = 3]

# And of course we can sort the above, to get the max and min.

If you have grief using the main menubar's item File->Export as... as a way to export (module and procedure sources) from .mw files to plaintext then you could also compare with the results from the undocumented command Worksheet:-WorksheetToMapleText.

If I recall, that command accepts a filename (string), and returns a string (with input code lines split by \n). So you then could use FileTools:-Text:-WriteFile command to push the result string into a .txt file.

@sand15 I do my source code edits using the text files directly. I use `vi` for which one can get maple syntax highlighting. But syntax highlighting is also available for emacs or other good editors. I'm not sure about git itself.

I also write so-called "unit tests" of the computational procedures, in plaintext files which I name as ".tst". For those I use Maple's TestTools package. There's something on this in the Programming Manual. I run the unit tests using the command line interface.

nb. The .mw format allows so-called Code-Edit Regions, which offer some syntax highlighting. But since .mw is completely at odds with decent, workable revision control then I would not try and maintain an involved packages source in it.

I would not tie myself to any format which cannot be read and re-used and rebuilt using the command line maple interface. That's one reason I would never use that IDE mentioned in another answer. 

The text-file approach can be used to rebuild from within the command line, Std Java GUI, or Classic GUI.

I understand that Maplets is a mature and quite full-fledged platform for the graphical interface aspect. I dont know how involved your app is, in those interactive ways. But have you considered using programmatically generated embedded components instead? I am not sure what future there is for Maplets in the Maple Cloud or the Maple Player.

I'll look for an old note about a programmatic command for exporting code from .mw to .txt. 

@nm screenshots are useless.

Upload an actual worksheet. Use kernelopts(version) not interface(version) which is no help. Execute `libname;` to show us what else might be in play. What's in your initialization file? You've been around long enough to realize why this stuff may matter.

Your first example worked just like your second example for me, in 64bit Maple 2017.0 running in 64bit Windows 7 Pro, pasted in line by line as either 1D Maple Notation or 2D Input.

Indeed, from the help page ?combine,trig

"Products and powers of trigonometric terms involving sin, cos, sinh and cosh are combined into a sum of trigonometric terms by repeated application of the transformations..."

"The form of the result is a sum of trigonometric terms whose arguments are integral linear combinations of the original arguments."

You could try entering it into Maple.

If I may make a few comments:

I'd like the documentation to explicitly mention that when both dot and prime settings are enabled, with the same symbol for both, then output is displayed with the prime notation. So, for example, if one wants to get diff(y(x),x) pretty-printed as 2D Output in dot notation then it is also necessary to set useprime=false as well as dot=x. That was the case in Maple 2016.2 as well, but as mentioned in Maple 2017.0 one must also set typesetdot=true.

To some it may seem a quibble, but I've always found it awkward that the over-dot is rendered centrally, which doesn't take into account that the variable names are (by default) rendered using italic font for 2D Output. This makes the dot look misplaced, too far to the left of the oblique name symbol. (Note that this effect doesn't show in the inlined code below, here on Mapleprimes, but it certainly does in my Maple proper for Linux.)

I can see the usefulness of the primenotationbound setting. But why does Typesetting:-Settings not also have a dotnotationbound setting?

Download typesetdotprime2016.mw

Download typesetdotprime2017.mw

@kuwait1 So then (at least for this example, as demonstrated by the above code) it might be good to use infinity for the upper value of the outer summation index.

If you replace the upper limit for the index of the outer summation by 20 instead of 100 then for the given examples you can halve the time and only lose a few digits of accuracy.

However you may not be confident that doing so is always safe, with regards to accuracy loss. In that case you might well choose to go with i=0..infinity instead, leaving it to `evalf/Sum` to figure out how many terms to utilize.

See also my last Comment in my Answer to a previous, related Question of yours. (I got your computation time down there by about a factor of ten, if I recall...) I note that you never responded to this, "I don't understand why you are still [...] using Digits=50 and nterms=100, when you haven't shown examples of n and phi that require that much computational expense".

[edited] If I recall your original attempt in that earlier Question also used active sum, and that the performance improvement of instead using add or evalf(Sum(...)) in the simplest way was very large. Essentially it made near intractable example(s) run in much more reasonable time. And something like a "factor of ten" was only how much I was able to improve further upon that large benefit. And that basic improvement of replacing active sum didn't necessarily require changing the Digits or number-of-terms choices. So it seems remarkably odd that in this current Question you are still trying to use sum.

@Christopher2222 Nasser's methodology in those test suites has nothing to do with his adeptness  (or rather, he tries hard to ensure that).

That's on principle. He's assessing how well the products do using just their integration commands called on the original input.

It's already well known that many of the more problematic integrals can be done if a human assists the Computer Algebra System -- integrating by parts, change of variables, splitting the range, changing the representation, doing it by contour, etc etc.

Something similar can be said about the "size" of the results. Maple doesn't automatically simplify after several kind of computation, and for some Mathematica does. That also affects the timings -- Maple beats all the other systems hands down on speed in these integration test suites, but its mean result-size is huge.

Of course there are also some much shorter results that can attain because a pattern lookup formula exists and may be known to the system. (Think of factored polynomials in the denominator, for example.)

@Sternkopf I'll send you an email later this morning.

@wswain 

Yes, the `print/pre` procedure only affects the printing of a call like pre(expression), which otherwise remains unevaluated. It's not common to have to construct this kind of approach.

The following is a so-called anonymous procedure. I don't have to assign it to a name (e.g.. f) in order to be able to use it.

x->x^2

Here is another.

(a,b)-> a^2+b^2

Here's another.

(a,b)-> g(a) <= g(b)

Given some other proc g which returns a numeric value, that last anonymous proc can be used as a comparator. It can be used, say, as the additional optional argument passed to the sort command.

A procedure like,

proc(a,b) a^2+b^2; end proc

or,

(a,b) -> a^2+b^2;

is an entity unto itself. There are situations in which it can be used without having to first assign it to a name.

By itself, the definition of an anonymous procedure does not "do anything" to its formal parameter(s). For example the following does not affect the name X.

X -> X^2;

In 2D Input mode the GUI will allow you to optional interpret the following in the same way.

f(x) := x^2

f := x -> x^2

I consider allowing the former to be a very poor design choice, because it re-uses a syntax that already meant something else in the Maple language. Ambiguous language syntax and nomenclature ALWAYS leads to problems and user confusion.

Similarly for so-called "programmer indexing", which has nothing to do with this discussion (despite the connotations about procedures inherent in the term "programmer"). It involves using round brackets for indexing into Arrays/Vectors/Matrices, as an twist on the more usual square-bracket indexing notation. Round brackets after a name already meant function call (since forever), so highjacking it to also mean Array indexing was another  (somewhat recent) poor language design choice (and your confusion above is understandable).

@wswain There is no procedure defined and assigned to the name pre. That is key. So when you call pre(expression) the output is the same thing -- a so-called unevaluated function call.

Maple allows you to set up a custom printing procedure that will get used to prettyprint such an unevaluated function call. For such an unevaluated function call to pre, the print-extension procedure must be named `print/pre`.

So I constructed a `print/pre` printing extension procedure. What it does is build up another expression that displays the way you want. See section 10.3 of the Programming Guide for a brief subsection on this.

Maple uses an internal mechanism sometimes called uniquification or simplification (not to be confused with the simplify command). The Maple kernel (engine) maintains a simplification table of uniquifications of expressions. This helps in memory management, and aids efficiency. For example there is only ever one instance in memory of an expression such as x+y. If you later on type in y+x then the internal structure for that (DAG) is the very same one for x+y. Whichever order is the first to be created and store is the one to which the other will be uniquified. See the Appendix of the Programming Guide for a brief section on this.

The Maple command sort does allow for some behind-the-scenes in-place replacement. For example,

restart;

ee := w+v+x+y+z;

             ee := w + v + x + y + z

ee;

                w + v + x + y + z

op(1,ee), op(2,ee);

                      w, v

z+y+x+v+w;

                w + v + x + y + z

sort(ee, order=plex(y,z,x,w,v));

                y + z + x + w + v

ee;

                y + z + x + w + v

op(1,ee), op(2,ee);

                      y, z

z+y+x+v+w;

                y + z + x + w + v

Notice how the op command pulls out the operands (summands) in the order in which they are stored, and here that matches the order in which they appear in the pretty-printed display.

Now, the LHS of your equation is not a polynomial in the differential terms -- they are not names. The above kind of forced sort did not get me what you were after.

I can pick of the summands (operands) of the LHS of your equation. I can put them in a list. But if I then try and add them together (using commands add, or `+`, say) then I just get back something which gets uniqified back to the already-stored expression with the original ordering.

There are other ways approach this problem, and to mimic a re-ordered display. Some of those will introduce visible artefacts, such as extra brackets or single-quotes in the display, or italic instead of upright fonts, or partially gray rather than black forground. etc. I wanted to obtain something that would look as close as possible to the usual pretty-printed output, but with a forced order.

In the case that the interface(typesetting) level is standard, my custom print extension `print/pre` constructs another version of its argument expression in which the global name diff is replaced by a freshly generated local name diff. This new sum of terms will not have been created before, and shouldn't uniquify to some earlier ordering. In the case that the typesetting level is extended I used a weaker approach, which should work as long as you haven't utilized %diff and its other inert friends on the same expression (yet not ordered)  earlier. If you encounter a problem in that (more rare) scenario I can likely strengthen it.

I wrote this in the very early morning. At some point, in some variant of diff/Diff/D or typesetting level I believe I saw an expression where the internal ordering of the terms in the SUM DAG did not match the order of the prettyprinted terms. I actually gave up on a few other approaches because of that (and because of additional visible artefacts).

I hope that I did not miss some much easier solution which would cover all the cases.