@Scot Gould There is special code inside plots:-display to merge an "array" of 2D plots into a single PLOT construct. It serves this special case of wanting to export a collection like this in a single image file. Having the plot device set to an external image driver flips this on.

In order to do this the individual 2D plots are all shifted, and their tickmarks faked as textplots at mapped locations.

However, that shifting manipulation also turns the float tickmark values into names, eg, `-1.0` etc. And that makes them render in italics. That is likely why there is confusion about which fonts are being used.

Here's one workaround, using the previous code, to get usual upright Roman tickmark values instead. You also use the usual font option, see attached.

Note that I use .png image format for the export (which I find often like more).

I've used String@parse here, to turn those names-of-floats back into string text, but there are also Typesetting (or more careful) alternatives to re-manipulate those tickmark values (in TEXT substructures...).

>  restart; >  with(plots): >  P := seq(plot(x^n, x=-1..1, color=ColorTools:-Color([1/n, 1-1/n, 0]),               size=[800, 400]), n=1..4): >  Q1 := display(P[1], P[3]): Q2 := display(P[2], P[4]): >  here := cat(kernelopts(homedir), "/mapleprimes/example.png"): >  plotsetup(png, plotoutput = here):    G := display(< Q1 | Q2 >):    #G := display(< Q1 | Q2 >, font=[Times,16]):    subsindets(G,And(name,satisfies(u->parse(u)::numeric)),String@parse); plotsetup(default); >  restart; >  here := cat(kernelopts(homedir), "/mapleprimes/example.png"): >  img := ImageTools:-Read(here): ImageTools:-Embed(img);

Download disp_ac.mw

ps. If you execute,
   display(G,axes=box);
after resetting the device with plotsetup(default) then you can see how the single PLOT is faked.

The server indicates that your first attachment is not accessible for download. I suspect that it's the filename. Could you reattach the first file, but using a different filename with no special characters like "+"?

Does it still go awry if you don't augment libname?

I can run it (with the libname change commented out).

note: the final plot uses `x` like a name, but at that point `x` is assigned a float value.

Are you trying to re-execute commands in the sheet out-of-order? If so we'd need to know the particular steps (presuming the issue is not due to something in your libname change...).

@Carl Love Yes, I more often think of it in terms of output effect in examples like for Factor.

It wouldn't normally occur to me to use it as an alternate terse input for a call that I'd expect to evaluate to something else -- as in the example given in this Question. I don't know whether the OP intends on using it in connection to generation of unevaluated function calls to aliased names.

@Carl Love I usually do the first of your alternatives, like,

    export XX:= Sqr1;

in order to get alternate spelling effects.

But then, I don't understand why anyone ever uses alias. It's like people playing the French Defense; I see how it works but I can't imagine ever wanting it.

@Ronan Notice that the calls to alias in your example above are not part of the body of any procedure (local or export). Those calls are just made as statement during the creation of the module.

Perhaps you can try having those statements instead be part of a ModuleLoad (local proc) of your other, problematic module(s).

I mean a ModuleLoad proc for the module, which might contain, say,

    alias(eparm, UHG:-CircleParmUHG);

You can have separate ModuleLoad procs for both parent module and submodules. See example at end. Or if you prefer you can put all your aliases in just a single ModuleLoad of the parent module. It depends on the effects you want.

If you access/reference/load any child module then the ModuleLoad of its parents (or parents' parents, etc) would also execute, IRC.

ps. Note that ModuleLoad of a module only gets automatically executed when it gets read in from a Library archive. Some people are in the habit of having a call to its own ModuleLoad be a final statement in a module's source code, so that they can test it immediately and directly without going to the trouble of LibraryTools:-Save, restart, etc. Or you can do the One True Test of an actual Save, restart, etc. That is to say, they don't have the statements in question appear standalone in the module source as well as be in the ModuleLoad proc. Just have them exist in one place, to manage them better.

pps. When I say "read" from a Library archive that's what I mean. It does suffice to call with on its name to read it in. But even without a call to with, any reference to the module name (eg. calling an export via longform name M:-foo ) would also read/load it from archive and trigger the ModuleLoad. This is off on a tangent.

Download 2024-06-29_use_alias_in_a_Sub_Package_ac3.mw

And, putting all the aliases in a single parent ModuleLoad,
2024-06-29_use_alias_in_a_Sub_Package_ac2.mw

@C_R Fwiw, I submitted a bug report related to this a few years ago.

The assignment,

    aS := -i/n;

makes no sense in that context, with no numeric value ever given for that `i`.

The x-coordinates of points S and C depend on aS, so of course geometry:-draw cannot handle them, since `i` has no value.

You asked, "How to correct this procedure?" The first thing to do is explain what you're trying to do.

@Ronan The is command will return FAIL when it is not able to ascertain whether the result is true or false. That could happen if the expression is too complicated (...think of complicated radicals of symbolic subexpressions, in numerator and denominator, etc). Or it could happen unless certain key assumptions were provided. And so on.

I don't know what kinds of expressions you'll encounter, so I don't know whether this situation is even likely here. If it is likely then it matters whether you would rather risk false positives or false negatives (or, throw an error). If you'd be ok with a false negative (eg. something very complicated isn't correctly identified as being mathematically equivalent to 1, and so it taken to not be 1) then no adjustment is needed.

@janhardo If I add it with the `true` as last argument to AddMet then it does get used and work. See the verbose printout. Of course I commented out the test-line to remove it, after adding it.

But your BestSimp routine is not returning the result with shortest value (LeafCount metric). I leave that for you.

fullSimplify_module_-metoden_toevoegen_werkt_ws_uitzoeken_forum_opmerkingen_corrigeren_A_acc.mw

@janhardo If you assign,

   fn := eval(parse(cat("proc(e) ", method_body, "; end proc")));

then (since procedures have last name evaluation) you'd want something more effective like,

   methods[method_name] := eval(fn);

instead of your,

   methods[method_name] := fn;

in order to add it more usefully to the table.

I am not a fan of passing/parsing a string, but here is that last worksheet, edited:
fullSimplify_module_-metoden_toevoegen_werkt_ws_uitzoeken_forum_opmerkingen_corrigeren_A_ac.mw

@janhardo You have the table `methods` as a local of BestSimp, which makes no sense, since you're trying to access/amend that from other procedures in the parent module of BestSimp.

Your code for a test/check (that it has worked properly) is also faulty.

Using globals in the other procs isn't the way to fix that. Using globals is also very poor programming for this (even if you altered the code to use it consistently). You have already got a module; you should utilize that fact, with a Record or table.

You don't need to inline the whole attachment here, each time.

@janhardo I don't see an attachment with a list named methoden, and so it's not clear what "worksheet" you're now referring to.

I see a table named methods in the module in your last attachment, a worksheet named,
   Module_fullSimplify-2_commands_MPforum.mw
but the paremeters of that module's export AddMet does not match your subsequent query about calling it like,
   AddMethod("TEST(e,trig)", proc(e) return TEST(e,trig); end proc);

Look again at your Reply in which you asked about this. It has no worksheet attachment. All it contains is the following -- which is why I responded using its very same format of arguments:

How to get the TEST methode name into the list methoden ?
The methoden list has more names in it.

AddMethod("TEST(e,trig)", proc(e) return TEST(e,trig); end proc);


methoden := [
        "CompleteSquareSteps(e)" = proc(e) return CompleteSquareSteps(e); end proc,
        "TEST(e,trig)", proc(e) return TEST(e,trig); end proc
          ];

@janhardo That's what my first block of code shows. I leave it to you to incorporate it into your own module.

note: You mentioned a worksheet containing `methoden`, but never gave it.

@janhardo An example,

Download module_ex.mw