This is the mail archive of the guile@cygnus.com mailing list for the guile project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
> 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