RE: [Gcl-devel] Re: Dynamic Library Linking (arbitray float)

[Vanuxem Gregory]

Hi,


> -----Message d'origine-----
> De : Camm Maguire [mailto:address@hidden
> Envoye : samedi 7 mai 2005 00:42
> A : Vanuxem Gregory
> Cc : Mike Thomas; address@hidden; Gcl-Devel
> Objet : Re: [Gcl-devel] Re: Dynamic Library Linking (arbitray float)
>
>
> Greetings!
>
> Vanuxem Gregory <address@hidden> writes:
>
> > Hi,
> >
> > Some correction about this incomprehensible e-mail.
> >
> > >
> > >
> > > Greetings!
> > >
> > > Vanuxem Gregory <address@hidden> 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?

A new multiple-precision floating-point class.


>
> >
> > >
> > > 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.

The set of integers is implemented in GCL.
The set of rationals is formally implemented i.e. Fraction over Integer.
The set of reals is computationally implemented i.e. floating point number.

These three types are frequently used and therefore
can be implemented in GCL.

This allow:

performance and memory (probably) enhancement
 (for example integer * real).
simpler interface if someone want to use some library.


Finally, these types are well known and the implementation
can be hidden.

>
> > > >
> > > > 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?

Can be.


Cheers,

Greg

>
> > >
> > > > 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
> > > address@hidden 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 : address@hidden
> > > > [mailto:address@hidden la part de
> > > > Camm Maguire
> > > > Envoye : jeudi 5 mai 2005 21:02
> > > > A : Mike Thomas
> > > > Cc : address@hidden
> > > > Objet : [Gcl-devel] Re: Dynamic Library Linking
> > > >
> > > >
> > > > Greetings!
> > > >
> > > > "Mike Thomas" <address@hidden> 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
> > > address@hidden
> > > >
> > >
> ==========================================================================
> > > > "The earth is but one country, and mankind its citizens."  --
> > > Baha'u'llah
> > > >
> > > >
> > > > _______________________________________________
> > > > Gcl-devel mailing list
> > > > address@hidden
> > > > http://lists.gnu.org/mailman/listinfo/gcl-devel
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > > --
> > > Camm Maguire
> address@hidden
> > >
> ==========================================================================
> > > "The earth is but one country, and mankind its citizens."  --
>  Baha'u'llah
> > >
> >
> >
> >
> >
> > _______________________________________________
> > Gcl-devel mailing list
> > address@hidden
> > http://lists.gnu.org/mailman/listinfo/gcl-devel
> >
> >
> >
>
> --
> Camm Maguire                                          address@hidden
> ==========================================================================
> "The earth is but one country, and mankind its citizens."  --  Baha'u'llah
>