Re: +-Inf and NaN

Hi Camm:

I haven't had a chance to fully ponder the detailed recommendations that you've
made.

So I'd like to simply pop up a level and plea for some degree of 'rationality', i.e.,
there are standard algebraic structures that have stood the test of time:

0.  Functions; domains, ranges. Restrictions.  1-1 functions.  Homomorphisms.
1.  Equivalence relations: a=a, a=b => b=a, a=b and b=c => a=c.
2.  Partial orders.
3.  Total orders x>y or x<y or x=y; there are no unordered options.
4.  Lattices -- e.g., subsets, gcd, lcm.
5.  semigroups with or without identities.
6.  groups.
7.  commutative groups.
8.  rings, both commutative and non-commutative.
9.  fields.
10.  vector spaces.
11.  matrices over rings and fields.
12,  direct products, direct sums.
etc.

If the computer implementations of these structures are faithful, then
their (sometimes deep) algebraic properties become the sources for
compiler optimizations.

Note on 'range' arithmetic:

I've done a fair amount of playing around with various types of
'range arithmetic', and have significant problems with all of them.

The 'standard' ranges -- e.g., [a,b], [a,b), (a,b], (a,b) don't do well
when multiplication/division comes in.  Division is particularly
problematic due to having 'holes' in the ranges.

For many numerical problems, I find Henrici's 'circular arithmetic'
to be more elegant, where 'ranges' are really *circles* in the complex
plane, and the 'range' is either *inside* the circle or *outside* the
circle.

https://link.springer.com/article/10.1007/BF01404681

The nice thing about 'circular arithmetic' is that 1/x maps circles
to circles -- more generally -- (ax+b)/(cx+d) maps circles to
circles -- although the circle *centers* do not map to one another.
If this looks to you remarkably like continued fractions, you
wouldn't be wrong.

-----Original Message-----
From: Camm Maguire <[email protected]>
Sent: Feb 26, 2024 6:42 AM
To: Henry Baker <[email protected]>, <[email protected]>
Cc: Raymond Toy <[email protected]>, Stavros Macrakis <[email protected]>, <[email protected]>, Richard Fateman <[email protected]>, Robert Dodier <[email protected]>, <[email protected]>
Subject: Re: [Maxima-discuss] +-Inf and NaN

Greetings!

Henry Baker writes:

> Re:
>
> Lisp arithmetic should be compatible with IEEE float arithmeticFor
> various interpretations of 'float' and/or 'arithmetic' ?There was a
> reason why Maclisp used a separate function namefor float arithmetic
> functions, and it wasn't just to speedup float arithmetic.

> The real reason is that *floats don't adhere to standard algebraic
> axioms*.

> 1. Float addition isn't associative.

> 2. Float addition isn't necessarily commutative -- e.g., when
> utilizing accumulation HW.

Oof.... I had no idea this was so bad. I don't see how we can reason
about real numbers without relying on their constituting a field.

I'd be particularly interested in your opinion on the two alternatives I
set out in separate email, given how I've based GCL's type system on
your paper :-)

Take care,
--
Camm Maguire [email protected]
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah