emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Making 'eq' == 'eql' in bignum branch


From: Alan Mackenzie
Subject: Re: Making 'eq' == 'eql' in bignum branch
Date: Sun, 2 Sep 2018 10:57:55 +0000
User-agent: Mutt/1.10.1 (2018-07-13)

Hello, Davis.

On Sat, Sep 01, 2018 at 01:05:33 +0000, Herring, Davis wrote:
> > +/-infinity are not numbers.  They do not satisfy the axioms which
> > define numbers.  For example they do not satisfy

> >     (x + y) + z = x + (y + z)

> What is the list of such axioms?

Obviously different for different sorts of number.  For the real numbers,
briefly, numbers form a field (loosely speaking, a structure in which one
can do +, -, *, / (except by 0, of course)), they are ordered (loosely
speaking, for any pair of numbers, they are either equal or one is less
than the other, together with axioms for manipulating <), and the
completeness axiom aplies (if a non-empty set of reals is bounded above,
there exists a real number which is a least upper bound).

> If it includes the existence of an additive identity, you lose the
> natural numbers; if it includes the trichotomy property, you lose the
> complex numbers; if it includes commutativity of addition, you lose the
> ordinal numbers.  Of course we can decide that any or all of those
> "aren't really numbers", but why?

Because this is an emacs groups, and we have to use "number" in that
context.  We have integers (of various sorts) and floating point numbers.
I believe SXEmacs has more categories of "number" than Emacs, but I don't
know what (if anything) they get used for.

[ .... ]

> >> They're not real numbers, but neither are complex numbers,
> >> split-complex numbers, dual numbers, p-adic numbers, quaternions,
> >> octonions, sedenions, hyperreal numbers, or (please no) surreal
> >> numbers.

> > That's a strawman.  The issue being discussed here is numbers, not
> > arbitrary algebraic structures.

> Which of those sets aren't sets of numbers?  No one said anything
> about vector spaces, Lie groups, Sobolev spaces, tangent bundles, etc.

See above.

> >> With all due respect to your mathematician friend, ....

> > That is offensive in the extreme.

> I'm sorry, but I don't understand how.  I _meant_ the "due respect"
> that I wrote.  Perhaps I should not presume that any two people are
> friends, but the broad use of that term was meant to be generous, not
> condescending.

"With all due respect, ....., I am ignoring your expert judgment" is how
it came over to me.

> >> .... she has no exclusive claim over the definition (such as it is)
> >> of "number"

> > That's analagous to saying that climate scientists don't have the
> > exclusive say-so about climate change.  Ha ha, who needs experts?

> I don't follow the analogy.  Outside of trivial misconceptions (like
> "weather" vs. "climate"), I don't know of a situation where the
> _definition_ of "climate change" is unclear.

The analogy was about respect and contempt for expertise, not
definitions.

> On the other hand, I don't know of any rigorous definition for "number"
> (thus my request for axioms above).

Note that these two "infinities" are being proposed as members of
(Emacs's) real numbers, so it is reasonable to focus on real numbers.  I
hope my summary of the axioms above has helped.

> > I would have expected, in this mailing list (as contrasted with
> > lesser forums) to see respect for expertise, not disparagement.

> No one is disparaging expertise, certainly not in general.  Experts
> routinely disagree, without any disrespect, about the more
> philosophical topics in their field.  Given (what I consider to be)
> such a weakness of definition, I remain uncertain why a mathematical
> expert would so flatly reject a widely-used category of "number".

I've explained already.  Because extending the real numbers with
"infinity" means they no longer satisfy the field axioms, or the ordering
axioms; they're no longer real numbers.

[ .... ]

> Davis

-- 
Alan Mackenzie (Nuremberg, Germany).



reply via email to

[Prev in Thread] Current Thread [Next in Thread]