MathGroup Archive 2007

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: FindInstance puzzler

  • To: mathgroup at
  • Subject: [mg83742] Re: [mg83633] FindInstance puzzler
  • From: Andrzej Kozlowski <akoz at>
  • Date: Thu, 29 Nov 2007 06:33:41 -0500 (EST)
  • References: <> <> <> <> <> <> <> <>

On 29 Nov 2007, at 01:08, Adam Strzebonski wrote:

> Andrzej Kozlowski wrote:
>> *This message was transferred with a trial version of 
>> CommuniGate(tm) Pro*
>> On 28 Nov 2007, at 05:40, Adam Strzebonski wrote:
>>> Andrzej Kozlowski wrote:
>>>> *This message was transferred with a trial version of 
>>>> CommuniGate(tm) Pro*
>>>> On 27 Nov 2007, at 17:05, Andrzej Kozlowski wrote:
>>>>> Reduce[2*y*I*Sqrt[x] + 2*(y - I*Sqrt[x]) == 0, {x, y}, Reals]
>>>> This should have been:
>>>> In[17]:= Reduce[2*y*I*Sqrt[x] + 2*(y - y*I*Sqrt[x]) == 0,
>>>> {x, y}, Reals]
>>>> During evaluation of In[17]:= Reduce::nddc:The system 2 \
>>>> [ImaginaryI] Sqrt[x] y+2 (y-\[ImaginaryI] Sqrt[x] y)\[LongEqual]0 =

>>>> contains a nonreal constant 2 \[ImaginaryI]. With the domain \
>>>> [DoubleStruckCapitalR] specified, all constants should be real. >>
>>>> Out[17]= Reduce[2*I*Sqrt[x]*y + 2*(y - I*Sqrt[x]*y) == 0,
>>>> {x, y}, Reals]
>>>> but it other than that it does not change anything. Note that:
>>>> Reduce[Simplify[2*y*I*Sqrt[x] + 2*(y - y*I*Sqrt[x]) == 0], {x, =

>>>> y}, Reals]
>>>> y==0
>>>> What I really mean tto say is: wouldn't it be a litte better to 
>>>> first automatically apply Simplify in such situation to see if 
>>>> the I's could be got rid of?
>>>> Andrzej Kozlowski
>>> It think this behaviour is correct. Reduce should disallow any non-=

>>> real
>>> subexpressions when the domain Reals is specified. The fact that it
>>> cannot detect potentially non-real functions that cancel during 
>>> input
>>> processing is more problematic, but hard to avoid.
>>> Adam Strzebonski
>> Well yes, but... There are plenty of real valued functions for 
>> which it is hard to give an explicit expression not involving 
>> complex numbers. For example, the function
>> g[x_] := Sec[(1/2)*Arg[I*Sin[x]]]*(Sqrt[I*Sin[x]] - 
>> I*Sqrt[Abs[Sin[x]]]*Sin[(1/2)*Arg[I*Sin[x]]])
>> is always real valued for real x. In fact, Mathematica is able to 
>> show that this is so:
>> ComplexExpand[Im[g[x]], TargetFunctions -> {Re, Im}]
>> 0
>> Moreover, Mathematica can even solve  (well, almost) the following:
>> Reduce[g[x] == 1 && Element[x, Reals], x]
>> Reduce::ztest:Unable to decide whether numeric quantities {1/8 (-8 =

>> tan-1(1-Power(<<2>>))-=CF=80)} are equal to zero. Assuming they are. =
>> Element[C[1], Integers] && (x == (1/2)*(4*Pi*C[1] - Pi) || x ===
>> (1/2)*(4*Pi*C[1] + 3*Pi) ||
>>   x == (1/2)*(4*Pi*C[1] + Pi))
>> But even so, it won't even touch:
>> Reduce[g[x] == 1, x,Reals]
>> I guess the reason why I am not happy about it is that I am used to =

>> telling students that an expression is not "complex" valued just 
>> because it has complex numbers in it. This behaviour would seem to =

>> confirm them in this, in my opinion, quite wrong anti-complex 
>> prejudice. Still, I admit, being able to dismiss certian inputs out =

>> of hand,  clearly makes the job of a CAS easier  ;-)
>> Andrzej Kozlowski
> With domain Reals specified, Reduce looks for solutions for
> which all constants and function values are real. So in
> Reduce[g[x]==1, x, Reals]
> g[x] does not need to be real valued for all x, but for x0 to
> be considered a solution, all subexpressions of g[x] need to
> be real valued at x0. Hence
> Sqrt[I*Sin[x0]], I*Sin[x0] and I
> all need to be real valued. Since a non-real constant is not
> real valued for any value of x, there are no solutions.
> Technically, Reduce could return False here, but I think it is
> better to give a warning message instead.
> As you noted, if you are looking for solutions for which x is real
> but subexpressions of g[x] are allowed to be non-real,
> Reduce[g[x] == 1 && Element[x, Reals], x]
> works just fine.
> Best Regards,
> Adam Strzebonski
> Wolfram Research

I understand that, of course, and do not really object to this 
behaviour, except to a small extent on grounds of consistency (which I =

already pointed out). Also, the definition of "subexpression" does not =

seem to be completely unambiguous to me. For example, the following 

Reduce[x - (Sqrt[2] + I)*(Sqrt[2] - I) == 0, x, Reals]
x == 3

But should it? Isn't Sqrt[2] - I a non-real subexpression of 3 - 
(Sqrt[2] + I)*(Sqrt[2] - I)?

It seems to me that there are two sensible ways to think of what 
Reduce[expr,vars,Reals] is supposed to do. One approach is that Reduce =

"reduces" the original expression by means of operations defined on 
real numbers. With this interpretation the above should not work, 
since operations involving I are not defined. The other interpretation =

is that we try to "reduce" not literarly the input "formula" but an 
equivalent real expression, if one exists. In that case, one should 
first attempt to convert the input expression, which may be 
"superficially" complex, into a purely real expression (in this case 
x-3==0) and then reduce the latter using only "real" operations. It =

seems that Reduce in general adopts the former approach (only real 
operations on the input expression are allowed) but in this particular =

case it actually first simplified the expression using multiplication =

of complex numbers - which strictly should not be allowed. But I 
understand that avoiding this would require a lot of extra programming =

effort for what would be a purely cosmetic effect.

With best regards

Andrzej Kozlowski

  • Prev by Date: Re: FindInstance puzzler
  • Next by Date: Re: Recursive function
  • Previous by thread: Re: FindInstance puzzler
  • Next by thread: Re: FindInstance puzzler