Hi, Some correction about this incomprehensible e-mail.
> > > Greetings! > > Vanuxem Gregory <[EMAIL PROTECTED]> writes: > > > Serious question about GCL, One question about GCL and multiple-precision floating-point computations. > > I've lost your mail about (arbitrary float), > > But how do yo think peopole can implement arbitrary float in > gcl; whith MPFR How do you think someone can implement arbitrary float (MPFR) in gcl ? > > ? > > With class or directly in num_arith... ? > > > > Camm... one Idea....? > > > > For lack of a better idea, I was thinking of something along the lines > of what clisp does -- have a system parameter which sets the 'big > float' precision, and then define a 'big float' type with coercion > rules identical to that between the existing short float and long > float types. This would all be in num_arith, just as the 'bignum' > integers are now. With a new 'switch ... case' ? >I was not envisioning any compiler support, thought > this could be added at some point. I.e. array's of bigfloats would be > array's of objects, as opposed to array's of 16byte float numbers, for > example. > > I don't see a reason to do this, however, unless there is a benefit to > an existing application. Axiom does its own bigfloat stuff already, > as does maxima. Now if we can demonstrate that performance gains along > the lines of what you are seeing with the gcd stuff in gmp can be had, > that is a good reason, and should motivate us to get this in quickly > provided that axiom and/or maxima expresses their intention to use it. > There is just so much to do, I don't want to work on stuff which won't > be used, at least not right now. Just for information. Here begins Post-Scriptum: > > > Actually AXIOM doesn't compile with ANSI version ... Sometimes I think about multiple-precision floating-point computations in GCL and connection with other CAS. CLOS require ANSI dialect isn't it? > > IMHO, a strength of GCL is that we support both CLtL1 and (work in > progress) ANSI dialects to allow existing applications to decide if > and when to migrate to ANSI. maxima has migrated to ANSI, largely > because they have a sizeable staff of lisp volunteers who are used to > ANSI, which is a good reason. ACL2 and AXIOM have not yet, as their > lisp teams are familiar with and find what they need in CLtL1. In my > opinion, they should have the option of choosing if and when to migrate > in the context of their other development considerations. > > If memory serves, plenty of lisp 'heavy-weights' don't use ansi > features, e.g. CLOS, presumably because they don't want the overhead. > If memory serves, Paul Graham said he's never used it, but double > check that before relying upon it. > Thanks for this information. > I'm missing the connection of this statement to the one above ... > > > I know that you work on tcl/tk, documentation and graphics , > >doesn't forget the concept of 'notebook' > > (literate programming and other things...). > > > > I'm afraid I don't follow. Translation: In some recent discussion, the notion of portable graphic library has been evoked and its utilization with graphic and documentation. I always think about a colossal work: notebook and interaction with literate programming. The graphic library has may be (for me) to be choosen such that: i) works under different OS ii) it is compliant with other projects > > Generally I work on UNIX* (linux and BSD*) but actually > ((numerical stuff to > > implemenent: transcendental function for matrix (see Higham > > (http://www.ma.man.ac.uk/~higham/ and gang) with linear algebra > (atlas, blas > > and lapack ...)) > > I' am on Windows(R) (thanks M.Thomas ...). > > I think in AXIOM five things has to be seriously be enhanced (for future > > library use...): My branch of AXIOM has to be enhanced in four directions. Three types seem important (not for performance): Integer, Real and Rational. > > > > 1) 'Integer' in arbitrary integer: > 'GMP (realized)' > > Is this not already the case??? > > > 2) 'Floating number' in arbitrary float (cf: Monagan, Michael > (1990)): 'ADD > > MPFR' > > Is this not already the case??? Or are we talking performance here? > > > 3) 'Fraction Integer' with gmp (GMP) > 'GMP (realized)' > > (cf: > > > (http://page.axiom-developer.org/zope/mathaction/EnhancedFractionDomain), > > I will update and explain this when time permits. > > I agree presuming we can test exhaustively. If there is interest in > axiom for this, I'll move the rational arithmetic accelerations into > soon to be released 2.6.7, otherwise it will wait for 2.7.0. This work is not destined to be included in axiom. > > > 4) C (or fortran) Dynamic library linkink in GCL. '...' Idea Maguire ? > > There is a recent thread on gcl-devel expressing my ideas on this. > All we really need is a little enhancement to unexec to store dynamic > relocation records in a dumped image. Perhaps an unexecbfd might help > here. > > But even now this is far more serviceable than it used to be. See the > example on linking in ddot from libblas recently posted to > [email protected] using compiler::link. Is there some specification about foreign language call in Common Lisp ? > > 5) Documentation about what I say. > > > > Yes, please! > > Take care, > Cheers, Greg > > > > -----Message d'origine----- > > De : [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] la part de > > Camm Maguire > > Envoye : jeudi 5 mai 2005 21:02 > > A : Mike Thomas > > Cc : [email protected] > > Objet : [Gcl-devel] Re: Dynamic Library Linking > > > > > > Greetings! > > > > "Mike Thomas" <[EMAIL PROTECTED]> writes: > > > > > Hi Camm. > > > > > > | This is indeed the short answer -- you can link in any new > symbols you > > > | want that are not present in the original image via compiler::link. > > > | See the documentation for this function in gcl-si.{texi,info}. What > > > | this essentially does is build a new gcl image using a fresh call to > > > | the system linker ld to modify the image symbol table with whatever > > > | new code or libraries you specify. It has the disadvantage that the > > > | image is 'fresh' -- i.e. any work you may have done in the running > > > | image before compiling compiler::link is lost. Such work can be > > > | respecified to run by hand in the fresh new image through one of > > > | compiler::link's arguments, but this is a bit awkward to use. > > > |7 > > > | What I'd like to do in 2.7.0 is to allow the user to link in new > > > | dynamic libraries at runtime, modify the running image's > symbol table, > > > | and allow this work to be preserved across image saves via > > > | si::save-system. What this essentially means is that > unexec needs to > > > | add a little section to the end of the dumped image containing > > > | relocation records for the new symbols for use by the > system's dynamic > > > | linker (ld.so on Linux), i.e. a GOT (Global Access Table). > > > > > > If I understand you correctly, on Windows one could store the > name of the > > > symbol and the name of the DLL from whence it came, then > while resolving > > > references at ru(i)ntime to call LoadLibrary() and > GetProcAddress() for > > each > > > pair as shown here: > > > > > > > > > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/ > > > base/using_run_time_dynamic_linking.asp > > > > > > I believe that PE-COFF executables actually have a section > for external > > > library references (ie references to DLL's) into which unexec > might put > > this > > > kind of information so that the OS could automatically do the external > > > relocation work at image load time (though probably only for those > > > relocation records in the text sections I guess) . This is all pretty > > hairy > > > though, especially as Windows moves towards 64 bits and > whatever system > > > changes might come with that. > > > > > > > This is exactly the idea. When we have time :-). > > > > Take care, > > > > > > > | A kludgy way of doing this without any special executable format > > > | knowledge might be to expand the explicit C plt table (mplt > in plt.c) > > > | with a bunch of dummy entries referring to unused symbols > in external > > > | shared libs, one of which we might provide for this purpose. Then > > > | when new symbols are needed, these symbols could be changed. This > > > | would still require us to be able to find the symbol in the image's > > > | symbol table, but at least we would not have to add any new > sections, > > > | etc. Of course this approach is rather awkward and limited too. > > > > > > It all sounds awkward to me as I'm pretty vague on all of this. > > > > > > Cheers > > > > > > Mike Thomas. > > > > > > > > > > > > > > > > > > > -- > > Camm Maguire > [EMAIL PROTECTED] > > > ========================================================================== > > "The earth is but one country, and mankind its citizens." -- > Baha'u'llah > > > > > > _______________________________________________ > > Gcl-devel mailing list > > [email protected] > > http://lists.gnu.org/mailman/listinfo/gcl-devel > > > > > > > > > > > > -- > Camm Maguire [EMAIL PROTECTED] > ========================================================================== > "The earth is but one country, and mankind its citizens." -- Baha'u'llah > _______________________________________________ Axiom-developer mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/axiom-developer
