Re: ANN: Schelab or numerics for Scheme -- prototype

[Tel <telford@eng.uts.edu.au>]

>   After a weak of hard work I'm proud to announce that the prototype for
> Schelab, a numerical analysis library for Scheme is out. Currently only
> simple operations on matrices, such as addition, subtraction and
> products are implemented, but up from now it is easy to add any new
> feature.
>   Schelab is being developed on MzScheme, Guile 1.2 (buggy) and Gambit-C
> 3.0.

I've had a read through your docs and you have a lot of interesting and
good ideas. I haven't got it up and running yet because I don't have
Maroon-V3 (and I'm not familiar with how it works).

I like the way you do the tensor index as a list so that arbitrary
dimensions of tensor can be handled. My matrix is always 2D (even if it
is a 1D vector it is 2D) but I didn't think of the idea of using a list
until I saw you do it. I might change mine over sometime.

I don't quite follow the idea of `coercers'. It seems that you are
saying that every foreign object must have a scheme equivalent.
Now I'll admit that the scheme data types are quite versatile but
suppose you are storing sparse matricies of the order of 10000x10000 size
but with only 5 to 10 non-zero elements in each row. There is no problem
storing it as a foreign object but when you use a coercer it tries to
force it into a scheme vector and blows out the memory. You could have
the coercer consider several possible translation options and choose the
one it likes best but then you have foreign objects
translating into several scheme representations. Worse, everything that
uses a foreign object has to fiddle with several representations.

Anyhow, I see pitfalls here without a lot of careful thinking.

Another thing that I like is the idea of doing all FORTRAN foreigns
through a thing called fortran-call and then using a scheme declaration
to generate wrappers in scheme. It results in a very neat way of handling
foreign functions, especially the way it does type checks in scheme
but is a problem regarding efficiency: You convert everything into pointers
to foreign data which requires that you malloc many small blocks for temporary
data and then free them after each call. Wrappers written in C will do this
on the stack which is much quicker (and doesn't depend on the garbage
collector to clean up the temporary space). Maybe this is not such a big
issue but the general idea is to avoid generating garbage where possible.

On the subject, the way that C uses the stack for local variables
is a very powerful and efficient system. In guile the local variables
within a let or a function are stored in much the same way as other
variables which implies that every time you enter a (let) and have
a bunch of variables declared, you generate a bunch of garbage even
though you know that they are only temporary variables.

Very clever use of recursion and `functional programming' often
eliminates the need for let but leads to some mind-bending code
(and still the function argument bindings will surely generate garbage too).
Is there a way for scheme to make more effective use of the stack?
Would this spoil the clean structure of the language?
Even if it introduced the same hole that C suffers (i.e. return()ing
a pointer to the stack and having the contents clobbered)
I for one would be willing to wear that.

Have I got the right idea of what is going on here or has this issue
already been taken care of?

	- Tel