Guile Mailing List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Guile numerical work and uniform arrays
> Jim Blandy <email@example.com> writes:
> > Okay, so here's the $64k question:
> > Do you want all of "the basic machine types" available for use in
> > uniform arrays?
> > Or do you want all of "the types corresponding to the C and FORTRAN
> > types" available?
> > 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"?
> Dunno about Clark, but I want the latter.
> > Is the purpose to mesh with libraries written in C or FORTRAN, or to
> > have exact control over the bytes?
> I think that co-existing nicely with C is the purpose of Guile. So
> having "more" control on bytes than C or FORTRAN on the same
> architecture whould be pointless and, um, surprising.
But you need it for some non-computational uses of uniform arrays,
particularly if you want to use uniform-array-read! and
uniform-array-write to generate binary files, but you want them in a
format portable between architectures. I think the right answer is
that you might want either a C `int' or exactly a 32-bit
quantity. Actually, if you want to be portable you also care about
endianness, so maybe uniform array operations are not the best basis
for binary I/O.
> > > 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?
> I can't think of exact reasons to shout "NO!", but that is what I want
> to do. When things start to smell like C++, I get wary,
> I think Guile should have the concept of "indirect" uniform vectors.
> These can appear in several situations: a pointer to something managed
> by C, a sub-vector of an existing vector, or as a "handle" to a
> vectored field of a record (heh, I had it all working here and then
> broke it :-().
> In all the above situations, Guile's GC should have no control over
> the indirect vector.
Hmm, that solves the cases of "the array must free the momory" or "the
array must not free the memory", but what about more complicated
situations, where e.g. the array memory is part of some bigger data
structure and this is the only reference to it, so you want to free it
when the array gets GC'd?
Guile Home |
Main Index |