I was wondering what happened to you
I was away, but with my ClassPad. I came back with CP filled with two more complex numerical methods, better plotting functions, and a (small) bug report (see below).
I think I will keep the double type for now.
It's ok for me. Numerical Analysis is (almost) all about double precision.
Btw, I worked on the "mat" package this week-end, I wrote over a thousand lines of C++ code to implement the different functions that PAP suggested and it worked fine but... Well, I had a better idea. I decided to start again from zero with this package; it will take a little time, but I think you will like it
Wow. You didn't lose your time either. Note that LuaNumAn now contains some more matrix-related utility functions (i was forced to write them for this weekend's developement):MatIdent(n)
: returns the identity matrix of size n
: returns the matrix A
: Matrix (or vector) multiplication.
All of them can be implemented easily (MatMul
is a little bit tricky, it needs to detect if an argument is a vector or a matrix). Maybe you will want to add these functions in the matrix library (if you didn't do it already). Note: the new version of LuaNumAn that includes them will be uploaded tomorrow (at least, I hope so - I need to write the documentation of the new numerical methods added this weekend).
About garbage collection: you're right, calling collectgarbage() periodically is really useful; the version 0.72 does it for you now
Indeed, it does it, and it does it very
well!. My non-linear fitting function hanged ClassPad in version 0.71, if you tried to use "large" data tables (more than 80 data points). Now it works very well with much larger tables, without even the need to call the function collectgarbage()
explicitly. Several matrices of 300 elemnts each are not a problem anymore. Good work!
- a draw.pxltest() function is easy to do, no problem
- I will try to create a complete packages for sprites, not only a single function
Bah, game-computing stuff
. The sprite support will be interesting though (but not too much for me).
Bug in the table.copy
function: this function works as expected only for vectors. It copies the table, but only on "level 1", i.e., only if the elements of the table are not tables. Elements in "level 2" or higher are not copied (the hated pointing system works instead). Consider the piece of code:
Now, if table.copy
worked as expected, table A should remain unchanged, but, in fact, this is not true: element in 2nd row, first column of A
is also changed to 4711, because the "copied" table A
is actually a matrix: table.copy
does not copy elements with type="table", it only uses pointers to them. So, if an element of B
is modified, the corresponding element in A
is modified as well. The obvious workaround is to use the following code, instead of a simple table.copy
for i=1,table.getn(A) do
It is, however, longer. Furthermore, the behavior of the function, as it is now, is a potential source of errors. Hopefully, it will be easy to eliminate this bug.
Note: it took me more than 2 hours to figure out what was happening in a program I was writing this weekend. I checked and rechecked everything in the algorithm, it was correct, but the results were wrong
. The problem was the behavior of the table.copy