I'm currently trying to perform the small changes about the 'doscript', 'require' and 'export' functions. If it takes me more than 20 minutes, I will release the current version and include those changes lateryes, yes, yes!
Project: Cplua
#321
Posted 23 October 2005  03:56 PM
#322
Posted 23 October 2005  04:33 PM
I will let it for later then.
I need to write a few words in CPLua's function list now
#323
Posted 23 October 2005  05:11 PM
CPLua Version 0.73 RC1 is now available.
Note that this is only a Release Candidate, so I let us a little time to discover the possible awful bugs that should be corrected before the real release of the version 0.73
Naturally, it would be better if there was no bugs at all, but we never know
#324
Posted 23 October 2005  07:18 PM
Wow, time for testing. As I said, I'm planning to convert all matrixrelated numerical methods, so that they will use the "mat" package instead of Lua tables; this is a good test. However, it will take some time, and, unfortunately, tomorrow is Monday . Anyway, I'll do my best to complete this task within a few days.Whew, it is ready.
CPLua Version 0.73 RC1 is now available.
Note that this is only a Release Candidate, so I let us a little time to discover the possible awful bugs that should be corrected before the real release of the version 0.73
Naturally, it would be better if there was no bugs at all, but we never know
I think that it is a good idea to keep this release candidate for the whole week, even if you don't get any bug reports. This will give time to all of us to test it.
#325
Posted 23 October 2005  08:29 PM
(1) Suppose that we define a 4x4 matrix by A=mat.new(4,4). Now, printing that matrix reveals that each element is equal to zero. This is not a bug, but I was expecting the matrix A filled with nils, instead of zeros. Wouldn't this be more natural? It will prevent the user to use a matrix before setting its elements; as it is now, if the user forgets to do so (a common error), it will be rather difficult to find the error, especially in large programs.
(2) If A=mat.new(4,5) then type(A) returns "userdata". It's one of the Lua predifined data types, and it's ok, although I was expecting "matrix". Now, try to print mat.size(A); it returns "4 5", which is correct, but type(mat.size(A)) returns "number". I was expecting "userdata" instead. Furthermore, s=mat.size(A) sets s equal to 4, and s is a scalar, not a matrix; the second dimension is lost. This is obvously a bug.
(3) mat.sizedim(A,2) returns "Bad argument #1 to 'sizedim' (number expected, got userdata)". According to the documentation, it should return 5. Suspecting that the arguments of sizedim were inverted by mistake, I tried mat.sizedim(2,A), and I got "bad parameter #1: matrix reference required".
(4) If A=mat.new(2,3,{1,2,3},{4,5,6}}) then print(mat.resize(A,3,2)) prints an empty line (it should print a 3x2 matrix). Furthermore, if foo=mat.resize(A,3,2) then print(foo) returns "nil", and A is changed to {{1,2},{4,5},{0,0}}; I was expecting to leave A untouched, and to set foo to {{1,2},{3,4},{5,6}}. In other words, resize seems to change its first argument, it changes it incorrectly, and it does not seem to return anything. Btw, when you correct this, be sure to explain how the resized matrix will be filled: rowwise or columnwise? (I prefer columnwise, as it's done in Fortran, but this is not really important).
Btw, mat.mul (matrix multiplication) is missing. Are you planning to add it later?
#326
Posted 23 October 2005  09:03 PM
You're right, I announced that nil values would be available for matrix too, but I had to remove it very quickly because it was really horrible to handle. I think that zero values are better than an uninitialized value like 3.64378e38 though, but that's right, nil values would have been even better.(1) Suppose that we define a 4x4 matrix by A=mat.new(4,4). Now, printing that matrix reveals that each element is equal to zero. This is not a bug, but I was expecting the matrix A filled with nils, instead of zeros. Wouldn't this be more natural? It will prevent the user to use a matrix before setting its elements; as it is now, if the user forgets to do so (a common error), it will be rather difficult to find the error, especially in large programs.
Hmmm... in fact, a matrix (like the CAS expressions) is a userdata. I could probably find a workaround to change the string returned by the "type" function for userdata if you want...(2) if A=mat.new(4,5) then type(A) returns "userdata". It's one of the Lua predifined data types, and it's ok, although I was expecting "matrix".
This is not a bug, it is my choice I spent a bit time wondering what solution would be better: distinct values or single array. I know that for example Matlab returns an array for the dimension, but I have never been completely satisfied with it... Suppose you want to get the size of a simple vector: you cannot use the 'n' index anymore (although I will maybe allow it), so you have to call mat.size(), which returns an array; to get the actual size you then have to access the first element of this array, altough it only contains a single valueBut try to use mat.size(A); it returns "4 5", which is correct, but type(mat.size(A)) returns "number". I was expecting "userdata" instead. Furthermore, s=mat.size(A) sets s equal to 4, and s is a scalar, not a matrix; the second dimension is lost. This is obvously a bug.
I supposed that generally you know the dimension of the matrices you are using, so you can use distinct variables to get the size of all the dimensions; and if you don't know how many variables are needed, there is still the sizedim() function. But I agree, it is an arbitrary choice from me  and I could change it easily. is it really needed though?
Thus currently to get the correct size of your matrix A, you have to write "sr, sc = size(A)".
Oops, this time it is really a bug: I wrote "luaL_checkint(L,1)" instead of "luaL_checkint(L,2)" in my code to get the dimension argument. Nice catch(3) mat.sizedim(A,2) returns "Bad argument #1 to 'sizedim' (number expected, got userdata)". According to the documentation, it should return 5. Suspecting that the arguments of sizedim were inverted by mistake, I tried mat.sizedim(2,A), and I got "bad parameter #1: matrix reference required". In other words, mat.sizedim is buggy.
#327
Posted 23 October 2005  09:26 PM
In my opinion, Matlab's (and Fortran's) implementation is preferrable, but it's not really important, provided that you inform us how it works . As for the sizedim function, see my previous post, I've added something for this...This is not a bug, it is my choice I spent a bit time wondering what solution would be better: distinct values or single array. I know that for example Matlab returns an array for the dimension, but I have never been completely satisfied with it... Suppose you want to get the size of a simple vector: you cannot use the 'n' index anymore (although I will maybe allow it), so you have to call mat.size(), which returns an array; to get the actual size you then have to access the first element of this array, altough it only contains a single value
I supposed that generally you know the dimension of the matrices you are using, so you can use distinct variables to get the size of all the dimensions; and if you don't know how many variables are needed, there is still the sizedim() function. But I agree, it is an arbitrary choice from me  and I could change it easily. is it really needed though?
Bughunting is one of my hobbies, especially if someone else will correct them .Nice catch
#328
Posted 23 October 2005  09:40 PM
I had writtenIn my opinion, Matlab's (and Fortran's) implementation is preferrable, but it's not really important, provided that you inform us how it works .
* d1, d2, ... = mat.size(matrix) // Return the size of each dimension of a matrixin the file functions.txt, but yes, I know, I really need to write a decent documentation
Hmm so 'resize' should return a resized copy of the matrix, instead of changing it... Why not. (Note that it was also written in the function list but it seems definitely unclear )(4) If A=mat.new(2,3,{1,2,3},{4,5,6}}) then print(mat.resize(A,3,2)) prints an empty line (it should print a 3x2 matrix). Furthermore, if foo=mat.resize(A,3,2) then print(foo) returns "nil", and A is changed to {{1,2},{4,5},{0,0}}; I was expecting to leave A untouched, and to set foo to {{1,2},{3,4},{5,6}}. In other words, resize seems to change its first argument, it changes it incorrectly, and it does not seem to return anything. Btw, when you correct this, be sure to explain how the resized matrix will be filled: rowwise or columnwise? (I prefer columnwise, as it's done in Fortran, but this is not really important).
I don't really see what is the difference between rowwise or columnwise filling; I just used the most natural way of doing it (if a dimension is "bigger" than before then new elements are added, otherwhise some elements are taken away); should it be different than the current implementation?
So you didn't try to simply perform ordinary operations on the matrices?Btw, mat.mul (matrix multiplication) is missing. Are you planning to add it later?
#329
Posted 23 October 2005  11:11 PM
Indeed, you really need to write a decent documentation. However, I was too hurry to test the new version, and I have felt to the same mistake once again: thinking as in Fortran, I was almost sure that size works as I was expected, and I didn't mentioned the syntax you adopted. Thinking of it again, getting accustomed to one language is not always a good thing, especially if you test another one.but yes, I know, I really need to write a decent documentation
Well, in all languages that I know, "resize" actually "shuffles" the elements of a matrix. For example, if A=mat.new(2,3,{1,2,3},{4,5,6}}) then mat.resize(A,3,2), if implemented columnwise, should return {{1,4},{2,5},{3,6}} (creates a 3x2 matrix with elements taken by A columnbycolumn); if implemented rowwise, it should return {{1,2},{3,4},{5,6}}. But I understand that your implementation is totally different: it is designed mainly to augment a matrix by adding new (zero) elements, and it is perharps more useful in practice. In any case, foo=mat.resize(A,3,2) should not affect A itself; I think that it's very confusing; it should return a new matrix instead. Afterall, if the user wants to convert A itself, he can always write A=mat.resize(A,3,2).Hmm so 'resize' should return a resized copy of the matrix, instead of changing it... Why not. (Note that it was also written in the function list but it seems definitely unclear )
I don't really see what is the difference between rowwise or columnwise filling; I just used the most natural way of doing it (if a dimension is "bigger" than before then new elements are added, otherwhise some elements are taken away); should it be different than the current implementation?
Well, you asked for it . In the following, A is a matrix defined by A=mat.new(2,3,{1,2,3},{4,5,6}}):So you didn't try to simply perform ordinary operations on the matrices?
(1) A[{}][{}]={33} returns {{0,0,0},{0,0,0}}; I think that an error message should be printed in this case, say "expected number, got table/matrix".
(2) B=A+1 does not work. the same holds true for B=math.new(A+1). In general, you cannot add, subtract or devide any scalar from the elements of a matrix this way. Only multiplying a matrix by a scalar is implemented, i.e., B=A*2 works as expected.
(3) A+B and AB works elementbyelement, as it should. However, A*B actually performs matrix multiplication, so that you cannot multiply each element of a matrix with the corresponding element of another (identical in size and dimensions) matrix. I think that the operator * should perform "elementbyelement" multiplication, and matrix multiplication should be performed by a function call, say "mat.mul"; as it is now, it is clearly confusing. Furthermore A/B does not work at all.
(4) B=A should return {4,5,6}, but returns {1,2,3}. More worse than that, [{}]print(A[{}][ 1 ]) sometimes returns {{},{}}, sometimes causes a fatal error .
Well, that is all for now. I think that you should release RC2 first, then we must seek for more bugs. It's natural, bugs are always lurking in a new version, especially if something really new is added. Anyway, I think that the "ultimate" test (converting LuaNumAn so that it will use matrices instead of tables) should wait for a more stable "mat" package.
#330
Posted 24 October 2005  12:17 AM
Okay, I will adopt this point of view then. This is a consequence of my own knowledge of C++: I really need to remember that a function argument in Lua should not be modified by the call of this function This is a very common behaviour in C.In any case, foo=mat.resize(A,3,2) should not affect A itself; I think that it's very confusing; it should return a new matrix instead. Afterall, if the user wants to convert A itself, he can always write A=mat.resize(A,3,2).
In fact, the interpreter expects a table or a matrix, of the same size as the part of the matrix A written at the left of the sign '='. In that case, you should give a 2*3 matrix/table for the new content of 'A[{}][{}]'. But here '{33}' is a simple table and the interpreter cannot guess by himself that the value '33' must be assigned to each element of A. However, 'A[{}][{}]=33' is okay.(1) A[{}][{}]={33} returns {{0,0,0},{0,0,0}}; I think that an error message should be printed in this case, say "expected number, got table/matrix".
Hmm, that's right. I'm just not used to make additions between matrices and scalar, so I didn't implement it. But I agree it could be convenient(2) B=A+1 does not work. the same holds true for B=math.new(A+1). In general, you cannot add, subtract or devide any scalar from the elements of a matrix this way. Only multiplying a matrix by a scalar is implemented, i.e., B=A*2 works as expected.
(3) [font=Courier New]A+B[/font] and [font=Courier New]AB[/font] works elementbyelement, as it should. However, [font=Courier New]A*B[/font] actually performs matrix multiplication, so that you cannot multiply each element of a matrix with the corresponding element of another (identical in size and dimensions) matrix. I think that the operator [font=Courier New]*[/font] should perform "elementbyelement" multiplication, and matrix multiplication should be performed by a function call, say "[font=Courier New]mat.mul[/font]"; as it is now, it is clearly confusing. Furthermore [font=Courier New]A/B[/font] does not work at all.I designed the matrix type as an algebric object, and not really as a programming tool... That's why the algebric operations are implemented like that (that's also why you cannot add a scalar to a matrix or divide a matrix by another). The problem is that you can consider the matrices with two different points of view (programmer or mathematicist (I hope this is the correct spelling)), and there are many things that will seem very confusing for some users or simply natural for other ones, depending on what you want to do
Wah(4) B=A should return {4,5,6}, but returns {1,2,3}. More worse than that, [{}]print(A[{}][ 1 ]) sometimes returns {{},{}}, sometimes causes a fatal error .
* ... 5 minutes debugging... *
.
Okay this is a problem in the "tostring" operation, not on the manipulation of the matrix: A [{}] indicates the second row correctly, it just prints something stupid. But it should be easily fixed
Thanks for your help, like you suggested it there will be an RC2 soon
#331
Posted 24 October 2005  08:02 AM
However, the matrices are now printed correctly, the 'resize' function returns a resized copy, and you can perform additions/substractions between matrices and scalars.
#332
Posted 24 October 2005  08:16 AM
Well, take a pencil and a paper, and write 1000 million times: "Lua is not C". I will also take a pencil and a paper, and I will write 1000 million times: "Unfortunately, Lua is not Fortran" . As I said before, getting accustomed to one programming language is not a good thing, if you try another one.Okay, I will adopt this point of view then. This is a consequence of my own knowledge of C++: I really need to remember that a function argument in Lua should not be modified by the call of this function This is a very common behaviour in C.
Now, seriously, I know that, in C, a function can modify any of its arguments. In most languages, however, this is strictly forbidden, since you can use subroutines for this, instead of functions. Usually, a function is considered as a mathematical object, and, as such, it returns a result, but it cannot modify any argument. When I saw for the first time that in C this is not the case, and that there are no pure subroutines, I said "Baaah! How can they even think that this is the language?"
I know that the interpreter expects a matrix, and A[{}][{}]={33} is clearly an error, but the interpreter should detect this, and print an appropriate error message. As it is now, it will be realy hard to find the error in a large program.In fact, the interpreter expects a table or a matrix, of the same size as the part of the matrix A written at the left of the sign '='. In that case, you should give a 2*3 matrix/table for the new content of 'A[{}][{}]'. But here '{33}' is a simple table and the interpreter cannot guess by himself that the value '33' must be assigned to each element of A. However, 'A[{}][{}]=33' is okay.
Btw, what if you want to fill a matrix with a constant? Of course, you can use loops for this, but I think that an automatic fill machanism can be easily implemented: for example, A=math.new(3,2,33) should be vallid, and should return a 3x2 matrix with all elements equal to 33 (similar to the Matlab's functions ones and zeros, but more sophisticated).
Edit: Well, A=math.new(3,2,33) is not a good idea, since it creates a 3x2x33 matrix, as it should. But what about a new function B=math.fill(A,33) which returns a matrix B with dimensions as in A, but with all elements equal to 33?
Believe me, it will be very convenient. Don't forget to implement subtraction and division by a scalar, too.Hmm, that's right. I'm just not used to make additions between matrices and scalar, so I didn't implement it. But I agree it could be convenient
Well, see it from another point of view: the + and  operators can be used to perform matrix addition elementbyelement, so the operators , *, and / should act in a similar way. You are right, matrices can be viewed as a programming or a mathematical tool, but in MatLab, Mathematica, Scilab, and ... Fortran, all basic arithmetic operators act in an elementbyelement way. Afterall, it will be rather strange, if A+B and AB is valid, but A/B is not, and A*B does a totally different thing .I designed the matrix type as an algebric object, and not really as a programming tool... That's why the algebric operations are implemented like that (that's also why you cannot add a scalar to a matrix or divide a matrix by another). The problem is that you can consider the matrices with two different points of view (programmer or mathematicist (I hope this is the correct spelling)), and there are many things that will seem very confusing for some users or simply natural for other ones, depending on what you want to do
Yes, I noticed that the fatal error occurs when trying to print A, not when evaluating it. Btw, wouldn't be useful to add a more sophisticated printing function, such as [{}]printf for formatted printing? I think that it will be very easy to do this.Okay this is a problem in the "tostring" operation, not on the manipulation of the matrix: A
[{}] indicates the second row correctly, it just prints something stupid. But it should be easily fixed
Please, think of it again, and consider how * and / is used in matrixoriented languages.Every problems have been corrected, there is just the '*' operation that I didn't replace because I'm not sure if it is a good idea or not...
Ehm, what about divisions?However, the matrices are now printed correctly, the 'resize' function returns a resized copy, and you can perform additions/substractions between matrices and scalars.
#333
Posted 24 October 2005  08:35 AM
Okay, but I guess you will have to wait a little bit for the next release of CPLua then =)Well, take a pencil and a paper, and write 1000 million times: "Lua is not C".
I don't wish to debate again about this (altough we could), but the main advantage of the C language here is the fact that you don't have to make a copy of an object just to modify it: in most case, this is really importantWhen I saw for the first time that in C this is not the case, and that there are no pure subroutines, I said "Baaah! How can they even think that this is the language?"
That's why I said that A[{}][{}]=33 was okBtw, what if you want to fill a matrix with a constant?
So how can I see the difference between a 3*2 matrix filled with 33's and a 3*2*33 matrix filled with zeros then?Of course, you can use loops for this, but I think that an automatic fill machanism can be easily implemented: for example, A=math.new(3,2,33) should be vallid, and should return a 3x2 matrix with all elements equal to 33 (similar to the Matlab's functions ones and zeros, but more sophisticated).
I will try to add an error message if the specified table has incorrect size though.
It seemed to me that Matlab performs an ordinar algebric matrix multiplication (thus, not elementbyelement), but I didn't use it for a long time so I can be wrong. However, this "rather strange" behaviour is the default comportement of the CP's matricesWell, see it from another point of view: the + and  operators can be used to perform matrix addition elementbyelement, so the operators , *, and / should act in a similar way. You are right, matrices can be viewed as a programming or a mathematical tool, but in MatLab, Mathematica, Scilab, and ... Fortran, all basic arithmetic operators act in an elementbyelement way. Afterall, it will be rather strange, if A+B and AB is valid, but A/B is not, and A*B does a totally different thing .
It would, it is in my todo list But it is not the first entryBtw, wouldn't be useful to add a more sophisticated printing function, such as printf for formatted printing? I think that it will be very easy to do this.
*Still thinking* :/Please, think of it again, and consider how * and / is used in matrixoriented languages.
#334
Posted 24 October 2005  09:54 AM
Noooooo! Don't write it 1000 million times then.Okay, but I guess you will have to wait a little bit for the next release of CPLua then =)
I don't wish to debate again about this as well, so I won't answer to your arguments, although one can mention some counterarguments. Afterall, this seems to be an endless conversation without any sense: it is 100% sure that you won't change your mind, and the same holds true for me as well. A chacun son language . I promise that I will never compare C and Fortran again (but I cannot guarantee that I will keep my promise; sometimes I cannot resist that temptation).I don't wish to debate again about this (altough we could), but the main advantage of the C language here is the fact that you don't have to make a copy of an object just to modify it: in most case, this is really important
I know, I know, I already noticed it, and edited my previous post accordingly. I was in a hurry again (damn weekend, it doesn't last forever) .So how can I see the difference between a 3*2 matrix filled with 33's and a 3*2*33 matrix filled with zeros then?
Well, since A[{}][{}]=33 is valid, there is no need for any "fill" function.
There is surely a way to perform both elementbyelement and matrix multiplication in Matlab. However, I don't use Matlab anymore, I prefer Scilab (http://scilabsoft.inria.fr), because it is free software, it is french, and it runs on <{GNULINUX}>: there are two multiplication operators, ".*" and "*". The first performs matrix multiplication, the second elementbyelement multiplication. I think that the same holds true in Matlab. Anyway, I think that the user should have some automated (without loops) way to perform elementbyelement multiplication, so that Fo...For...Fort... huh, Fortran's approach is more convenient ("*" acts as I proposed, and matrix multiplication is done via a function matmul). That way, both operations are possible, and there is no confusion between + and * behavior.It seemed to me that Matlab performs an ordinar algebric matrix multiplication (thus, not elementbyelement), but I didn't use it for a long time so I can be wrong.
Yes, but who said that ClassPad's CAS is perfect? It's not even decent . We are trying to make a better language for ClassPad, don't we? In this case, "better" means "with more capabilities".However, this "rather strange" behaviour is the default comportement of the CP's matrices
Wish you will take the "right" decision...*Still thinking* :/
#335
Posted 24 October 2005  11:32 AM
try this code:
require("draw") showgraph() for i=0,6.26,.01 do draw.point(80+50*math.tan(i),80+20*math.tan(i)) end for i=0,6.26,.01 do draw.pixel(80+50*math.tan(i),80+20*math.tan(i)) end waitkey(K_EXE)
draw.pixel have a problem .
#336
Posted 24 October 2005  11:36 AM
But it's okay, I will add a test to prevent this problem.
#337
Posted 24 October 2005  02:09 PM
All matrix operations work now elementbyelement, and there is now a "mat.mul" function for the algebraic multiplication of 2 matrices.
Note that it is now forbidden for a runnable script to use the "export" function; only the chunks called with "require" may export symbols to the calling chunk. However, the doscript() function can now return the values returned by the script after its execution, if there is any.
Thus Crimson, in the code I gave you yesterday there should be some changes:
///////// File "Runner/stage1": function init() local stage = { {...}, test=1 } return stage end return init  now we return this function ///////// File "Runner/lib": do local current  an interesting trick :) function loadStage(i) if current~=i then  print("loading stage "..i) initStage = doscript("Runner/stage"..i)  and we catch it here current=i end return initStage end end export{loadStage=loadStage}
#338
Posted 24 October 2005  06:37 PM
#339
Posted 24 October 2005  10:56 PM
#340
Posted 24 October 2005  10:58 PM
But why are you asking for that?
#341
Posted 24 October 2005  11:01 PM
#342
Posted 25 October 2005  11:23 AM
The link in the download topic points to the current version, 0.73 RC2, i.e., it is correct. However, the latest version referred to the topic is 0.72, and there is no link for this. This might be confusing for someone who wants to download CPLua for the first time (he thinks that the link refers to version 0.72, which is not true). That's probably what unique33 wants to say. Maybe it will be better if Orwell adds a link for the latest "stable" version, which is 0.72. However, every version until now is considered as "beta", and that's probably the reason for linking the latest version.I mean the post in the download Cplua topic .
#343
Posted 25 October 2005  11:26 AM
I will change it to points to CPLua 0.72
#344
Posted 25 October 2005  12:52 PM
How one will be able to download version 0.73 RC2 then? I think that you should leave it as it is, or add two links, one for 0.72 and one for 0.73.RC2.That's true, I must say I forgot this link when I uploaded the latest versions of CPLua
I will change it to points to CPLua 0.72
Thanks for implementing all elementbyelement matrix operations, operations between matrices and scalars, and adopting a mat.mul implementation of matrix multiplication. You can't imagine how shorter LuaNumAn scripts will become now!
Some remarks:
(1) If A=mat.new(2,3,{1,2,3}{4,5,6}) then A[{}][ 2 ] is equal to {2,5}; this is not a bug; although one could expect {{2},{5}}, it is perharps preferable as it is. However, mat.dim(A[{}][ 2 ]) returns 1, instead of 2. Furthermore, B=mat.new(A[{}][ 2 ]) is valid, but B=mat.new(1,2,A[{}][ 2 ]) is not, probably because, in the latter case, the third argument is expected to be a table, not a matrix.
(2) As I said before, A=mat.new(2,3,{33}) is, of course, incorrect, but CPLua does not stop execution; it simply returns {{0},{0},{0}}, i.e., the same as A=mat.new(2,3). In other words, it does not check its third argument (in this case, it should print an error message). This is a potential source of errors, which are difficult to catch in a large program. For example, if you type, by mistake, A=mat.new(3,1,{2,4,8}], instead of A=mat.new(1,3,{2,4,8}], you will get a 3x1 vector filled with zeros. Of course, this is a programmer's error, not a bug, but it is easy to do such an error. I think that you should add argument checking, as in print(A[{}][ 4 ] (which stops execution, and prints a useful error message), or mat.mul(A,A) (which also stops execution, and reports that matrix multiplication cannot be done).
#345
Posted 25 October 2005  01:07 PM
I finally gave the two links in the topic.How one will be able to download version 0.73 RC2 then? I think that you should leave it as it is, or add two links, one for 0.72 and one for 0.73.RC2.
Well, it's good to knowThanks for implementing all elementbyelement matrix operations, operations between matrices and scalars, and adopting a mat.mul implementation of matrix multiplication. You can't imagine how shorter LuaNumAn scripts will become now!
Hmmm... In the way I implemented it (and the whole package is based on it), 'A[{}][ 2 ]' is considered exactly like a simple 1D matrix, because you only let one dimension free. This is why it prints the text '{2,5}' and why the mat.dim function returns 1 and not 2. I think everything is coherent, supposed that we know exactly what is done If something seems very strange though, don't hesitate to ask me(1) If A=mat.new(2,3,{1,2,3}{4,5,6}) then A[{}][ 2 ] is equal to {2,5}; this is not a bug; although one could expect {{2},{5}}, it is perharps preferable as it is. However, mat.dim(A[{}][ 2 ]) returns 1, instead of 2.
That's right, I didn't consider the case where you pass a matrix after the dimensions, simply because you can write 'B=mat.new(A[{}][ 2 ])' (or 'B=mat(A[{}][ 2 ])') directly; since it is possible to get the dimensions of a matrix directly (that's not the case of the tables) there is no need to specify it in the mat.new functionFurthermore, B=mat.new(A[{}][ 2 ]) is valid, but B=mat.new(1,2,A[{}][ 2 ]) is not, probably because, in the latter case, the third argument is expected to be a table, not a matrix.
It seems like I forgot to add this error message in CPLua 0.73RC2 but it is easy to do so it should be okay(2) As I said before, A=mat.new(2,3,{33}) is, of course, incorrect, but CPLua does not stop execution; it simply returns {{0},{0},{0}}, i.e., the same as A=mat.new(2,3). In other words, it does not check its third argument (in this case, it should print an error message).
#346
Posted 25 October 2005  02:44 PM
As I said, the fact that A[{}][ 2 ] is considered as a simple 1D matrix is not a problem at all. Btw, would't be useful to implement good equality test of matrices? As it is now, mat.new(2,{3,5})==mat.new(2,{3,5}) returns "false" . Furthermore, A==A returns "true", but, if B=mat.new(A) then B==A returns "false" .Hmmm... In the way I implemented it (and the whole package is based on it), 'A[{}][ 2 ]' is considered exactly like a simple 1D matrix, because you only let one dimension free. This is why it prints the text '{2,5}' and why the mat.dim function returns 1 and not 2. I think everything is coherent, supposed that we know exactly what is done If something seems very strange though, don't hesitate to ask me
It's ok, although it will be more "robust", if mat.new could also handle matrices.That's right, I didn't consider the case where you pass a matrix after the dimensions, simply because you can write 'B=mat.new(A[{}][ 2 ])' (or 'B=mat(A[{}][ 2 ])') directly; since it is possible to get the dimensions of a matrix directly (that's not the case of the tables) there is no need to specify it in the mat.new function
Nice.It seems like I forgot to add this error message in CPLua 0.73RC2 but it is easy to do so it should be okay
#347
Posted 25 October 2005  02:52 PM
But Is it really more robust to write "B=mat.new(2,3,A)" instead of "B=mat.new(A)"?
==================================================================
During the evaluation of CPLua 0.73RC2, I'm preparing the new major modifications or improvements for the next version. As I already said, it generally concerns the structure of my code (I want to modularize it as much as possible), thus there shouldn't be many visible changes, from the user's point of view.
Just for your information, the entire CPLua project comprises currently something like 23200 lines of C/C++ code, split in 86 files, for more than 600 Kb of code.
Altough 10550 lines from this total concern the core of the Lua interpreter, that I didn't write myself and on which I would like to avoid modifications as much as possible, it's starting to be a consistent project
I don't have any problem to handle it for now, but I think it could be rather uneasy for someone who would like to contribute to CPLua's development by implementing some new features in the addin; that's why I'm trying to present it in a convenient way, and why I do not release the source code yet. I think it will just be more confusing if I release it now, since I'm planning to make some deep changes in it. But it will certainly be available later
Did anyone already take a look on the Lua stuff available on the web, and particularly on the links of this page? I've just seen several interesting things, such as the "tolua" wrapper (which should be really useful), and also the other versions of the Lua Reference Manual. Perhaps I will use one of those 'summaries' and booklets and complete it with the ClassPad's specific stuff for the future documentation of CPLua
#348
Posted 25 October 2005  03:06 PM
I'm not surprised; CPLua is obviously the largest AddIn ever made . You should be proud of it.Just for your information, the entire CPLua project comprises currently something like 23200 lines of C/C++ code, split in 86 files, for more than 600 Kb of code.
Altough 10550 lines from this total concern the core of the Lua interpreter, that I didn't write myself and on which I would like to avoid modifications as much as possible, it's starting to be a consistent project
Wow, cool stuff. There is even a <{GNULINUX}> version of Lua, and, together with its IDE made by eclipse, it makes it a real programming environment, for whoever wants to run Lua on his PC.Did anyone already take a look on the Lua stuff available on the web, and particularly on the links of this page? I've just seen several interesting things, such as the "tolua" wrapper (which should be really useful), and also the other versions of the Lua Reference Manual.
Cheater!Perhaps I will use one of those 'summaries' and booklets and complete it with the ClassPad's specific stuff for the future documentation of CPLua
Now, more seriously, there are many details that you may want to add in this documentation, which are related to CPLua. An example: mat.new(2,{3,5}) is not equivalent to mat.new(1,2,{3,5}).
Of course it's not. But mat.new itself is more robust, if it can handle B=mat.new(A) as well as B=mat.new(2,3,A). But it's not really important: if you can implement it easily, it will be nice; if it needs time, forget it.But Is it really more robust to write "B=mat.new(2,3,A)" instead of "B=mat.new(A)"?
#349
Posted 25 October 2005  10:56 PM
====================================
A suggestion
what is your Idea about draw.title?
consider this Code and see the output screen .
require("draw") showgraph() A=0 B=0 x0=1 y0=20 x=x0 y=y0 draw.title(1,1,"A",space*8,"B",space*8,"A*B") for i=1,5 do draw.text(x,y,A) draw.text(x+35,y,B) draw.text(x+70,y,A*B) x=x0 y=y+20 A=A+1 B=B+1 end waitkey(K_EXE)
#350
Posted 26 October 2005  01:23 AM
yeah . It was exactly what I wanted to say.The link in the download topic points to the current version, 0.73 RC2, i.e., it is correct. However, the latest version referred to the topic is 0.72, and there is no link for this. This might be confusing for someone who wants to download CPLua for the first time (he thinks that the link refers to version 0.72, which is not true). That's probably what unique33 wants to say. Maybe it will be better if Orwell adds a link for the latest "stable" version, which is 0.72. However, every version until now is considered as "beta", and that's probably the reason for linking the latest version.
nice.I finally gave the two links in the topic.
#351
Posted 26 October 2005  01:12 PM
function LUinverse(LU,indx) local n,Ainv,Id if LU~=nil then n=mat.sizedim(LU,1) Id=mat.ident(n) Ainv=mat.new(n,n) for i=1,n do Ainv[{}][i]=LUsubstitute(LU,indx,mat.new(Id[{}][i])) end return Ainv end end(this function calls the function LUsubstitute, which is correct, so I'm not posting it to save space). Unfortunately, the above code does not work. The problem is in the line
Ainv[{}][i]=LUsubstitute(LU,indx,mat.new(Id[{}][i]))which result a runtime error ("Dimension mismatch"). However, the dimensions of Ainv[{}][i] and LUsubstitute(LU,indx,mat.new(Id[{}][i])) are both equal to 1, and both vectors contain the same number of elements . Now, if this line is replaced by
foo=LUsubstitute(LU,indx,mat.new(Id[{}][i])) Ainv[{}][i]=fooeverything is ok. Note that the alternative code does exactly the same thing, except that it uses a temporary variable foo. I really don't get it .
#352
Posted 26 October 2005  03:01 PM
This may come from a really strange behaviour of the lua interpreter itselfs, and I already had several problems with it
Thanks for the report; I will let you know
#353
Posted 27 October 2005  12:17 AM
What kind of problem?"*" sign in draw.text have a problem.
That's true, a function to draw a table would be greatwhat is your Idea about draw.title? (...)
But there are many possibilities, depending on the size/dimensions of the table, the type of its element, the "style" of the frame etc... We should make a standard implementation for this
However I don't know if a specific function is needed to draw the title of the table, since you can get the same result with draw.text and draw.rect
#354
Posted 27 October 2005  12:37 AM
I tried to do such a thing in the console window (it's actually the function MatPrint, included in LuaNumAn), but there is an obvious problem: the ClassPad screen is not wide enough to print even a 4x4 matrix, with elements having several decimal digits. Of course, in the graph window, one can use a smaller font, and a specified format with a fixed number of decimal digits, so it's possible to print wider matrix rows in a single line. But the problem remains. I personally gave up.That's true, a function to draw a table would be great
But there are many possibilities, depending on the size/dimensions of the table, the type of its element, the "style" of the frame etc... We should make a standard implementation for this
#355
Posted 27 October 2005  01:08 AM
Orwell :
what kind of problem ?
the "*" sign (graphic) is something different in the output window. ( in draw.text)
yeah .you are right.Orwell :
there is no need for draw.title
I tried to do such a thing in the console window (it's actually the function MatPrint, included in LuaNumAn), but there is an obvious problem: the ClassPad screen is not wide enough to print even a 4x4 matrix, with elements having several decimal digits. Of course, in the graph window, one can use a smaller font, and a specified format with a fixed number of decimal digits, so it's possible to print wider matrix rows in a single line. But the problem remains. I personally gave up.
this problem can be solved by implementing a horizontal scrollable window .
also orwell said that he has the plan to add the 2D form output which needs horizontal scrolling too.
#356
Posted 28 October 2005  07:28 PM
#357
Posted 28 October 2005  07:37 PM
With draw.point() you can draw a point with a custom width for example, and with draw.pixel() you can only turn a single pixel on or off.I noticed something a bit strange:what is the difference between draw.point() and draw.pixel() ?
In term of C++, draw.point() calls the (heavy) function PegThing::Rectangle(), and draw.pixel() only performs a bitwhise OR on the screen
#358
Posted 28 October 2005  10:44 PM
and the current topic would become fo bug reports and ....
#359
Posted 28 October 2005  11:07 PM
limit[multi]  multidimensional limits
. Calling Sequence
limit(f, points)
limit(f, points, dir)
. Parameters
f  algebraic expression
points  set of equations of the form x=a
dir  (optional) direction
. Description
Given a set of points as its second argument,
limit attempts to compute the limiting value of f in a multidimensional space.
The optional direction dir is applied to all points, and consequently each point will be approached from the same direction;
from the left or right, bidirectional (real), or complex.
If the limit depends on the direction approached, undefined is returned.
A limiting point defined as x=x is ignored.
Examples
> limit((x^2y^2)/(x^2+y^2), {x=0,y=0}); undefined > limit(x+1/y, {x=0,y=infinity}); 0 > limit(x*y, {x=0,y=infinity}); undefined > limit((sin(x^2)sin(y^2))/(xy), {x=0,y=0}); /sin(x ^2)  sin(y^2) \ limit, {x = 0, y = 0} \ x  y /
Suggestion :
Continuity testing :
discont  Find the Discontinuities of a Function over the Reals
fdiscount  Numerically find the discontinuities of a function over the Reals
iscont  test continuity on an interval

discont  Find the Discontinuities of a Function over the Reals
. Calling Sequence
discont(f, x )
. Parameters
f  algebraic expression in x
x  name
. Description
discont returns a set of values where it is possible (not necessarily certain) that discontinuities occur.
This function returns all the discontinuity points over the reals.
This includes the points where the function goes to plus or minus infinity.
Multiple discontinuities may be expressed with the aid of extra variables with the names _Zn~, _NNn~, and _Bn~.
When these variables appear in the answer, the expression f has discontinuities for all integer assignments to the variables _Zn~,
for all nonnegative integer assignments to the variables _NNn~,
and for all binary assignments to the variables _Bn~.
. Examples
> > discont(round(3*x1/2),x); / 1 1 \ {  +  _Z1~ } \ 3 3 / > discont(GAMMA(x/2),x); {2 _NN1~} > discont(arctan(1/2*tan(2*x))/(x^21),x); / 1 1 \ { 1, 1,  Pi _Z2~ +  Pi } \ 2 4 / > discont(1/(sin(x)1/2),x); / 1 2 \ {  Pi +  Pi _B1~ + 2 Pi _Z3~ } \ 6 3 /
fdiscont  Numerically find the discontinuities of a function over the Reals
. Calling Sequence
fdiscont(f, domain, res, ivar, eqns)
. Parameters
f  algebraic expression or a procedure
domain  the domain of interest
res  the desired resolution
ivar  the independent variable name
eqns  optional equations
. Description
fdiscont attempts to return a list of ranges, each of width res,
in which there appears to be a discontinuity in the function or its first derivative.
fdiscont works via the application of divided differences.
This method will not locate point discontinuities,
nor can it differentiate between cusps and singularities or jump discontinuities.
Note that absolute success is not guaranteed.
In addition, ranges may be larger than res due to overlapping results, which are coalesced.
fdiscont can be fooled by dense oscillatory functions (such as sin(500*x) on 0..Pi)  if features are found that are not expected,
the resolution, res, should be made smaller. If too few singularities are found,
res should be made smaller, or in the evalhf case,
the amount of internal storage (see number below) should be increased.
fdiscont uses evalhf when possible. However, in this instance,
the number of ranges returned is limited by the size of the internal work array.
See the number option below to change this limit.
f may be an algebraic expression in ivar, or a procedure.
If f is algebraic, then ivar must be specified in ivar or domain (see below).
If f is a procedure, it may only take one argument, and must return a single value of type realcons.
domain is used to define the domain of interest of f. It may be specified as either of
left..right
ivar = left..right
left and right must be of type realcons. When f is algebraic, the second form above may be used to specify ivar.
Note that the initial evaluation mesh extends at most from leftres/10 to right+res/10 under evalhf,
whereas the range is strictly adhered to under evalf.
res indicates the desired width for returned ranges.
The minimum allowable resolution is given by 10^(evalhf(Digits)+5) under evalhf, and 10^(Digits+2) under evalf.
The maximum resolution for computation is (rightleft)/bins, where bins is the number of bins used when generating the mesh.
If res falls outside of these bounds, it will be internally set to the closer of the two. The default is 0.001.
The available option equations eqns are:
'bins' = nbins
'newton' = b_newt
'number' = num
'order' = ord
'pts' = b_pts
bins = integer
bins indicates the number of bins to be used in the evaluation mesh.
Better results are generally obtained for higher mesh values, but at the expense of efficiency.
It is recommended that bins be an odd number. The default is 21.
newton = true, false
If newton is true, then fdiscont attempts to apply an inverse modified Newton method (secant method) on each of the returned ranges.
This method will not work if f is a procedure. The inverse of f is evaluated under a secant method, to a maximum of twenty iterations.
If successful, the final point is returned, otherwise the original range of interest is returned.
This method generally works best if res is not overly restrictive (i.e. for res of magnitude 10^(1) or 10^(2)). The default is false.
number = integer
number indicates the maximum number of features (ranges) to be stored while working under evalhf mode.
This value will have no effect in evalf mode.
Note that fewer than number features may be returned (even if more exist) due to coalescing by fdiscont of overlapping features.
The default is 20. The global variable _FullFeatures indicates if the internal work array has reached its maximum capacity.
order = integer
order specifies the order of divided differences to use.
The default is 3, as this produces good results without excessive computation.
The minimum order is 2, while the maximum is 7.
pts = true, false
pts indicates if evaluation points should be returned along with features.
If set to true, then coordinates from the evaluation mesh will be stored and returned, up to three levels of recursion.
If true, then output will take the form of a list of two lists, the first being the features,
the second the evaluation coordinates. The default is false.
. Examples
> > Digits := 10: > fdiscont(round(3*x1/2),x=0..1,10^(7)); [ 9 8 [2.90176482619169016 10 .. 2.96232197934016767 10 , 0.333333311503948793 .. 0.333333365118703484, 0.666666634827754456 .. 0.666666688442514421, ] 0.99999997489472380 .. 1.00000000741972572] > fdiscont(GAMMA(x/2),x=10..0,0.0001); [10.0000040115811011 .. 9.99993688041961448, 8.00003684860928743 .. 7.99993619049896676, 6.00005928060314897 .. 5.99993646871883702, 4.00003131597394379 .. 3.99994066358497768, 2.00006127219906915 .. 1.99993363390919954, 0.0000711912818118716527 .. 0.0000100384454261080879] > fdiscont(arctan(1/2*tan(2*x))/(x^21),x=Pi..2*Pi); [2.35651729870959503 .. 2.35595674964007484, 1.00033852530346379 .. 0.999308841270097448, 0.785699586320803167 .. 0.785135697197511196, 0.785071766410837868 .. 0.785849176136740768, 0.999565718968806860 .. 1.00054782837217138, 2.35596458487031768 .. 2.35651728326344356, 3.92674313106993855 .. 3.92733051734023908, 5.49724475356822318 .. 5.49820428173395560] > fdiscont(1/(x1)+1/(x985/1000)+1/(x3),x=0..4,10^(2),newton=true); [0.984999999999999987, 1., 3.] > fdiscont(abs(x/10000),x=1..1,0.001); [] > fdiscont(tan(10*x),x=0..Pi,0.01,newton=true); [0.157079632679489656, 0.471238898038468967, 0.785398163397448279, 1.09955742875642760, 1.41371669411540690, 1.72787595947438644, 2.04203522483336553, 2.35619449019234483, 2.67035375555132414, 2.98451302091030347] sin(75*x) gives features when the resolution is as large as 0.1. > fdiscont(sin(75*x),x=0..Pi,0.1); [0.0530192255545248320 .. 0.109366607410037132, 0.245628531612153867 .. 0.382908172193943241, 0.599252242806429524 .. 0.655100576727008388, 0.765094945444971919 .. 0.820321436916456426, 0.895037182238975215 .. 0.970848606022647664, 1.10423229527544153 .. 1.13763518521840923, 1.35265543902545215 .. 1.57118235731468392, 1.64883259501780311 .. 1.73796893651044560, 1.85430243041642062 .. 1.95325735724170135, 1.98660098849520340 .. 2.11961704070690615, 2.18623087004868787 .. 2.28468705221604740, 2.35999139920419987 .. 2.40379094997954779, 2.44461307262544114 .. 2.53390741448588130, 2.61203054817927915 .. 2.69886870377993036, 2.86183595331357976 .. 2.93870685227911599, 3.03013104808143519 .. 3.12152982185566597] Narrowing the resolution to 0.001 shows there are no features. > fdiscont(sin(75*x),x=0..Pi,0.001); []
iscont  test continuity on an interval
. Calling Sequence
iscont(expr, x = a .. b )
iscont(expr, x = a .. b, 'closed')
iscont(expr, x = a .. b, 'open')
. Parameters
expr  an algebraic expression
x  variable name
a..b  real interval
'closed'  (optional) indicates that endpoints should be checked
'open'  (optional) indicates that endpoints should not be checked (default)
. Description
The iscont function returns true if the expression is continuous on the interval (thus having no poles),
or false if the expression is not continuous. If iscont cannot determine the result it returns FAIL.
The iscont function assumes that any symbols in the expression are real.
By default, or if the optional third argument 'open' is specified, then the interval is considered to be an open interval.
If the optional third argument 'closed' is specified then continuity at the endpoints is checked; specifically under this option,
limit(expr, x = a, right) and limit(expr, x = b, left) must exist and be finite.
The endpoints of the interval must be either real constants or infinity or infinity.
If the endpoints of the interval are ordered with the first value greater than the second,
iscont will reverse them.
. Examples
> iscont( 1/x, x=1..2 ); true > iscont( 1/x, x=1..1 ); false > iscont( 1/x, x=0..1 ); true > iscont( 1/x, x=0..1, 'closed' ); false > iscont( 1/(x+a), x=0..1); FAIL
#360
Posted 29 October 2005  07:51 AM
map={}
stage={}
...
...
stage=dpscript("Runner/stage1")
print(stage ) // prints 99 (i made it 99 just to varify, normally its 0)
...
...
export{map=map,stage=stage} // all this works fine
then in Lib, when i try to use stage it always give me an error saying its a nil cell... even if i use the same print(stage1 ) right after the map.Load() when i know that it just printed 99... any thoughts on what im doing wrong here?
1 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users

Bing (1)