A useful addition to PDEtools might be a command, say unindex, that expands an indexed name to a derivative of a previously declared function.  Then one could use the shorthand to enter the derivative. 

For that to work properly, the functions generally have to be declared, otherwise unindex(f[x,y]) is ambiguous, the base function could be f(x,y), f(y,x), or even f(x,y,z).

A useful addition to PDEtools might be a command, say unindex, that expands an indexed name to a derivative of a previously declared function.  Then one could use the shorthand to enter the derivative. 

For that to work properly, the functions generally have to be declared, otherwise unindex(f[x,y]) is ambiguous, the base function could be f(x,y), f(y,x), or even f(x,y,z).

Another possibility is to only sum over the last year's worth of responses. 

FYI, his email address is listed above. However, I already sent him a corrected worksheet. 

FYI, his email address is listed above. However, I already sent him a corrected worksheet. 

The initial setting of currendir is only part of the picture.  I use linux and always launch the Maple GUI from a shell (I don't use icons for launching applications).  As such, currentdir is set properly, to the directory from which the command was executed. Alas, the setting of currentdir does not affect the default directories use by the various File menu entries (Open, Save, SaveAs, Export).  Rather, the default directories for these commands are taken from the maplerc file (located in ~/.maple/12/maplerc), which stores the previous value last used by the corresponding file operation.

I find that operation particularly annoying---it forces me to click through the file hierarchy to return to the directory from which the worksheet was launched. With a deep tree that can require a lot of clicks and mouse operations. More useful would be for Maple, when launched from a shell, to use the current directory as the default for standard file operations.  Possibly it would even use currentdir() as the default.  This gets tricky when a worksheet is opened from a different directory from which the GUI was launched.  In that case, it is reasonable to use that directory as the default for the next operation.  A fairly simple solution might be to provide a means, in the menu dialogs, to easily reset the default directory to the value of currentdir().

The initial setting of currendir is only part of the picture.  I use linux and always launch the Maple GUI from a shell (I don't use icons for launching applications).  As such, currentdir is set properly, to the directory from which the command was executed. Alas, the setting of currentdir does not affect the default directories use by the various File menu entries (Open, Save, SaveAs, Export).  Rather, the default directories for these commands are taken from the maplerc file (located in ~/.maple/12/maplerc), which stores the previous value last used by the corresponding file operation.

I find that operation particularly annoying---it forces me to click through the file hierarchy to return to the directory from which the worksheet was launched. With a deep tree that can require a lot of clicks and mouse operations. More useful would be for Maple, when launched from a shell, to use the current directory as the default for standard file operations.  Possibly it would even use currentdir() as the default.  This gets tricky when a worksheet is opened from a different directory from which the GUI was launched.  In that case, it is reasonable to use that directory as the default for the next operation.  A fairly simple solution might be to provide a means, in the menu dialogs, to easily reset the default directory to the value of currentdir().

I should have mentioned that foldr applies the transformations from bottom to top.  In your case, the transformation to \frac{1}{2} is later converted to \frac 1 2.  To avoid that, move your transformation to be physically above the one that strips braces from single digits.

While not necessarily a pitfall, there is a disadvantage to inserting into a preexisting library, that is, one used to store your other packages (that may not be what you are doing here).  If something goes wrong with the process you can corrupt the library.  Unless you have provided a quick (that is automated) way to rebuild the library (say with a shell script) you may have to manually rerun all the worksheets that generated the library.  When developing a package I generally insert it into its own library. 

While not necessarily a pitfall, there is a disadvantage to inserting into a preexisting library, that is, one used to store your other packages (that may not be what you are doing here).  If something goes wrong with the process you can corrupt the library.  Unless you have provided a quick (that is automated) way to rebuild the library (say with a shell script) you may have to manually rerun all the worksheets that generated the library.  When developing a package I generally insert it into its own library. 

Because no filename was passed to savelib, it chooses one.  First it looks at whether the global variable savelibname is assigned, if so, it uses it.  Otherwise it tries, in turn, each element of libname, stopping when it successfully saved the file. By appending test.m to libname, it is quite likely that that won't be the file name used (that is, it will be the last one tried, and only if the previous could not be used).

Because no filename was passed to savelib, it chooses one.  First it looks at whether the global variable savelibname is assigned, if so, it uses it.  Otherwise it tries, in turn, each element of libname, stopping when it successfully saved the file. By appending test.m to libname, it is quite likely that that won't be the file name used (that is, it will be the last one tried, and only if the previous could not be used).

I don't understand what you are asking. As defined, the curve is quadratic in y, which means that for a given value of x there are two values of y that satisfy the equation.  So specifying x = 1..6 doesn't not uniquely specify a segment of the curve.  I suppose one could argue that the lengths of the two segments are the same. In which case you might just solve for y and pick one branch.

eq := y^2+y = x:
sol := solve(eq, y);
curve1 := <x,sol[1]>:
curve2 := <x,sol[2]>:
length1 := ArcLength(curve1, x=1..6);
length2 := ArcLength(curve2, x=1..6);
 

I don't understand what you are asking. As defined, the curve is quadratic in y, which means that for a given value of x there are two values of y that satisfy the equation.  So specifying x = 1..6 doesn't not uniquely specify a segment of the curve.  I suppose one could argue that the lengths of the two segments are the same. In which case you might just solve for y and pick one branch.

eq := y^2+y = x:
sol := solve(eq, y);
curve1 := <x,sol[1]>:
curve2 := <x,sol[2]>:
length1 := ArcLength(curve1, x=1..6);
length2 := ArcLength(curve2, x=1..6);
 

In case anyone is interested, I refactored the code that Tim submitted.  The following might be nicer to play with. It is an appliable module.

MyLaTeX := module()
export ModuleApply
    , ExprsToLaTeX
    , CleanLaTeX
    ;

    ModuleApply := CleanLaTeX;

    ExprsToLaTeX := proc()
        return cat("", `latex/print`(_passed));
    end proc;

    CleanLaTeX := proc(expr, regsubs :: seq(string=string), $)

        return foldr(StringTools:-RegSubs
                     , ExprsToLaTeX(expr)
                     , ListTools:-Reverse([regsubs])[]
                     , "\\\\!"            = ""      # remove \!
                     , "{([0-9])}"        = "\\1 "  # strip braces from single digits
                     , "\\\\_"            = "_"     # change \_ to _
                     , " \\\\right\\)"    = ")"     # remove \right)
                     , " \\\\left\\( "    = "("     # remove \left)
                     , "{\\\\it ([^}]*)}" = "\\1"   # remove italics from variables
                     , "\\\\,"            = " "     # remove \,
                    );

    end proc;

end module: