@Markiyan Hirnyk Thanks very much. I too had found an approximate minimizing value near yC=0.46757... but I was wondering whether it could be shown to be some exact value. I don't see how to get it out of the high degree results in `sol`, but I was curious whether some other route could get it. I don't know whether that is tractable.

Thank you for the interesting post.

Do you know the exact value of yC at which the radius of the circle (on which all six points lie) is at its least? Is 1/4 the least radius, for your A and B?

acer

This should work in both Maple 17 and 18. But in Maple 18 it is more fun because one can simply left-click drag around the plotted point C instead of adjusting the two sliders which denote xC and yC.

I put in a try..catch to prevent a popup error when three points in a triangle are collinear. But otherwise pretty much all I had to do was put Markiyan's code inside a proc.

restart:

F:=proc(xC,yC)
  uses geometry, plots;
  try
  point(A, 0, 0);
  point(B, 1, 0);
  point(C, xC, yC);
  triangle(T, [A, B, C]);
  median(mA, A, T, MA);
  median(mB, B, T, MB);
  median(mC, C, T, MC);
  line(m1, [A, MA]);
  line(m2, [B, MB]);
  intersection(E, m1, m2);
  triangle(AEMB, [A, E, MB]);
  circumcircle(c1, AEMB, 'centername' = C1);
  circumcircle(c2, triangle(CEMB, [C, E, MB]), 'centername' = C2);
  circumcircle(c3, triangle(CEMA, [C, E, MA]), 'centername' = C3);
  circumcircle(c4, triangle(BEMA, [B, E, MA]), 'centername' = C4);
  circumcircle(c5, triangle(BEMC, [B, E, MC]), 'centername' = C5);
  circumcircle(c6, triangle(AEMC, [A, E, MC]), 'centername' = C6);
  circle(CC, [C1, C2, C3]);
  display([draw([T(color = black), mA(color = black),
                 mB(color = black), mC(color = black),
                 C1(color = blue), C2(color = blue),
                 C3(color = blue), C4(color = blue),
                 C5(color = blue), C6(color = blue),
                 CC(color = red)], symbol = solidcircle, symbolsize = 15,
                 thickness = 2, scaling = constrained),
           textplot({[-0.5e-1, 0.5e-1, "A"], [.95, 0.5e-1, "B"],
                     [xC-0.5e-1, yC+0.5e-1, "C"]})],
          axes = none, view = [-1..2,-2..2]
         );
  catch:
  end try;
end proc:

#F(15*(1/10), sqrt(3));

Explore( F(xc,yc), parameters=[xc=-1.0..2.0,yc=-2.0..2.0],
         initialvalues=[xc=1.5,yc=sqrt(3.0)], markers=[[xc,yc]] );

acer

The entries of your `words` are not being accessed in alphabetical order, so perhaps you are looking for "weird" in the wrong place.

acer

I was wondering whether the question was presented exactly as intended. In particular I was wondering whether the intention was to ask about, say,

add(...(add(f(i_1,...,i_n),i_1=0..k_1),...),i_n=0..k_n);

or perhaps even,

add(...(add(f(x[i_1],...,x[i_n]),i_1=0..k_1),...),i_n=0..k_n);

If that is actually the case then it seems to me that the question is about `fold` functionality. Ie,

p := n -> foldl(F, f(seq(i[j],j=1..n)), seq(i[j]=0..k[j],j=1..n)):

p(3);

    F(F(F(f(i[1], i[2], i[3]), i[1] = 0 .. k[1]),

          i[2] = 0 .. k[2]), i[3] = 0 .. k[3])

p := n -> foldl(F, f(seq(x[i[j]],j=1..n)), seq(i[j]=0..k[j],j=1..n)):

p(2);                                                                

         F(F(f(x[i[1]], x[i[2]]), i[1] = 0 .. k[1]), i[2] = 0 .. k[2])

So, if the various k[j] have all been assigned then `F` could be replaced with `add` above.

Of course this might not be a correct interpretation of the intended arguments to `f`. I was just wondering.

acer

@Carl Love Lookup by table.. indeed. Thank you.

It's been a long time since this old discussion and mention of using lookup tables for base conversion (convert base 10 also does the given task, but slowly) that I'd quite forgotten it.

Raising the above (10^5 digits) example up to 10^6 digits then a bit more speed might be squeezed out by switching to Threads:-Seq above some cutoff number of digits, but the memory allocation becomes huge.

The `in` syntax seems to save a little bit of (64bit MS-Win 7 quad-core i7) speed using either `seq` or Threads:-Seq, but doubles the huge memory allocation due to using Threads:-Seq.

restart:

F1:=proc(x) local y;
     y:=sprintf("%a",op(1,x));
     if length(y)>400000 then
       [Threads:-Seq(parse(s),s in y)];
     else
       [seq(parse(s),s in y)];
     end if;
end proc:

x:=evalf[1000000](5555/7):

CodeTools:-Usage( F1(x) ):
memory used=2.08GiB, alloc change=4.02GiB, cpu time=14.57s, real time=10.01s

Compare with,

restart:

F1:=proc(x) local y;
     y:=sprintf("%a",op(1,x));
     if length(y)>400000 then
       [Threads:-Seq(parse(y[i]),i=1..length(y))];
     else
       [seq(parse(s),s in y)];
     end if;
end proc:

x:=evalf[1000000](5555/7):

CodeTools:-Usage( F1(x) ):
memory used=2.08GiB, alloc change=1.82GiB, cpu time=14.94s, real time=10.78s

All a bit confusing.

@rlopez If such a sheet is closed and then re-opened, where should the mouse cursor be placed on that function assignment line so that pressing the Enter key will correctly execute it?

@Thomas Richard Just a note:

It can also be accomplished directly in the Worksheet/Document with the command,

Typesetting:-Settings(functionassign = true):

If it is a command in the sheet or in its Startup Region then other readers (eg. instructors, etc) of the sheet would also not need to be bothered by it, I suppose.

If you are using Maple 13 or earlier, and if you are using 2D Math input, then you could use this form of the `if` operator,

Butcher, map(x->`if`(x=0,``,x),Butcher);

acer

@Markiyan Hirnyk I have not so far stated that there are only two pairs of purely real solutions.

But I think that you should at least look harder at that 3rd result you cited from DirectSearch, where `a` was approx. 15.2 and `x` was approx. 5e-7.

For example, why would eq[2] become less than 2 when `x` gets close to zero?

Also, if one creates two nonevalhable procedures to evaluate eq[1] and eq[2] while respecting a very high working precision then I don't see the solution curves crossing near x=0.

For example, zooming in...

U1:=unapply(eq[1],[a,x]):
F1:=proc(a,x) Digits:=500; []; U1(a,x); end proc:
U2:=unapply(eq[2],[a,x]):
F2:=proc(a,x) Digits:=500; []; U2(a,x); end proc:

plots:-implicitplot( [F1,F2], 33..35, 0..1e-14,
                     labels=[a,x], color=[red,blue], gridrefine=2 );

In other words, I don't believe that the red and blue curves are going to cross at some larger value for `a`, for the curves seen going off to the bottom right of this,

plots:-implicitplot( [F1,F2], 1..5, 0..0.5,
                     labels=[a,x], color=[red,blue], gridrefine=2 );

If they do seem to cross, then zooming in (and also possibly increasing precision or grid refinement) seems to show such a manifested crossing as spurious. Of course some deft exact analysis (or the difference eq[2]-eq[1], perhaps?) would be better.

@awass The key difference is not that your example was (or was not) inside a do-loop. The key difference was that one of your examples contained literal numerics which automatically simplified to zero in a denominator. (In your looped version one of the literal 7s was replaced by the loop index j.)

Automatic simplification precedes usual evaluation, and as a consequence of which is not delayed by unevaluation quotes and not trapped by the try..catch mechanism. In other words you cannot disable it for your particular example except by using something other than literal numeric input.

By the way, some numeric exception in your examples can also be managed by another mechanism -- a custom Numeric Event Handler. Eg,

restart:

'1/(7-7)';
Error, numeric exception: division by zero

NumericStatus( ':-division_by_zero' );
                              true

MyHandler := proc(operator,operands,default_value)
   NumericStatus( division_by_zero = false );
   return infinity;
end proc:

NumericEventHandler( ':-division_by_zero'=MyHandler ):

1/(7-7);
                            infinity

NumericStatus( ':-division_by_zero' );
                             false

That's just an example of usage. You could alter it to return a different value, or alter it to not reset the numeric event's status flag, etc.

There are other kinds of automatic simplification that can occur than just the purely numeric subtraction & division example you gave. Eg,

'2*(x+y)';

                             2 x + 2 y

'proc() x*~y; end proc';

                 proc() ~[:-`*`](x,  $, y) end proc;

'x-x';

                                 0

@Stephen Forrest Compiling a symbolic piecewise produced by CurveFitting:-Spline is not a good approach in the case that there are many data points. The task of producing the piecewise scales badly with the number of points, and the compilation cost must be paid for each new set of data. That compiled-piecewise method is easy to set up, but its set up is very costly at large sizes. This is the kind of scenario for which ArrayInterpolation can be used for much more efficient set up. The addition of an even easier way to set up a proc that does lean scalar->scalar calls to ArrayInterpolation would improve Maple.

@Andriy I would concur with what Preben has said about `A` not being evaluated when say `A[1]` is called, and that is key.

If you are going to access elements of `A` many times then you would be better off assigning Q:=eval(A) after the assignment b:=a, and then working with `Q`. 

Note that if you had done all this inside a procedure with local `A` then numelems(A) would return 3 even after the assignment of `a` to `b`. That would be similar to calling numelems(eval(A,1)) at the top level which Preben described. In that procedure setting the extra statement like Q:=eval(A) might seem less unusual.

It might seem that another reasonable workaround for the top level is to use op(2,A) instead of A[2]. That should produce the results you were expecting, ie. op(1,A) returns `a` and op(2,A) returns `c`. But I suspect that for a large set `A` with many elements there could be large overhead with using `op` instead of square bracket indexing to handle this special situation that some entries change upon evaluation. I would worry that each new expression sequence of evaluated entries might get resorted during the uniquification process, upon each (higher than 1-level) evaluation of A.

@Markiyan Hirnyk I used the example about which the original poster had inquired. You're not contributing in a meaningful way here.