@flash20001 If you have Maple 7 then your won't be able to use the legend=... option in that way. (For one thing, that typeset() facility is much more recently added functionality for Maple, and for another thing a long string in a legend will often get truncated in what is show.)

You could try textplot, and maybe pass it a string. I don't have Maple 7 to test that with, sorry. The string could be formatted using sprintf (similarly to how printf was used above) so that it contains your computed points xs and ys without your having to type in their values. I suppose that textplot & nprintf is another possible combination.

@Markiyan Hirnyk It really looks like the task is that the name of the extra parameter, which only in this particular example happens to be `b`, is as yet unknown and is not given. If that is in fact the challenge then using the name `b` to select itself from a set or list... is silly. If the user chooses any other name but `b` then this fails.

@Markiyan Hirnyk It really looks like the task is that the name of the extra parameter, which only in this particular example happens to be `b`, is as yet unknown and is not given. If that is in fact the challenge then using the name `b` to select itself from a set or list... is silly. If the user chooses any other name but `b` then this fails.

I think that it is not correct to compare floats only in some such uncontrolled way. If the mechanism used for comparison (...and then used in turn by `union`) were as flexible as `testfloat` or `verify/float` then I'd agree. But it isn't.

And Digits affects both the `convert` and the `evalf` stages, in this method.

That is speaking in general. The member who asked here, icegood, could of course easily say that it was OK fully acceptable and that he wanted the working precision to dictate comparison. There would be nothing wrong with that, of course. He just hasn't said so... yet.

I think that it is not correct to compare floats only in some such uncontrolled way. If the mechanism used for comparison (...and then used in turn by `union`) were as flexible as `testfloat` or `verify/float` then I'd agree. But it isn't.

And Digits affects both the `convert` and the `evalf` stages, in this method.

That is speaking in general. The member who asked here, icegood, could of course easily say that it was OK fully acceptable and that he wanted the working precision to dictate comparison. There would be nothing wrong with that, of course. He just hasn't said so... yet.

notice that this entails rouding, and thus discards entries according to te current Digits. He may or may not want that here.

s:={Float(10.00)} union {Float(10.0)} union {Float(10.0000000000000000000001)};

            {10.00, 10.0, 10.0000000000000000000001}

convert(s, rational, exact);

                 /    100000000000000000000001\ 
                { 10, ------------------------ }
                 \    10000000000000000000000 / 

evalf(%);

                       {10.00000000, 10.}

convert(s, rational);

                              {10}

evalf(%);

                             {10.}

So, terms like 10.000000000001 are dropped when Digits=10, etc.

notice that this entails rouding, and thus discards entries according to te current Digits. He may or may not want that here.

s:={Float(10.00)} union {Float(10.0)} union {Float(10.0000000000000000000001)};

            {10.00, 10.0, 10.0000000000000000000001}

convert(s, rational, exact);

                 /    100000000000000000000001\ 
                { 10, ------------------------ }
                 \    10000000000000000000000 / 

evalf(%);

                       {10.00000000, 10.}

convert(s, rational);

                              {10}

evalf(%);

                             {10.}

So, terms like 10.000000000001 are dropped when Digits=10, etc.

It's quite bad that Maple does not either save that parsed meaning in the worksheet (so that it doesn't ask, when others run it) or convert it and replace it with the unambiguous -> operator syntax.

I wonder what is meant by f[i] in this example.

It's just a minor comment, but I often prefer to get a grip on why the `symbolic` option is necesary for some example. And so I prefer using assumptions, where possible.

> expr:=ln(1+y^2/(x-1)^2)+2*ln(x-1):

> simplify(expr) assuming x>1;

                              / 2              2\
                            ln\x  - 2 x + 1 + y /


> new := Student:-Precalculus:-CompleteSquare(%);

                                /       2    2\
                              ln\(x - 1)  + y /

> simplify(eval(expr,x=-1));

                               /     2\         
                             ln\4 + y / + 2 I Pi

> simplify(eval(new,x=-1));

                                   /     2\
                                 ln\4 + y /

This can help explain to the Asker why Maple does not simplify it without qualification: it's not true, for all complex values.

It's just a minor comment, but I often prefer to get a grip on why the `symbolic` option is necesary for some example. And so I prefer using assumptions, where possible.

> expr:=ln(1+y^2/(x-1)^2)+2*ln(x-1):

> simplify(expr) assuming x>1;

                              / 2              2\
                            ln\x  - 2 x + 1 + y /


> new := Student:-Precalculus:-CompleteSquare(%);

                                /       2    2\
                              ln\(x - 1)  + y /

> simplify(eval(expr,x=-1));

                               /     2\         
                             ln\4 + y / + 2 I Pi

> simplify(eval(new,x=-1));

                                   /     2\
                                 ln\4 + y /

This can help explain to the Asker why Maple does not simplify it without qualification: it's not true, for all complex values.

What have you got so far?

@Joe Riel I mentioned only the step, solve(equn1,beta[2]) , mostly because equn2 is already an explicit expression for beta[1] , without beta[2] present, and so no other `solve` call is required there.

And so, as Joe explains, `subs` can be used to express the explicit solution for beta[2] in all other variables excluding beta[1].

(I don't understand why the additonal explicit equation beta[1]=....  prevents either solve({equn1,equn2},beta[2]) or solve({equn1,equn2},{beta[1],beta[2]}) from succeeding. What am I missing there??)

@Joe Riel I mentioned only the step, solve(equn1,beta[2]) , mostly because equn2 is already an explicit expression for beta[1] , without beta[2] present, and so no other `solve` call is required there.

And so, as Joe explains, `subs` can be used to express the explicit solution for beta[2] in all other variables excluding beta[1].

(I don't understand why the additonal explicit equation beta[1]=....  prevents either solve({equn1,equn2},beta[2]) or solve({equn1,equn2},{beta[1],beta[2]}) from succeeding. What am I missing there??)

@alex_01 You need to add one more argument to `f`, for u::Array(datatype=float[8]) which was previously declared as a global.

If I add that, then `f` itself Compiles.

But GRADIENT(f) produces an error about array bounds, which you'd have to fix before you could Compile that.

The code of `f` looks logically wrong in some other respects. How can the entries of V be used if you haven't given them any values? At one point, you divide by V[i] which is going to return undefined if V[i] is zero.

I am not sure that `kuk` is going to have the correct form for the (commented out) style of call to NLPSolve.

I would try getting the Optimization call to work first (prefereably under evalhf mode as indicated by Optimization's userinfo, but in any event get it working in some usual way) and think about compiling it only later.

@alex_01 You need to add one more argument to `f`, for u::Array(datatype=float[8]) which was previously declared as a global.

If I add that, then `f` itself Compiles.

But GRADIENT(f) produces an error about array bounds, which you'd have to fix before you could Compile that.

The code of `f` looks logically wrong in some other respects. How can the entries of V be used if you haven't given them any values? At one point, you divide by V[i] which is going to return undefined if V[i] is zero.

I am not sure that `kuk` is going to have the correct form for the (commented out) style of call to NLPSolve.

I would try getting the Optimization call to work first (prefereably under evalhf mode as indicated by Optimization's userinfo, but in any event get it working in some usual way) and think about compiling it only later.