If I'm not interpreting the PLOT structures incorrectly, then what happens is this: The feasible region is initially constructed as a POLYGON structure that fills the whole space (and is then colored). This gets used as the background. And then the complement of what is actually feasible is formed into (at least) one POLYGON structure, and is used as the foreground. Ie., the complement is laid over the feasible region, and so acts as a mask (so that only the actual feasible region shows  through).

If it were done the opposite way then wouldn't it be very easy to merge such inequal plots? That is to say: fill the background or create a POLYGON which fills in entirely as background, then form a POLYGON of only the actual feasible region and color it. Make the feasible region the foreground not the background.

If done that way, then each `inequal` plot produces a background (filling) POLYGON as well as a foreground feasible POLYGON. To display more than one such plot, one only has to remove all but the first background filler. Eg. with p1 and p2,  one simply uses both op(p1) and op(p2) where the background POLYGON is removed from op(p2). Probably display(op(p1),op([2..-1],p2)) would then suffice.

Overlaps would occur naturally, in any order of the arguments to `display`.

Please pardon me, if I'm wrong.

acer

If I'm not interpreting the PLOT structures incorrectly, then what happens is this: The feasible region is initially constructed as a POLYGON structure that fills the whole space (and is then colored). This gets used as the background. And then the complement of what is actually feasible is formed into (at least) one POLYGON structure, and is used as the foreground. Ie., the complement is laid over the feasible region, and so acts as a mask (so that only the actual feasible region shows  through).

If it were done the opposite way then wouldn't it be very easy to merge such inequal plots? That is to say: fill the background or create a POLYGON which fills in entirely as background, then form a POLYGON of only the actual feasible region and color it. Make the feasible region the foreground not the background.

If done that way, then each `inequal` plot produces a background (filling) POLYGON as well as a foreground feasible POLYGON. To display more than one such plot, one only has to remove all but the first background filler. Eg. with p1 and p2,  one simply uses both op(p1) and op(p2) where the background POLYGON is removed from op(p2). Probably display(op(p1),op([2..-1],p2)) would then suffice.

Overlaps would occur naturally, in any order of the arguments to `display`.

Please pardon me, if I'm wrong.

acer

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

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