Turn off ZeroDivisionError?

[Grant Edwards]

Re: Turn off ZeroDivisionErr or?

On 2008-02-15, Mark Dickinson <dickinsm@gmail .comwrote:

On Feb 15, 1:38 pm, Grant Edwards <gra...@visi.co mwrote:

>On 2008-02-15, Mark Dickinson <dicki...@gmail .comwrote:
>>

>If you're doing such serious number-crunching that you really
>want to handle NANs, you're probably not writing in Python
>anyway.

>
Some dodgy quoting here: that wasn't me!

Yup. That's indicated by the xtra level of ">". Sorry if that
mislead anybody -- I accidentally deleted the nested attribute
line when I was trimming things.

>I disagree completely. I do a lot of number crunching in
>Python where I want IEEE NaN and Inf behavior. Speed is a
>completely orthogonal issue.

>
Exactly.

--
Grant Edwards grante Yow! I know how to do
at SPECIAL EFFECTS!!
visi.com

[Steve Holden]

Re: Turn off ZeroDivisionErr or?

Mark Dickinson wrote:

On Feb 14, 11:09 pm, John Nagle <na...@animats. comwrote:

> You also need to think about how conditionals interact with
>quiet NANs. Properly, comparisons like ">" have three possibilities:

>
True. There was a recent change to Decimal to make comparisons (other
than !=, ==) with NaNs do the "right thing": that is, raise a Python
exception, unless the Invalid flag is not trapped, in which case they
return False (and also raise the Invalid flag). I imagine something
similar would make sense for floats.
>

>True, False, and "raise". Many implementations don't do that well,
>which means that you lose trichotomy. "==" has issues; properly,
>"+INF" is not equal to itself.

>
I don't understand: why would +INF not be equal to itself? Having
INF == INF be True seems like something that makes sense both
mathematically and computationally .
[...]

There are an uncountable number of infinities, all different.

regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/

[Jeff Schwab]

Re: Turn off ZeroDivisionErr or?

Steve Holden wrote:

Mark Dickinson wrote:

>On Feb 14, 11:09 pm, John Nagle <na...@animats. comwrote:

>> You also need to think about how conditionals interact with
>>quiet NANs. Properly, comparisons like ">" have three possibilities:

>>
>True. There was a recent change to Decimal to make comparisons (other
>than !=, ==) with NaNs do the "right thing": that is, raise a Python
>exception, unless the Invalid flag is not trapped, in which case they
>return False (and also raise the Invalid flag). I imagine something
>similar would make sense for floats.
>>

>>True, False, and "raise". Many implementations don't do that well,
>>which means that you lose trichotomy. "==" has issues; properly,
>>"+INF" is not equal to itself.

>>
>I don't understand: why would +INF not be equal to itself? Having
>INF == INF be True seems like something that makes sense both
>mathematical ly and computationally .
> [...]

>
There are an uncountable number of infinities, all different.

+ALEPH0?

[Carl Banks]

Re: Turn off ZeroDivisionErr or?

On Feb 14, 11:09 pm, John Nagle <na...@animats. comwrote:

You also need to think about how conditionals interact with
quiet NANs. Properly, comparisons like ">" have three possibilities:
True, False, and "raise". Many implementations don't do that well,
which means that you lose trichotomy. "==" has issues; properly,
"+INF" is not equal to itself.

I'm pretty sure it is. It certainly is on my machine at the moment:

>>float(3e300*3 e300) == float(2e300*4e3 00)

True

Are you confusing INF with NAN, which is specified to be not equal to
itself (and, IIRC, is the only thing specified to be not equal to
itself, such that one way to test for NAN is x!=x).

For Python, I'd suggest throwing a Python exception on all errors
recognized by the FPU, except maybe underflow. If you're doing
such serious number-crunching that you really want to handle NANs,
you're probably not writing in Python anyway.

Even if that were entirely true, there are cases where (for example)
you're using Python to glue together numerical routines in C, but you
need to do some preliminary calculations in Python (where there's no
edit/compile/run cycle but there is slicing and array ops), but want
the same floating point behavior.

IEEE conformance is not an unreasonable thing to ask for, and "you
should be using something else" isn't a good answer to "why not?".


Carl Banks

[Mark Dickinson]

Re: Turn off ZeroDivisionErr or?

On Feb 15, 2:35 pm, Steve Holden <st...@holdenwe b.comwrote:

There are an uncountable number of infinities, all different.

If you're talking about infinite cardinals or ordinals in set theory,
then yes. But that hardly seems relevant to using floating-point as a
model for the doubly extended real line, which has exactly two
infinities.

Mark

[Steve Holden]

Re: Turn off ZeroDivisionErr or?

Mark Dickinson wrote:

On Feb 15, 2:35 pm, Steve Holden <st...@holdenwe b.comwrote:

>There are an uncountable number of infinities, all different.

>
If you're talking about infinite cardinals or ordinals in set theory,
then yes. But that hardly seems relevant to using floating-point as a
model for the doubly extended real line, which has exactly two
infinities.
>

True enough, but aren't they of indeterminate magnitude? Since infinity
== infinity + delta for any delta, comparison for equality seems a
little specious.

regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/

[Mark Dickinson]

Re: Turn off ZeroDivisionErr or?

On Feb 15, 5:27 pm, Steve Holden <st...@holdenwe b.comwrote:

True enough, but aren't they of indeterminate magnitude? Since infinity
== infinity + delta for any delta, comparison for equality seems a
little specious.

The equality is okay; it's when you start trying to apply arithmetic
laws like

a+c == b+c implies a == b

that you get into trouble. In other words, the doubly-extended real
line is a perfectly well-defined and well-behaved *set*, and even a
nice (compact) topological space with the usual topology. It's just
not a field, or a group under addition, or ...

Mark

[Steven D'Aprano]

Re: Turn off ZeroDivisionErr or?

On Thu, 14 Feb 2008 20:09:38 -0800, John Nagle wrote:

For Python, I'd suggest throwing a Python exception on all errors
recognized by the FPU, except maybe underflow. If you're doing such
serious number-crunching that you really want to handle NANs, you're
probably not writing in Python anyway.

Chicken, egg.

The reason people aren't writing in Python is because Python doesn't
support NANs, and the reason Python doesn't support NANs is because the
people who want support for NANs aren't using Python.

Oh, also because it's hard to do it in a portable fashion. But maybe
Python doesn't need to get full platform independence all in one go?

# pseudo-code
if sys.platform == "whatever"
float = IEEE_float
else:
warnings.warn(" no support for NANs, beware of exceptions")


There are use-cases for NANs that don't imply the need for full C speed.
Number-crunching doesn't necessarily imply that you need to crunch
billions of numbers in the minimum time possible. Being able to do that
sort of "crunch-lite" in Python would be great.



--
Steven

[Steven D'Aprano]

Re: Turn off ZeroDivisionErr or?

On Fri, 15 Feb 2008 14:35:34 -0500, Steve Holden wrote:

>I don't understand: why would +INF not be equal to itself? Having INF
>== INF be True seems like something that makes sense both
>mathematical ly and computationally .
> [...]

>
There are an uncountable number of infinities, all different.

But the IEEE standard only supports one of them, aleph(0).

Technically two: plus and minus aleph(0).



--
Steven

[Mark Dickinson]

Re: Turn off ZeroDivisionErr or?

On Feb 15, 7:59 pm, Steven D'Aprano <st...@REMOVE-THIS-
cybersource.com .auwrote:

On Fri, 15 Feb 2008 14:35:34 -0500, Steve Holden wrote:

I don't understand: why would +INF not be equal to itself? Having INF
== INF be True seems like something that makes sense both
mathematically and computationally .
[...]

>

There are an uncountable number of infinities, all different.

>
But the IEEE standard only supports one of them, aleph(0).
>
Technically two: plus and minus aleph(0).

Not sure that alephs have anything to do with it. And unless I'm
missing something, minus aleph(0) is nonsense. (How do you define the
negation of a cardinal?)

From the fount of all wisdom: (http://en.wikipedia.org/wiki/
Aleph_number)

"""The aleph numbers differ from the infinity ($B!g(B) commonly found in
algebra and calculus. Alephs measure the sizes of sets; infinity, on
the other hand, is commonly defined as an extreme limit of the real
number line (applied to a function or sequence that "diverges to
infinity" or "increases without bound"), or an extreme point of the
extended real number line. While some alephs are larger than others, $B!g(B
is just $B!g(B."""

Mark

[Jeff Schwab]

Re: Turn off ZeroDivisionErr or?

Paul Rubin wrote:

Mark Dickinson <dickinsm@gmail .comwrites:

>>But the IEEE standard only supports one of them, aleph(0).
>>Technically two: plus and minus aleph(0).

>Not sure that alephs have anything to do with it.

>
They really do not. The extended real line can be modelled in set
theory, but the "infinity" in it is not a cardinal as we would
normally treat them in set theory.

Georg Cantor disagrees. Whether Aleph 1 is the cardinality of the set
of real numbers is provably undecidable.

http://mathworld.wolfram.com/ContinuumHypothesis.html

[Paul Rubin]

Re: Turn off ZeroDivisionErr or?

Jeff Schwab <jeff@schwabcen ter.comwrites:

They really do not. The extended real line can be modelled in set
theory, but the "infinity" in it is not a cardinal as we would
normally treat them in set theory.

>
Georg Cantor disagrees. Whether Aleph 1 is the cardinality of the set
of real numbers is provably undecidable.

You misunderstand, the element called "infinity" in the extended real
line has nothing to do with the cardinality of the reals, or of
infinite cardinals as treated in set theory. It's just an element of
a structure that can be described in elementary terms or can be viewed
as sitting inside of the universe of sets described by set theory.
See:

http://en.wikipedia.org/wiki/Point_at_infinity

Aleph 1 didn't come up in the discussion earlier either. FWIW, it's
known (provable from the ZFC axioms) that the cardinality of the reals
is an aleph; ZFC just doesn't determine which particular aleph it is.
The Wikipedia article about CH is also pretty good:

http://en.wikipedia.org/wiki/Continuum_hypothesis

the guy who proved CH is independent also expressed a belief that it
is actually false.

[Steven D'Aprano]

Re: Turn off ZeroDivisionErr or?

On Fri, 15 Feb 2008 17:31:51 -0800, Mark Dickinson wrote:

On Feb 15, 7:59 pm, Steven D'Aprano <st...@REMOVE-THIS-
cybersource.com .auwrote:

>On Fri, 15 Feb 2008 14:35:34 -0500, Steve Holden wrote:

>I don't understand: why would +INF not be equal to itself? Having
>INF == INF be True seems like something that makes sense both
>mathematical ly and computationally .
> [...]

>>

There are an uncountable number of infinities, all different.

>>
>But the IEEE standard only supports one of them, aleph(0).
>>
>Technically two: plus and minus aleph(0).

>
Not sure that alephs have anything to do with it. And unless I'm
missing something, minus aleph(0) is nonsense. (How do you define the
negation of a cardinal?)

*shrug* How would you like to?

The natural numbers (0, 1, 2, 3, ...) are cardinal numbers too. 0 is the
cardinality of the empty set {}; 1 is the cardinality of the set
containing only the empty set {{}}; 2 is the cardinality of the set
containing a set of cardinality 0 and a set of cardinality 1 {{}, {{}}}
.... and so on.

Since we have generalized the natural numbers to the integers

.... -3 -2 -1 0 1 2 3 ...

without worrying about what set has cardinality -1, I see no reason why
we shouldn't generalize negation to the alephs. The question of what set,
if any, has cardinality -aleph(0) is irrelevant. Since the traditional
infinity of the real number line comes in a positive and negative
version, and we identify positive ∞ as aleph(0) [see below for why], I
don't believe there's any thing wrong with identifying -aleph(0) as -∞.

Another approach might be to treat the cardinals as ordinals. Subtraction
isn't directly defined for ordinals, ordinals explicitly start counting
at zero and only increase, never decrease. But one might argue that since
all ordinals are surreal numbers, and subtraction *is* defined for
surreals, we might identify aleph(0) as the ordinal omega ω then the
negative of aleph(0) is just -ω, or {|{ ... -4, -3, -2, -1 }}. Or in
English... -aleph(0) is the number more negative than every negative
integer, which gratifyingly matches our intuition about negative infinity.

There's lots of hand-waving there. I expect a real mathematician could
make it all vigorous. But a lot of it is really missing the point, which
is that the IEEE standard isn't about ordinals, or cardinals, or surreal
numbers, but about floating point numbers as a discrete approximation to
the reals. In the reals, there are only two infinities that we care
about, a positive and negative, and apart from the sign they are
equivalent to aleph(0).

From the fount of all wisdom: (http://en.wikipedia.org/wiki/
Aleph_number)
>
"""The aleph numbers differ from the infinity (∞) commonly found in
algebra and calculus. Alephs measure the sizes of sets; infinity, on the
other hand, is commonly defined as an extreme limit of the real number
line (applied to a function or sequence that "diverges to infinity" or
"increases without bound"), or an extreme point of the extended real
number line. While some alephs are larger than others, ∞ is just ∞."""

That's a very informal definition of infinity. Taken literally, it's also
nonsense, since the real number line has no limit, so talking about the
limit of something with no limit is meaningless. So we have to take it
loosely.

In fact, it isn't true that "∞ is just ∞" even in the two examples they
discuss. There are TWO extended real number lines: the projectively
extended real numbers, and the affinely extended real numbers. In the
projective extension to the reals, there is only one ∞ and it is
unsigned. In the affine extension, there are +∞ and -∞.

If you identify ∞ as "the number of natural numbers", that is, the number
of numbers in the sequence 0, 1, 2, 3, 4, ... then that's precisely what
aleph(0) is. If there's a limit to the real number line in any sense at
all, it is the same limit as for the integers (since the integers go all
the way to the end of the real number line).

(But note that there are more reals between 0 and ∞ than there are
integers, even though both go to the same limit: the reals are more
densely packed.)



--
Steven

[Mark Dickinson]

Re: Turn off ZeroDivisionErr or?

On Feb 16, 7:08 pm, Steven D'Aprano <st...@REMOVE-THIS-
cybersource.com .auwrote:

On Fri, 15 Feb 2008 17:31:51 -0800, Mark Dickinson wrote:

Not sure that alephs have anything to do with it.  And unless I'm
missing something, minus aleph(0) is nonsense. (How do you define the
negation of a cardinal?)

>
*shrug* How would you like to?

Since we have generalized the natural numbers to the integers
>
... -3 -2 -1 0 1 2 3 ...
>
without worrying about what set has cardinality -1, I see no reason why
we shouldn't generalize negation to the alephs.

The reason is that it doesn't give a useful result. There's a natural
process for turning a commutative monoid into a group (it's the
adjoint to the forgetful functor from groups to commutative monoids).
Apply it to the "set of cardinals", leaving aside the set-theoretic
difficulties with the idea of the "set of cardinals" in the first
place, and you get the trivial group.

There's lots of hand-waving there. I expect a real mathematician could
make it all vigorous.

Rigorous? Yes, I expect I could.

And surreal numbers are something entirely different again.

That's a very informal definition of infinity. Taken literally, it's also
nonsense, since the real number line has no limit, so talking about the
limit of something with no limit is meaningless. So we have to take it
loosely.

The real line, considered as a topological space, has limit points.
Two of them.

Mark

[Mark Dickinson]

Re: Turn off ZeroDivisionErr or?

On Feb 16, 7:30 pm, Mark Dickinson <dicki...@gmail .comwrote:

The real line, considered as a topological space, has limit points.
Two of them.

Ignore that. It was nonsense. A better statement: the completion (in
the sense of lattices) of the real numbers is (isomorphic to) the
doubly-extended real line. It's in this sense that +infinity and -
infinity can be considered limits.

I've no clue where your (Steven's) idea that 'all ordinals are surreal
numbers' came from. They're totally unrelated.

Sorry. I haven't had any dinner. I get tetchy when I haven't had any
dinner.

Usenet'ly yours,

Mark