20108 Reputation

29 Badges

14 years, 357 days

Social Networks and Content at

MaplePrimes Activity

These are answers submitted by acer

Firstly, did you mean a*x^2+b*c+c, or perhaps a*x^2+b*x+c? (Below, I'm assuming the latter. That makes the equations linear in a,b,c.)

Those conditions won't hold exactly for any d,e,f,g and x0,x1. You can do things like this in Maple, to discover such restrictions,

> P := x -> a*x^2+b*x+c:
> eq1 := P(x0)=d:
> eq2 := D(P)(x0)=e:
> eq3 := P(x1)=f:
> eq4 := D(P)(x1)=g:
> solve({eq1,eq2,eq3,eq4},{a,b,c,x0,x1});

which gives,

{a = 1/4*(e^2-g^2)/(-f+d), b = 1/2*(-x1*e^2-2*g*f+2*g*d+x1*g^2)/(-f+d),
c = 1/4*(x1^2*e^2+4*f*d+4*f*x1*g-4*d*x1*g-4*f^2-x1^2*g^2)/(-f+d),
x0 = (x1*e-2*f+2*d+x1*g)/(e+g), x1 = x1}

But that's to make the equations hold exactly. (Notice the dependence of x0 on d,e,f,g,x1. It is not "free".) The title of your post suggests that you might be looking for something else, however.

Do you want to to know a method to find a,b,c which minimizes some total of squares of residuals (least squares), for given numeric d,e,f,g and x0,x1? If so, you might consider applying LinearAlgebra:-LeastSquares something like this,

> A,B := LinearAlgebra:-GenerateMatrix({eq1,eq2,eq3,eq4},[a,b,c]);
                                [2 x0    1     0]
                                [               ]  [e]
                                [2 x1    1     0]  [ ]
                                [               ]  [g]
                        A, B := [  2            ], [ ]
                                [x0      x0    1]  [d]
                                [               ]  [ ]
                                [  2            ]  [f]
                                [x1      x1    1]

Notice that the above is a matrix form of the equation. Multiplying out the equivalent matrix form shows that's so.

> A . <a,b,c> - B;
                            [   2 a x0 + b - e   ]
                            [                    ]
                            [   2 a x1 + b - g   ]
                            [                    ]
                            [    2               ]
                            [a x0  + b x0 + c - d]
                            [                    ]
                            [    2               ]
                            [a x1  + b x1 + c - f]
> sol := LinearAlgebra:-LeastSquares(eval(A,[e=0.1,g=0.2,d=0.3,f=0.4,x0=1,x1=2]),
>   eval(B,[e=0.1,g=0.2,d=0.3,f=0.4,x0=1,x1=2]));
                               [0.0499999999999999681 ]
                               [                      ]
                        sol := [-0.0099999999999998129]
                               [                      ]
                               [ 0.239999999999999797 ]

I chose some specific numeric values of d,e,f,g,x0,x1 at which to evaluate A and B in doing the above LeastSquares call. The entries of sol are the computed values for a,b,c.

Now evaluate the equations at those same supplied data points.

> eval({eq1,eq2,eq3,eq4},[e=0.1,g=0.2,d=0.3,f=0.4,x0=1,x1=2]);
     {2 a + b = 0.1, 4 a + b = 0.2, a + b + c = 0.3, 4 a + 2 b + c = 0.4}

Now evaluate the last by the least squares solution, to see how well it fits.

> eval(%,{a=sol[1],b=sol[2],c=sol[3]});
{0.09000000000 = 0.1, 0.1900000000 = 0.2, 0.2800000000 = 0.3,
    0.4200000000 = 0.4}

What's being done above is this: for given numeric d,e,f,g and x0,x1 it finds the a,b,c which minimizes error in eq1,eq2,eq3,eq4 by least squares. Or at least, that was my intention. There are other commands in Maple which will do something like the steps above, and which can even quantify the calculated least squares error. But it seemed to me that you were wondering how to set it up by hand (for which it is the creation of A,B above that is key.)


Please phrase your post in the form of a question.


> expr := -sin(Pi*(alpha+n+beta))*sin(Pi*beta)/
>         (sin(Pi*(alpha+beta))*sin(Pi*(-1+n+beta)));
                        sin(Pi (alpha + n + beta)) sin(Pi beta)
           expr := - ----------------------------------------------
                     sin(Pi (alpha + beta)) sin(Pi (-1 + n + beta))

> simplify(expand(expr)) assuming
>    alpha::real,alpha>0,beta::real,beta>0,n::posint;


You probably intended to get the functionality of signum instead of sign.

I'm referring to your code line,

while sign(f(b)) <> sign(f(c)) do

You might want to look at the respective help-pages ?signum and ?sign.


My guess is that your procedure OVLM is using `i` and assuming that it is unassigned and free, but without having actually declared it as a local variable. That's just a guess.

As Axel says, without an example (or more details) it's almost impossible to gauge what's going on. You've described OVLM's task, but you haven't said anything about how it goes about that.


> equ:=a^2=b^2+c^2;
                                      2    2    2
                              equ := a  = b  + c
> eval( equ, [b=1,c=2] );
                                    a  = 5
> eval( equ, [b=1.,c=2.] );
                                    a  = 5.
> eval( equ, [b=1/3.,c=1/2.] );
                               a  = 0.3611111111


It looks like the problem is that the solid lines and the point-plots are not really paired. They are merely overlaid. So the symbols and the lines don't get grouped in the legend.

Done your original way, the legend has only the line, and not the symbols.

If you do it this way next below, then the legend has only the symbols and not the lines.

     legend=[typeset(" acc(",`&Hscr;`[1]^`(24)`, ")")]),
     legend=[typeset(" acc(",`ε`[48]^`(1)`, ")")]),

The following is also not satisfactory, as there is no way to back-up the symbols in the legend. Unfortunately Maple's typesetting doesn't have any mechanism to shift-left (like LaTeX does have), as far as I know.

with(plottools): with(plots):
seq( point([i,sin(i)], color="red", symbol=asterisk, symbolsize=10), i=1..20),
seq( point([i,sin(2*i)], color="green", symbol=diamond, symbolsize=10), i=1..20),
                  typeset(`&ast;`," acc(",`&Hscr;`[1]^`(24)`, ")"),
                  typeset(`♦`," acc(",`ε`[48]^`(1)`, ")")

I also couldn't seem to put color on the symbols in that second example above. If I tried to use `#mo("&ast;",mathcolor = "red")` instead of `&ast;` then my Maple 12 GUI froze solid.

Apart from that GUI crash, it would be nice to have a "negative space" availiable in the typesetting. It would also be nice to be able to specify the plot option symbol= where value can be any typeset object and not just one of the named choices.


> f:=x->0.5*x^4-3*x^3-x^2+x+10:
> g:=x->x*exp(1)^(0.5*x-1):

> sol1 := fsolve(f(x)-g(x),x=-20..20);
                              sol1 := 1.528541752
> sol2 := fsolve(f(x)-g(x),x=-20..20,avoid={x=sol1});
                              sol2 := 16.51585692
> sol3 := fsolve(f(x)-g(x),x=-20..20,avoid={x=sol1,x=sol2});
                              sol3 := 6.650030266

> RootFinding:-Analytic(f(x)-g(x),x=-20-1*I..20+1*I);
             1.52854175180261, 6.65003026642525, 16.5158569246140


What are your expectations of this indefinite integral with floating-point coefficients? I ask that as a potentially serious concern with your example.

If you want a formulaic answer, only so that you can subsequently plug in numeric values (and so get results to some definite integration problem, using the FTOC) then perhaps you could consider doing definite numeric integration (quadrature) in the first place.

If instead you wish to investigate the indefinite integral for, say, qualitative aspects then how do you expect any (floating-point) numeric issues in the integrand to relate to numerical issues in the integral?


Have a look at the EmbeddedComponents help-page in Maple 12.


I had no apparent problems with running the intpakX v1.2 package's compute_all_zeros_with_plot routine, provided that I issued the following call before the module defnition.


After regenerating the module, with the above preceding it, and then loading that package using with, the following example from its user guide worked OK for me in Worksheet mode. Again, you might want to check that you really are recreating the module and that it's not also being picked up from a saved version in libname.


The following also worked for me in Worksheet mode in the Standard GUI (with either Maple Standard or Extended typesetting level as set under Tools->Options->Display),

> A1:=[1,0,1];
> A2:=[-1,1,1];
                             A1 := [1, 0, 1]
                             A2 := [-1, 1, 1]

> A4:=A1 &cmult_opt A2;
               A4 := [-1.390388204, 1.390388204, 2.969562256]

I don't know why it didn't work for you. (I don't know what you C1 is, however. I'm also not totally clear on your Maple version, or interface, or typesetting level.)

While looking for other problematic function names I noticed that the package's init routine also calls with(geometry). That too is a module-based package in Maple 12, and is no longer table-based. Since there are no calls like geometry[somefunction] inside the intpakX sources, it seems "ok" to also issue with(geometry) as another separate command prior to the definition of the intpakX modulein its source. (Again, uses would be a better solution.)


What happens if you remove the space betwene the & and the cmult_opt?


This seems fixable.

If you want to rebuild that package (from its version 1.2 .mw source) then the following command could be inserted right after the restart at its beginning (and before the actual package module code).


Alternatively, you could edit the package sources and replace appropriate instances of display with :-plots:-display accordingly. (It could be written better in several repects, but this is probably one way to patch the thing quickly.)

Once the fixed package has been loaded using with the following should work,

X := [0.5,2.];
f3 := x->exp(-x^2)*sin(Pi*x^3);
P1 := compute_range(f3,X,6);


A solution containing a RootOf may be unfamiliar to the user new to Maple. But it is not meaningless gibberish.

The RootOf acts as a placeholder for the root of an equation which may not be directly expressible. Maple is capable of doing work with such objects, because it some situations they may be usefully manipulated/combined during subsequent computations.

But also, a RootOf can express a exact (non-floating-point) root. That root could be then evaluated to a floating-point approximation at the user's choice of working precision.

For some problems, the work done by `solve` to compute the result can be considerable. If a user wishes to obtain a floating-point approximation, and then to refine that approximation by a repeated floating-point evaluation, it can be much more time  and resource consuming to repeat the entire `solve` call (after replacing some coefficient by its float approximant, say) with a higher setting of Digits. It can be much more efficient to compute the exact RootOf representation once and then to apply evalf[n] as desired.

For example,

> restart:
> e1:=22 - 44*t + 216*t^2 - 66*u - 450*u^2 + 362*u^3:
> e2:=150 - 300*t + 185*t^2 - 450*u + 795*u^2 - 495*u^3:

> _EnvExplicit:=true: sols := solve({e1,e2}):

> evalf(sols);
{t = 0.3553932236, u = 0.2256393210}, {t = -0.392720252, u = 1.261618450},
    {t = 1.089017838 + 0.153896733 I, u = 0.7930027610 + 0.4135809565 I},
    {t = 0.05432219403 - 0.6134738526 I, u = -0.07035986551 + 0.3340858801 I},
    {t = 0.05432219403 + 0.6134738526 I, u = -0.07035986551 - 0.3340858801 I},
    {t = 1.089017838 - 0.153896733 I, u = 0.7930027610 - 0.4135809565 I}
> evalf[20](sols);
{t = 0.35539322359002767246, u = 0.22563932100319632252},
    {t = -0.3927202491803974905, u = 1.2616184500250283042}, {
    t = 1.0890178383908523764 + 0.1538967326801938346 I,
    u = 0.79300276100467055164 + 0.41358095648073648234 I}, {
    t = 0.054322194043184680550 - 0.61347385248733028667 I,
    u = -0.070359865507798909630 + 0.33408588008148581458 I}, {
    t = 0.054322194043184680550 + 0.61347385248733028667 I,
    u = -0.070359865507798909630 - 0.33408588008148581458 I}, {
    t = 1.0890178383908523764 - 0.1538967326801938346 I,
    u = 0.79300276100467055164 - 0.41358095648073648234 I}

The original posted example does not necessarily raise this performance difference to any great extent. But other problems can. And there are other Maple routines that can compute (approximate) roots of rational polynomial systems (eg. fsolve, etc). My point is purely  about the relative merits of replacing exact equations by floating-point equivalents if the intention is to pass the system to solve.

And RootOf objects should not be avoided for their own sakes (as ostensibly meaningless). There can be benefits to having control over how Maple computes floating-point results. The balance of power and ease-of-use is usually hard to implement best.


These all just showed as blank pages in my firefox browser. Did they work for anyone else?


First 194 195 196 197 198 199 200 Last Page 196 of 227