Services & Resources / Wolfram Forums / MathGroup Archive
-----

MathGroup Archive 2013

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

Search the Archive

Re: inconsistent refinement behavior

  • To: mathgroup at smc.vnet.net
  • Subject: [mg131420] Re: inconsistent refinement behavior
  • From: Alex Krasnov <akrasnov at cory.eecs.berkeley.edu>
  • Date: Sun, 21 Jul 2013 04:25:17 -0400 (EDT)
  • Delivered-to: l-mathgroup@mail-archive0.wolfram.com
  • Delivered-to: l-mathgroup@wolfram.com
  • Delivered-to: mathgroup-outx@smc.vnet.net
  • Delivered-to: mathgroup-newsendx@smc.vnet.net
  • References: <20130717054943.ED2F569C5@smc.vnet.net>

I mostly agree with your interpretation, especially regarding the 
(x==0)||(x>0) example. The reason why the x==0 example returns 
ComplexInfinity, while perhaps subtle, is not particularly relevant here. 
In order for the (x==0)||(x>0) example to return Infinity, Refine must 
assume the strongest condition that x is real and positive, i.e., that 
x>0. A mathematical justification for this transformation appears to not 
exist, since the original expression is not a limit from the right.

Regarding the appropriate result, Refine should return a less general 
expression given the specified assumptions. This example should return 
unrefined. ComplexInfinity is appropriate if, given the specified 
assumptions, no additional assumptions can determine the direction, which 
is false here. Consider the following similar examples:

In:	Assuming[x==0, Refine[DirectedInfinity[1/x]]]
Out:	ComplexInfinity

In:	Assuming[x>0, Refine[DirectedInfinity[1/x]]]
Out:	Infinity

In:	Assuming[x>=0, Refine[DirectedInfinity[1/x]]]
Out:	DirectedInfinity[Sign[x]^(-1)]

In any case, this behavior is likely a result of internal simplification 
rather than logical design. However, it deserves at least a note under 
"Possible Issues" and possibly a correction.

Alex


On Wed, 17 Jul 2013, Bill Rowe wrote:

> On 7/16/13 at 5:56 AM, akrasnov at cory.eecs.berkeley.edu (Alex Krasnov)
> wrote:
>
>> Refine treats Reals as a subset of Complexes, as expected:
>
>> In:    Assuming[Element[x, Reals], Refine[Element[x, Complexes]]]
>> Out:   True
>
> Yes, I didn't adequately make my point.
>
> Others have offered as an explanation for
>
> Assuming[x>=0, Refine[Infinity/x]] yielding Infinity or more
> precisely, DirectedInfinity[1] as simply being x>=0 requires x
> to be a real in order for the > portion to have validity.
>
> You suggested
>
> Assuming[x==0, Refine[Infinity/x]]
>
> yields ComplexInfinity or more precisely DirectedInfinity[] as
> being due to not having a know sign value for x when x is 0
>
> I find both explanations wanting, i.e. somewhat incomplete.
>
> If I take x == 0 to be an isolated point, then I can see why
> Mathematica returns DirectedInfinity[] (ComplexInfinity) rather
> than DirectedInfinity[1] (Infinity) as there is no basis for
> assuming any particular direction.
>
> And when I take x>0, I implicitly require x to be real for the >
> operation to be valid which makes DirectedInfinity[1] reasonable.
>
> But none of the reasons for Assuming[x>=0, Refine[Infinity/x]]
> yielding DirectedInfinity[1] seem to be adequate from a strictly
> mathematical point of view.
>
> I can see why it might be simpler from a programming viewpoint
> to return DirectedInfinity[1] rather than DirectedInfinity[].
> And I can kind of see it as being somewhat implied that I am
> restricting things to the real line with x>=0. But I just
> haven't seen a mathematical reason for assuming I am restricting
> the problem to the real line at x == 0 simply by adding the
> possibility of other real positive values for x.
>
> In fact, it seems very inconsistent that
>
> Assuming[(x == 0 && Element[x, Complexes]) || x > 0,
>  Refine[Infinity/x]]
>
> returns DirectedInfinity[1] (Infinity)
>
> when
>
> Assuming[(x == 0 && Element[x, Complexes]), Refine[Infinity/x]]
>
> returns DirectedInfinity[] (ComplexInfinity)
>
>



  • Prev by Date: Re: keep special functions unexpanded
  • Next by Date: Re: CRC32 Hash Missmatch
  • Previous by thread: Re: inconsistent refinement behavior
  • Next by thread: numerical integration of vector integrands