Johan Kullstam <········@ne.mediaone.net> writes: > Florian Weimer <··@deneb.enyo.de> writes:
>
> > ·······@pcrm.win.tue.nl () writes:
> >
> > > COBOL has lots of interesting numerical types, such as fixed-precision
> > > decimal numbers. Very useful for counting beans.
> >
> > Well, fixed point decimal numbers are extremely useful, and many
> > people actually need them. Just try to implement the ECB currency
> > conversion guidelines in a language without fixed-point decimal
> > support, and you'll see what I mean.
> >
> > Just my EUR .0000010100011110101110000101000111101011100001...
>
> you can always do fixed point with integers.
Indeed you can, but the advantage of decimal arithmetic is the range
of values is typically greater than that offered by integer
arithmetic (decimal hardware offers varying field length arithmetic
of from 1 to say, 30 digits).
> for example, to do dollars to two decimal places, just count pennies
> instead of dollars.
That typically allows up to $21,474,836.48, which isn't a large amount.
Even less in Lire (L2,147,483,647 -- L1000 = $1 approx)
> other than a little notational convenience, i've never understood what
> the big deal was with fixed point.
>
> --
> J o h a n K u l l s t a m
> [········@ne.mediaone.net]
> sysengr
"robin" <·······@bigpond.nospam.com> wrote in message
··························@newsfeeds.bigpond.com...
> Johan Kullstam <········@ne.mediaone.net> writes: > Florian Weimer
<··@deneb.enyo.de> writes:
> > you can always do fixed point with integers.
>
> Indeed you can, but the advantage of decimal arithmetic is the range
> of values is typically greater than that offered by integer
> arithmetic (decimal hardware offers varying field length arithmetic
> of from 1 to say, 30 digits).
So? So does Lisp.
> > for example, to do dollars to two decimal places, just count pennies
> > instead of dollars.
>
> That typically allows up to $21,474,836.48, which isn't a large amount.
> Even less in Lire (L2,147,483,647 -- L1000 = $1 approx)
Not in Lisp. Arbitrary size integers. Same with Smalltalk.
> > other than a little notational convenience, i've never understood what
> > the big deal was with fixed point.
Me nether, but then (obviously), we use the right languages.
faa
P.S. Any language where you can add two positive numbers together and get a
negative number is inherently broken. It is a sign of the language designer
and compiler writer choosing their own convenience over yours.
> P.S. Any language where you can add two positive numbers together and get a
> negative number is inherently broken. It is a sign of the language designer
> and compiler writer choosing their own convenience over yours.
Since Java was not one of the many newsgroups posted to,
I presume it is not the only language with such a stupid
feature?
--
Wes Groleau
http://freepages.rootsweb.com/~wgroleau
In article <·················@ftw.rsc.raytheon.com>,
Wes Groleau <······@ftw.rsc.raytheon.com> wrote:
>
>> P.S. Any language where you can add two positive numbers together and get a
>> negative number is inherently broken. It is a sign of the language designer
>> and compiler writer choosing their own convenience over yours.
>
>Since Java was not one of the many newsgroups posted to,
>I presume it is not the only language with such a stupid
>feature?
>
It's fairly usual in C. The C standard leaves the case of
arithmetic overflow in signed types undefined, which means
that the result could be negative, imaginary, text, or armed
with thermonuclear weapons for all the standards care.
Most systems I've used it on will wrap around, so that adding
positive numbers and overflowing the limits will give you
a negative number.
Partly the choice of languages depends on such things as
whether you wish to get the right answer almost immediately
or the wrong one with even greater speed. I never want
to have to trust intermediate results not to overflow,
which is one of the many reasons I like Common Lisp (in
which case such overflow yields the right answer at a loss
in speed).
Other interesting behaviors are truncation on the left because
somebody left a 9 off a variable definition in COBOL. I've
seen that cost thousands of dollars (well, to be honest, the
client being billed probably saw it as a savings of thousands
of dollars). I've heard of such behavior in PL/I, a language
I have never had the pleasure of working in.
You can also avoid some floating-point errors in Common Lisp
by using rational numbers instead of floating-point. (/ 1 3)
evaluates to an honest 1/3 rather than a floating-point
approximation. If (+ (/ 1 3) (/1 3) (/1 3)) doesn't yield
1, your CL system has problems. Pity about transcendental
functions that have rational values on only a few points of
their range.
--
David H. Thornley | If you want my opinion, ask.
·····@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
"Frank A. Adrian" <·······@uswest.net> writes:
> P.S. Any language where you can add two positive numbers together and get a
> negative number is inherently broken.
it depends upon what you mean by "number" and what you mean by
"negative". sometimes you really do want to work in the ring
Z_{2^32}. e.g., i often represent angles in terms of 2^32 quanta per
revolution. when the 32 bit "int" wraps, so does the angle --
exactly as intended.
i agree that it is a pain to have no way to use integers Z, but are
forced to choose among Z_{2^N} for a few ill-defined choices of N.
> It is a sign of the language designer and compiler writer choosing
> their own convenience over yours.
--
J o h a n K u l l s t a m
[········@ne.mediaone.net]
Don't Fear the Penguin!
Yes, I was talking about the set of integers. Most languages call the type
something based on the word integer, leading the user to assume that one is,
in fact, working with an element from that set. Although you are correct
that it is sometime desirable to work with elements from alternative sets, I
would also think that this is not the norm and that it would be better to
actually declare the variables whose values are taken from these sets as
such and not simply let the user to stumble upon the fact willy-nilly. One
could also make a case that one should not canonize the size of these
elements, defined by accident of hardware, but instead provide a specific
data-type for any integral sub-ring the user desires. But then, that would
ask the language designers and compiler writers to actually sweat the
details.
Worse is better may be a model of what is, but it doesn't have to be a model
of what will be...
faa
"Johan Kullstam" <········@ne.mediaone.net> wrote in message
···················@euler.axel.nom...
> "Frank A. Adrian" <·······@uswest.net> writes:
>
> > P.S. Any language where you can add two positive numbers together and
get a
> > negative number is inherently broken.
>
> it depends upon what you mean by "number" and what you mean by
> "negative". sometimes you really do want to work in the ring
> Z_{2^32}. e.g., i often represent angles in terms of 2^32 quanta per
> revolution. when the 32 bit "int" wraps, so does the angle --
> exactly as intended.
>
> i agree that it is a pain to have no way to use integers Z, but are
> forced to choose among Z_{2^N} for a few ill-defined choices of N.
>
> > It is a sign of the language designer and compiler writer choosing
> > their own convenience over yours.
>
> --
> J o h a n K u l l s t a m
> [········@ne.mediaone.net]
> Don't Fear the Penguin!
>
[ replying to comp.lang.lisp only
http://world.std.com/~pitman/pfaq/cross-posting.html ]
robin <·······@bigpond.nospam.com> writes:
> Johan Kullstam <········@ne.mediaone.net> writes: > Florian Weimer <··@deneb.enyo.de> writes:
> >
> > > ·······@pcrm.win.tue.nl () writes:
> > >
> > > > COBOL has lots of interesting numerical types, such as fixed-precision
> > > > decimal numbers. Very useful for counting beans.
> > >
> > > Well, fixed point decimal numbers are extremely useful, and many
> > > people actually need them. Just try to implement the ECB currency
> > > conversion guidelines in a language without fixed-point decimal
> > > support, and you'll see what I mean.
> > >
> > > Just my EUR .0000010100011110101110000101000111101011100001...
> >
> > you can always do fixed point with integers.
>
> Indeed you can, but the advantage of decimal arithmetic is the range
> of values is typically greater than that offered by integer
> arithmetic (decimal hardware offers varying field length arithmetic
> of from 1 to say, 30 digits).
But Lisp integers offer an arbitrarily large number of digits. So why
is it an advantage to have only 30 digits? That's a step down, not a
step up.
> > for example, to do dollars to two decimal places, just count pennies
> > instead of dollars.
>
> That typically allows up to $21,474,836.48, which isn't a large amount.
> Even less in Lire (L2,147,483,647 -- L1000 = $1 approx)
Maybe you don't understand that Lisp integers go higher? As high as you
want, actually. Try this in a Lisp listener:
(defun factorial (n) (if (= n 0) 1 (* n (factorial (- n 1)))))
(factorial 100)
=> 93326215443944152681699238856266700490715968264381621468592963895217599993229915608941463976156518286253697920827223758251185210916864000000000000000000000000
You'll run out of stack in some implementations since that definition of factorial is recursive, not iterative, but you generally won't run out of integer precision.
Lisp also has true rational numbers as a datatype, btw. That's quite handy in this context, too.