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

[Vanuxem Gregory]

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

>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
> address@hidden 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 : 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
>