Enter a period (lower dot) for Matrix-Vector and Matrix-Matrix multplication, not a star (which displays as a center-dot in 2D Input).

Download trc_ac.mw

I found that using solve might depend on whether the changed equation was expanded, and upon the working precision (Digits).

You can also adjust Digits to see effect on residual (forward) error.

There are other ways to compute this (eg. using procedures which each raise working precision ie. Digits locally while keep fsolve's notion of accuracy (dependent on inbound Digits) coarser. I haven't done that. Similar effects can be had by treating it as an optimization problem (eg. by using DirectSearch, or setting it up that way).

Download no_conjugate_ac.mw

You can also use the command-completion facility, or the palettes, or the Ctl-Shift-G keyboard shortcut to easily construct compound names in 2D Input mode.

This also allows the names to appear in their nice typeset form as 2D Input, and not just as 2D Output.

See Help pages for command-completion and the entry palettes.

Download cmd_completion.mw

As Carl mentioned, you can also enter the compound names using its 1D equivalent notation (which -- as you can see above -- involves a name containing HTML-style entity, here). But for some kinds of typeset name you may not find that easy to guess, eg. names with a caret over them, etc.

In 2D Input mode, you can also use the keyboard acceleration Ctl-Shift-G to temporarily place the GUI into Greek-entry-mode. For your example, the same result for typeset 2D Input can also be had using the keystrokes,
   Ctl-Shift-G D x
There, the "D" makes it enter a Greek uppercase Delta. See the Help page.

In a previous Question you were shown in an Answer that the simplify command accepts the assume=[...] option.

That does not mean that option assume=[...] works for all commands. It does not.

The odetest command does not throw an error if you pass it some extra arguments.

If you want to construct your call (to utilize the assuming facility) from a precomputed list or collection of inputs then you can call using its prefix form:

sol:=y(x)^(1/2)=-1+2*exp(x):
ode:=diff(y(x),x)-2*y(x)=2*y(x)^(1/2):
`assuming`([odetest(sol,ode)], [x::real, x>0]);
                     0

Why are you trying to pass the plot function call around as if it were an object!? Do you have some special purpose where there really isn't a better programming methodology? (I can think of very few, and since you are new to Maple I suspect that your actual goal could be better done in another way altogether).

Having said that,

  eval('plot'(x, x = 0 .. a), a = 3);
  value(eval(%plot(x, x = 0 .. a), a = 3));
  ((e::uneval)->eval(e,a=3))( plot(x, x = 0 .. a) );

On this forum it is almost always better to inform us in detail of your actual motivating goal, rather than just inquiring about some barrier found during an attempt you devised for getting there.
 

You can customize and adjust this.

The idea is that you can write a convenient procedure to generate such plots in a reusable manner. And you could also augment the results futher.

Download plotting_fun.mw

Download unitconvert.mw

Since NULL is ephemeral when used in ways that you intend (eg. being passed around, or returned, in an expression sequence) then it isn't a very good choice. Don't choose something that can be problematic for one of your basic usage patterns.

Using {} is not terrible, but it will fall down for a computation where {} is also a possible natural result and where you need to distinguish between the two situations. In that case you'd have to utilize something else instead, which means that your methodologies could be inconsistent. Note that you didn't cite only computations where the result denoted possible solutions -- so {} might make sense to denote the empty set, but is not great to denote general cases where something "could not be computed".

How about using FAIL instead? Note that your two cited example circumstances were, "...it could be something that could not be computed inside foo, or some solution that could not be found". The common phrasing there is "could not be".

For the cases of computing possible solutions, would you want to be able to distinguish between the case of provably no solutions and the case where it happens to not succeed in finding any solution?

[edit] I don't think that solutions involving returning uneval-quoted NULL is great. You'd need to avoid using whatever it got assigned to in an analogous situation. Why introduce any need for extra care, if you don't have to?

Here is one way to deal with that, which consists of the step,

   subsindets(eq[4], float,u->`if`(frac(u)=0.0,trunc(u), u));

(There are more complicated ways, some of which deal with other things that you might encounter and want, such as stripping off trailing zeroes. Let us know...)

Download question_sunit_ac1.mw

Here is one way.

Let me know if you really prefer that multiple calls foo(ode,y,x) would produce the exact same result (in which case it could adjusted to be store and manage that, I think.)

Download genglobal.mw

Be careful about terminology. You wrote, "I think, `evalb` is used to compare numbers and `is` used to compare expression, logic. Is this true?" That sentence is not precise, in Maple terminology, and that can lead to misunderstanding here.

Think instead in terms of technical Maple terminology, for example whether something is of type numeric. That includes floating-point numbers, integers, and fractions (rationals, with integers in numerator and denominator). That does not include exact representations such as sqrt(2). Yes, that denotes a "number" in the common mathematical sense, but it is not of type numeric to Maple. A related and useful class is things of type realcons, which would produce something of type numeric if evalf were applied.

The evalb command can compare equality and inequality relations of items that are both of type numeric. It can also test whether two structues are identically the same, by which I mean that they have the same address in memory.

So you cannot generally, reliably compare two expressions (of type algebraic but not numeric) with the evalb command unless you can put both into a canonical form, in which case they are uniquified and the canonical forms are identically the same.

Your example,
  f := x + 1 = (x^2 - 1)/(x - 1);
can be simplified (using simplify or normal, for example) so that lhs and rhs of that normal form are in fact the very same expression. That is why evalb(simplify(f)) returns true.

But not all expressions can be easily put by Maple into some canonical form. (For example, there are mathematically equivalent formulations for some expressions involving trig and special function calls for which a choice of canonical reformulation is not obvious.) That's one advantage of using is, as it has a variety of mathematical operations it can do for comparison.

Another significant advantage of the is command is that it can (often) utilize assumptions on names in symbolic expressions.

Here are some tips:

1) For mathematical testing of an equation (ie. A=B), it can sometimes help is by querying is(A-B=0) since (while zero-testing is hard) at least the target form is clear: zero.

2) In general the is command performs more strongly that simplify (or its friends, normal, radnormal, shake, evalc, rationalize, combine, and expand) alone. It is rare that it helps to make a call such as is(simplify(A-B)=0) , but examples do exist.

3) For inequality testing involving expressions of type realcons you may generally be better off invoking the is command, rather than applying evalf and risking a mistake due to close roundoff error. Like most "rules", this too has its exceptions.

4) If you are going to use the is comand then you might have to write your code so that it handles the case that is returns FAIL instead of true or false.

5) For verification of floating-point results from a computation against a target value you might look at the testfloat command, or the verify command with a float comparator.

6) For verification of data structures (lists, sets, Vectors, etc) you could also look at a call of the verify command, according to the type of the structures' members.

It's a large topic, and a textbook on Maple could be written while covering it comprehensively.

Background reading, Help pages for Topics:
   -  testfloat
   - verify
   - evalr, shake
   - testeq
   - signum
   - type numeric, realcons, algebraic
   - evalc, radnormal, evala, normal

The catch clause is intended to catch whatever throws a catchable error with the given prefix¹, and there could be more than one statement in the try clause that emits such.

One point of the finally clause is that its code is supposed to run if either an error is caught or no error occurs. If you don't want some code run when a error is caught then put it later in the try clause, instead -- eg. after your conditional.

In complicated scenarios you may find it helpful to set and use one or more flags, or to use a nested try..catch, etc.

Does the error message upon time-out always begin with "time expired"?

¹ Managing uncatchable errors is a different story.

You can write your own wrapper around ColumnGraph, allowing you to retain your plots:-setoptions setting in your initialization file. You can make it ignore or respect the setting, and override it.

(A bug report will be submitted...)

Download ColumnGraph_Problem_ac.mw

Could you not also try using a personal Maple initialization file, so that you wouldn't have to change its contents when you upgrade your Maple release?

That is to say, from the initialization Help page,
    "C:\Users\userid\maple.ini"
where userid is your Windows id. (See also kernelopts(':-homedir') output, if relevant.)

Let me know if I did this incorrectly. This is not thread-safe (but I suspect that you could make a variant that is -- each thread getting its own parameter name and dummy container Vector).

[edit] I see that mmcdara has written about subscribers being a discrete uniform random variable over {0, ..., 16}, and getting the fast direct generation of the sample. But I won't delete this, since it might interest someone later, to compare varying the parameter value of a preformed RV against generating a sample from a fresh call to Binomial (or other distribution flavour) for each entry.

Download subscribers_ac1.mw