@lemelinm It's up to you, I'd say. If you use poundforce then you might get asked to define a slug.

1 lbf = 1 slug*ft/s^2

while,

1 pdl = 1 lb*ft/s^2

I'm not 100% sure which is used more regularly, in the USA, but I've seen indications that they might use lbf ie. pound-force. (I live in a country that uses kg and N.)

We can also make wrapper around DirectSearch:-SolveEquations which rejects spurious solutions which do not meet the residual tolerance.

Not surprisingly it can detect (depending on the specified tolerance) similar inaccurate candidate solutions that fsolve baulks (with all defaults as before).

Download DSrej.mw

@Markiyan Hirnyk The DirectSearch:-SolveEquations command accepts a tolerance option similar to that of DirectSearch:-Search.

   tolerances =[positive, positive], [positive], or positive -- Set the absolute
   tolerances for the extremum point (tolerances[1]) and minimum (or maximum) value
   (tolerances[2]). The search is stoped when the following exit conditions are met
   several times:  ||Xmin-Xold ||<=tolerances[1] and |fmin-fold |<=tolerances[2].
   The default value is [10^(-6), 10^(-6)]. If tolerances contains one value
   this value corresponds to both the extremum point and minimum (or maximum) value.

Note that the help-page for DirectSearch:-SolveEquations also says, as a last Note before its Examples, "...If the residuals too large then the solution is not exact solution but it is only solution that minimizes the residuals."

That last sentence is the key. It surely means that SolveEquations is going to return a result even if it does not meet the criteria of being a root. And that is just what it does. Let's call DirectSearch:-SolveEquations and specify tolerances.

DirectSearch:-SolveEquations( g(x)=VP[14], tolerances=[1e-10,1e-10] );

    [                   -16  [                    -8]                               ]
    [2.24381757423686 10   , [-1.49793777382001 10  ], [x = 0.0261201463011024], 40 ]

The middle value -1.49793777382001e-8 is documented on that help-page as meaning the residual. (The first value in the returned result is just the square of that, because, as documented, the objective used is f[1](x)^2 by default.) So the returned result does not meet the second passed tolerence value which specifies the acceptance target for the residual.

So in the sense that DirectSearch:-SolveEquations considers the matter, the returned value is not a (exact, its word) root. But the result is returned anyway, as per that cited Note.

It's not returning what it considers to be a root. It's returning a value that minimizes the sum of the squares of the residuals. The absolute value of the residual (what I call the forward error) exceeds the tolerance supplied for the residuals, so it is not deemed to be an actual root.

@erik10 I am submitting a bug report that there are no cross-references in the help-pages plots,polyhedraplot and plots,polyhedra_supported to the help-page geom3d,polyhedra .

Alternatively, you could pay closer attention to what Kitonum wrote [implying under Digits=10 or higher, and correct at the default Digits=10 of your sheet], "Because  x= 0.02612014634  does not belong to  0.01338216460 < x and x <= 0.02612014630."

Note that increasing working precision to higher than Digits=10 will not make 0.02612014634 <= 0.02612014630, although lowering it will.

restart:
Digits := 10:
evalb( 0.02612014634 <= 0.02612014630 );
                                    false

restart:
Digits := 20:
evalb( 0.02612014634 <= 0.02612014630 );
                                    false

restart:
Digits := 9:
evalb( 0.02612014634 <= 0.02612014630 );
                                    true

@Markiyan Hirnyk The expression p[14][2] is not the part of the piecewise that matters when x=0.02612014634, when Digits=10.

When you call g(0.02612014634) the piecewise takes p[13][2] as the formula that gets computed, if g has been created with Digits=10 and if that is still the current working precision.

Download fsolvexx.mw

@madagascar Please upload your actual worksheet (big green arrow in the editor here) in a new Comment to your Question.

Right now your post consists on just images of statements, and few if any people would want to retype that all by hand.

You'll need to make that lowercase display instead of Display.

Maple is a case-sensitive language.

acer

@Preben Alsholm Nice work.

I'd noticed that there was nothing `local`, for convert/global to change, even when it caused an example to work. I'd formed a few odd &under procedures which made the examples work (even though they ought not have affected anything). And this had made me consider that something wrong was happening inside `indets`.

Your `cg4` make a strong case for the internal state being in a mess, inside indets.

Has anyone submitted the bug report?

@Melvin Brown Having your module inside a .mla archive will not, in and of itself, prevent its contents from being inspected.

@Melvin Brown I suggest that you read my earlier suggestion more carefully. I had suggested that you put the source code which defines the module into the Startup Code Region. I didn't suggest augmenting libname in a effort to try and pick up the module from a .mla archive.

The MaplePlayer has its own security settings, which different from those of Maple (including the Std GUI interface) by default, and are quite tight.

It might be possible to use a custom .mla archive with the MaplePlayer 2015, but why even bother? If you burn the module source into the "App" .mw file then you only have one file to distribute to your end-user.

Why not put the source code that defines the module in the Startup Code Region of the Worksheet or Document that you intend to become an interactive application that can run in either Maple or the MaplePlayer?

See this Answer to a recent question about authoring so-called MathApps.

We haven't been told what kind of inputs your module might have, Marvin. But if the commands it provides can be run using the Explore [1, 2, 3] command to obtain an interactive application that you deem suitable then you could have a look at this or this. So another idea is that you can build some kinds of simple interactive applications that have just one kind of output (math expression, or plot, or image), in standalone worksheets, without having to first learn all the ins and outs of programming with Embedded Components. Of course you can build it all from scratch yourself, using Embedded Components, but in that case you might find the StartUp Code Region to be useful.

acer

@Kitonum The situation can be clarified a bit more.

At default working precision of Digits=10 the result of 4.+10^(-20) is identical to 4. . And that is why Markiyan's example by itself does not show a with Carl's suggestion to use member. That example was not a matter of floating-point comparison of two distinct values.

> r := 4.+10^(-20);

                                   r := 4.

> lprint(r);
4.

> dismantle(r);

FLOAT(3): 4.
   INTPOS(2): 4
   INTPOS(2): 0

However the case of comparing and testing for floats is indeed tricky. In Maple -- outside of special contexts like say ScientificErrorAnalysis -- there is not much explicit documentation of the precision of a floating-point number. By that I mean the number of significant digits stored in the representation of the float, rather than the working precision at which computation is performed. Facilities like SfloatMantissa are not commonly encountered and used, in my opinion. (This contrasts with Mathematica, in which working precision, precision of specific floats, and accuracy are quite commonly used.)

Let's consider another example.

> restart:

> evalb( 4. = 4.000 );

                                    true

> M := Matrix([[4.000]]);

                                M := [4.000]

> member(4., M);

                                    false

> ormap(`=`, M, 4.);

                                    true

So we can see that the question of membership (ie, presence) is tricky even before getting into the topic of floating-point comparison versus identity testing.

Now let's look at an issue with using is. Maple's evalf remembers computed results, for efficiency, but it knows that it has to recompute when Digits is raised. (It does this by having a special kind of remember table mechanism that stores the used Digits value alongside results.) But is uses remember tables less carefully, and can return remembered results even when the working precision has since been raised. This is a problem, because is uses floating-point methods and is quite often used by the unwary instead of evalf for (in)equality testing of realcons expressions.

restart:
M := Matrix([[4.000000000000000001]]):

Digits := 40:
ormap(is, M, 4.);  # OK, since Digits=40
                                    false

restart:
M := Matrix([[4.000000000000000001]]):

ormap(is, M, 4.); # OK, since Digits=10
                                    true

Digits := 40:
ormap(is, M, 4.);  # Wrong, something is being remembered
                                    true

forget(evalf);
ormap(is, M, 4.);  # Still wrong. What's remembering it?
                                    true

forget(is);
ormap(is, M, 4.);  # ... aah, found it
                                    false

Here's another example of this problem.

restart:
x := 3.14159265358:
Digits := 20:
is( x = Pi ); # OK
                                    false

restart:
x := 3.14159265358:
is( x = Pi ); # OK, as x agrees with Pi when Digits=10
                                    true

Digits := 20:
is( x = Pi ); # Wrong
                                    true

forget(is);
is( x = Pi ); # OK
                                    false

The Original Poster of this Question gave an example with exact integers, and might not be interested in floating-point examples.

The case above that I described with, "This is not good", which is a regression bug in Maple 2015.0,  is fixed in Maple 2015.1.

NOTE: All three for-do-loop lines in both sets of code shown next occur in just one single execution group in their respective worksheets. That fact is not visually clear when the code is inlined here on Mapleprimes. (Links to the actual worksheet are also given.) Don't confuse this with the case of all three lines occuring as separate statement attempts within three seperate execution groups.

Here it is in Maple 2015.0

And here it is in Maple 2015.1

Download ml20151.mw

Note that the new "Maple 2015" behaviour to allow as optional the statement terminator of the last line of 1D Maple Notation code in an execution group is retained in Maple 2015.1. And that does not mean that it's now valid to break statements across multiple execution groups. But the problematic regression case I mention above, for a single execution group with multiple lines having prompts, is fixed.

@Kitonum  Nice work by Rouben and you.

For fun, calling Explore on a modification of your procedure.

Download Pursuit.mw