858 replies to this topic

[PAP]

The only "advantage" of this function would be to be able to save rounded numbers in a file... I can't find any situation where this feature would be really useful

On the other hand, I can imagine such a situation: all my LuaNumAn functions, and the CPLua testing program I'm planning to create . Btw, I was right, adding "tonumber" in FPrintf doesn't solve the problem...

Again, remember that fprintf() (in C) is mainly used to write text files.

I strongly disagree. I have used fprintf plenty of times to save files containing text and numbers. To be honest, I have used the fprintf version of Matlab, but I think it's the same in pure C. Anyway, I will modify the Lua version of fprintf as I said before; it will be more complex than printf, but it will do what i want to do .

[Orwell]

On the other hand, I can imagine such a situation: all my LuaNumAn functions, and the CPLua testing program I'm planning to create .

What's the advantage of writing rounded numbers instead of raw numbers?

[PAP]

What's the advantage of writing rounded numbers instead of raw numbers?

It will permit to compare the saved file with actual results, without be bothering on how many digits are saved by default. It will also permit to remove unecessary decimal digits, where they don't make any sense. Examples: (1) if you want to save percent differences, there is no need to spend memory just to save 16 decimal digits in exponential form, where 2 or 3 digits are enough, (2) it doesn't make sense to save plenty of decimal digits in a numerical result obtained with an accuracy of the numerical method set to, say, 1e-6 (which is the default for several LuaNumAn functions); if the result is accurate to 6 decimal digits, there is no need to save 16 of them.

[Orwell]

You must be aware that a number is not written in ASCII format in a file, but rather in binary mode. Every number take exactly the same size in a file, independtly on their precision.
For example if you do "f:write(3.141592)" this will save the number 3.141592 in the file, but you will never find a string "3.141592" in it; instead, you will find the 8 bytes corresponding to this number, as a double type.
Remember: you are not writing text files.

Futhermore, if you want to compare the results of LuaNumAn with some other results saved in a file, and if you suppose that only the 2 first decimals must be considered, then I think that this rounding operation should be done at the moment of the comparison of the 2 values, not when you write the file

[PAP]

You must be aware that a number is not written in ASCII format in a file, but rather in binary mode. Every number take exactly the same size in a file, independtly on their precision.
For example if you do "f:write(3.141592)" this will save the number 3.141592 in the file, but you will never find a string "3.141592" in it; instead, you will find the 8 bytes corresponding to this number, as a double type.
Remember: you are not writing text files.
Futhermore, if you want to compare the results of LuaNumAn with some other results saved in a file, and if you suppose that only the 2 first decimals must be considered, then I think that this rounding operation should be done at the moment of the comparison of the 2 values, not when you write the file

Well, the name "binary files" says it all. It is more than obvious that text files would be much more convenient, but at least we now have a way to save and load data, even if it is implemented using binary files. I have to learn to live with it, as I did with the prehistorical "loops for everything" concept...

[Orwell]

It is more than obvious that text files would be much more convenient

Well, this is your opinion We'll wait for the comments of the other users to see if text files are really needed

By the way, I'd like you to give me an easy way to save tables/matrices in a text file

[PAP]

By the way, I'd like you to give me an easy way to save tables/matrices in a text file

Horribly easy. For example, a N x N matrix is saved row by row (formatted saving is useful here, in order to save the matrix in a "pretty way"). After saving, you can open the file using a text editor, and see its contents as a real matrix. Now, my turn: I'd like to give me a decent way to save a N x N matrix using binary file (bah!). I'm not asking on how you can read this matrix outside CPLua, because this is simply impossible with binary files.

Now, a question: A record in text files is simply a line of the file, which can contain strings and/or numbers or boolean variables; in other words, a record contains fields. If I understood well, the term record has a totally different meaning in binary files: "line of the file" is meaningless, and a "record" what in text files is called "field", i.e., each entity saved is a record (or a field, in binary files, it's the same thing). Did I understood well?

[Orwell]

For example, a N x N matrix is saved row by row (formatted saving is useful here, in order to save the matrix in a "pretty way").

Indeed, you need a double loop to write it, and to read it.

Now, my turn: I'd like to give me a decent way to save a N x N matrix using binary file.

a = { (your matrix here) }
f:write(a)

and to read it:

a = f:read()

I thought you didn't like loops?

I'm not asking on how you can read this matrix outside CPLua, because this is simply impossible with binary files.

This was never considered nor suggested
But consider how many users will need an easy way to just save a table and get it back later, and how many will want to be able to read it outside CPLua. I'm pretty sure that most of the time, the users will just want to basically save their table in the file, andthey will be happy to have only one function call to perform to write it and to read it. Do you really want to be forced to use loops each time you want to save a set of data's?

Now, a question: A record in text files is simply a line of the file, which can contain strings and/or numbers or boolean variables; in other words, a record contains fields. If I understood well, the term record has a totally different meaning in binary files: "line of the file" is meaningless, and a "record" what in text files is called "field", i.e., each entity saved is a record (or a field, in binary files, it's the same thing). Did I understood well?

If I understand correctly what you wrote, I think that you understood correctly indeed

[2072]

A note about file:open() function: As it is now, it permits to: write a file ("w"), read a file ("r"), or append to the contents of a file ("a"). These are, indeed, the most common things the user wants to do. However, if a file exists, file:open("w") deletes its previous contents silently. It would be nice to modify the behavior of file:open("w") so that it prints a warning or error message, if the file exists. However, this needs the implementation of another option, say file:open("R"), which means "create the file, if it doesn't exist, or replace the old file silently, if it exists". Note that this modification is not urgent at all: file:open() is quite functional, as it is now; if, however, it isn't difficult to modify it as I suggested, it would be nice.

about the possible optioons of the file:open() function you should inspire yourself from the optioons of the fopen() php function: http://fr.php.net/ma...ction.fopen.php

[Orwell]

Thinking about this again:

It is more than obvious that text files would be much more convenient

Okay.
But consider this:

B = { 1, 2, 3, a=2, b="foo", c={"hello", 2, "foo2"}, "string" }
C = { "this", is="a", "more", { "complex", "table"}, "don't you think?", embedded=B }
A = { B, {{C}}, "it's getting", funny="now" }
B.huh = A
C.C = C

Now how am I supposed to write the table 'A' in a text file?

[PAP]

Thinking about this again:
Okay.
But consider this:

B = { 1, 2, 3, a=2, b="foo", c={"hello", 2, "foo2"}, "string" }
C = { "this", is="a", "more", { "complex", "table"}, "don't you think?", embedded=B }
A = { B, {{C}}, "it's getting", funny="now" }
B.huh = A
C.C = C

Now how am I supposed to write the table 'A' in a text file?

According to common notation (not Lua's notation), "A" is what is called "list", not table. Of course, it can be saved in a text file, but it's a nightmare to do so. But let me ask you, will you ever need to save such a funny "table"?
Actually, when I said that text files are much more convenient, I had matrices in mind, not lists. Nevertheless, you are right, the shortest way to save a table is to use binary files. However, I never said that using text files is a short method to save data. I said (and I'm still saying) that it's more convenient, since it permits to use the saved data outside the program that had created them.

[Orwell]

According to common notation (not Lua's notation), "A" is what is called "list", not table

I don't see how it does matter here. But for me, the common meaning of a "table" in a programming language is a set of couples key/value ("dictionary" is another name for the same thing), which is indeed the case of Lua's tables.

But let me ask you, will you ever need to save such a funny "table"?

This is a good question, and my answer is: certainly not. However, this table shows several situations where the use of a text file would have been rather hard:
- non numeric keys and values
- embedded tables
- non homogeneous dimensions ( { 1, {2,3}, ... } etc )
- cycles in table references (A knows B, B knows A etc)
- strings with more that 1 word
- ...

Actually, when I said that text files are much more convenient, I had matrices in mind, not lists.

Matrices are a cute, nice, gentle, quite particular case of Lua tables. You only have numeric keys and values, the dimensions are homogeneous, ... everything is perfect in the most perfect world.
So you are pretending that I should consider this case only, and choose a file format that would be more convenient for matrices only And your main argument is still : "I want to be able to read it outside CPLua".
I already said it, I am convinced that most users will prefer an easy way to store their tables, rather than to spend time and effort to write loops, just because someone dreamed that text files would be better for matrices. Excuse-me, but this is completely nonsense! Again, I appreciate your interest for CPLua, but unfortunately, CPLua != LuaNumAn. And as you already noticed it, several people here are more interested by writing games that using math programs. I understand your needs, I can certainly admit that indeed text files would be nice for matrices; but I just want to satisfy as many users as possible, and unfortunately I think that you are representing a low minority. Your suggestions are certainly important too, but you should not forget that CPLua is designed for every kind of applications, not only for maths.

I don't want to start a war here, but hey, you seem to forget really often that you can do many other things than maths with a powerful programming language.

[-Tom-]

You are mostly right! But I must agree with PAP that it will be very difficult to exchange data outside Lua...
Is it very difficult to do add handling of text files?

[PAP]

Matrices are a cute, nice, gentle, quite particular case of Lua tables. You only have numeric keys and values, the dimensions are homogeneous, ... everything is perfect in the most perfect world.

You forgot to mention that matrices are "perfect in the most perfect world" only concerning their shape. You forgot to mention that matrices may represent a difficult problem that needs to be solved. This is the most common case, and it is not a game nor an easy task for a "perfect world".

So you are pretending that I should consider this case only, and choose a file format that would be more convenient for matrices only And your main argument is still : "I want to be able to read it outside CPLua".

I'm not pretending anything, and I still think that my main argument is very strong. I can live with binary files, though. I have just proposed a more convenient alternative, don't blame me for that.

I already said it, I am convinced that most users will prefer an easy way to store their tables, rather than to spend time and effort to write loops, just because someone dreamed that text files would be better for matrices. Excuse-me, but this is completely nonsense!

Wow-wow, take it easy maaan! I never said that binary files aren't useful; they are, since they provide an easy way to store things. I said that text files are more convenient for storing matrices. I'm not the only one that says that, and I didn't "dreamed" it.

Again, I appreciate your interest for CPLua, but unfortunately, CPLua != LuaNumAn. And as you already noticed it, several people here are more interested by writing games that using math programs. I understand your needs, I can certainly admit that indeed text files would be nice for matrices; but I just want to satisfy as many users as possible, and unfortunately I think that you are representing a low minority.

Yes, I ask for things to be implemented in CPLua having LuaNumAn in mind. This is natural, don't you think? given that I'm not interested on CP games, what did you expected, to ask for something having games in mind?
LuaNumAn is only a library written in CPLua. It eventually becomes larger and larger, and I can say that it expands CP's mathematical capabilities. Nevertheless, it is still a library; I was never thinking that CPLua==LuaNumAn. Furthermore, don't think that I forgot that such a project would be impossible without your work on CPLua.

Your suggestions are certainly important too, but you should not forget that CPLua is designed for every kind of applications, not only for maths. I don't want to start a war here, but hey, you seem to forget really often that you can do many other things than maths with a powerful programming language.

I don't want to start a war too (and I don't have any reason to do that). However, I feel that I have to answer: No, I don't forget "really often" that you can do many other things than maths on CP. I have completely forgot about it, once and for all. Writing games in ClassPad? For god's sake, it has a black & white dim screen, no sound, and it is not fast enough for games, even using CPLua. It is more than obvious that this thing is not made for games. On the other hand, it is obvious that it is made for maths: just have a look at what is considered as the "Main Application" .

Btw, I start to feel that I'm not representing a "low minority", at least not as "low" as I was thinking before. Several users have been interested on math problems, some of them have proposed very interesting things, or asked for really difficult numerical methods. It's getting better and better.

[unique33]

The doscript does not work in .8 B , C . I do not know why ?
and there is a problem in version .72 . when I use the draw package and when I use showconsole() ,
the input function does not work as expected . but there is no such problem in .8 !
I should press the input window area to force it work !

[Orwell]

You forgot to mention that matrices are "perfect in the most perfect world" only concerning their shape. You forgot to mention that matrices may represent a difficult problem that needs to be solved.

Don't mix everything... We both know that I was obviously talking about the shapes of matrices, not about what you can do with it

Yes, I ask for things to be implemented in CPLua having LuaNumAn in mind. This is natural, don't you think? given that I'm not interested on CP games, what did you expected, to ask for something having games in mind?

In the way you wrote your last posts, you do not suggest something that would be useful for you, you just refuse anything else.

Writing games in ClassPad? For god's sake, it has a black & white dim screen, no sound, and it is not fast enough for games, even using CPLua. It is more than obvious that this thing is not made for games.

Basically, I agree with you. But look how many games were written for the other Casio models, and how many websites exist to share them... I'm making programs on calculator since more than 5 years now, and I know quite well what people desire most. You're talking about ideals, I'm just talking about facts.

Btw, I start to feel that I'm not representing a "low minority", at least not as "low" as I was thinking before. Several users have been interested on math problems, some of them have proposed very interesting things, or asked for really difficult numerical methods. It's getting better and better.

Yup, I can't deny that. But I'm still absolutely sure that in the future you will find more games in Lua than math applications.

The doscript does not work in .8 B , C . I do not know why ?

I can't reproduce any problem with it... do you have an example?

and there is a problem in version .72 . when I use the draw package and when I use showconsole() ,
the input function does not work as expected . but there is no such problem in .8 !
I should press the input window area to force it work !

This is a problem of focus... but since it does not appear anymore in CPLua 0.8, I consider that it has been fixed

[unique33]

I can't reproduce any problem with it... do you have an example?

Yes,I have . but I,m working on it ( because it is a huge project ,I will send you a part of it privately)
Is it possible to release a version with the doscript function like version .72 ?
to see if the problem is with the doscript function itself or not.

also consider this :

File A:
a=2
b=3
doscript(fileB,{a=a,b=b})

---------------
File B:
a=a
b=b
print(a,b)
doscript(FileC,{a=a,b=b})

---------------
FileC:
print(a,b)

why a and b in file C are nil values ?
I can not understand .
please explain about it. thanks.

[Orwell]

Is it possible to release a version with the doscript function like version .72 ?

Well you could use CPLua 0.72 to try it then...

why a and b in file C are nil values ?
I can not understand .
please explain about it. thanks.

Those variables are in the "args" table
Use "args.a" or "args.b" in your subscripts

[Orwell]

I found and fixed 2 bugs in the "io" package (thanks to Gaumerie and Kilburn for their reports):
- an annoying problem when storing literal values (strings, table keys etc);
- the maximum size of data that you could write at once was limited to 65535 bytes.

Show me the problem you have with doscript and I will fix it before releasing CPLua 0.8RC1

[unique33]

Those variables are in the "args" table
Use "args.a" or "args.b" in your subscripts

humm
I found the origin of my problem

File A:
a=2
b=3
doscript(FileB,{a=a,b=b})

---------
File B:
print(args.a,args.b)
print(a,b)

run this on version .72 and .8 and see the difference .( the second print)
Ok . there is no problem any more . I changed my code to fit to version .8.

[Orwell]

I remember there was a bug in CPLua 0.72 concerning the data hiding (it was PAP who noticed it)... I think it is related to your problem. "a" and "b" must be nil in File B

[Kilburn]

There is something strange (but it doesn't seem to be a bug):

tbl={1,2,8,0,2,4,3,7}

for i in tbl do
 print(tbl[i])
end

waitkey()

This works on CPLua 0.7x but on CPLua 0.8C I get something like "Attempt to call a table value".
Is it normal?

[Orwell]

Maybe they made some modifications concerning the use of iterators to browse table...

Check the Manual

[unique33]

Why the newer versions of Cplua runs out of memory more ?
Is it because of Lua 5.1?
the same programs does not run out of memory even when there are some programs open in the interpreter on version .7x !

now ,when I want to run some of my programs even when there is no file open ,
just runing a program leads to the system memory error !

[Orwell]

This is a consequence of data hiding. Because each slot must be isolated from the others, there are many elements that must be duplicated in each file, and thus it requires a lot of memory That's why I said that it is not a good idea to divide a program into many files containing only 1 or 2 small functions.
And it seems indeed that Lua 5.1 use more memory than Lua 5.0.2...

If you are making a program that often runs out of memory, consider calling the collectgarbage() function periodically. Ideally you wouldn't have to call it yourself, but perhaps it will be useful for very large applications

[PAP]

This is a consequence of data hiding. Because each slot must be isolated from the others, there are many elements that must be duplicated in each file, and thus it requires a lot of memory That's why I said that it is not a good idea to divide a program into many files containing only 1 or 2 small functions.
And it seems indeed that Lua 5.1 use more memory than Lua 5.0.2...
If you are making a program that often runs out of memory, consider calling the collectgarbage() function periodically. Ideally you wouldn't have to call it yourself, but perhaps it will be useful for very large applications

Indeed, dividing a program into many small files is not a good idea: all functions serving one purpose should be collected to one chunk. If you do so, you will not need to use collectgarbage(). I only needed it once (in LuaNumAn's "DLMfit" program), and that only for a short time, during CPLua debugging.

[TacoFred]

If only we could use the flash ROM...(I still have 4.025MB left O.o) though ROM stands for Read-Only Memory..

[Gaumerie]

I think it's possible, there's documentation on the DMAC which (I think) is used to write in the ROM...
But I understand english...but not this part
Alexandre

[Orwell]

Just a few words here to tell you that I'm still alive, but exams are starting this Monday thus I will be busy until end of January

Also, I guess I just saw a new challenger for LuaNumAn: http://www.classpad....ails.php?id=246
Maybe PAP should try it and compare the results

[-Tom-]

Hi!
I could not find anywhere else answer for this, but Im sure that here I will find help!

require("cas")
l1={1,2,3,4,5}
l2={2,4,8,4,2}
cas.Quadreg(l1,l2)
print(cas.Acoef)

I need a number, not userdata. What should I do? (Im not a programmer :| )

[Orwell]

This code won't work, because the CAS function "Quadreg" does not understand the Lua tables l1 and l2. You have to create CAS lists instead:

require("cas")
l1=cas("{1,2,3,4,5}")
l2=cas("{2,4,8,4,2}")
cas.Quadreg(l1,l2)

Normally to convert a CAS userdata to a number you have to call it, that means basically that you have to put some parenthesis behind.
But here "Acoef" seems to be a variable, not a function, so you cannot write cas.Acoef, instead you should use cas("Acoef") . The syntax cas("...") is more general, because everything written in "..." will be interpreted as a standard CAS expression, so you can write exactly the same things as in the Main mode.
Thus the correct code should be

print(cas("Acoef"))

However, this seems to return a blank line, meaning that an error happened
I tried it in the main mode, and "Quadreg(l1,l2)" raises an error. Are you sure of the arguments?

[-Tom-]

However, this seems to return a blank line, meaning that an error happened
I tried it in the main mode, and "Quadreg(l1,l2)" raises an error. Are you sure of the arguments?

It was just an example... Thanks for help, I hope it will work now.

Yes... it is it! Thank You very much!

[-Tom-]

Maybe not exactly it...

It seems that Cas.Quadreg(l1,l2) is not working...
cas("Acoef") returns a result of "Statistics" calculations, not those made in Lua...

[Orwell]

Indeed, Cas.Quadreg(l1,l2) does not work because it does not work in the Main mode neither... Perhaps you should try those calculations in the Main mode first to be sure of the syntax?

[-Tom-]

Indeed, Cas.Quadreg(l1,l2) does not work because it does not work in the Main mode neither... Perhaps you should try those calculations in the Main mode first to be sure of the syntax?

In Main it should be Quadreg l1,l2 , but I think I cannot use in Lua Cas.Quadreg l1,l2 ....

[Orwell]

Oh okay, this is a command and not a function
Thus the code should be

require("cas")
l1=cas("{1,2,3,4,5}")
l2=cas("{2,4,8,4,2}")
cas("Quadreg " .. l1 .. "," .. l2)
print(cas("Acoef"))

As I said, you could consider the cas table as a simple function which needs a string as argument. This string is the operation you want to perform, written in the same way as in the Main Mode. Here I made this string by concatenating the "Quadreg" command with the contents of the expressions l1 and l2; this will give the same result as writing

cas("Quadreg {1,2,3,4,5},{2,4,8,4,2}")

Note that if you use the default keyboard, you could use simple CAS variables too.
For example, this will give the same result:

require("cas")
cas("{1,2,3,4,5}=>l1")  -- "=>" is the assignment key
cas("{2,4,8,4,2}=>l2")
cas("Quadreg l1, l2")
print(cas("Acoef"))

This is not really complicated, but the thing is that you have many different ways to do the same thing with CPLua, and I guess people can get lost sometimes

[-Tom-]

require("cas")
l1=cas("{1,2,3,4,5}")
l2=cas("{2,4,8,4,2}")
cas("Quadreg " .. l1 .. "," .. l2)
print(cas("Acoef"))

Can get lost.... especially when it does not working...

I use Lua 0.72

[Orwell]

Awww, "Quadreg {1,2,3,4,5},{2,4,8,4,2}" isn't a valid command

require("cas")
cas("{1,2,3,4,5}=>l1")  -- "=>" is the assignment key
cas("{2,4,8,4,2}=>l2")
cas("Quadreg l1, l2")
print(cas("Acoef"))

seems to be the only way then (and this one works, I tried )
Unfortunately it's not really comfortable

[-Tom-]

Awww, "Quadreg {1,2,3,4,5},{2,4,8,4,2}" isn't a valid command

require("cas")
cas("{1,2,3,4,5}=>l1")  -- "=>" is the assignment key
cas("{2,4,8,4,2}=>l2")
cas("Quadreg l1, l2")
print(cas("Acoef"))

seems to be the only way then (and this one works, I tried )
Unfortunately it's not really comfortable

Yes, it returns value... 0, but correct is -1.1428....
Where is problem?

It returns correct value only after doing the same in "Statistics". then in Acoef is correct value.. before is 0. It seems that Quadreg cannot be called from Lua becouse does not working.

[-Tom-]

Another problem... (but this last is more important to me)

require("cas")
f=cas("-x^2")
print(cas.Fmax(f,x,-1,1,4))

does not work.. when:

require("cas")
f=cas("-x^2")
print(cas.Fmax(f))

works correctly. But I need to search for local Max... Is it possible?