Re: Guile numerical work and uniform arrays

[Clark McGrew <mcgrew@ale.physics.sunysb.edu>]

Hi,

>>>>> "Michael" == Michael N Livshin <mike@olan.com> writes:

    >> That is, what do you want to specify in your Guile code ---
    >> 64-bit IEEE float, or "whatever a C `double' is on this
    >> machine"?

    Michael> Dunno about Clark, but I want the latter.

If I'm hacking together a program I'd certainly use "C double", unless
I needed to handle something bizarre.  However, isn't it possible to
use the actual machine type internally and then have a mapping to the
C types.

BTW: floats may not be the best example to work with since there are
different float formats (I know of two).  I think that integers are a
better illustration of problems that may be encountered.  As far as I
know C does not guarrantee the size of the int types.  I often need
a "4 byte integer" (an int on every machine I work on), but if I read
the ansi standard correctly I really can't count on that.  

    >> Is the purpose to mesh with libraries written in C or FORTRAN,
    >> or to have exact control over the bytes?

Definately mesh with programs and libraries written in other
languages; however, I suspect by the time Guile can mesh with C, C++,
F77, Ada, Smalltalk, (ie. your favorite langauge that implements
"uniform array") it will need a lot of control over the bytes.

    >> > I would also find it very useful if there were a way to get
    >> guile to > treat a region of memory as a uniform array (and not
    >> try to GC the > memory block).  This would let me attach to
    >> large chunks of memory > allocated by other packages.

    >> Should Guile call a hook associated with the array to free its
    >> space?

    Michael> I can't think of exact reasons to shout "NO!", but that
    Michael> is what I want to do.  When things start to smell like
    Michael> C++, I get wary,

I think that sort of routine is an internal implementation detail.  It
might make the code more efficient or something, but as a user I don't
want to know about it.

    Michael> I think Guile should have the concept of "indirect"
    Michael> uniform vectors.  These can appear in several situations:
    Michael> a pointer to something managed by C, a sub-vector of an
    Michael> existing vector, or as a "handle" to a vectored field of
    Michael> a record (heh, I had it all working here and then broke
    Michael> it :-().

    Michael> In all the above situations, Guile's GC should have no
    Michael> control over the indirect vector.

This is exactly what I thinking about.  What I want is a uniform array
where GC will leave the array memory alone.  I'd go for something
simple and stupid like 

/* Make a uve of TYPE using the memory at LOC.  The user is
responsible for insuring LOC exists for as long as necessary and for
deallocating it as necessary */
SCM gh_uve_attach(loc, type); 

/* If VE was created using gh_uve_attach then mark the attached
location as "undefined", otherwise do nothing. */
SCM gh_uve_detach(ve);

Cheers,

Clark