Hi Lutz! Thanks for not top-posting.
On Monday 01 Feb 2010 00:09:38 Lutz Gehlen wrote: > Hi Shlomi, > thank you for your encouraging comments > You're welcome. :-) > On Sunday 31 January 2010 22:03:20 Shlomi Fish wrote: > > Hi Lutz! > > > On Sunday 31 Jan 2010 08:17:40 Lutz Gehlen wrote: > [...] > > > > This is rather a "request for comments" so to > > > speak. So if you have any comments, please let me know. > > > > I don't have any other comments except for thanking you for: > > > > 1. Thanking you for releasing this useful code. > > > > 2. Asking if your module can work with other mathematical APIs on > > > > CPAN such as http://search.cpan.org/dist/PDL/ , > > http://search.cpan.org/dist/Math-GSL/ , > > http://search.cpan.org/search?query=vector&mode=all , etc. > > I think one underlying question is: Did I check if somebody did the > thing already? The question is: Yes, I did and I hope I have not > overlooked anything. OK. > > In a bit more detail: > 1) PDL: Although it's been on my TODO list for a long time, I still > haven't got into PDL. Therefore my module is not integrated into the > PDL framework. However, I think I might not be the only one deterred > by the learning curve of PDL, so there might be people who > appreciate a stand-alone module. You can easily learn a small but usable subset of PDL using one of the tutorials there. It didn't take me a long time to get up and running with it. Of course, I have already learnt Matlab (from my homework assignments at technion.ac.il ) by then, but it still shouldn't be too hard for someone who knows linear algebra basics. > > 2) Math::GSL: At the beginning I intended to use Math::GSL as a back > end for the matrix operations. However, I did not get it installed > on my machine. The issue had already been reported. Now I am using > Math::MatrixReal as back end which works fine. It is still possible > to support Math::GSL as an alternative back end in the future. > However, the algorithm only deals with 3x3 matrices. If performance > is an issue I/O is likely to be the rate limiting step. OK. I should note that making assumptions that I/O is always the bottleneck does not always prove itself to be correct: http://community.livejournal.com/shlomif_tech/20200.html > > 3) Vector modules: As I said, I/O is likely to be the most expensive > part of the whole thing. Therefore, I kept the input of vectors as > simple as possible, and vectors are required to be given as [x, y, > z] ARRAY references. All conversions from various vector formats are > left to the user. However, other import methods can always be added > in the future. I see - nice. Regards, Shlomi Fish > > Thank you for your comments and best regards, > Lutz -- ----------------------------------------------------------------- Shlomi Fish http://www.shlomifish.org/ "Humanity" - Parody of Modern Life - http://shlom.in/humanity Deletionists delete Wikipedia articles that they consider lame. Chuck Norris deletes deletionists whom he considers lame. Please reply to list if it's a mailing list post - http://shlom.in/reply .
