@Carl Love 

It makes no practical difference here stating the method ftoc. See the output of:

infolevel[IntegrationTools]:=8:
int(g(c(t))*D(c)(t), t=0..1);

You will get the time spent in each integration method. Almost all the time is spent in the method ftoc, almost 100 times the next one (elliptictrig).

And almost all the time spent in the method ftoc is spent on discontinuity checking. Compare:

> CodeTools:-Usage(int(g(c(t))*D(c)(t), t=0..1,method=ftoc,continuous=true)):
memory used=2.83MiB, alloc change=32.00MiB, cpu time=69.00ms, real time=67.00ms

> CodeTools:-Usage(int(g(c(t))*D(c)(t), t=0..1,method=ftoc,continuous=false)):
memory used=431.08MiB, alloc change=78.01MiB, cpu time=7.34s, real time=7.21s

@Carl Love 

Actually it fails while checking this "inclusion":

> trace(`property/PropInclusion`):
> is(n^2<=2^n) assuming(n::posint);
[...]
{--> enter property/PropInclusion, args = AndProp(integer,RealRange(1,infinity)
), RealRange(-2*LambertW(1/2*ln(2))/ln(2),2)
[...]
<-- exit property/PropInclusion (now in property/PropInclusion) = FAIL}
                                  res := FAIL

Note the difference with and without the property integer:

> `property/PropInclusion`(AndProp(integer,RealRange(1,infinity)), 
RealRange(-2*LambertW(1/2*ln(2))/ln(2),2));
                                      FAIL
> `property/PropInclusion`(AndProp(RealRange(1,infinity)), 
RealRange(-2*LambertW(1/2*ln(2))/ln(2),2));
                                     false

On the other hand, this check for an integer between those bounds fails in both ways:

> prop1:=n::integer:prop2:=n in RealRange(2,4):
> coulditbe(prop1) assuming prop2;
                                      FAIL
> coulditbe(prop2) assuming prop1;
                                      FAIL

But this or similar check apparently is never made in the above computation.

@Carl Love 

Actually it fails while checking this "inclusion":

> trace(`property/PropInclusion`):
> is(n^2<=2^n) assuming(n::posint);
[...]
{--> enter property/PropInclusion, args = AndProp(integer,RealRange(1,infinity)
), RealRange(-2*LambertW(1/2*ln(2))/ln(2),2)
[...]
<-- exit property/PropInclusion (now in property/PropInclusion) = FAIL}
                                  res := FAIL

Note the difference with and without the property integer:

> `property/PropInclusion`(AndProp(integer,RealRange(1,infinity)), 
RealRange(-2*LambertW(1/2*ln(2))/ln(2),2));
                                      FAIL
> `property/PropInclusion`(AndProp(RealRange(1,infinity)), 
RealRange(-2*LambertW(1/2*ln(2))/ln(2),2));
                                     false

On the other hand, this check for an integer between those bounds fails in both ways:

> prop1:=n::integer:prop2:=n in RealRange(2,4):
> coulditbe(prop1) assuming prop2;
                                      FAIL
> coulditbe(prop2) assuming prop1;
                                      FAIL

But this or similar check apparently is never made in the above computation.

I am not very familiar with this subject. So, I find that explicit examples using your code might help me to understand better what you say.

@Adri van der Meer 

Yes, the cases of 4.^(1/2) and 4^.5 are representatives of another variety of the process of smartness lent to the power constructor, here mediated by floating-point contagion.

@Adri van der Meer 

Yes, the cases of 4.^(1/2) and 4^.5 are representatives of another variety of the process of smartness lent to the power constructor, here mediated by floating-point contagion.

This is interesting. I keep forgetting about this facility... It looks like the arguments are nor needed for MyHandler. In my opinion, infinity should be the default as it would make the algebra of complex numbers consistent:

> MyHandler := proc()
>    NumericStatus( division_by_zero = false );
>    return infinity;
> end proc:
> 
> NumericEventHandler(division_by_zero=MyHandler):
> 
> 2/0;
                                    infinity
> 1/%=0/2;
                                     0 = 0
> 

Yet, this handler should be improved for other expressions as e.g. ln(0) should return undefined instead.

This is interesting. I keep forgetting about this facility... It looks like the arguments are nor needed for MyHandler. In my opinion, infinity should be the default as it would make the algebra of complex numbers consistent:

> MyHandler := proc()
>    NumericStatus( division_by_zero = false );
>    return infinity;
> end proc:
> 
> NumericEventHandler(division_by_zero=MyHandler):
> 
> 2/0;
                                    infinity
> 1/%=0/2;
                                     0 = 0
> 

Yet, this handler should be improved for other expressions as e.g. ln(0) should return undefined instead.

@Carl Love 

It is a bit more odd. In document mode, when the above conditional clause is placed within a procedure (and only that procedure is executed in the document session), its execution produces the "expected" error message:

proc() if(1>0) then 1 else 0 end if;end proc;
print(`output redirected...`); # input placeholder
Error, unable to parse
Typesetting:-mambiguous(procApplyFunction()

  Typesetting:-mambiguous(ifApplyFunction(1gt0) then, 

  Typesetting:-merror("unable to parse")) 1 else 0 end ifsemiend 

  procsemi)

But if an assignment is made to the name width previously (two blocks), the error message disappears:

width := .1;
print(??); # input placeholder
proc() if(1>0) then 1 else 0 end if;end proc;
print(??); # input placeholder

(here again, just copy&pasting from the Standard GUI onto the editor). This effect seems special to the name width as the assignments to different names that I have tried do not produce this suppression effect. So, I may guess that width is being used by some code but it is not protected...

PD: I have traced for this latter case, the computations of the Maple library part of the 2-D parser (Typesetting:-Parse) and the error message is present up to the point where the computation is transfered back to the Java code part (i.e. the Java kernel). Hence it seems that collision with the global name width is located in the Java code.

@Carl Love 

It is a bit more odd. In document mode, when the above conditional clause is placed within a procedure (and only that procedure is executed in the document session), its execution produces the "expected" error message:

proc() if(1>0) then 1 else 0 end if;end proc;
print(`output redirected...`); # input placeholder
Error, unable to parse
Typesetting:-mambiguous(procApplyFunction()

  Typesetting:-mambiguous(ifApplyFunction(1gt0) then, 

  Typesetting:-merror("unable to parse")) 1 else 0 end ifsemiend 

  procsemi)

But if an assignment is made to the name width previously (two blocks), the error message disappears:

width := .1;
print(??); # input placeholder
proc() if(1>0) then 1 else 0 end if;end proc;
print(??); # input placeholder

(here again, just copy&pasting from the Standard GUI onto the editor). This effect seems special to the name width as the assignments to different names that I have tried do not produce this suppression effect. So, I may guess that width is being used by some code but it is not protected...

PD: I have traced for this latter case, the computations of the Maple library part of the 2-D parser (Typesetting:-Parse) and the error message is present up to the point where the computation is transfered back to the Java code part (i.e. the Java kernel). Hence it seems that collision with the global name width is located in the Java code.

@Carl Love 

This thread deals with this subtle distinction.

@Carl Love 

This thread deals with this subtle distinction.

@raccoon 

This thread deals with a somewhat similar problem when using the Standard GUI.

What input mode: 1-D or 2-D?

@Carl Love 

Just select-copying 2D input and output from the Standard GUI and pasting at the editor here (or at any text editor). A complementary view of the process is obtained by debugging Typesetting:-Parse.