There is actually such a software-float backup to STATS_MaplePoissonRandomSample_HW. But it may not work very quickly.

> MPFloat("libstatsmp.so"); true > a2:=define_external("STATS_MaplePoissonRandomSample_MP", MAPLE,LIB = "libstatsmp.so"); a2 := proc() option call_external, define_external("STATS_MaplePoissonRandomSample_MP", MAPLE, LIB = "libstatsmp.so"); call_external(0, 182955163792, 0, args) end proc

In another reply below, I showed how some answer might be obtained even when the parameter was greater than this cut-off point, by setting UseHardwareFloats=false or by having Digits be greater than trunc(evalhf(Digits)). But it works slowly then, and only seven digits of information are ever returned (which isn't so useful, I think).

acer

There is actually such a software-float backup to STATS_MaplePoissonRandomSample_HW. But it may not work very quickly.

> MPFloat("libstatsmp.so"); true > a2:=define_external("STATS_MaplePoissonRandomSample_MP", MAPLE,LIB = "libstatsmp.so"); a2 := proc() option call_external, define_external("STATS_MaplePoissonRandomSample_MP", MAPLE, LIB = "libstatsmp.so"); call_external(0, 182955163792, 0, args) end proc

In another reply below, I showed how some answer might be obtained even when the parameter was greater than this cut-off point, by setting UseHardwareFloats=false or by having Digits be greater than trunc(evalhf(Digits)). But it works slowly then, and only seven digits of information are ever returned (which isn't so useful, I think).

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

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