bug in iscont?

User login

Poll

Collaborative Books

Syndicate

What is this?

Posted on 2007-11-05 15:18 By Doug Meade ( Maple Rating 4

617)

Categories:

Questions

Can anyone explain why Maple has so much trouble deciding if sqrt(2^x+x^4) is continuous for k>=1?

f := 2^x+x^4;
                                      x    4
                               f :=  2  + x 
iscont( f, x=1..infinity );
                                    true
iscont( sqrt(f), x=1..infinity );
                                    FAIL
iscont( sqrt(f), x=1..100 );
                                    FAIL
solve( f>0, x );
                                      x

Accoring to the online help for solve,inequal, the last result means Maple understands that f>0 for all real values of x.

So, given all of this, what is the problem deciding that sqrt(f) is continuous for x>=1?

OR, is this a bug?

Doug

Doug Meade's blog
Login or register to post comments

Comments

iscont background: discont=true, discont, and fdiscont

Comment on 2007-11-05 15:44 from Doug Meade ( Maple Rating 4

617)

In my previous blog entry, I neglected to explain how I discovered this problem with iscont. Recall:

f := 2^x+x^4:

In my work on my Maplets for Calculus project, I used a general command similar to the following to create a plot within a maplet:

plot( sqrt(f), x=1..10, discont=true );
Error, (in plot) invalid arguments

What could be invalid here?

None of the following cause any trouble:

plot( f, x=1..10, discont=true );
plot( f, x=1..10 );
plot( sqrt(f), x=1..10 );

After more time than I want to admit, it dawned on me that the discont=true option is causing the trouble. As I dug deeper into this, I discovered the iscont oddity reported in my previous post.

I overcame this situation with the use of try ... catch as follows:

try
  __p4:=plot( sqrt(f), x=1..10, discont=true, color=red );
catch:
  __p4:=plot( sqrt(f), x=1..10, color=red );
end try;

Why does this example cause so many problems?

We now look at how discont handles this problem:

discont(f,x);
                                     {}
discont(sqrt(f),x);
               /            /       /1   1  \        (1/2)\  
               |  4 LambertW|_NN18, |- - - I| ln(2) 2     |  
              <             \       \8   8  /             /  
               |- -----------------------------------------, 
               \                    ln(2)                    

                            /       /  1   1  \        (1/2)\  
                  4 LambertW|_NN17, |- - - - I| ln(2) 2     |  
                            \       \  8   8  /             /  
                - -------------------------------------------, 
                                     ln(2)                     

                            /       /1   1  \        (1/2)\  
                  4 LambertW|_NN19, |- + - I| ln(2) 2     |  
                            \       \8   8  /             /  
                - -----------------------------------------, 
                                    ln(2)                    

                            /       /  1   1  \        (1/2)\\ 
                  4 LambertW|_NN20, |- - + - I| ln(2) 2     || 
                            \       \  8   8  /             / >
                - -------------------------------------------| 
                                     ln(2)                   / 
evalf(%);
      {-5.770780164 LambertW(_NN18, 0.1225322679 - 0.1225322679 I), 

        -5.770780164 LambertW(_NN19, 0.1225322679 + 0.1225322679 I), 

        -5.770780164 LambertW(_NN20, -0.1225322679 + 0.1225322679 I), 

        -5.770780164 LambertW(_NN17, -0.1225322679 - 0.1225322679 I)}

The uses of discont=true and iscont (with a real interval) trapped me into thinking only about the real-valued cases. It never dawned on me (until seeing the output from discont) that this result was being complicated by the more general complex-valued case.

Knowing what I now know, is there a clean way to overcome this problem (without my try ... catch kludge)?

I do see that fdiscont can be used in this situation, but I am not sure about using this in general (and it's not an option within the plot command).

fdiscont(f,x=1..infinity);
                                     []
fdiscont(sqrt(f),x=1..infinity);
                                     []

Hopefully, some of this insight will help someone to either i) understand the problem in a way that enables them to provide a better solution to this problem or ii) suggest an efficient way to handle such situations.

Doug

---------------------------------------------------------------------
Douglas B. Meade
Math, USC, Columbia, SC 29208  E-mail: mailto:meade@math.sc.edu       
Phone:  (803) 777-6183         URL:    http://www.math.sc.edu/~meade/

This is a ``weakness''

Comment on 2007-11-05 20:23 from JacquesC ( Maple Rating 4

1629)

Personally, I would call it a bug, but in Maple lingo, this is called a weakness. Basically, Maple has only one solve, which solves over the complex. It does not really have a solve which finds only solutions in a smaller domain, except for the integers. In other words, no 'solve' that is designed from the ground up to deal with the reals. Of course, this is not so simple: one can easily conjure up an equation where the solution is real, but intermediate values of the expression (but not the final values) are complex.

In other words, the problem here is that discont() is asking solve() much too general a question, because it has no real way (pun intended) to ask a more meaningful question. The issue is really that the restriction that only solution with x in 1..10 interest you is not "used".

Mathematically, this is a very hard problem. What is puzzling is how little this seems to matter; I mean, this kind of ``weakness'' is rarely encountered in practice. Either that or, when it is encountered, it is not reported and/or blamed on something else. Or maybe this really is rare. It would be interesting to know! If it is rare, then it is not worth expending a lot of effort on it. If it is merely under-reported, then maybe this requires real attention.