Hi Everyone,
I've got a beginner's question about how numeric types are handled.
I'm writing a program that uses Newton's Approximation method to find
the roots of functions
(http://www.sosmath.com/calculus/diff/der07/der07.html if you care that
much), so I'm doing a lot of math with fractions.

Unfortunately, lisp (I've tried clisp 2.33.1 and cmucl 18e) keeps
handling these fractions not as finite-precision floating point numbers
(which I was kinda hoping for), but as unlimited-precision ratios
(seriously huge ones too, with 30+ digits). These huge ratios eat up
all available memory, and cause a crash, so I'd like them to be handled
as finite-precision numbers instead (complex floating point numbers in
particular).

Is there some way that I can force lisp to handle these numbers not at
ratios, but as finite floats (or finite complex floats)?

From:	Trent Buck
Subject:	Re: Type Question
Date:	Tue, 18 Jan 2005 11:02:00 GMT

Up spake Mario S. Mommer:
> > Oh, you want wrong results. Yes, for physics it'd be ok I guess. But
> > for math...
>
> Oh please.

I can't resist.

3 is prime.
5 is prime.
7 is prime.
9 is an experimental error.
11 is prime.
13 is prime.
The data supports the hypothesis.

(What, you want more than the punchline?)

Why does CL parse 0.5 differently to (/ 2)? I would have expected it to
say "Oh yes, that can be expressed exactly as a rational." and require
the user to (more) explicitly coerce it to a float.

--
-trent
Every program has two purposes -- one for which it was written and
another for which it wasn't.

From:	Barry Margolin
Subject:	Re: Type Question
Date:	Tue, 18 Jan 2005 09:03:23 -0500

In article <20050118220224.5cf869f0@harpo.marx>,
Trent Buck wrote:

> Why does CL parse 0.5 differently to (/ 2)? I would have expected it to
> say "Oh yes, that can be expressed exactly as a rational." and require
> the user to (more) explicitly coerce it to a float.

When you type a number as a decimal fraction, you're implying that this
is an approximation that you want represented as a floating point. For
instance, you might do:

(defconstant *pi* 3.14159)

If you want a number you enter to be taken as an exact rational, enter
it as a fraction:

(defconstant *half* 1/2)

So we provide two ways for you to enter numbers, to get two different
results.

(defconstant *about-half* .5)

Why do you think it would be preferable for it to second-guess you?

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

From:	Jens_Axel_Søgaard
Subject:	Re: Type Question
Date:	Tue, 18 Jan 2005 18:07:20 +0100

Barry Margolin wrote:

> (defconstant *pi* 3.14159)

I can't resist:

The primary purpose of the DATA statement is to give
names to constants; instead of referring to pi
as 3.141592653589793 at every appearance, the
variable PI can be given that value with a DATA
statement and used instead of the longer form of the
constant. This also simplifies modifying the program,
should the value of pi change.

-- FORTRAN manual for Xerox Computers

--=20
Jens Axel S=F8gaard

From:	David Steuber
Subject:	Re: Type Question
Date:	18 Jan 2005 18:40:13 -0500

Trent Buck writes:

> Why does CL parse 0.5 differently to (/ 2)? I would have expected it to
> say "Oh yes, that can be expressed exactly as a rational." and require
> the user to (more) explicitly coerce it to a float.

The short version is that the reader should not be changing the type.
0.5 is not the same type as 1/2 any more than 0 and "0" are the same.

--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1

From:	Pascal Bourguignon
Subject:	Re: Type Question
Date:	18 Jan 2005 04:01:53 +0100

"rhat" writes:

> Hi Everyone,
> I've got a beginner's question about how numeric types are handled.
> I'm writing a program that uses Newton's Approximation method to find
> the roots of functions
> (http://www.sosmath.com/calculus/diff/der07/der07.html if you care that
> much), so I'm doing a lot of math with fractions.
>
> Unfortunately, lisp (I've tried clisp 2.33.1 and cmucl 18e) keeps
> handling these fractions not as finite-precision floating point numbers
> (which I was kinda hoping for), but as unlimited-precision ratios
> (seriously huge ones too, with 30+ digits).

30 digits ain't nothing. Lisp can easily handle numbers with 100000
digits, and the limit is really really high.

> These huge ratios eat up all available memory, and cause a crash, so
> I'd like them to be handled as finite-precision numbers instead
> (complex floating point numbers in particular).

Oh, you want wrong results. Yes, for physics it'd be ok I guess. But
for math...

> Is there some way that I can force lisp to handle these numbers not at
> ratios, but as finite floats (or finite complex floats)?

Yes, don't give ratios, give floating point numbers.
Write 0.1 instead of (/ 1 10).
Write (/ x 2.0) instead of (/ x 2).
etc.

--
__Pascal Bourguignon__ http://www.informatimago.com/
Cats meow out of angst
"Thumbs! If only we had thumbs!
We could break so much!"

From:	Rahul Jain
Subject:	Re: Type Question
Date:	Sun, 23 Jan 2005 12:01:40 -0500

Christophe Rhodes writes:

> Rahul Jain writes:
>
>> Cameron MacKinnon writes:
>>
>>> Scheme has an explicit mechanism for tagging numbers as being either
>>> exact or approximations, and numeric contagion when performing
>>> operations works about as one would expect.
>>
>> Good thing CL works the same in these regards.
>
> No it doesn't. In Scheme, inexactitude is mostly orthogonal to
> numeric value representation.

Yes, the CL forces you to assume that inexact rationals (see below about
irrationals) have a denominator which is a power of a specific base. I
suppose having a type where the denominator is of a specific integral
type, e.g. (unsigned-byte 32) would be useful in this regard. Don't know
if it'll really improve performance much.

Maybe you're talking about using expressions similar to '(+ (LOG 15)
(SIN 15)) as numeric values? I'd rather something more powerful like
weyl or maxima for such tasks, but maybe such a library could be
integrated into some implementations...

--
Rahul Jain
rjain@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist

From:	ole.rohne at cern.ch
Subject:	Re: Type Question
Date:	Tue, 18 Jan 2005 17:36:08 +0100

Trent> Why does CL parse 0.5 differently to (/ 2)? I would have
Trent> expected it to say "Oh yes, that can be expressed exactly as a
Trent> rational." and require the user to (more) explicitly coerce it
Trent> to a float.

>> Why would you "expect" that 0.5 and (/ 2) are both "parsed" into a
>> rational? Is there anything in the spec that would indicate such
>> behaviour?

Trent> I was unclear. By "expectation" I meant
Trent> 1) Assume that Lisp has a perfect system.[0]

What do you mean by "perfect", perhaps something like "ideal"? CL is a
very powerful but *practical* system for programming computers. This
has very little to do with *ideal* representations of maths. In maths,
the rational numbers form a subset of the real numbers. In CL (or any
practical programming system), rational numbers are strictly disjoint
from floating point numbers.

Trent> 2) Assume that the formatting of a literal number (e.g. "0.5"
Trent> vs. "1/2") should not affect how it is stored internally
Trent> (after being read in) in an perfect system.

I don't agree that "0.5" and "1/2" are just different formatting of
the same literal number. Maybe so if we were doing maths on a
blackboard, but not when interacting with a computer: "0.5" screams
"floating point", "1/2" will confuse just about everybody except
lispers.

Trent> (Similar to how symbols are not treated any differently if
Trent> they are lowercase, UPPERCASE or MiXeD.)

(I'm sure you know that this isn't really true; the casing behavior of
the CL reader is indeed configurable.)

Trent> Of course, what I'm *really* interested in is whether (2) is
Trent> actually correct, and *why*.

(2) is wrong because CL deals with programming real computers
implemented on actual hardware. Hardware doesn't have "real number
units", but most of them do have "floating point units".

Trent> [0] That's right, it's an ideal system; the Real World can only
Trent> approximate it.

I beg to differ: The real world doesn't approximate anything; it is an
exact representation of itself. Don't think of floating point numbers
as approximations the real numbers; they are exact representations of
a subset of the rational numbers. Ok, sometimes you have to pick the
floating point number that is closest to a real number like PI, but
otherwise everything inside your computer is exact.

Trent> Do you want to go on being pedantic, or would you prefer to
Trent> discuss the question to hand?

Who is pedantic? My rhetoric was perhaps a bit overdone, but the quote
fitted all too well to be missed:-) Seriously, you shouldn't miss the
importance of CL behaving according to a *specification* (as opposed
to the whims of any particular *implementation*, see any of
tcl/perl/python/ruby/guile).

So you knew about the ANSI spec already? I guess I've insulted your
intellect even more now by explaining about FPUs:-)

Ole

From:	ole.rohne at cern.ch
Subject:	Re: Type Question
Date:	Thu, 20 Jan 2005 09:23:25 +0100

googlegroups> The point about (= 0.5 1/2) remains valid, however.

I think (= 0.5 1/2) => T shows that the FP numbers are exact
representations of a subset of the rationals. Try (= 0.2 1/5) => NIL
instead.

Ole

From:	Christophe Rhodes
Subject:	Re: Type Question
Date:	Wed, 19 Jan 2005 21:50:59 +0000

googlegroups@reillyhayes.com writes:

> Unfortunately, this example is not entirely duplicable. In SBCL and
> Lispworks:
>
> (EQL 1 1.0) => T
> (= 1 1.0) => T
> (EQL 0.5 1/2) => NIL
> (= 0.5 1/2) => T

You are either doing something very strange or doing something wrong.
If you can reproduce the first of these results in any Common Lisp
(without any user initialization) I'm sure the respective vendor would
love a bug report.

Christophe

From:	Sam Steingold
Subject:	Re: Type Question
Date:	Tue, 18 Jan 2005 12:12:22 -0500

> * [2005-01-18 17:36:08 +0100]:
>
> Don't think of floating point numbers as approximations the real
> numbers; they are exact representations of a subset of the rational
> numbers.

if this were the case, FP arithmetics would have been exact, which it is not
(cf )

--
Sam Steingold (http://www.podval.org/~sds) running w2k

Yeah, yeah, I love cats too... wanna trade recipes?

From:	Mario S. Mommer
Subject:	Re: Type Question
Date:	Tue, 18 Jan 2005 09:19:51 +0100

Pascal Bourguignon writes:
> "rhat" writes:
>> These huge ratios eat up all available memory, and cause a crash, so
>> I'd like them to be handled as finite-precision numbers instead
>> (complex floating point numbers in particular).
>
> Oh, you want wrong results. Yes, for physics it'd be ok I guess. But
> for math...

Oh please.

>> Is there some way that I can force lisp to handle these numbers not at
>> ratios, but as finite floats (or finite complex floats)?
>
> Yes, don't give ratios, give floating point numbers.
> Write 0.1 instead of (/ 1 10).
> Write (/ x 2.0) instead of (/ x 2).
> etc.

To the OP: 2.0 is usually single precission, while 2.0d0 is double
precission.

Take a look (a look! this is too dry for a beginner, but can give you
some ideas) at

http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/sec_the_numbers_dictionary.html

To ensure some number is coerced to the correct floating point format,
you can use

(float yournumber prototype)

where prototype is some example. So for instance

(float pi 0.0)

gives you a single precission version of Pi, and

(sqrt (float 1/3 0.0d0))

gives you the square root of 0.3333333333333333d0. &.c.

From:	Christophe Rhodes
Subject:	Re: Type Question
Date:	Tue, 18 Jan 2005 22:39:45 +0000

Sam Steingold writes:

>> * [2005-01-18 17:36:08 +0100]:
>>
>> Don't think of floating point numbers as approximations the real
>> numbers; they are exact representations of a subset of the rational
>> numbers.
>
> if this were the case, FP arithmetics would have been exact, which it is not

No, that's not true. They are exact representations of a subset of
the rational numbers; that set is not closed under the action of the
various exact arithmetic operations; the constraint that
x -> where x is an arithmetic operator
implies that some FP arithmetic results will be inexact.

From:	ole.rohne at cern.ch
Subject:	Re: Type Question
Date:	Wed, 19 Jan 2005 11:08:55 +0100

>> Don't think of floating point numbers as approximations the real
>> numbers; they are exact representations of a subset of the rational
>> numbers.

Sam> if this were the case, FP arithmetics would have been exact,
Sam> which it is not

I don't follow your logic here; why does "FP arithmetics would have
been exact" follow from "FP numbers are exact representations of a
subset of the rational numbers"?

On the other hand, if A, B and C=A+B are all rational numbers
supported by the actual FP representation, isn't (= C (+ A B)) true?
I'd admit I haven't thought too hard about the other arithmetic
operations (#'- #'* #'/).

Ole

From:	Sam Steingold
Subject:	Re: Type Question
Date:	Tue, 18 Jan 2005 19:12:41 -0500

> * Christophe Rhodes [2005-01-18 22:39:45 +0000]:
>
> Sam Steingold writes:
>
>>> * [2005-01-18 17:36:08 +0100]:
>>>
>>> Don't think of floating point numbers as approximations the real
>>> numbers; they are exact representations of a subset of the rational
>>> numbers.
>>
>> if this were the case, FP arithmetics would have been exact, which it is not
>
> No, that's not true. They are exact representations of a subset of
> the rational numbers; that set is not closed under the action of the
> various exact arithmetic operations; the constraint that x
> -> where x is an arithmetic operator implies that
> some FP arithmetic results will be inexact.

This means that the model "FP represents a rational" is a bad model -
just what I said.

A much better model is "FP represents a segment on a real line".

--
Sam Steingold (http://www.podval.org/~sds) running w2k

You think Oedipus had a problem -- Adam was Eve's mother.

From:	Christophe Rhodes
Subject:	Re: Type Question
Date:	Wed, 19 Jan 2005 07:13:08 +0000

Sam Steingold writes:

>> * Christophe Rhodes [2005-01-18 22:39:45 +0000]:
>>
>> Sam Steingold writes:
>>
>>> if this were the case, FP arithmetics would have been exact, which it is not
>>
>> No, that's not true. They are exact representations of a subset of
>> the rational numbers; that set is not closed under the action of the
>> various exact arithmetic operations; the constraint that x
>> -> where x is an arithmetic operator implies that
>> some FP arithmetic results will be inexact.
>
> This means that the model "FP represents a rational" is a bad model -
> just what I said.
>
> A much better model is "FP represents a segment on a real line".

I'm not convinced it is much better, because floating point arithmetic
doesn't obey the interval arithmetic rules you'd expect from that
point of view either.

Christophe

From:	Rahul Jain
Subject:	Re: Type Question
Date:	Tue, 18 Jan 2005 23:30:23 -0500

Cameron MacKinnon writes:

> Scheme has an explicit mechanism for tagging numbers as being either
> exact or approximations, and numeric contagion when performing
> operations works about as one would expect.

Good thing CL works the same in these regards.

--
Rahul Jain
rjain@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist

From:	ole.rohne at cern.ch
Subject:	Re: Type Question
Date:	Tue, 18 Jan 2005 13:22:10 +0100

From:	Christophe Rhodes
Subject:	Re: Type Question
Date:	Wed, 19 Jan 2005 07:14:56 +0000

Rahul Jain writes:

> Cameron MacKinnon writes:
>
>> Scheme has an explicit mechanism for tagging numbers as being either
>> exact or approximations, and numeric contagion when performing
>> operations works about as one would expect.
>
> Good thing CL works the same in these regards.

No it doesn't. In Scheme, inexactitude is mostly orthogonal to
numeric value representation.

Christophe

From:	Thomas A. Russ
Subject:	Re: Type Question
Date:	19 Jan 2005 11:19:45 -0800

Cameron MacKinnon writes:

>
> Trent Buck wrote:
> > I was unclear. By "expectation" I meant
> >
> > 1) Assume that Lisp has a perfect system.[0]
> >
> > 2) Assume that the formatting of a literal number (e.g. "0.5"
> > vs. "1/2") should not affect how it is stored internally
> > (after being read in) in an perfect system.
> ...
> > Of course, what I'm *really* interested in is whether (2) is actually
> > correct, and *why*.
>
> (2) is incorrect, because Common Lisp overloads number input
> representation -- 1/2 says "exact", 0.5 says either (depending on whom
> you listen to) "0.5 or a close approximation thereto" or "an interval
> which contains 0.5"
>
> This is, of course, a bad idea. The three proofs are that new users are
> often confused by this behaviour (because it doesn't accord with the
> notation that everyone uses in the real world),

Well, this is true of all programming languages that use floating point
numbers that are backed by a binary representation. For computer
scientists it shows a gap in their education. For those not formally
trained in computer science or programming it is a pitfall.

But it seems that solutions to this will not be all that pretty. The
engineering design decision was to make the input of the numbers easy on
the user and to also make the computation fast. Either of these design
decisions could be done differently, but it isn't clear that people
would on balance be happier with the results:

(1) Make the numeric input be more cumbersome. Force an explicit
notation of the type of number that you want to have and reject input
that doesn't conform to that. Some ideas would be like:
(double-float 0.5)
(rational 0.5)

As a matter of fact, Common Lisp comes pretty close to providing that as
input forms, but for the convenience of users, certain abbreviations are
also allowed. It just happens that you don't like the choice of
semantics chosen by the language designers for those abbreviations. As
far as I can tell, when encountering a floating point number, the
semantics you want to have are something like the following:

(defun return-number (n)
(if (eql (rational n) (rationalize n))
(rational n)
n))

Now, I suppose you could modify the reader to do this for you, but it
seems like it makes things a lot more cumbersome just to handle the
relatively few cases where it would actually come into play. In fact,
the only fractions where this would be true are the ones of the form

m / (2 ^ n)

and as a practical matter, I doubt that many people would choose to use
decimal inputs for values below n/4. Now, it would perhaps be more
useful

(2) Change the floating point representation. Instead of using a
computationally efficient binary representation, the fractions should be
decimal fractions. In that case, the printed representation would be
exact. This alone would do more to "fix" people's trouble with floating
point rounding than just about any other solution. It would have the
benefit of making the surface representation match the internals. I
would also imagine that for most run-of-the-mill computations with
floats that the speed would even be adequate. I'm not talking about
massive simulation runs or other heavy numeric computations. But such
computations are much less common than, say, currency computations.

Actually, that does suggest that using $10.50 or even $3.125 would not
be the worst syntax (although perhaps US-centric) for specifying true
decimal fractions in programming languages.

For true fractions, moreover, using the rational number syntax in common
lisp actually works quite well. Where it breaks down is with improper
fractions, which do not have the nicest representation. Neither of the
following is particularly compact, although the former is a bit clearer:
(+ 100 1/4)
401/4

But if one doesn't adopt a special input syntax for decimal fractions,
it leaves open the question of how one would then specify binary
floating point numbers. Clearly forcing the use of binary would be
impractical, and I'm not really clear about how one would introduce
something like hexadecimal notation for the fractional part of a number.

I suppose that one could adopt the convention that unmodified floating
point numbers are decimal floats and require the use of a marker like
"f", "d", "l" or "s" for binary floats. That would leave "e" available
for scientific notation of decimal floats.

> experienced users
> continue to argue over the approximation/interval interpretations, and
> it causes some people post oddities suggesting that 0.5 and 1/2 aren't
> the same number.

Well, they aren't. One of them is of type FLOAT and the other is of
type RATIONAL.

That isn't meant as a facetious comment. We have to distinguish between
talking about computer representations of numbers and the values of
numbers in the real world. Although there may be a numerical equivalent
in the real world between a number designated as 0.5 and 1/2, they are
very different inside the computer. This is a consequence of having
multiple representations for numbers in computers.

It is also why
(EQL 1 1.0) => NIL
(= 1 1.0) => T
(EQL 0.5 1/2) => NIL
(= 0.5 1/2) => NIL

There is numeric equality between any floating point numbers that happen
to have an exact representation in the binary encoding used for floats
on a particular platform.

--
Thomas A. Russ, USC/Information Sciences Institute

From:	Pascal Bourguignon
Subject:	Re: Type Question
Date:	19 Jan 2005 22:23:55 +0100

tar@sevak.isi.edu (Thomas A. Russ) writes:
> That isn't meant as a facetious comment. We have to distinguish between
> talking about computer representations of numbers and the values of
> numbers in the real world. Although there may be a numerical equivalent
> in the real world between a number designated as 0.5 and 1/2, they are
> very different inside the computer. This is a consequence of having
> multiple representations for numbers in computers.

But still, there is no real number in the real world. Even when you
"compute" Pi to the 10,000,000 decimal, what you get is only a finite
number of atoms representing a rational, not a real.

If you want real numbers, you have to go to maths, ie. symbolic
computing. You can do it in Lisp, but not by typing 3.1141592 or
CL:PI, but by typing stuff like:

(solve (x) (and (< 3 x 4) (= (sin x) 0)))

(limit (p n)
(n integer +infinity)
(system
(= (x 0) (square-root 2))
(= (y 1) (expt 2 1/4))
(= (p 0) (+ 2 (x 0)))
(= (x n) (/ (+ (square-root (x (1- n)))
(/ (square-root (x (1- n))))) 2))
(= (y n) (/ (+ (* (y (1- n)) (square-root (x (1- n))))
(/ (square-root (x (1- n)))))
(1+ (y (1- n)))))
(= (p n) (* (p (1- n)) (/ (1+ (x n)) (1+ (y n)))))))

;; etc.

These symbolic expressions ARE the real Pi.

--
__Pascal Bourguignon__ http://www.informatimago.com/
I need a new toy.
Tail of black dog keeps good time.
Pounce! Good dog! Good dog!

From:	rhat
Subject:	Re: Type Question
Date:	17 Jan 2005 19:55:28 -0800

Wow, thanks, that worked just fine! (now I wonder why I didn't think to
do that =P )

From:	Trent Buck
Subject:	Re: Type Question
Date:	Wed, 19 Jan 2005 09:13:57 GMT

Up spake Cameron MacKinnon:
> Common Lisp overloads number input representation -- 1/2 says
> "exact", 0.5 says either (depending on whom you listen to) "0.5 or a
> close approximation thereto" or "an interval which contains 0.5".
>
> This is, of course, a bad idea. The three proofs are that new users are
> often confused by this behaviour (because it doesn't accord with the
> notation that everyone uses in the real world), experienced users
> continue to argue over the approximation/interval interpretations, and
> it causes some people post oddities suggesting that 0.5 and 1/2 aren't
> the same number.
>
> [...]
>
> Short of having a mind reading parser, it might not be too difficult to
> implement (exactly 0.333) and (approximately 0.333).
>
> Barring that, I doubt that any rational (sorry) users expect 0.333 to be
> promoted to 1/3, because they're NOT equivalent. This is a vastly
> different thing from expecting 0.5 to be equivalent to 1/2, because they
> ARE the same number.

Thanks, this is what I tried to say in the first place. If I'm not the
most communicative of writers, at least I can be understood by those who
are.

--
-trent
A monk asked Tozan when he was weighing some flax: `What is Buddha?'
Tozan said: `This flax weighs three pounds.'

From:	googlegroups at reillyhayes.com
Subject:	Re: Type Question
Date:	19 Jan 2005 13:48:09 -0800

Unfortunately, this example is not entirely duplicable. In SBCL and
Lispworks:

(EQL 1 1.0) => T
(= 1 1.0) => T
(EQL 0.5 1/2) => NIL
(= 0.5 1/2) => T

The surprising one for me was (EQL 1 1.0) => T, which I think is a bug.
If we choose a rational that does not have an exact floating point
representation, the results are more illustrative:

(EQL 0.1 1/10) => NIL
(= 0.5 1/10) => NIL

From:	Jeff
Subject:	Re: Type Question
Date:	Tue, 18 Jan 2005 09:06:06 -0800

On Mon, 17 Jan 2005 18:52:30 -0800, rhat wrote:

>...
> (seriously huge ones too, with 30+ digits). These huge ratios eat up
> all available memory, and cause a crash, so I'd like them to be handled
>...

Does anyone know why using rational numbers would cause his program to
crash? It doesn't seem to me that it would take that much more memory.
Perhaps there is another problem?

-Jeff

From:	Rahul Jain
Subject:	Re: Type Question
Date:	Tue, 18 Jan 2005 23:32:07 -0500

Jeff writes:

> On Mon, 17 Jan 2005 18:52:30 -0800, rhat wrote:
>
>>...
>> (seriously huge ones too, with 30+ digits). These huge ratios eat up
>> all available memory, and cause a crash, so I'd like them to be handled
>>...
>
> Does anyone know why using rational numbers would cause his program to
> crash? It doesn't seem to me that it would take that much more memory.
> Perhaps there is another problem?

If he's actually getting numbers with 2^30 digits, it might crash. He
seems to be trying to do an arbitrarily-long search for a root to some
equation, so he'll keep getting larger denominators with each iteration,
most likely.

--
Rahul Jain
rjain@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist

From:	rhat
Subject:	Re: Type Question
Date:	19 Jan 2005 05:41:39 -0800

Yeah, you got that right: I knew something was a bit off when the
Garbage Collector kicked in ;)

From:	googlegroups at reillyhayes.com
Subject:	Re: Type Question
Date:	20 Jan 2005 17:21:48 -0800

That was exactly my point, if you read my previous message.

From:	Thomas A. Russ
Subject:	Re: Type Question
Date:	18 Jan 2005 17:23:55 -0800

Trent Buck writes:

>
> Up spake ole.rohne@cern.ch:
> > Trent> Why does CL parse 0.5 differently to (/ 2)? I would have
> > Trent> expected it to say "Oh yes, that can be expressed exactly as a
> > Trent> rational." and require the user to (more) explicitly coerce it
> > Trent> to a float.

> 2) Assume that the formatting of a literal number (e.g. "0.5"
> vs. "1/2") should not affect how it is stored internally
> (after being read in) in an perfect system.
>
> (Similar to how symbols are not treated any differently if
> they are lowercase, UPPERCASE or MiXeD.)

And what would you have the system do with "0.333"

Would you want it to guess that this is supposed to be an extremely lazy
way of saying 1/3 or an exact way of saying 333/1000 ? Short of having
a mind reading parser, it would be rather difficult to get Lisp, clever
though it is, to figure out what you meant, since any finite decimal
fraction has an exact representation as a rational number.

--
Thomas A. Russ, USC/Information Sciences Institute

From:	Cameron MacKinnon
Subject:	Re: Type Question
Date:	Tue, 18 Jan 2005 22:40:14 -0500

Thomas A. Russ wrote:
> Trent Buck writes:
>
>
>> 2) Assume that the formatting of a literal number (e.g. "0.5"
>> vs. "1/2") should not affect how it is stored internally
>> (after being read in) in an perfect system.

> And what would you have the system do with "0.333"
>
> Would you want it to guess that this is supposed to be an extremely lazy
> way of saying 1/3 or an exact way of saying 333/1000 ? Short of having
> a mind reading parser, it would be rather difficult to get Lisp, clever
> though it is, to figure out what you meant, since any finite decimal
> fraction has an exact representation as a rational number.

Short of having a mind reading parser, it might not be too difficult to
implement (exactly 0.333) and (approximately 0.333).

Barring that, I doubt that any rational (sorry) users expect 0.333 to be
promoted to 333/1000, because they're NOT equivalent. This is a vastly
different thing from expecting 0.5 to be equivalent to 1/2, because they
ARE the same number.

From:	Cameron MacKinnon
Subject:	Re: Type Question
Date:	Tue, 18 Jan 2005 22:46:11 -0500

Cameron MacKinnon wrote:
> Barring that, I doubt that any rational (sorry) users expect 0.333 to be
> promoted to 333/1000, because they're NOT equivalent.

Umm... "to be promoted to 1/3" - but everyone figured that out from
context, right?

From:	Trent Buck
Subject:	Re: Type Question
Date:	Tue, 18 Jan 2005 13:22:55 GMT

Up spake ole.rohne@cern.ch:
> Trent> Why does CL parse 0.5 differently to (/ 2)? I would have
> Trent> expected it to say "Oh yes, that can be expressed exactly as a
> Trent> rational." and require the user to (more) explicitly coerce it
> Trent> to a float.
>
> Why would you "expect" that 0.5 and (/ 2) are both "parsed" into a
> rational? Is there anything in the spec that would indicate such
> behaviour?

I was unclear. By "expectation" I meant

1) Assume that Lisp has a perfect system.[0]

2) Assume that the formatting of a literal number (e.g. "0.5"
vs. "1/2") should not affect how it is stored internally
(after being read in) in an perfect system.

(Similar to how symbols are not treated any differently if
they are lowercase, UPPERCASE or MiXeD.)

1 AND 2 IMPLIES 3

3) Lisp does not care if you write "0.5" or "1/2" -- it will use
the most accurate, reasonable form. You can use the operator
FOO to redefine what is `resonable', or BAR to force a
particular literal to be stored in a particular way.

Of course, what I'm *really* interested in is whether (2) is actually
correct, and *why*.

[0] That's right, it's an ideal system; the Real World can only
approximate it. Do you want to go on being pedantic, or would you
prefer to discuss the question to hand?

--
-trent
For is it not written, wheresoever two or three are gathered together,
yea they will perform the Parrot Sketch. -- Rob

From:	Pascal Bourguignon
Subject:	Re: Type Question
Date:	18 Jan 2005 15:26:11 +0100

Trent Buck writes:

> Up spake ole.rohne@cern.ch:
> > Trent> Why does CL parse 0.5 differently to (/ 2)? I would have
> > Trent> expected it to say "Oh yes, that can be expressed exactly as a
> > Trent> rational." and require the user to (more) explicitly coerce it
> > Trent> to a float.
> >
> > Why would you "expect" that 0.5 and (/ 2) are both "parsed" into a
> > rational? Is there anything in the spec that would indicate such
> > behaviour?
>
> I was unclear. By "expectation" I meant
>
> 1) Assume that Lisp has a perfect system.[0]

Lisp perhaps has it. But Common-Lisp is a practical lisp, which
specifies stuff to give efficient implementations, not perfect ones.

--
__Pascal Bourguignon__ http://www.informatimago.com/
You never feed me.
Perhaps I'll sleep on your face.
That will sure show you.

From:	Cameron MacKinnon
Subject:	Re: Type Question
Date:	Tue, 18 Jan 2005 22:33:31 -0500

Trent Buck wrote:
> I was unclear. By "expectation" I meant
>
> 1) Assume that Lisp has a perfect system.[0]
>
> 2) Assume that the formatting of a literal number (e.g. "0.5"
> vs. "1/2") should not affect how it is stored internally
> (after being read in) in an perfect system.
....
> Of course, what I'm *really* interested in is whether (2) is actually
> correct, and *why*.

(2) is incorrect, because Common Lisp overloads number input
representation -- 1/2 says "exact", 0.5 says either (depending on whom
you listen to) "0.5 or a close approximation thereto" or "an interval
which contains 0.5"

This is, of course, a bad idea. The three proofs are that new users are
often confused by this behaviour (because it doesn't accord with the
notation that everyone uses in the real world), experienced users
continue to argue over the approximation/interval interpretations, and
it causes some people post oddities suggesting that 0.5 and 1/2 aren't
the same number.

Scheme has an explicit mechanism for tagging numbers as being either
exact or approximations, and numeric contagion when performing
operations works about as one would expect.

Be that as it may, Common Lisp's interpretation of numbers (according to
how they are written) is not open to interpretation -- it is written in
to the standard.

From:	Jens_Axel_Søgaard
Subject:	Re: Type Question
Date:	Wed, 19 Jan 2005 08:26:41 +0100

Cameron MacKinnon wrote:

> Scheme has an explicit mechanism for tagging numbers as being either=20
> exact or approximations, and numeric contagion when performing=20
> operations works about as one would expect.

Not everybody thinks Scheme has found the ideal solution.
See "Cleaning up the Tower: Numbers in Scheme"

--=20
Jens Axel S=F8gaard

From:	Cameron MacKinnon
Subject:	Re: Type Question
Date:	Wed, 19 Jan 2005 04:39:35 -0500

Jens Axel Søgaard wrote:
> Cameron MacKinnon wrote:
>
>> Scheme has an explicit mechanism for tagging numbers as being either
>> exact or approximations, and numeric contagion when performing
>> operations works about as one would expect.
>
>
> Not everybody thinks Scheme has found the ideal solution.
> See "Cleaning up the Tower: Numbers in Scheme"
>
>
>

Thanks, that was good food for thought.

From:	Thomas A. Russ
Subject:	Re: Type Question
Date:	18 Jan 2005 17:20:37 -0800

Trent Buck writes:

> 2) Assume that the formatting of a literal number (e.g. "0.5"
> vs. "1/2") should not affect how it is stored internally
> (after being read in) in an perfect system.
>
> (Similar to how symbols are not treated any differently if
> they are lowercase, UPPERCASE or MiXeD.)

But would you also expect that the internal representation of "2" and
"2.0" would be the same? Or would you expect that

(type-of 2) => FIXNUM
(type-of 2.0) => FLOAT

--
Thomas A. Russ, USC/Information Sciences Institute

From:	Paul F. Dietz
Subject:	Re: Type Question
Date:	Tue, 18 Jan 2005 19:53:24 -0600

Thomas A. Russ wrote:

> Or would you expect that
>
> (type-of 2) => FIXNUM

Not in Common Lisp! :)

Paul

From:	googlegroups at reillyhayes.com
Subject:	Re: Type Question
Date:	19 Jan 2005 23:39:01 -0800

Crap. Brain damage. Too much time using OCAML lately. I forgot to
include the trailing zero behind the "1.".
The point about (= 0.5 1/2) remains valid, however.

reilly