@mmcdara You wrote:

• Thanks for your first reply about the mechanism behind satisfies.

My first Reply is about the distinction between operators and operands. I hope that you read that also. My second Reply is about satisfies.

• Is there a particular reason to write  indets(e, typefunc(anything, And(name, Not(mathfunc)))) instead of 
  indets(e, typefunc(And(anything, name, Not(mathfunc))))?

As you confirmed, anything is the implicit first argument of typefunc when it's used with one argument. Since anything is like the identity type of And, there's never a reason to use anything as an argument to And. So, the whole thing can be simplified to indets(e, typefunc(And(name, Not(mathfunc)))).

• What situation does indets(e, typefunc(anything, And(name, Not(mathfunc)))) avoid that 
  indets(e, Not(mathfunc)) doesn't?

Given any "reasonable" type foo, I don't think that it'd ever be a good idea to use indets(e, Not(foo)), which would select all subexpressions, no matter how complicated, that aren't of type foo.

• Is it necessary to discard the "case of a constant" in indets(expr, And(name, Not(constant))) ?
  For instance it seems that these simplifications of v still give the correct result.

From your new example expr, I guess that you realize that Pi is both a name and a constant. But your example is superficial because the Pi is not inside piecewise. If you put it inside the piecewise for which it's currently a coefficient (this can even be done in a way that doesn't change the mathematical meaning of expr), then you'll see why constants need to be discarded from the freeof set. (Your example is superficial because the expressions that appear outside the piecewises are irrelevant to determining whether a term is selected.)

• Maybe a little less concise than Preben's but I still vote up

Preben's Answer addresses the specific example that you gave. My Answer addresses the verbal description that you gave (modulo my comment about operator vs, operator) using the example as a guide but trying to cover all cases "in the same spirit" as the example that fit your verbal description. There are a vast variety of such cases "in the same spirit" that are covered by my Answer but not his. For example, Preben's Answer will select any term containing any piecewise that contains any inequality or equation whose left side is t, even if that piecewise contains x elsewhere. Surely, such a piecewise shouldn't be considered to be a "function of t alone". And what if 2*t is on the left side of the inequalities? What if t is on the right side but not the left?

@mmcdara I hope that this can alleviate those mental gymnastics:

In other (perhaps more-formal) words, satisfies is a meta-type (or type constructor) that allows, on an ad hoc basis, any predicate expressed in procedure form to be used as a type. Here, I'm using predicate as it's standardly used in mathematical logic: a parameterized expression which becomes a proposition when appropriate values are substituted for its parameters. A proposition is an expression that can be evaluated to true or false.

For non-ad-hoc situations, it's probably better to use TypeTools:-AddType. For example, if P is a one-parameter procedure that always returns true or false, then 
TypeTools:-AddType(typeP, P);
type(e, typeP)
is equivalent to
type(e, satisfies(P)). (typeP could be replaced by simply P or any other symbol.)

Having read this whole thread, I now know that by "operator" you mean either "operand" or "term", and this has led to some confusion among the respondents. In this particular case---where expr is type `+`--- "operand" and "term" mean the same thing.

Consider the expression a + b*f(t). Its top-level operator is `+`. The operands of that operator are a and b*f(t). A 2nd-level operator is `*`.

In f(t) we can call f the operator (although I'm not sure if that usage of operator is universally standardized) and t the operand. Another point of view (towards which I lean), is that the operator in f(t,u) is the invisible infix function application operator (represented in prefix form in Maple as `?()`) and its operands are f, t, and u (or f and the sequence (t,u)). In either point of view, calling t and u the arguments is universal.

A term, as that word is used in secondary-school algebra, is simply any single operand of a `+` expression, or anything that could be used as a single operand of `+`. (Expressions constructed with infix `-` are considered to be type `+` also.)

From my quick reading, both eq1 and eq2 are derived from id, but no definition is given for id. S​​​​​​o the more-fundamental question is Where is id (which presumably stands for ideal diode) defined?

@vv You wrote:

•  I don't know why uses does not work in this form.

Because the module references are linked into the code at the time that the code is read, not the time that it's executed.

This is the same reason that with doesn't work in procedures and why my procedure init wouldn't work without the parse command.

@greatpet You wrote:

• For example, I might want to do this if I want to use some "inner" procedure heavily in the defintion of a procedure in the outer module.

Using so-called "short-form" names is a bad programming habit that makes code less readable. I advise against it, and I never do it myself, even at the top level, unless I'm doing "scratch" work that won't be saved and I need to work quickly (usually because I'm talking to a student at the same time as doing some computations relevant to what I'm talking about). Instead, I do what VV recommended: I use uses to define a one- or two-character abbreviation of the prefix.

@Rouben Rostamian My interpretation is that (a,b) < (c,d) means a < c and b < d, although it's not entirely clear that that's the intended meaning.

@greatpet You wrote:

• Unfortunately this gets very verbose when there are many inner modules.

The way that you described the steps makes it seem as if you consider defining the inner modules and exporting them to be separate steps. Yes, you can do it that way, but it's not necessary. I define all procedures and submodules immediately at the point that they're declared local or export. See the example below. It also seems as if you consider export to be a command instead of a declaration. I lconsider it to have the same status as local. Every variable is either a local, an export, or a global.

• It would be really helpful if Maple supported "nested export", allowing procedures exported by inner modules to be further exported by the outer module.

I'm not sure what you mean. Could you show an example that leads you to believe that Maple doesn't have that feature?

Here's my example:

OM:= module()
export
    IM:= module()
    option package;
    export add_three:= x-> x+3;
    end module;
end module
:
with(OM:-IM);
                          [add_three]
add_three(z);
                             z + 3

For months you have been asking Questions very similar to this one. I'm not saying that that's a problem, but hopefully you're trying to learn how to do these yourself? You should post your attempts at writing procedures so that we can help you better. It doesn't matter how incorrect the attempts are; you'll learn more that way than by just asking straightforward graph theory questions. 

@brian bovril Regardless of whether the integration can be done symbolically, there's no benefit to using unapply like that.

You can use a step with add, unlike sum. The only reason I used sum was because the integration could be done symbolically. If it can't be, you should use add anyway.

Isn't the expression u above also "a product of two Gaussians"? Yet it can be integrated symbolically nearly instantaneously. Can you show an example of just one term from your actual expression? 

This is likely of little significance towards fixing this; I just mention it as a curiosity: The assigned value is the final valid value, whereas with a for loop, it'd be the first invalid value.

@nmacsai You asked:

• The data set I am working with is a csv file.  Is there a way to convert it into a binary format?

Once the numeric data is in a Maple Array (or Matrix or rtable) with a hardware datatype (such as float[8]), it can be made into a binary file with the command 

FileTools:-Binary:-WriteFile("file name", array name);

Reconstruction of the array from the file requires (at the very least) knowledge of the number of rows and columns (and other dimensions, if applicable). Making a complete and automatic conversion followed by reconstruction, including all of the array's options and attributes, is the subject of the first Reply to my Answer below.

The command convert(n, binary) that you mentioned represents a number n using the literal digits 1 and 0 (and possibly a decimal point). It is mainly for display rather than computational purposes.

@mmcdara If you're saying that the CSV file should be read into Maple once and then saved as a binary file for re-use within Maple, then I agree with you, and I've already said so, and my Answers show how to do it while retaining all the structural information (number of rows, number of columns, etc.).

But both the OP and I have interpretted "it is not recommended to work with csv files this size. It is much more efficient to use binary files instead" to mean that you're advocating the complete elimination of the CSV. That's what I disagree with. The OP's data is in a CSV, so they have no choice but to "work with a csv file of this size" at least once. And the binary file is worthless without that structural information (including the byte order), so I'd keep the CSV for long-term (aka archival) storage, or use one of those other formats (JSON, etc.) that are human readable. I'll note that CSV is one of the "acceptable" formats discussed on the "big data" web page that you linked.

Also, I have no idea what "essentially raises the main question" means. Perhaps it's a phrase that doesn't directly translate well from French to English.

@acer Does having a large DataTable slow down the GUI, like having a large plot or large prettyprinted formulas slows it down even when they're off screen? What about the auto-saves?

@Muhammad Usman There's no computational reason to put the ands in the piecewise conditions; indeed, they slow down the computation a tiny bit. So, Tom's form is functionally equivalent to yours. The only reason to use the ands would be to achieve a certain display.

The traditional textbook-style display of piecewise functions supposes that one views the conditions independently of each other. The lines could be rearranged in any order and they'd still make sense (although it would reduce the readability). But the conditions in a Maple piecewise are not processed independently of each other. They are processed strictly in the order presented, and the processing stops as soon as one condition is true. This is why the ands aren't needed when the conditions are given in real-number order.