Adding new object types WAS: Operations on inf

Stavros, unfortunately I am rather uneasy with this proposal on the whole.

> For objects with number-like behavior, I believe the easiest way
> we can do this is to piggyback on the existing bfloat code.

Well, what is it about the bigfloat simplification dispatch that makes
it fast enough to be practical? That is the aspect of bigfloats that
I think we need to copy for other number-like objects.

> Let's use ((bigfloat simp interval) ...), ((bigfloat simp quadfloat) ...)
> etc. to represent new data types.

I dunno. This makes me very uneasy. I don't like objects which
aren't really bigfloats masquerading as such. At present we have
(MLIST CF) for continued fractions, which was a very weak choice,
frankly. I don't want new objects like that.

> This seems to me by far the simplest way of handling extensions
> like the ones you're talking about.  What is unavoidable, though,
> is going through the code to remove incorrect assumptions, such
> as trichotomy (compare the interval [2,5] with [3,4] or [1,3]) and
> realness (currently, all things that Maxima considers to be "numbers"
> are real).

I don't think it's much of win to reuse some of the identities now
applied to bigfloats for other number-like objects. It's much more
important to be able to distinguish the identities applied to each
type of object. One of Maxima's biggest problems at present
(IMNSHO) is that it is more or less impossible to know what are the
identities which Maxima applies to a given kind of expression.
I don't want to make the problem any worse than it is.

> This technique could be applied to Gaussian integers, bfloat
> complexes, float intervals, even distributions (with various rules
> of combination) etc. etc.

I agree that Maxima should be able to handle all of these,
but not by the method mentioned above.

FWIW
Robert