very large reals?
Deepak Goel
While (Expt 100 100) is okay with CL, why deosn't (expt 100.0 100.0)
return something useful?
why can't the exponent-parts of the reals be allowed to be as high as
it gets?
It's like: CL frees you from upper limits on numbers (as compared to,
say C) when dealing with integers but not when dealing with reals..
or did i miss something obvious? or is there a package or some other
way that allows the exponent-part to get as large as it wants to ?
Deepak <http://www.glue.umd.edu/~deego>
--
Got root beer?
Kent M Pitman
> While (Expt 100 100) is okay with CL, why deosn't (expt 100.0 100.0)
> return something useful?
>
> why can't the exponent-parts of the reals be allowed to be as high as
> it gets?
>
> It's like: CL frees you from upper limits on numbers (as compared to,
> say C) when dealing with integers but not when dealing with reals..
>
> or did i miss something obvious? or is there a package or some other
> way that allows the exponent-part to get as large as it wants to ?
If you want infinite precision, use rationals.
Floats are really not reals and you do yourself a serious misservice
by modeling them that way. They are just rational approximations to
reals with a very strange-shaped precision space that it's not clear
you want in the larger arena. The primary function of floats is to
allow access to specific machine operations; once those machine
operations don't make sense, the purpose of the datatype is
substantially impaired.
Deepak Goel
> Deepak Goel <de...@glue.umd.edu> writes:
>
> > While (Expt 100 100) is okay with CL, why deosn't (expt 100.0 100.0)
> > return something useful?
> >
> > why can't the exponent-parts of the reals be allowed to be as high as
> > it gets?
> >
> > It's like: CL frees you from upper limits on numbers (as compared to,
> > say C) when dealing with integers but not when dealing with reals..
> >
> > or did i miss something obvious? or is there a package or some other
> > way that allows the exponent-part to get as large as it wants to ?
>
> If you want infinite precision, use rationals.
Kent
thanks for replying..
i was not talking of infinite precision, but of allowing the numbers
to get infinitely big.. i thought i made that pretty clear above by
repeatedly referrinmg to the 'exponent' part of a 'real' rather than
the 'mantissa' part..
>
> Floats are really not reals and you do yourself a serious misservice
> by modeling them that way. They are just rational approximations to
> reals
yes i am aware of that, but thanks for pointing that out anyways..
Deepak Goel
To clarify with an example, lisp will tell me (expt 100 100), and
(expt 101 100) but
what if i want lisp to tell my what (expt 100.5 100) is? and not get
"infinity" for an answer but a good aprox to the answer?
surely, it must be possible to implement this within the existing
'framework' of CL.. anyone know of any packages? :) though, wouldn't
it be nice if CL had arbitrarty "expt"s that as the default?
or am i completley missing some basic point?
Dr. Edmund Weitz
You arent't satisfied with the result of, say,
(expt (+ 100 1/2) 100)
?
Edi.
--
Dr. Edmund Weitz
Hamburg
Germany
The Common Lisp Cookbook
<http://cl-cookbook.sourceforge.net/>
Rahul Jain
> While (Expt 100 100) is okay with CL, why deosn't (expt 100.0 100.0)
> return something useful?
Because your floating point representation can't, probably.
> why can't the exponent-parts of the reals be allowed to be as high as
> it gets?
> It's like: CL frees you from upper limits on numbers (as compared to,
> say C) when dealing with integers but not when dealing with reals..
They are, but you're using floats, which are a specific type of real.
> or did i miss something obvious? or is there a package or some other
> way that allows the exponent-part to get as large as it wants to ?
if you want arbitrary-precision exact fraction arithmetic, try
rationals, but I don't think expt will return a rational...
Floating point arithmetic is fixed-range-precision inexact fraction
arithmetic. The range and precision of floating point is a function of
the size of the type you're using. (expt 100.0d0 100.0d0) _might_ work
better.
--
-> -/- - Rahul Jain - -\- <-
-> -\- http://linux.rice.edu/~rahul -=- mailto:rj...@techie.com -/- <-
-> -/- "I never could get the hang of Thursdays." - HHGTTG by DNA -\- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
Version 11.423.999.221020101.23.50110101.042
(c)1996-2002, All rights reserved. Disclaimer available upon request.
Rahul Jain
> surely, it must be possible to implement this within the existing
> 'framework' of CL.. anyone know of any packages? :) though, wouldn't
> it be nice if CL had arbitrarty "expt"s that as the default?
> or am i completley missing some basic point?
I think you're missing the point Kent made about floats being designed
to correspond exactly to the hardware's supported datatypes are. If
you implement this in lisp with your own custom features, you'll be
losing the HUGE speed advantage that having those operations encoded
in the hardware would buy you, but it's definitely possible.
If you really don't care about precision, you could try operating on
the logs of the values in question, and multiplying instead of
exponentiating, etc. I suppose doing (expt (round number) base) would
be the way of converting them back to bignums.
Deepak Goel
Thanks a lot Kent, Dr. Weitz and Rahul. this example (+ 100 1/2)
indeed clearified the point to me..
Nils Goesche
>
> While (Expt 100 100) is okay with CL, why deosn't (expt 100.0 100.0)
> return something useful?
>
> why can't the exponent-parts of the reals be allowed to be as high as
> it gets?
>
> It's like: CL frees you from upper limits on numbers (as compared to,
> say C) when dealing with integers but not when dealing with reals..
I guess the reason is that not many people ever needed floating point
numbers with that great a precision in exponent and mantissa (and
performance would probably a disaster, but I am not a compiler writer).
Are you sure you need them? And are you sure that if you compute
with such large numbers in floating point arithmetic your results
won't be totally meaningless because of rapidly growing error bounds?
They don't have to, of course, but better check up, first :-)
Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x42B32FC9
Thomas F. Burdick
> Deepak Goel <de...@glue.umd.edu> writes:
>
> > While (Expt 100 100) is okay with CL, why deosn't (expt 100.0 100.0)
> > return something useful?
> >
> > why can't the exponent-parts of the reals be allowed to be as high as
> > it gets?
> >
> > It's like: CL frees you from upper limits on numbers (as compared to,
> > say C) when dealing with integers but not when dealing with reals..
> >
> > or did i miss something obvious? or is there a package or some other
> > way that allows the exponent-part to get as large as it wants to ?
>
> If you want infinite precision, use rationals.
In fact, given the question, I don't think he should be using floats
at all; at least, not until he's done a lot of reading. This isn't
meant as any sort of a slight -- floats are weird, and they're made
way too easy to use by most languages, including CL. Most people
figure they know how to use them -- they're numbers, right? -- and
create all sorts of problems. The fact that most languages don't even
*have* a rational type doesn't help.
If I were the benevolent dictator of CL, I'd make it so that 1.2 did
not read, or if it did, would produce the rational 12/10. To get a
float, you'd have to do #f<single, 1.2>. I think there might be a lot
of people who are really thankful I'm not the dictator of CL :)
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Nils Goesche
> Kent M Pitman <pit...@world.std.com> writes:
>
>> Deepak Goel <de...@glue.umd.edu> writes:
>>
>> > While (Expt 100 100) is okay with CL, why deosn't (expt 100.0 100.0)
>> > return something useful?
>>
>
> In fact, given the question, I don't think he should be using floats
> at all; at least, not until he's done a lot of reading. This isn't
> meant as any sort of a slight -- floats are weird, and they're made
> way too easy to use by most languages, including CL. Most people
> figure they know how to use them -- they're numbers, right? -- and
> create all sorts of problems. The fact that most languages don't even
> *have* a rational type doesn't help.
Indeed. In case anybody didn't know it yet, this is great for a
start:
http://cch.loria.fr/documentation/IEEE754/ACM/goldberg.pdf
> If I were the benevolent dictator of CL, I'd make it so that 1.2 did
> not read, or if it did, would produce the rational 12/10. To get a
> float, you'd have to do #f<single, 1.2>. I think there might be a lot
> of people who are really thankful I'm not the dictator of CL :)
You bet :-)
Erik Naggum
| If you really don't care about precision, you could try operating on the
| logs of the values in question, and multiplying instead of
| exponentiating, etc. I suppose doing (expt (round number) base) would be
| the way of converting them back to bignums.
If you choose base 10, computing with the logarithms is pretty easy for
most mathematical operations. Printing the value is not very hard,
either: Just print the antilogarithm of the fractional part followed by
the usual E and the integral part with a sign, and voila! you have the
regular floating-point format. Reading such numbers back in into
logarithmic form is also a piece of cake: read the string, split it on
the exponent marker, read the floating point number from the string, take
the logarithm, which should now be in the range [0,1), and just add the
integer exponent you read from the rest of the string. This way, you can
work with floating-point representations of logarithms. It might take
some getting used to, but before computers, people used to work with
logarithmic projections all the time. Remember the slide rule? :)
///
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
Raymond Toy
Deepak> While (Expt 100 100) is okay with CL, why deosn't (expt 100.0 100.0)
Deepak> return something useful?
Deepak> why can't the exponent-parts of the reals be allowed to be as high as
Deepak> it gets?
Deepak> It's like: CL frees you from upper limits on numbers (as compared to,
Deepak> say C) when dealing with integers but not when dealing with reals..
Deepak> or did i miss something obvious? or is there a package or some other
Deepak> way that allows the exponent-part to get as large as it wants to ?
Not aware of anything that lets you have totally arbitrary limits, but
CMUCL used to support a long-float type that was the same size as
x86's 80-bit reals.
Also, Clisp's long-float type has a large exponent (don't remember)
and an arbitrary length for the fraction part.
Maxima might have a Lisp bigfloat implementation that might allow
arbitrary exponent and fraction.
Ray
Barry Margolin
In general, when you use floating point you're more interested in
performance than accuracy, so it uses the hardware's native floating point
representation. No hardware I know of supports arbitrary-precision
mantissas or exponents.
Why don't you use rationals instead of floats: (expt 1005/10 100)
--
Barry Margolin, bar...@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Barry Margolin
Rahul Jain <rj...@sid-1129.sid.rice.edu> wrote:
>if you want arbitrary-precision exact fraction arithmetic, try
>rationals, but I don't think expt will return a rational...
(expt <rational> <integer>) is required to return a rational.
Rahul Jain
> In article <873czwe...@photino.sid.rice.edu>,
> Rahul Jain <rj...@sid-1129.sid.rice.edu> wrote:
> >if you want arbitrary-precision exact fraction arithmetic, try
> >rationals, but I don't think expt will return a rational...
> (expt <rational> <integer>) is required to return a rational.
Right. Silly of me to assume that the type restrictions on
(expt <integer> <rational>) could even be considered to be the same :)
Sam Steingold
> * On the subject of "very large reals?"
> * Sent on 20 Feb 2002 12:52:27 -0500
> * Honorable Deepak Goel <de...@glue.umd.edu> writes:
>
> While (Expt 100 100) is okay with CL, why deosn't (expt 100.0 100.0)
> return something useful?
CLISP has unlimited precision long floats (well, you have to set this
precision first), but the exponent is 32 bits.
thus, you can operate on high precision floats by moving them into the
32-bit exponent range (use logs).
see <http://clisp.cons.org/impnotes.html#lfd>
rationals is another (portable) alternative.
--
Sam Steingold (http://www.podval.org/~sds) running RedHat7.2 GNU/Linux
Keep Jerusalem united! <http://www.onejerusalem.org/Petition.asp>
Read, think and remember! <http://www.iris.org.il> <http://www.memri.org/>
You think Oedipus had a problem -- Adam was Eve's mother.
Marco Antoniotti
t...@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
...
>
> If I were the benevolent dictator of CL, I'd make it so that 1.2 did
> not read, or if it did, would produce the rational 12/10. To get a
> float, you'd have to do #f<single, 1.2>. I think there might be a lot
> of people who are really thankful I'm not the dictator of CL :)
>
Can I apply for the title of "Evil Overlord" of CL? :)
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
Erik Naggum
| If I were the benevolent dictator of CL, I'd make it so that 1.2 did
| not read, or if it did, would produce the rational 12/10. To get a
| float, you'd have to do #f<single, 1.2>. I think there might be a lot
| of people who are really thankful I'm not the dictator of CL :)
It is a pity that *read-default-float-format* does not accept 'rational
as a possible value. Then you would have write 1.2f0 to get a float.
rationalize is a very nice and useful function.