[sympy] nan**0 == 1**nan == 1?

2012-02-21 Thread smichr
Ronan cites IEEE 754 as specifying that powers nan**0 and 1**nan both be 1. I would suggest that for SymPy we should return NaN for both cases. Other ideas? -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@goog

Re: [sympy] nan**0 == 1**nan == 1?

2012-02-21 Thread Chris Smith
Quoting wikipedia's article on NaN: The 2008 version of the IEEE 754 standard says that pow(1,qNaN) and pow(qNaN,0) should both return 1 since they return 1 whatever else is used instead of quiet NaN. To satisfy those wishing a more strict interpretation of

Re: [sympy] nan**0 == 1**nan == 1?

2012-02-21 Thread Aaron Meurer
Just follow the built-in float('nan'): In [594]: float('nan')**0 Out[594]: 1.0 In [595]: 1**float('nan') Out[595]: 1.0 Aaron Meurer On Tue, Feb 21, 2012 at 7:58 PM, Chris Smith wrote: > Quoting wikipedia's article on NaN: > > The 2008 version of the IEEE 754 standard says > that pow(1,qNaN) an

Re: [sympy] nan**0 == 1**nan == 1?

2012-02-22 Thread Joachim Durchholz
Am 22.02.2012 03:34, schrieb smichr: Ronan cites IEEE 754 as specifying that powers nan**0 and 1**nan both be 1. I would suggest that for SymPy we should return NaN for both cases. Other ideas? I'm not sure that IEEE is a good source for SymPy. IEEE's primary focus is numerics, SymPy is about

Re: [sympy] nan**0 == 1**nan == 1?

2012-02-22 Thread Chris Smith
> > I'm not sure that IEEE is a good source for SymPy. IEEE's primary focus is > numerics, SymPy is about symbolics. > So while IEEE is definitely a good source of hints, we should check > whether the reasoning behind each still holds in a symbolic context. > > This is one of those borderline cases

Re: [sympy] nan**0 == 1**nan == 1?

2012-02-25 Thread Aaron Meurer
No, but Python is a good source, as the project goal is to build on top of it using the same rules. So if a Python built-in equivalent exhibits some behavior, we should emulate it (except in the cases where we try to do better, like arbitrary precision vs. machine precision). And anyway, Python f