equality, was: sinc(x) -- defining evaluating and simplifying operations

How much work do you want done to see if x=0, or x>0?

There are several obvious choices and some no-obvious ones.

1. is x identically the constant 0
2. can x be reduced to the constant 0 after simplification,e.g. sin(0).
3. can x be reduced to the constant 0 after more simplification e.g. ratsimp
4. is it consistent with the assume database that x might be 0

And then the choices
1. if you can't tell,  you signal an error
2. if you can't tell,  you say no
3. if you can't tell,  you return  '(is (x=0))

Here is an alternative to "if"...

if predicate(a,b,c)  then x1  else x2  unknown x3

But that has probs too..

RJF


Robert Dodier wrote:

>Concerning this construction --
>
>  sinc(x) := if (x = 0) then 1 else sin(x)/x;
>
>I wrote:
>
>  
>
>>That "=" is the wrong kind of equality, seems simply 
>>capricious; but I'll leave that aside for now.
>>    
>>
>
>Let me expand on that. In trying some apparently-equivalent
>expressions, I find that the handling of equality and 
>inequality is complicated, and incompletely described
>by the available documentation. It seems impossible to 
>predict the result from some logical expressions shown below.
>Naively one would think that they're all equivalent -- 
>"naive" being "what one would think if the documentation
>didn't say otherwise" -- since the documentation is 
>incomplete, that is the state of mind of most people.
>
>I have some specific ideas for improving the documentation,
>which I'm writing up. I'll file a bug report about that.
>
>Perhaps some the following expressions should indeed 
>be equivalent -- if so that implies code changes.
>(Let it be known that I am not suggesting that 
>we should make EQUAL and "=" equivalent.)
>
>Here are some details. Consider these functions:
>
>(C1) A(x,y):=EQUAL(x,y)$
>(C2) B(x,y):=x <= y AND x >= y$
>(C3) C(x,y):=NOT (x < y OR x > y)$
>(C4) D(x,y):=x = y$
>(C5) E(x,y):=NOT x # y$
>
>It turns out that only B and C are equivalent in the sense
>of yielding the same output in a variety of contexts.
>B and C are more like A, but not always. E is more like D,
>but not always. Consider:
>
>(C6) prederror:FALSE$
>
>(C7) [A(z,z),B(z,z),C(z,z),D(z,z),E(z,z)];
>(D7) [EQUAL(z,z),TRUE,TRUE,z = z,TRUE]
>
>(C8) [A(z,z+1),B(z,z+1),C(z,z+1),D(z,z+1),E(z,z+1)];
>(D8) [EQUAL(z,z+1),FALSE,FALSE,z = z+1,FALSE]
>
>(C9) [A(x,y),B(x,y),C(x,y),D(x,y),E(x,y)];
>(D9) [EQUAL(x,y),UNKNOWN,UNKNOWN,x = y,FALSE]
>
>(C10) assume(x>y)$
>(C11) [A(x,y),B(x,y),C(x,y),D(x,y),E(x,y)];
>(D11) [EQUAL(x,y),FALSE,FALSE,x = y,FALSE]
>
>As expected, EQUAL yields a different result than "=".
>What about the other formulations? They're different
>from both EQUAL and "=". Consider:
>
>(C16) map(is,[A(z,z),B(z,z),C(z,z),D(z,z),E(z,z)]);
>(D16) [TRUE,TRUE,TRUE,TRUE,TRUE]
>
>(C17) map(is,[A(z,z+1),B(z,z+1),C(z,z+1),D(z,z+1),E(z,z+1)]);
>(D17) [FALSE,FALSE,FALSE,FALSE,FALSE]
>
>(C19) forget(x>y)$
>(C20) map(is,[A(x,y),B(x,y),C(x,y),D(x,y),E(x,y)]);
>(D20) [UNKNOWN,UNKNOWN,UNKNOWN,FALSE,FALSE]
>
>(C21) assume(x>y)$
>(C22) map(is,[A(x,y),B(x,y),C(x,y),D(x,y),E(x,y)]);
>(D22) [FALSE,FALSE,FALSE,FALSE,FALSE]
>
>When there's a definite answer, all formulations agree.
>Otherwise, there are different answers; B and C act like A,
>and E like D. 
>
>Consider these formulations of sinc:
>
> sinc_FOO_nois(x):=BLOCK(eq:FOO(x,0),
>  IF eq = TRUE THEN 1
>   ELSE (IF eq = FALSE THEN SIN(x)/x
>    ELSE FUNMAKE('sinc_a,[x])))$
>
>and
>
> sinc_FOO(x):=BLOCK(eq:is(FOO(x,0)),
>  IF eq = TRUE THEN 1
>   ELSE (IF eq = FALSE THEN SIN(x)/x
>    ELSE FUNMAKE('sinc_a,[x])))$
>
>with FOO = A, B, C, D, or E. 
>
>PLOT2D(sinc_FOO(u),[u,-10,10])$ works for 
>sinc_A, sinc_B, and sinc_C, but not for the others.
>PLOT2D(sinc_FOO_nois,[u,-10,10])$ works for
>sinc_B_nois and sinc_C_nois, but not for the others.
>
>For what it's worth,
>Robert Dodier
> 
>