@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

You can also obtain a somewhat messy piecewise result with explicit numeric bounds on `a`, `b`, and `c`.

solve( {a*x^2 + b*x + c, -1<a, a<1, -1<b, b<1, -1<c, c<1}, x, real, parametric );

@mehdi jafari The region within the cube [-1..1]×[-1..1]×[-1..1] for which there are real solutions is bounded by the conic specified by the discriminant (see my earlier comment). Do you need us to plot it for you?

Are you simply looking for the sign of the discriminant discr=b^2-4*a*c ?

By which I mean the fact that your quadratic has two real roots if discr>0, one real root (of multiplicity two) if discr=0, and zero real roots if discr<0 .

Did you intend to ask how to prove when this quadratic equation would have real roots?

acer

@Bendesarts I don't know of any simple visual cue that allows you to tell, merely at a glance, that an instance of a "Heading 1" has its text wrapped in a Font element.

Here's my limited understanding. "Heading 1" is a named format (style aspect), and in the upper portion of a .mw file the named formats are defined. For example my Maple 2015 .mw files have, by default, a "Heading 1" format that is defined as follows:

<Font name="Heading 1" background="[255,255,255]" bold="true" executable="false" family="Times New Roman" foreground="[0,0,0]" italic="false" opaque="false" readonly="false" size="18" subscript="false" superscript="false" underline="false" placeholder="false"/>

Now, if I select all of a Section title with the mouse cursor and use the main menubar to change the font to something other than Times New Roman at 18pt (as defined above as default for the Heading 1 format) then the saved .mw file contains this for the Section title. The text is just "BBB",

<Title>
<Text-field style="Heading 1" layout="Heading 1"><Font family="Courier New">BBB</Font></Text-field></Title>

Now if I subsequently change that back to the default for the Heading 1 format of Times New Roman at 18pt and resave then the .mw file has that title as only,

<Title>
<Text-field style="Heading 1" layout="Heading 1">BBB</Text-field></Title>

So it appears to me that the title is not marked up inside a Font element as long as (?) the chosen font and size match the default style for that format.

So some questions I'd ask you include: How did you create the "Heading 1" instances that contain the text wrapped in a Font element? Did you change the font? And do you use a custom style sheet? (I don't.)

Can't your external editor get rid of the Font element wrapping as it appears above? Or is it in another pattern? Or does it wrap around a Textfield? Also, have you considered editing the XML using Maple's XMLTools (even if only to read the .mw file in and parse to a nested function call...)? Maple's a handy high level tool for doing such manipulations.

A great deal of the computations done by the Finance package are made via external calls to a (bundled) Quantlib (dynamic shared) library.

But -- even if this is the case for the path generation in question -- it may be necessary to identify the particular version number of the bundled Quantlib library in order to get the right answer.

acer

What methodology are you using to "recover the structure of my worksheet by working on XMLElements"?

Are you using the XMLTools package? Are you reading in the .mw file, so that it becomes a large nested function call?

Are you saying that you just want to remove any qualification by Font, so as to be left with just a Textfield?

It's not clear to me how you are doing the work, so far, and so it's hard to make a concrete suggestion.

(It may or may not be of interest to you, but I have been working on a tool to scrape a .mw file so as to extract all its contents. Ie, all code to 1D Maple Notation, all Text to comment strings, optionally all Output to expressions saved aside, and even all unassigned rendered plots to actual PLOT structures save aside. And so on. I can't tell whether this is of possible use to you as I can't tell whether your target is plainext or rather just a modified .mw file, etc.) 

acer

You already asked this question in another post. This is spam.

acer

@Mac Dude These are not new features. I've seen these kinds things demonstrated in the Std GUI since very early in its existence. The example I gave can be created with the same steps in my Maple 15.01 for Windows 64bit as in my Maple 2015.1 on the same platform.

Here is is, done in Maple 15.01.

inlined1501.mw