[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CLN instead of mpwrap
Hello,
George <jirka@5z.com> writes:
> I'm investigating how to replace mpwrap and a lot of the genius routines with
> CLN. So perhaps you may see some genius breakage in the coming days because
> of this. This may actually speed up the process of the new interface as it
> will take care of modularizing a large part of the engine. It also seems
> like cln will be quite a bit faster then mpwrap which eats cache for
> breakfast.
>
> The only thing is that I can't find rpms for this beast. The homepage is at
> http://clisp.cons.org/~haible/packages-cln.html
>
> Lemme know what you think about this. It should definately improve
> precision, speed and features of dr genius. And I think it will be simpler
> then trying to make mpwrap work nicely. Also it offloads the burden of
> maintaining some of the math stuff from genius which means more time for
> other stuff.
It indeed does offload a large burden. We have been doing the same
thing for GiNaC <http://www.ginac.de/>, too. And we are quite happy
with that decision. In particular, thanks to CLN, we don't have a
problem with some things discussed earlier on this list:
| ginsh - GiNaC Interactive Shell (GiNaC V0.5.0)
| __, _______ Copyright (C) 1999-2000 Johannes Gutenberg University Mainz,
| (__) * | Germany. This is free software with ABSOLUTELY NO WARRANTY.
| ._) i N a C | You are welcome to redistribute it under certain conditions;
| <-------------' see the file COPYING for details.
|
| Type ?? for a list of help topics.
| > sqrt(4/8);
| sqrt(1/2)
| > sqrt(4/9);
| 2/3
| > (64/27)^(1/3);
| 4/3
| > evalf(sqrt(4/10));
| 0.632455532033675866399778708886543706743L0
Aaron Lehmann <aaronl@vitelus.com> writes:
> Shouldn't be needed. I would hate to have yet another dependencey for
> dr-genius, especially one of which no rpm's are available. Unfortunately,
> it looks very large, perhaps too large to include in the source tree.
Maybe not everything should be put into the source tree. Better
provide RPMs and convince the folks at Redhat to include them, I
think. For Debian (the dist we use over here) I have made packages
and put them into the next release (2.2, a.k.a. potato).
And:
> I looked into it a little further and found that it is 3.5 megs when only
> considering the source. It includes gmp in its source tree which we will
> not need becuase we have a GMP dependency already. It includes other stuff
> such as benchmarks and documentation that may be discarded. What are your
> thoughts - should cln be put into the source tree, or linked against and
> link to source and binaries from the web page?
CLN includes GMP in its source tree because it cannot link into GMP on
most ELF systems due to missing ELF .type directives on some assembler
routines. Also note that CLN only includes the MPN stuff from GMP,
wich is not very much. According to Torbjorn Granlund <tege@swox.com>
this problem is being addressed for the upcoming release GMP3. CLN
will most probably make use of GMP3 once it becomes available and
evolve to link dynamically into it and gradually make use of some new
functionality. Note that CLN is much more than just a wrapper for
GMP, it has quite a number of state-of-the-art algorithms. (The above
example of (64/27)^(1/3) for instance uses Hensel's Lemma and
quadratic Hensel-Lifting.)
Regards
-rbk.
--
Richard Kreckel
<http://wwwthep.physik.uni-mainz.de/~kreckel/>