858 replies to this topic

[Orwell]

yes, yes, yes!

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 later

[Orwell]

Hmm, there is a strange problem when I execute a script, I cannot get the returned symbols
I will let it for later then.

I need to write a few words in CPLua's function list now

[Orwell]

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

[PAP]

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

Wow, time for testing. As I said, I'm planning to convert all matrix-related 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.
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.

[PAP]

I'm afraid that I don't understand some things concerning the "mat" package:

(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: row-wise or column-wise? (I prefer column-wise, 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?

[Orwell]

(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.

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.

(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".

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...

But 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.

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?
Thus currently to get the correct size of your matrix A, you have to write "sr, sc = size(A)".

(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.

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

[PAP]

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?

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...

Nice catch

Bug-hunting is one of my hobbies, especially if someone else will correct them .

[Orwell]

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 .

I had written

* d1, d2, ... = mat.size(matrix)
// Return the size of each dimension of a matrix

in the file functions.txt, but yes, I know, I really need to write a decent documentation

(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: row-wise or column-wise? (I prefer column-wise, as it's done in Fortran, but this is not really important).

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 row-wise or column-wise 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?

Btw, mat.mul (matrix multiplication) is missing. Are you planning to add it later?

So you didn't try to simply perform ordinary operations on the matrices?

[PAP]

but yes, I know, I really need to write a decent documentation

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.

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 row-wise or column-wise 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, 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 column-wise, should return {{1,4},{2,5},{3,6}} (creates a 3x2 matrix with elements taken by A column-by-column); if implemented row-wise, 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).

So you didn't try to simply perform ordinary operations on the matrices?

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}}):
(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 A-B works element-by-element, 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 "element-by-element" 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=A2[{}] 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.

[Orwell]

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).

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.

(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".

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.

(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.

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

(3) [font=Courier New]A+B[/font] and [font=Courier New]A-B[/font] works element-by-element, 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 "element-by-element" 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

(4) B=A2[{}] should return {4,5,6}, but returns {1,2,3}. More worse than that, print(A[{}][ 1 ]) sometimes returns {{},{}}, sometimes causes a fatal error .

Wah
* ... 5 minutes debugging... *
.
Okay this is a problem in the "tostring" operation, not on the manipulation of the matrix: A2[{}] 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

[Orwell]

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...
However, the matrices are now printed correctly, the 'resize' function returns a resized copy, and you can perform additions/substractions between matrices and scalars.

[PAP]

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.

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.
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?"

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.

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.
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?

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

Believe me, it will be very convenient. Don't forget to implement subtraction and division by a scalar, too.

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

Well, see it from another point of view: the + and - operators can be used to perform matrix addition element-by-element, 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 element-by-element way. Afterall, it will be rather strange, if A+B and A-B is valid, but A/B is not, and A*B does a totally different thing .

Okay this is a problem in the "tostring" operation, not on the manipulation of the matrix: A2[{}] indicates the second row correctly, it just prints something stupid. But it should be easily fixed

Yes, I noticed that the fatal error occurs when trying to print A2[{}], 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.

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...

Please, think of it again, and consider how * and / is used in matrix-oriented languages.

However, the matrices are now printed correctly, the 'resize' function returns a resized copy, and you can perform additions/substractions between matrices and scalars.

Ehm, what about divisions?

[Orwell]

Well, take a pencil and a paper, and write 1000 million times: "Lua is not C".

Okay, but I guess you will have to wait a little bit for the next release of CPLua then =)

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 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

Btw, what if you want to fill a matrix with a constant?

That's why I said that A[{}][{}]=33 was ok

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).

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?
I will try to add an error message if the specified table has incorrect size though.

Well, see it from another point of view: the + and - operators can be used to perform matrix addition element-by-element, 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 element-by-element way. Afterall, it will be rather strange, if A+B and A-B is valid, but A/B is not, and A*B does a totally different thing .

It seemed to me that Matlab performs an ordinar algebric matrix multiplication (thus, not element-by-element), 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 matrices

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.

It would, it is in my to-do list But it is not the first entry

Please, think of it again, and consider how * and / is used in matrix-oriented languages.

*Still thinking* :/

[PAP]

Okay, but I guess you will have to wait a little bit for the next release of CPLua then =)

Noooooo! Don't write it 1000 million times then.

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 don't wish to debate again about this as well, so I won't answer to your arguments, although one can mention some counter-arguments. 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).

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?

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) .
Well, since A[{}][{}]=33 is valid, there is no need for any "fill" function.

It seemed to me that Matlab performs an ordinar algebric matrix multiplication (thus, not element-by-element), but I didn't use it for a long time so I can be wrong.

There is surely a way to perform both element-by-element 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 element-by-element 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 element-by-element 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.

However, this "rather strange" behaviour is the default comportement of the CP's matrices

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".

*Still thinking* :/

Wish you will take the "right" decision...

[unique33]

fatal error :

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 .

[Orwell]

I would rather say that you're doing something very dangerous... the "math.tan" function is not defined in PI/2 for example, and you are evaluating it around this value; thus you are giving some unexpected (and quite high) values to draw.pixel (and thus the program is happily drawing points somewhere else in the memory, and your CP does not like it very much )
But it's okay, I will add a test to prevent this problem.

[Orwell]

I uploaded CPLua 0.73 RC2.

All matrix operations work now element-by-element, 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}

[CrimsonCasio]

ok, that actually works better for my purposes

[unique33]

please change the download link when there is a new release . thanks.

[Orwell]

I don't wish to do it
But why are you asking for that?

[unique33]

I mean the post in the download Cplua topic .

[PAP]

I mean the post in the download Cplua topic .

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.

[Orwell]

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

[PAP]

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

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.

Thanks for implementing all element-by-element 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).

[Orwell]

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.

I finally gave the two links in the topic.

Thanks for implementing all element-by-element 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!

Well, it's good to know

(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.

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

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.

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

(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).

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

[PAP]

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

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" .

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

It's ok, although it will be more "robust", if mat.new could also handle matrices.

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

Nice.

[Orwell]

Oops, I completely forgot the '==' operator Thanks for your remark I will work on it right now
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 add-in; 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

[PAP]

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'm not surprised; CPLua is obviously the largest Add-In ever made . You should be proud of it.

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.

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.

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

Cheater!
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}).

But Is it really more robust to write "B=mat.new(2,3,A)" instead of "B=mat.new(A)"?

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.

[unique33]

"*" sign in draw.text have a problem.
====================================
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)

[unique33]

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.

yeah . It was exactly what I wanted to say.

I finally gave the two links in the topic.

nice.

[PAP]

I have started converting matrix-related LuaNumAn scripts, so that they will use matrices instead of tables. I started from LUdecom, and everything was ok, until I encountered an ugly error in computing the inverse matrix (I know that it is implemented in the "mat" package, but I want to convert the old code nevertheless). Now, the natural implementation of the function LUinverse in CPLua 0.73 is:

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]=foo

everything 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 .

[Orwell]

I think I know what's happening, but I'm not at home so I can't test it right now.
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

[Orwell]

"*" sign in draw.text have a problem.

What kind of problem?

what is your Idea about draw.title? (...)

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
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

[PAP]

Is it possible to implement "elemental" functions? That is, functions that can act on matrices, taking as arguments each element of the matrix? For example, if A=mat.new(3,{4,5,6}) then math.sin(A) will return the matrix {sin(4),sin(5),sin(6)}; if f(x) is a user defined function, then f(A) should return {f(4),f(5),f(6)}. Of course, this can be easily done with a loop (or nested loops, if there are more dimensions in the matrix), but "elemental" functions will be very useful in a more complex assignment between matrices. I don't know if it can be implemented, though.

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

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.

[unique33]

Orwell :
what kind of problem ?

the "*" sign (graphic) is something different in the output window. ( in draw.text)

Orwell :
there is no need for draw.title

yeah .you are right.

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.

[Kilburn]

I noticed something a bit strange:what is the difference between draw.point() and draw.pixel() ?

[Orwell]

I noticed something a bit strange:what is the difference between draw.point() and draw.pixel() ?

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.
In term of C++, draw.point() calls the (heavy) function PegThing::Rectangle(), and draw.pixel() only performs a bitwhise OR on the screen

[unique33]

what,s your Idea about making a new topic for Suggestions ?
and the current topic would become fo bug reports and ....

[unique33]

Suggestion :

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^2-y^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))/(x-y), {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 non-negative integer assignments to the variables _NNn~,
and for all binary assignments to the variables _Bn~.

. Examples

> 
> discont(round(3*x-1/2),x);
						  / 1   1	 \ 
						 {  - + - _Z1~ }
						  \ 3   3	 / 
> discont(GAMMA(x/2),x);
						   {-2 _NN1~}

> discont(arctan(1/2*tan(2*x))/(x^2-1),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 left-res/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 (right-left)/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*x-1/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^2-1),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/(x-1)+1/(x-985/1000)+1/(x-3),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

-----------------------------------------------------------------------------------------------------------------------

[CrimsonCasio]

having another problem now, ive altered my code so that "stage" is an array returned from file "stage1" via doscript().
map={}
stage={}
...
...
stage=dpscript("Runner/stage1")
print(stage11) // 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(stage111) right after the map.Load() when i know that it just printed 99... any thoughts on what im doing wrong here?