Greetings! Vanuxem Gregory <[EMAIL PROTECTED]> writes:
> 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' ? > Basically, yes. > >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. OK. > CLOS require ANSI dialect isn't it? Rather ANSI requires CLOS, but what has this to do with mfpr? > > > > > 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. > I don't understand what might be missing except for performance. Please explain if you have the time. > > > > > > 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. > Why not? > > > > > 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 ? > Not in the standard. Each implementation does its own. GCL's is pretty flexible IMHO. > > > 5) Documentation about what I say. > > > > > > > Yes, please! > > > > > Take care, > > > > Cheers, > Take care, > 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 > > > > > > > _______________________________________________ > 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
