Here's a kludge, for just this one example.

It works by substituting the name `2` for the number 2 in the two fractions 1/2 and -1/2. (That's the non-technical explanation. Experts may nit-pick...) The 2D fraction layout works better for pure names in the denominator. Conversion back can be accomplished using expand().

> restart:

> sol:=solve({x^2+b*x+c},{x});

     /                        (1/2)\    /                        (1/2)\ 
     |      1     1 / 2      \     |    |      1     1 / 2      \     | 
    < x = - - b + - \b  - 4 c/      >, < x = - - b - - \b  - 4 c/      >
     |      2     2                |    |      2     2                | 
     \                             /    \                             / 


> op(simplify(subs(-1/2=-1/`2`,1/2=1/`2`,[sol])));

           /                    /1\\    /                    /1\\ 
           |                    |-||    |                    |-|| 
           |                    \2/|    |                    \2/| 
          <           / 2      \    >  <           / 2      \    >
           |      b - \b  - 4 c/   |    |      b + \b  - 4 c/   | 
           |x = - -----------------| ,  |x = - -----------------| 
           \              2        /    \              2        / 


> expand(%);

                          /                    /1\\ 
                          |                    |-|| 
                          |                    \2/| 
                         <           / 2      \    >
                          |      b   \b  - 4 c/   | 
                          |x = - - + -------------| 
                          \      2         2      / 

Notice that it also makes the sqrt display as power-1/2, which you may not enjoy. That too could be side-stepped, but the code might then look too involved.

acer

I don't believe that anyone intended to convey that this might be a font issue. It's more that some of us miss more about the Classic interface than just its superior typesetting and 2D output layout capabilities.

At one point I had hoped that setting the prettyprint level might resolve it, if only for this one example. That is,

interface(prettyprint=1):

But I now believe that this is not adequate either.

acer

I don't believe that anyone intended to convey that this might be a font issue. It's more that some of us miss more about the Classic interface than just its superior typesetting and 2D output layout capabilities.

At one point I had hoped that setting the prettyprint level might resolve it, if only for this one example. That is,

interface(prettyprint=1):

But I now believe that this is not adequate either.

acer

Joe, are you thinking about Maple 11?

acer

Joe, are you thinking about Maple 11?

acer

The calls to CrossProduct do not resolve to LinearAlgebra:-CrossProduct.

I suggest that you replace CrossProduct with LinearAlgebra:-CrossProduct.

You could also use `use`.

For example,

> CalculerH := proc(Mc)
local Wc, W, vuOB, vuBA, vuBD, vW, Mow, Mowc, MoBA, eqrOB, eqrBA, eqrBD,
eqSommeMoy, eqSommeMoz;
    Wc := 9.81*Mc;
    W := 9.81*(0.5 + 0.125);
    vuOB := Vector([xB/80, yB/80, zB/80]);
    vuBA := Vector([4/3 - xB/60, 1/12 - yB/60, 2/5 - zB/60]);
    vuBD := Vector([-xB/d, -yB/d, (100 - zB)/d]);
    vW := Vector([0, -W, 0]);
    Mow := LinearAlgebra:-CrossProduct(50*vuOB, vW);
    Mowc := LinearAlgebra:-CrossProduct(80*vuOB, Wc*vuBD);
    MoBA := LinearAlgebra:-CrossProduct(80*vuOB, TBA*vuBA);
    eqrOB := 80 = sqrt(xB^2 + yB^2 + zB^2);
    eqrBA := 60 = sqrt((80 - xB)^2 + (5 - yB)^2 + (24 - zB)^2);
    eqrBD := d = sqrt(xB^2 + yB^2 + (100 - zB)^2);
    eqSommeMoy := Mow[2] + Mowc[2] + MoBA[2] = 0;
    eqSommeMoz := Mow[3] + Mowc[3] + MoBA[3] = 0;
    fsolve({eqrOB, eqrBA, eqrBD, eqSommeMoy, eqSommeMoz},
        {xB, yB, zB, d, TBA}, {xB = -100 .. 100, yB = -100 .. 100,
        zB = -100 .. 100, d = -100 .. 100, TBA = -10000 .. 10000})
end proc:

> CalculerH(2);
{TBA = 20.64833346, d = 51.53334730, zB = 68.72157058, xB = 40.83550627,
 
    yB = -3.131639188}

Alternatively,

> CalculerH := proc(Mc)
local Wc, W, vuOB, vuBA, vuBD, vW, Mow, Mowc, MoBA, eqrOB, eqrBA, eqrBD,
eqSommeMoy, eqSommeMoz;
    Wc := 9.81*Mc;
    W := 9.81*(0.5 + 0.125);
    vuOB := Vector([xB/80, yB/80, zB/80]);
    vuBA := Vector([4/3 - xB/60, 1/12 - yB/60, 2/5 - zB/60]);
    vuBD := Vector([-xB/d, -yB/d, (100 - zB)/d]);
    vW := Vector([0, -W, 0]);
    use LinearAlgebra in
    Mow := CrossProduct(50*vuOB, vW);
    Mowc := CrossProduct(80*vuOB, Wc*vuBD);
    MoBA := CrossProduct(80*vuOB, TBA*vuBA);
    end use;
    eqrOB := 80 = sqrt(xB^2 + yB^2 + zB^2);
    eqrBA := 60 = sqrt((80 - xB)^2 + (5 - yB)^2 + (24 - zB)^2);
    eqrBD := d = sqrt(xB^2 + yB^2 + (100 - zB)^2);
    eqSommeMoy := Mow[2] + Mowc[2] + MoBA[2] = 0;
    eqSommeMoz := Mow[3] + Mowc[3] + MoBA[3] = 0;
    fsolve({eqrOB, eqrBA, eqrBD, eqSommeMoy, eqSommeMoz},
        {xB, yB, zB, d, TBA}, {xB = -100 .. 100, yB = -100 .. 100,
        zB = -100 .. 100, d = -100 .. 100, TBA = -10000 .. 10000})
end proc:

> CalculerH(2);
{TBA = 20.64833346, d = 51.53334730, xB = 40.83550627, yB = -3.131639188,
 
    zB = 68.72157058}

It is not advised to load LinearAlgebra (outside any such proc definition) and then define a procedure with bare calls like CrossProduct.

acer

It's been four releases (5 years) of the Standard GUI now, that many of those things have been missing.

I miss all the easy colourizing control that the X11_defaults/Maple resource configuration file gives for the Classic UI. (Blaming such loss, in Standard, on Java is fun but doesn't help any.)

And the fuzzy fonts have been a big disappointment. Is font anti-aliasing off by default? (Turned on, it used to sometimes cause leading minus signs to display erroneously as merged with fraction-bars.)

Is hardware acceleration of plots still turned off by default, and how does one tell in 11.02? (When did that first appear? MapleV R5.1 , or am I thinking of something else?)

I prefer Maple's TTY interface. It's the definition of rock solid.

acer

It's been four releases (5 years) of the Standard GUI now, that many of those things have been missing.

I miss all the easy colourizing control that the X11_defaults/Maple resource configuration file gives for the Classic UI. (Blaming such loss, in Standard, on Java is fun but doesn't help any.)

And the fuzzy fonts have been a big disappointment. Is font anti-aliasing off by default? (Turned on, it used to sometimes cause leading minus signs to display erroneously as merged with fraction-bars.)

Is hardware acceleration of plots still turned off by default, and how does one tell in 11.02? (When did that first appear? MapleV R5.1 , or am I thinking of something else?)

I prefer Maple's TTY interface. It's the definition of rock solid.

acer

You've likely surmised that my misunderstanding of the rules was because I was considering transcendental numbers.

I interpreted the exercise's description as meaning that `a` and `b` themselves were not allowed to appear anywhere explicitly, and that one had to "build" them too. Is that not the case?

acer

You say that `a` and `b` may be any two real numbers. And the expression for a*b is supposed to consist of a finite number of those arithmetic operations (and contain 1 as the only the bare constant)? Over the rationals, that I could see. But, over the reals? Maybe I've misunderstood the exercise.

acer

As it was presented, it is not permanent and would vanish upon restart. To become permanent it would need either to be savelib'd to a .mla archive that would subsequently appear in libname in new sessions or to go in an initialization file.

By a strange coincidence, I've been trying to hammer out a decent blog item which relates to patching the Library. (Actually, I've learned that issues come in clumps and clusters, so coincidences suprise me less and less.) Maybe this will motivate me to post.

acer

If you enter a subliteral from the Layout palette (or a subscripted table-reference which you then toggle as Atomic Identifier) then conversion from 2D Math input to 1D input using the context-menus will show the mark-up syntax.

One must be careful, when creating such atomic identifiers (subscripted names which are not table references), to ensure that they are exactly the same wherever they are used. The font information can also be embedded in the atomic identifier. Eg,

`#msub(mi("V"),mi("BE",fontstyle = "normal"))`;

If one intends to use this name in several places, and have maple understand that they mean the same thing, then such embedded font information must also match. If it doesn't match, then Library routines can see the differing instances as wholly different names (and so might not work as one intends).

acer

If you enter a subliteral from the Layout palette (or a subscripted table-reference which you then toggle as Atomic Identifier) then conversion from 2D Math input to 1D input using the context-menus will show the mark-up syntax.

One must be careful, when creating such atomic identifiers (subscripted names which are not table references), to ensure that they are exactly the same wherever they are used. The font information can also be embedded in the atomic identifier. Eg,

`#msub(mi("V"),mi("BE",fontstyle = "normal"))`;

If one intends to use this name in several places, and have maple understand that they mean the same thing, then such embedded font information must also match. If it doesn't match, then Library routines can see the differing instances as wholly different names (and so might not work as one intends).

acer

Yes, thanks, I had seen such cases. It's what I had in mind when I wrote of taking guidance, if possible, from knowledge of the background problem that is being solved. It may be that the optional arguments allowed by the `identify` routine could be used. But there would still be a need for ingenuity.

acer

It may be an art, I suppose, to do the best thing in such cases.

Sometimes the floats may come from physical measurement, and be accidentally near a "wrong" exact quantity.

Sometimes the background of the motivating problem may give hints or provide guidance. Eg, to prefer a radical over a trigonometric quantity, from `identify`.

I should have mentioned that `dsolve` allows disabling of the automatic conversion of floats to exact rationals, by the convert_to_exact=false option. But that's pretty much all that ?dsolve,details says on the matter, as far as alternative conversions go.

And the behaviour of `int` and `dsolve` appear at odds with each other. For `int`, it matters whether floats appear in the range of integration, for definite integrals. And for indefinite integrals it's not clear whether both back- and front-end conversion to exact values is done. Meanwhile, `dsolve` doesn't appear to call `dsolve/numeric` even for IVPs with floats in both the DE and ICs.

> restart:
> infolevel[`evalf/int`]:=1:

> int(1.2*sin(x),x=1..2);
                                  1.147738971
 
> int(1.2*sin(x),x=1.0..2);
Control:   Entering NAGInt
Control:   trying d01ajc (nag_1d_quad_gen)
d01ajc:   result=1.14773897089833854
                                  1.147738971

The inexperienced Maple user may trip up. The help-pages ?int and ?dsolve,details do (briefly) describe their behaviour in the presence of floating-point data in the input. But the best course of action for a given problem may be less clear without more explanation.

I often wonder how these aspects of Maple appear to the new user.

acer