hi,
coming from the c/c++ fraction, i am a newbie in cl, trying out some
free cl-environments.
I tried gnu cl (gcl 2.6.6) and clisp 2.33.2.
I like both, but i prefer clisp since it has built in support for long
floats. On the other hand, clisp does not have a native code compiler (to
my understanding), but has a byte-code compiler. So i have some questions
to you lisp people:
* is there any possibility for (arbitrary precision) long floats as an
extension/library for gcl?
* does a PCL extension to support CLOS in gcl yield a slow CLOS
implementation ??
* is there a clos implementation in cvs gcl already ??
I must admit i begin to love common lisp for its genericity and power...
thanks in advance
oni
--
(I already try to be as amusing as possible, my master!)
From: Sam Steingold
Subject: Re: (arbitrary precision) long float implementation for free lisp's other than clisp ???
Date:
Message-ID: <u4qdhwww9.fsf@gnu.org>
> * Onay <·····@tzk.arg> [2005-05-05 15:49:09 +0200]:
>
> I tried gnu cl (gcl 2.6.6) and clisp 2.33.2.
> I like both, but i prefer clisp since it has built in support for long
> floats. On the other hand, clisp does not have a native code compiler (to
> my understanding), but has a byte-code compiler.
why are you so worried about native compilation?
I find CLISP speed quite adequate for my needs - did you actually
benchmark your application to make sure CLISP is too slow?
> * is there any possibility for (arbitrary precision) long floats as an
> extension/library for gcl?
there probably is, but it will be much slower than the CLISP one
because the CLISP long floats are implemented in C (with some assembly).
note also that when you are doing long float computations you are
generating a lot of garbage, and CLISP's generational GC is likely to
handle that much better than GCL's conservative GC.
--
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.mideasttruth.com/> <http://www.camera.org> <http://pmw.org.il/>
<http://www.jihadwatch.org/> <http://www.iris.org.il>
Booze is the answer. I can't remember the question.
Sam Steingold wrote:
>> * Onay <·····@tzk.arg> [2005-05-05 15:49:09 +0200]:
>>
>> I tried gnu cl (gcl 2.6.6) and clisp 2.33.2.
>> I like both, but i prefer clisp since it has built in support for long
>> floats. On the other hand, clisp does not have a native code compiler (to
>> my understanding), but has a byte-code compiler.
>
> why are you so worried about native compilation?
> I find CLISP speed quite adequate for my needs - did you actually
> benchmark your application to make sure CLISP is too slow?
actually, no. since i am a newbie, i am just looking around to find the best
performing cl environment with good CLOS support and long floats.
I saw some benchmarks at http://www.cons.org/cmucl/benchmarks/, and in
these, CLISP does not look good...
Unfortunately, i cannot compile CMUCL due to architecture incompatibility (i
own x86_64 arch), and it does not provide long floats anyway.
> note also that when you are doing long float computations you are
> generating a lot of garbage, and CLISP's generational GC is likely to
> handle that much better than GCL's conservative GC.
Since the benchmarks seem to be quite old (clisp v. 2.27.2, released
2001-10-05), things might have changed since then...
i think i keep tryin clisp...
--
(I already try to be as amusing as possible, my master!)
From: Jon Boone
Subject: Re: (arbitrary precision) long float implementation for free lisp's other than clisp ???
Date:
Message-ID: <m3mzr9wpr3.fsf@amicus.delamancha.org>
Onay <·····@gmx.net> writes:
> i think i keep tryin clisp...
you can also try the SBCL x86_64 images.
--jon
From: Pascal Costanza
Subject: Re: (arbitrary precision) long float implementation for free lisp's other than clisp ???
Date:
Message-ID: <3dv59mFcidbU1@individual.net>
Onay wrote:
> Sam Steingold wrote:
>
>>>* Onay <·····@tzk.arg> [2005-05-05 15:49:09 +0200]:
>>>
>>>I tried gnu cl (gcl 2.6.6) and clisp 2.33.2.
>>>I like both, but i prefer clisp since it has built in support for long
>>>floats. On the other hand, clisp does not have a native code compiler (to
>>>my understanding), but has a byte-code compiler.
>>
>>why are you so worried about native compilation?
>>I find CLISP speed quite adequate for my needs - did you actually
>>benchmark your application to make sure CLISP is too slow?
>
> actually, no. since i am a newbie, i am just looking around to find the best
> performing cl environment with good CLOS support and long floats.
If you are a newbie, don't worry too much about efficiency, but focus on
what is most convenient to use. ANSI compliance is also very important
because it's usually assumed that you are talking about ANSI Common Lisp
when you ask questions. Therefore, GCL is currently not the best choice.
Since compatibility across Common Lisp implementations is generally very
good when you stick to standard stuff, you can worry about technical
requirements (time and space efficiency, etc.) much later. For example,
a good development environment is much more important to support your
learning process. Make it either one of the commercial IDEs or Emacs +
SLIME. (Choosing a commercial IDE doesn't tie you to that implementation
later on. Good Lisp hackers usually know a number of implementations,
both commercial and open source ones, and pick the right one depending
on the needs of a project.)
> I saw some benchmarks at http://www.cons.org/cmucl/benchmarks/, and in
> these, CLISP does not look good...
It really depends on what you want to use it for. Paul Graham used clisp
for Yahoo stores because it had the most efficient streams
implementation at that time, which was apparently more important than
other aspects.
Pascal
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
From: Raymond Toy
Subject: Re: (arbitrary precision) long float implementation for free lisp's other than clisp ???
Date:
Message-ID: <sxdis1xpug8.fsf@rtp.ericsson.se>
>>>>> "Onay" == Onay <·····@gmx.net> writes:
Onay> * is there any possibility for (arbitrary precision) long floats as an
Onay> extension/library for gcl?
You mean an already made library? I don't think so.
Onay> * does a PCL extension to support CLOS in gcl yield a slow CLOS
Onay> implementation ??
SBCL and CMUCL use PCL and are reasonably fast (or slow) with PCL. If
PCL is slow in gcl, then it's probably because the compiler didn't do
a very good job.
Onay> * is there a clos implementation in cvs gcl already ??
I think so.
The gcl mailing lists are probably the best place to find out for
sure.
Ray
From: Camm Maguire
Subject: Re: (arbitrary precision) long float implementation for free lisp's other than clisp ???
Date:
Message-ID: <541x8l1nm1.fsf@intech19.enhanced.com>
Greetings, and thanks for your interest!
In summary, GCL already has an interface to gmp, the highly optimized
external library for multiple-precision integer computations. It is a
simple task, and on our todo list, to extend this to bring forward the
floating point calls as well, which has now been branched into a
separate library, mfpr. If you have a specific need with real code,
we will bump the priority on this. It is not difficult. Open source
projects take higher priority in GCL development, so if your code is
open source, you'll get more attention from us!
The other poster is correct, though, the main performance issue with
multi-precision stuff is due to garbage collection. GCL has a multi
layer model, with different types of objects segregated of different
page types, and in some cases gc'd differently. By default, GCL uses
a fast copying collector on bignums which are stored on relocatable
pages. This is quite robust now having been thoroughly tested in a
number of computer algebra systems such as axiom making heavy use of
this functionality. The user can switch to a slower immovable type of
allocation at runtime, but this is really an obsolete option at this
point.
GCL has also recently implemented a memory balancing algorithm that
has significantly reduced gc times in a number of large applications.
acl2 comes to mind, where now gcl is the fastest lisp as measured in
their regression suite times among their handful of supported
options.
CLOS is supported in GCL currently via PCL in the ansi build. GCL
supports both traditional CLtL1 and ANSI images, the latter of which
is a work in progress and not yet 100% compliant, though it is good
enough for many purposes. The primary goal of the 2.7.0 release,
hopefully out by summer's end, will be substantively full ansi
compliance. Paul Diets has developed a very helpful ansi test suite
for the GCL project to assist in this effort. The PCL code
essentially tracks the same code used by cmucl and sbcl, which is
known to perform quite acceptably, and provides an easy compliance
path for GCL to follow.
GCL is the basis for maxima, acl2, and axiom on Debian, and supports
all 12 Debian architectures in this regard.
If you would like to assist GCL in its development, please join in at
·········@gnu.org. Like any open source project, we can always use
the person power.
Please also note that the GCL developers are quite busy and have very
little time for a newsgroup like this. Questions should be directed
to ·········@gnu.org.
Take care,
Onay <·····@gmx.net> writes:
> hi,
> coming from the c/c++ fraction, i am a newbie in cl, trying out some
> free cl-environments.
> I tried gnu cl (gcl 2.6.6) and clisp 2.33.2.
> I like both, but i prefer clisp since it has built in support for long
> floats. On the other hand, clisp does not have a native code compiler (to
> my understanding), but has a byte-code compiler. So i have some questions
> to you lisp people:
> * is there any possibility for (arbitrary precision) long floats as an
> extension/library for gcl?
> * does a PCL extension to support CLOS in gcl yield a slow CLOS
> implementation ??
> * is there a clos implementation in cvs gcl already ??
>
> I must admit i begin to love common lisp for its genericity and power...
> thanks in advance
>
> oni
> --
> (I already try to be as amusing as possible, my master!)
--
Camm Maguire ····@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Camm Maguire wrote:
> Greetings, and thanks for your interest!
>
> In summary, GCL already has an interface to gmp, the highly optimized
> external library for multiple-precision integer computations. It is a
> simple task, and on our todo list, to extend this to bring forward the
> floating point calls as well, which has now been branched into a
> separate library, mfpr. If you have a specific need with real code,
> we will bump the priority on this. It is not difficult. Open source
> projects take higher priority in GCL development, so if your code is
> open source, you'll get more attention from us!
>
> The other poster is correct, though, the main performance issue with
> multi-precision stuff is due to garbage collection. GCL has a multi
> layer model, with different types of objects segregated of different
> page types, and in some cases gc'd differently. By default, GCL uses
> a fast copying collector on bignums which are stored on relocatable
> pages. This is quite robust now having been thoroughly tested in a
> number of computer algebra systems such as axiom making heavy use of
> this functionality. The user can switch to a slower immovable type of
> allocation at runtime, but this is really an obsolete option at this
> point.
>
> GCL has also recently implemented a memory balancing algorithm that
> has significantly reduced gc times in a number of large applications.
> acl2 comes to mind, where now gcl is the fastest lisp as measured in
> their regression suite times among their handful of supported
> options.
>
> CLOS is supported in GCL currently via PCL in the ansi build. GCL
> supports both traditional CLtL1 and ANSI images, the latter of which
> is a work in progress and not yet 100% compliant, though it is good
> enough for many purposes. The primary goal of the 2.7.0 release,
> hopefully out by summer's end, will be substantively full ansi
> compliance. Paul Diets has developed a very helpful ansi test suite
> for the GCL project to assist in this effort. The PCL code
> essentially tracks the same code used by cmucl and sbcl, which is
> known to perform quite acceptably, and provides an easy compliance
> path for GCL to follow.
>
> GCL is the basis for maxima, acl2, and axiom on Debian, and supports
> all 12 Debian architectures in this regard.
>
> If you would like to assist GCL in its development, please join in at
> ·········@gnu.org. Like any open source project, we can always use
> the person power.
>
> Please also note that the GCL developers are quite busy and have very
> little time for a newsgroup like this. Questions should be directed
> to ·········@gnu.org.
>
> Take care,
First of all, thank you very much for your response !
my primary goal with CL is to write a neural network (NN) library with an
implementation of RBF networks. In these, it is necessary to solve large
and ill conditioned linear equations (or to invert those matrices). I know
about axiom but in order to learn CL, i would prefer writing a math and NN
library from ground up based on CLOS.
The resulting library is planned to be open sourced!! So if there is a
possibility to enhance gcl by impementing (gmp based) long floats, it would
qualify it for an implementation platform!
To my understanding, long floats with arbitrary precision are NOT required
for an ANSI CL implemetation...
I would suggest to vote for it in the next ANSI/ISO standart for CL, though!
--
(I already try to be as amusing as possible, my master!)
Onay wrote:
> First of all, thank you very much for your response !
>
> my primary goal with CL is to write a neural network (NN) library with an
> implementation of RBF networks. In these, it is necessary to solve large
> and ill conditioned linear equations (or to invert those matrices). I know
> about axiom but in order to learn CL, i would prefer writing a math and NN
> library from ground up based on CLOS.
> The resulting library is planned to be open sourced!! So if there is a
> possibility to enhance gcl by impementing (gmp based) long floats, it would
> qualify it for an implementation platform!
> To my understanding, long floats with arbitrary precision are NOT required
> for an ANSI CL implemetation...
Correct. The need for long floats is rather esoteric and not commonly
found in applications. You already know that arbitrary long floats are
not features of other mainline programming languages either, although
they are available via add-on libraries. This is as it should be.
You might want to investigate Maxima's bigfloats.
> I would suggest to vote for it in the next ANSI/ISO standart for CL, though!
I weould like to explain to you that this suggestion is a waste of
network bandwidth. Why not suggest that the next revision of ANSI CL
contain mandatory support for RBF networks?
An addition to a standard doesn't happen because some newbie thinks it
is useful and wants the rest of the community to support his needs. An
extension happens in general because (1) There is widespread need for a
new facility; (2) There is a competent community willing to experiment
with the facility and provide at least prototype code; (3) The existing
community is convinced by the worth of these materials, or at least is
willing to suffer them.
Bigfloats or somethign like them migh be a worthwhile addition to the
language, but they don't often surface as a real need by significant
subsets of the user community. Much of the need, I suspect, can be
handled by the standard bignum/ratio facilities. Have you considered
them for whatever you are intending to do? They have most of the
benefits of bigfloats without all the drawbacks: approximation and/or
arbitrary user-specified limits on precision.
if you rreally _really_ think arbitrary precision floats are worthwhile
in the language, you can implement an open-source package for them and
perhsp some of the existing implementations will pick it up and extend
the standard, non-user-extensible arithmetic functions to support them.
But suggesting the community vote for them is, as my sailor friends
would say, simply spitting to windward.
Steven M. Haflich wrote:
> Onay wrote:
>
>> First of all, thank you very much for your response !
>>
>> I would suggest to vote for it in the next ANSI/ISO standart for CL,
>> though!
>
> I weould like to explain to you that this suggestion is a waste of
> network bandwidth. Why not suggest that the next revision of ANSI CL
> contain mandatory support for RBF networks?
>
> An addition to a standard doesn't happen because some newbie thinks it
> is useful and wants the rest of the community to support his needs. An
> extension happens in general because (1) There is widespread need for a
> new facility; (2) There is a competent community willing to experiment
> with the facility and provide at least prototype code; (3) The existing
> community is convinced by the worth of these materials, or at least is
> willing to suffer them.
>
> Bigfloats or somethign like them migh be a worthwhile addition to the
> language, but they don't often surface as a real need by significant
> subsets of the user community. Much of the need, I suspect, can be
> handled by the standard bignum/ratio facilities. Have you considered
> them for whatever you are intending to do? They have most of the
> benefits of bigfloats without all the drawbacks: approximation and/or
> arbitrary user-specified limits on precision.
>
> if you rreally _really_ think arbitrary precision floats are worthwhile
> in the language, you can implement an open-source package for them and
> perhsp some of the existing implementations will pick it up and extend
> the standard, non-user-extensible arithmetic functions to support them.
> But suggesting the community vote for them is, as my sailor friends
> would say, simply spitting to windward.
Oh, well CLSIP already has it. GCL seems to have an interface to the c-lib
gmp which provides arbitrary precision floats...
Since, except long floats, all other numerical formats are already required
by the standard, even fractions, wouldn't it just be consequent to fill the
gap?
--
(I already try to be as amusing as possible, my master!)
From: Bruno Haible
Subject: Re: (arbitrary precision) long float implementation for free lisp's other than clisp ???
Date:
Message-ID: <d5o45s$pue$1@laposte.ilog.fr>
Steven M. Haflich wrote:
>
> The need for long floats is rather esoteric and not commonly
> found in applications.
Arbitrary precision floats are needed at least for the following kinds
of applications:
- So-called "stiff" differential equations,
- Numeric analytic continuation,
- Factorization of multivariate polynomials over Z in polynomial time
(using the Lenstra-Lenstra-Lovasz algorithm),
- High-energy physics,
- ...
> but they don't often surface as a real need by significant
> subsets of the user community.
Twenty years ago, the computer-algebra user community was a subset of
the Lisp users community. This is not the case any more nowadays.
(Axiom being the most famous counterexample.)
Why?
Certainly also because the computer-algebra system implementors
noticed that they would better write their own bignums in Lisp than
use the ones in the core language. So poor was their performance in
the then-common implementations (like Symbolics Lisp, which did
bignums slower than an Atari ST could do at the same time).
Bruno
From: Pascal Bourguignon
Subject: Re: (arbitrary precision) long float implementation for free lisp's other than clisp ???
Date:
Message-ID: <87acn6xvhr.fsf@thalassa.informatimago.com>
Onay <·····@gmx.net> writes:
> my primary goal with CL is to write a neural network (NN) library with an
> implementation of RBF networks. In these, it is necessary to solve large
> and ill conditioned linear equations (or to invert those matrices). I know
> about axiom but in order to learn CL, i would prefer writing a math and NN
> library from ground up based on CLOS.
> The resulting library is planned to be open sourced!! So if there is a
> possibility to enhance gcl by impementing (gmp based) long floats, it would
> qualify it for an implementation platform!
> To my understanding, long floats with arbitrary precision are NOT required
> for an ANSI CL implemetation...
> I would suggest to vote for it in the next ANSI/ISO standart for CL, though!
clisp has long floats.
http://www.podval.org/~sds/clisp/impnotes/num-concepts.html
[277]> (/ 1.0 3.0)
0.33333334
[278]> (/ 1.0 (coerce 3.0 'double-float))
0.3333333333333333d0
[279]> (/ 1.0 (coerce 3.0 'long-float))
0.33333333333333333334L0
[280]> (SETF (EXT:LONG-FLOAT-DIGITS) 100)
100
[281]> (/ 1.0 (coerce 3.0 'long-float))
0.333333333333333333333333333333333333334L0
[282]> (SETF (EXT:LONG-FLOAT-DIGITS) 1000)
1000
[283]> (/ 1.0 (coerce 3.0 'long-float))
0.333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333334L0
--
__Pascal Bourguignon__ http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we. -- Georges W. Bush
From: Alan Crowe
Subject: Re: (arbitrary precision) long float implementation for free lisp's other than clisp ???
Date:
Message-ID: <8664xs1ngc.fsf@cawtech.freeserve.co.uk>
Onay wrote:
> my primary goal with CL is to write a neural network (NN)
> library with an implementation of RBF networks. In these,
> it is necessary to solve large and ill conditioned linear
> equations (or to invert those matrices).
I suspect that you will be better off using Singular Value
Decomposition to solve your ill-conditioned linear equations.
http://kwon3d.com/theory/jkinem/svd.html
Alan Crowe
Edinburgh
Scotland
From: M Jared Finder
Subject: Re: (arbitrary precision) long float implementation for free lisp's other than clisp ???
Date:
Message-ID: <efmdneIjIO18_uDfRVn-gQ@speakeasy.net>
Onay wrote:
> hi,
> coming from the c/c++ fraction, i am a newbie in cl, trying out some
> free cl-environments.
> I tried gnu cl (gcl 2.6.6) and clisp 2.33.2.
> I like both, but i prefer clisp since it has built in support for long
> floats. On the other hand, clisp does not have a native code compiler (to
> my understanding), but has a byte-code compiler. So i have some questions
> to you lisp people:
> * is there any possibility for (arbitrary precision) long floats as an
> extension/library for gcl?
I'm confused. How are arbitrary precision long floats different from
arbitrary precision ratios, which are in Common Lisp? Does it
symbolically manipulate irrational numbers instead of approximating them
with a truncated value?
-- MJF
From: David Golden
Subject: Re: (arbitrary precision) long float implementation for free lisp's other than clisp ???
Date:
Message-ID: <B5efe.52852$Z14.43428@news.indigo.ie>
M Jared Finder wrote:
> I'm confused. How are arbitrary precision long floats different from
> arbitrary precision ratios, which are in Common Lisp?
bignum rationals in common lisp
probably don't represent the denominator sparsely: i.e. you're
saying:
123453 /
1000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000
000
as a fixnum and a bignum, rather than representing as 123453x10^-550
i.e. what one might want is the facility for
[number x 10^number] without limitations on the number
(unlike float/double-float), and rather than [number / number]
From: M Jared Finder
Subject: Re: (arbitrary precision) long float implementation for free lisp's other than clisp ???
Date:
Message-ID: <DbKdna82PYbSPeDfRVn-gg@speakeasy.net>
David Golden wrote:
> M Jared Finder wrote:
>
>>I'm confused. How are arbitrary precision long floats different from
>>arbitrary precision ratios, which are in Common Lisp?
>
> bignum rationals in common lisp
> probably don't represent the denominator sparsely: i.e. you're
> saying:
>
> 123453 /
> 1000000000000000000000000000000000000000000000000000000000000
> 0000000000000000000000000000000000000000000000000000000000000
> 0000000000000000000000000000000000000000000000000000000000000
> 0000000000000000000000000000000000000000000000000000000000000
> 0000000000000000000000000000000000000000000000000000000000000
> 0000000000000000000000000000000000000000000000000000000000000
> 0000000000000000000000000000000000000000000000000000000000000
> 0000000000000000000000000000000000000000000000000000000000000
> 0000000000000000000000000000000000000000000000000000000000000
> 000
>
>
> as a fixnum and a bignum, rather than representing as 123453x10^-550
>
> i.e. what one might want is the facility for
> [number x 10^number] without limitations on the number
> (unlike float/double-float), and rather than [number / number]
This doesn't seem like it would be all that useful except for very
specific applications. Unless all your multiplications and divisions
are by 10, representing a number as s * 10^e would take up more space
with the added benefit of excluding a significant amount of numbers from
ever being used. 1/3, 1/6, 1/7, and 1/9 are all impossible to represent
in finite space with 10 as a base.
If this is what the OP wanted, I'd like to know how he expects this
functionality to be useful.
-- MJF
From: David Golden
Subject: Re: (arbitrary precision) long float implementation for free lisp's other than clisp ???
Date:
Message-ID: <prpfe.52864$Z14.43240@news.indigo.ie>
M Jared Finder wrote:
>
> If this is what the OP wanted, I'd like to know how he expects this
> functionality to be useful.
>
Well, note that I was speculating "what one might want" - turns out
that "long floats" in CLISP as another post describes appear to be
adjustable-precision (set through "long-float-digits") in mantissa and
fixed size exponent. Given that you've already lost much hope of
performance by such a thing, I'd say why not have arbitrary-size
exponent too...
Either way, I've never had need to use them, myself!
From: David Golden
Subject: Re: (arbitrary precision) long float implementation for free lisp's other than clisp ???
Date:
Message-ID: <daefe.52853$Z14.43409@news.indigo.ie>
David Golden wrote:
> as a fixnum and a bignum, rather than representing as 123453x10^-550
>
Just to clarify: nothing special about 10^, one might use 2^ (as IEEE
floats do!) or even something else, it was just clearest to illustrate
with 10^ ...
From: Gareth McCaughan
Subject: Re: (arbitrary precision) long float implementation for free lisp's other than clisp ???
Date:
Message-ID: <87ekchd7dt.fsf@g.mccaughan.ntlworld.com>
M Jared Finder wrote:
> Onay wrote:
>> hi, coming from the c/c++ fraction, i am a newbie in cl, trying out
>> some
>> free cl-environments. I tried gnu cl (gcl 2.6.6) and clisp 2.33.2. I
>> like both, but i prefer clisp since it has built in support for long
>> floats. On the other hand, clisp does not have a native code compiler (to
>> my understanding), but has a byte-code compiler. So i have some questions
>> to you lisp people:
>> * is there any possibility for (arbitrary precision) long floats as an
>> extension/library for gcl?
>
> I'm confused. How are arbitrary precision long floats different from
> arbitrary precision ratios, which are in Common Lisp? Does it
> symbolically manipulate irrational numbers instead of approximating
> them with a truncated value?
We're talking about floating-point arithmetic, with a
fixed-size[1] mantissa. If you do a long sequence of arithmetic
operations on rationals, the results are liable to blow up,
with enormous numerators and denominators. That doesn't
happen with floating-point arithmetic. You could instead
use rationals and do some sort of rounding operation
every now and then, but (1) the need for explicit rounding
could be troublesome, and (2) it might be harder to do
decent error analysis. (Though error analysis on FP
arithmetic can be plenty tricky too.) I speculate
baselessly that using big floats ends up being faster
and using less memory for any given level of accuracy
and implementation effort.
[1] Er. Fixed-size within a single calculation, but
user-adjustable if need be.
--
Gareth McCaughan
.sig under construc