Documentation

# `MAXEFFORT`

Maximum amount of work to spend on the computation

MuPAD® notebooks will be removed in a future release. Use MATLAB® live scripts instead.

MATLAB live scripts support most MuPAD functionality, though there are some differences. For more information, see Convert MuPAD Notebooks to MATLAB Live Scripts.

## Description

The environment variable `MAXEFFORT` determines the amount of effort allowed for heuristical parts of a computation, measured in “working units”. The default value is `MAXEFFORT` = 1000000.

Possible values: Non-negative floating-point number; or `infinity`.

`MAXEFFORT` determines the maximum number of “working units” that may be spent on internal heuristics.

One working unit roughly corresponds to 1000 evaluation steps done by an average kernel function.

Whatever `MAXEFFORT` is set to, every MuPAD® function returns a correct though possibly unsimplified result; in particular, some functions may return unevaluated. `MAXEFFORT` determines the amount of additional time spent on obtaining a better or more simplified result; a value of `infinity` means that all built-in heuristics are really tried, a value of `0` means that all heuristics that might take considerable effort are left out.

A function whose result is uniquely specified has no way to react to `MAXEFFORT`.

Other functions carry out, in any event, all computations necessary to obtain some correct result; `MAXEFFORT` only determines the time available for improving that result. In case of functions that may return unevaluated immediately (e.g., `solve` or `int`), or may return their input immediately (as, e.g., `simplify`), or may answer a question by `UNKNOWN` immediately (as, e.g., `is`), all of their time consumption is counted to be spent on heuristics (purely heuristic functions).

Purely heuristic functions will usually return immediately if their input is quite complicated in relation to the effort allowed. This is also true if the user has provided that input on the interactive level. In order to pose a difficult problem where a longer running time is acceptable, `MAXEFFORT` should be increased.

A simplification achieved by heuristic methods may speed up the deterministic parts, such that a small value of `MAXEFFORT` does not necessarily decrease the total computing time.

The user may employ `MAXEFFORT` in his own functions as follows: any function may use the amount of effort given by `MAXEFFORT` partly for own overhead, and distribute the rest on the functions it calls. To do this, the caller has to `save` the variable `MAXEFFORT` and set it to whatever it wants to make available to the called function. Depending on whether the call is necessary to obtain a correct result at all and whether the called function is a heuristic one, there are the following cases to handle. If the call is necessary and the called function is deterministic, `MAXEFFORT` has no influence. If the call is not absolutely necessary and as far as the called function is deterministic, the caller has to subtract the necessary amount as own overhead from `MAXEFFORT` if enough is available; otherwise, such call must not take place. As far as the called function works heuristically (for whatever reason it was called), it has to limit its efforts to the amount given by `MAXEFFORT`.

In no event may the value of `MAXEFFORT` on entering a procedure be different from the value on leaving it, even not in case of an error. `save` must be used to ensure this.

No function may distribute and/or use more than the amount it has been given by its caller. The own overhead should be estimated; if it is supposedly small, `MAXEFFORT` may be ignored.

In order to avoid casual, not reproducible effects, e.g., by other programs running on the same computer, `MAXEFFORT` should not be used in connection with time measurement using `time` or `rtime`. For example, the running time saved in one recursive call according to time measurement must not be supplied to another recursive call.

## Examples

### Example 1

The decomposition of an integer into prime factors is unique; hence the result of `ifactor` is uniquely determined, such that `ifactor` does not react to `MAXEFFORT`:

```MAXEFFORT:= 0: ifactor(2^10 + 1)```
` `

### Example 2

The `solve` function can return unevaluated. For example, this happens if there is no effort left to spend on the computation:

```MAXEFFORT:= 0: solve(ln(x) + x = 3, x)```
` `

### Example 3

Increasing the value of `MAXEFFORT` can help solve equations, for which the solver normally returns unevaluated results. The following example uses `MAXEFFORT = 100` and `x^1000` because running this example for the default value `MAXEFFORT = 1000000` and `x^10000000` takes many hours.

When you use `MAXEFFORT = 100`, the solver returns unevaluated result for the following equation.

```MAXEFFORT:= 100: solve(ln(x) + x^1000 = 3, x)```
` `

Setting the `MAXEFFORT` to `200` allows the solver to return an explicit solution. To display the solution, delete the colon at the end of the `solve` command.

```MAXEFFORT:= 200: solve(ln(x) + x^1000 = 3, x):```
```Warning: Possibly spurious solutions. [solvelib::checkSolutions] ```

You can set the value of `MAXEFFORT` to `infinity` to ensure that the system will try all built-in heuristics. Note that for some computations, setting `MAXEFFORT` to `infinity` might lead to extremely long computation times.