858 replies to this topic

[PAP]

limit[multi] - multidimensional limits
Given a set of points as its second argument,
limit attempts to compute the limiting value of f in a multidimensional space.

Hmmm, this is a CAS-related problem; I'm afraid that has nothing to do with CPLua . Anyway, you can compute "multidimensional" limits by using nested limits in the CAS. For example,

lim(lim(x+1/y,x,0),y,infinity)

computes the limit of x+1/y as x goes to 0 and y goes to infinity.
Warning:, nested limits don't always give the correct result, if it is undeterminate. You have to think the order of limits to be computed thoroughly. For example, suppose that you want to compute the limit of x*y ax x goes to 0, and y goes to infinity. In this case,

lim(lim(x*y,x,0),y,infinity)

returns 0, which is wrong. This is not a bug, it's due to the order of the limits computed (you can easily realize why it gives 0). However,

lim(lim(x*y,y,infinity),x,0)

returns "Undefined", and it is correct.

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

Well, this problem can be solved numerically, but, again, this has nothing to do with CPLua as well. Furthermore, to the best of my knowledge, there is no robust numerical method for this; how one can test dicontinuity numerically over all reals?

[Orwell]

> unique33: Well like PAP said it already, these are suggestions concerning the CAS or numerical analysis, it's not related to CPLua itself... Also don't forget that I'm only able to provide support to the ClassPad's CAS and to let you call it in Lua code, but in any case I will never add new features to it There won't be more CAS functions than the functions available in the Main mode.

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(stage[ 1 ][ 1 ]) // 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[ 1 ][ 1 ]) right after the map.Load() when i know that it just printed 99... any thoughts on what im doing wrong here?

Hmm I think that you shouldn't export the stage directly, but rather export a function that will return an initialized stage, like in my example, then each time you need the stage in a function of Lib you have to pass it as argument. The problem here is that you are defining an empty table at the beginning of your file Lib, and you export it at the end. Then when you call a function doing stage=doscript() you are not modifying the content of the table 'stage': you are replacing it by another one, and this is not the same table as the one you exported before :/
If you really want to work this way, you should rather write something like doscript("Runner/stage1",{stage=stage}) to pass the stage as argument to your script (args.stage will be available in it), and thus you will be able to modify the content of the table you exported. Note that args.stage = { ... } will not change the content but rather replace it by another table, and this won't have any effect to the table 'stage' that you passed as argument to doscript: you have to change each element of 'args.stage' separately.
But I still think that the solution I suggested before should work fine; did you have any problem with it?

[CrimsonCasio]

yay, it works!
(probably in the sloppiest way possible, but who cares!)

thanks for the help

[Orwell]

Some news:

* PAP's recent tests show that the current implementation of the 'mat' package is rather unsatisfactory. It is still too slow compared with Lua's basis tables, and it drains a lot of memory for arithmetic operations etc I will now change it again to increase its performances.
One of the main modifications will be the way the matrices are indexed. Currently if 'A' is a 2D-matrix then 'A[i][j]' is used to access the element 'j' at the row 'i'. This syntax had a nice advantage: you can write 'x = A[i][j]' or 'A[i][j] = x' to read or write an element of the matrix. However, the price in speed and memory for this possibility is huge, and I think that we need to find a better way.
Thus, I suggest the following notations instead:

x = A:get(i,j)   -- with another allowed form: x = A(i,j)
A:set(i,j, x)

Unfortunately it is not possible to make Lua accepts something like 'A(i,j)=x'.
Note that the arithmetic operations will still be available; most of the modifications you will have to do concern the way the indexing operations are made (use '(...,...)' instead of '[...][...]'), and the way the element of a matrix are modified. You won't lose any feature that are currently available

* rafapa recently asked me if I was planning to update the version of Lua, and I said (honestly) that it was not the case. However, I've taken a look today at the features offered by Lua 5.1(alpha) and, well, it's very tempting
There are different modifications concerning the C API (and those are mainly interesting for me only ), but here is a short list of the improvements made on the Lua language:
- metatables for all types
- new "primitive" getn
- new `mod' (`%') operator
- new math functions
- new operation #t (for size of t).
I think I will try to use this last version in CPLua 0.8. Perhaps it would be better to wait for the final release of Lua 5.1, but I do not wish to do that after the release of CPLua 1.0, thus if you don't want to wait too long for it I think it should be okay to do it now. Of course I will make some updates when Lua 5.1 will be officially released, but there won't be much consequences on the existing Lua programs.

As allways, comments are welcome

[rafapa]

Some news:

* PAP's recent tests show that the current implementation of the 'mat' package is rather unsatisfactory. It is still too slow compared with Lua's basis tables, and it drains a lot of memory for arithmetic operations etc I will now change it again to increase its performances.
One of the main modifications will be the way the matrices are indexed. Currently if 'A' is a 2D-matrix then 'A[i][j]' is used to access the element 'j' at the row 'i'. This syntax had a nice advantage: you can write 'x = A[i][j]' or 'A[i][j] = x' to read or write an element of the matrix. However, the price in speed and memory for this possibility is huge, and I think that we need to find a better way.
Thus, I suggest the following notations instead:

x = A:get(i,j)   -- with another allowed form: x = A(i,j)
A:set(i,j, x)

Unfortunately it is not possible to make Lua accepts something like 'A(i,j)=x'.
Note that the arithmetic operations will still be available; most of the modifications you will have to do concern the way the indexing operations are made (use '(...,...)' instead of '[...][...]'), and the way the element of a matrix are modified. You won't lose any feature that are currently available

I'm curious if there is a similar development in the "official" Lua world. I means if there is some other people which have tried to implement matrices in standard Lua. I know there is something called Luanumeric or similar but it's mostly a frontend to libraries.

* rafapa recently asked me if I was planning to update the version of Lua, and I said (honestly) that it was not the case. However, I've taken a look today at the features offered by Lua 5.1(alpha) and, well, it's very tempting
There are different modifications concerning the C API (and those are mainly interesting for me only ), but here is a short list of the improvements made on the Lua language:
- metatables for all types
- new "primitive" getn
- new `mod' (`%') operator
- new math functions
- new operation #t (for size of t).
I think I will try to use this last version in CPLua 0.8. Perhaps it would be better to wait for the final release of Lua 5.1, but I do not wish to do that after the release of CPLua 1.0, thus if you don't want to wait too long for it I think it should be okay to do it now. Of course I will make some updates when Lua 5.1 will be officially released, but there won't be much consequences on the existing Lua programs.

As allways, comments are welcome

Well, my main interest in asking was because I didn't wanted to learn something which was going to be obsolete in a few months. If the changes are minor there is no problem. If the changes are big the sooner the better.

Thanks a lot for all the work you are doing (ok PAP also deserves to be thanked). I haven't started with CPLua and LuaNuman because I'm waiting them to stabilize a bit.

Regards

[PAP]

I'm curious if there is a similar development in the "official" Lua world. I means if there is some other people which have tried to implement matrices in standard Lua. I know there is something called Luanumeric or similar but it's mostly a frontend to libraries.

I have seen several sites with Lua stuff, there are even some Numerical Analysis libraries, but, to the best of my knowledge, they are very "specialized", i.e., they cover only specific topics. Furthermore, like you said, these packages are more or less frontends to C libraries, so they don't really need a decent matrix support. So, my answer is no, I haven't seen a similar developement of matrices in Lua (but Orwell obviously knows more about that).
The lack of matrix support in Lua is a big disadvantage, since mathematical applications are full of matrix operations. Lua itself is not a programming language for mathematics; as I said before, I don't think that most programmers will ever use Lua in their computers to write mathematical applications, simply because they have more powerful choices, for example Fortran 95 or programming environments such as MatLab, Mathematica, Maple, Octave, Scilab etc. But in ClassPad, the situation is totally different: CPLua is the only choice, given that the built-in basic is so poor and slow. Even without a decent matrix support, CPLua permits to implement complex numerical methods in ClassPad; such a thing is totally unthinkable without CPLua. The Lua implementation of mathematical applications is not as compact as in a pure mathematical programming language, but it is surprisingly fast. Furthermore, CPLua supports structured programming to a decent level, and has some advanced proramming features. Now, Orwell has decided to add decent matrix support in CPLua, and I'm glad for that, because it will make programming mathematical applications in ClassPad much more convenient. I have tried the first attempt of matrix support in CPLua, and I must say that, despite its drawbacks, the code becomes now shorter, and much more clearer. I believe that the current matrix problems, concerning speed and memory, will be eliminated by using the new format that Orwell proposed. This will make programming mathematical applications in CPLua an easier and more enjoying task.

[PAP]

I haven't started with CPLua and LuaNuman because I'm waiting them to stabilize a bit.

Well, CPLua is still in (heavy) developement, but it's quite stable to start with. This way, you may be able to give a hand in debugging as well .
@ Orwell: remember what I said in a previous post? there are people that are simply waiting for an official version; in the meantime, they let us to do the dirty job . But it's ok, I can understand rafapa's decision to wait for an official version.

PS: Look at the "views" and "replies" for this topic. It's amazing that CPLua has reached such numbers in such a short time.

[rafapa]

I have seen several sites with Lua stuff, there are even some Numerical Analysis libraries, but, to the best of my knowledge, they are very "specialized", i.e., they cover only specific topics. Furthermore, like you said, these packages are more or less frontends to C libraries, so they don't really need a decent matrix support. So, my answer is no, I haven't seen a similar developement of matrices in Lua (but Orwell obviously knows more about that).
The lack of matrix support in Lua is a big disadvantage, since mathematical applications are full of matrix operations. Lua itself is not a programming language for mathematics; as I said before, I don't think that most programmers will ever use Lua in their computers to write mathematical applications, simply because they have more powerful choices, for example Fortran 95 or programming environments such as MatLab, Mathematica, Maple, Octave, Scilab etc. But in ClassPad, the situation is totally different: CPLua is the only choice, given that the built-in basic is so poor and slow. Even without a decent matrix support, CPLua permits to implement complex numerical methods in ClassPad; such a thing is totally unthinkable without CPLua. The Lua implementation of mathematical applications is not as compact as in a pure mathematical programming language, but it is surprisingly fast. Furthermore, CPLua supports structured programming to a decent level, and has some advanced proramming features. Now, Orwell has decided to add decent matrix support in CPLua, and I'm glad for that, because it will make programming mathematical applications in ClassPad much more convenient. I have tried the first attempt of matrix support in CPLua, and I must say that, despite its drawbacks, the code becomes now shorter, and much more clearer. I believe that the current matrix problems, concerning speed and memory, will be eliminated by using the new format that Orwell proposed. This will make programming mathematical applications in CPLua an easier and more enjoying task.

I asked the question because I believe that Lua is used in developing games. The rotations of rigid bodies could be represented by matrix multiplications (ok, quaternions can also be used) so I assumed that somebody had already developed them for "standard" Lua. Maybe the problem in this reasoning is that the games developed using Lua does not rotate objects.

Anyway, I'm always worried by going to far in including things in CPLua which are not available in Lua itself.
I will prefer to develop and debug in my PC and transfer the result to the CLASSPAD.

[rafapa]

Well, CPLua is still in (heavy) developement, but it's quite stable to start with. This way, you may be able to give a hand in debugging as well .
@ Orwell: remember what I said in a previous post? there are people that are simply waiting for an official version; in the meantime, they let us to do the dirty job . But it's ok, I can understand rafapa's decision to wait for an official version.

PS: Look at the "views" and "replies" for this topic. It's amazing that CPLua has reached such numbers in such a short time.

My problem is that at some point there were new CPLua versions almos everyday. I don't know how to transfer add-ins to the CLASSPAD from <{GNULINUX}>. I tried wine without success. Then I need to reboot the PC and use windows just to transfer things something I cannot always afford because the PC is doing real work.

I do not need an "official" version an RC will do.

[PAP]

I asked the question because I believe that Lua is used in developing games. The rotations of rigid bodies could be represented by matrix multiplications (ok, quaternions can also be used) so I assumed that somebody had already developed them for "standard" Lua. Maybe the problem in this reasoning is that the games developed using Lua does not rotate objects.

Yes, rotation of solid objects can be done by using rotating matrices. But Lua is an interpreted language, so I don't think that it's a good idea to develop a 3D game in Lua, even on a fast PC. I bet that there is no 3D game written in Lua (can you imagine a Lua version of Half-Life? ).
As far as ClassPad is concerned, Lua is surprisingly fast in numerical methods, but it is a little bit slow for games. I tried to write a simple game in an earlier version of CP Lua; it was running much faster than CP Basic, but it was easy to see the interpreter limits. Personally, I don't think that CPLua is for games.

My problem is that at some point there were new CPLua versions almos everyday. I don't know how to transfer add-ins to the CLASSPAD from <{GNULINUX}>. I tried wine without success. Then I need to reboot the PC and use windows just to transfer things something I cannot always afford because the PC is doing real work.

I have exactly the same problem too. I never connect to the internet via Windows, so, everytime a new version of CPLua is released, I have to download it from <{GNULINUX}>, transfer it to a Windows partition, then reboot to install it. It's such a universal <{GNULINUX}>-users problem. I don't know if VMWare Workstation works (it's similar to Wine, but it is rumored that it's more powerful)...

[Nanard]

I don't know if VMWare Workstation works (it's similar to Wine, but it is rumored that it's more powerful)...

vmware isn't as wine, vmware allow you (despite i never succed) to boot another os on a window. wine try to lunch a win32 executable from <{GNULINUX}>. moreover, vmware isn't free...



on the other hand, 'wine CPLua.exe' works very well
I had aso try to connect the classpad with <{GNULINUX}>, but no success... and now I hadn't any windows partition

[PAP]

vmware isn't as wine, vmware allow you (despite i never succed) to boot another os on a window. wine try to lunch a win32 executable from <{GNULINUX}>. moreover, vmware isn't free...

I know the difference . However, for the purposes discussed here (CP Manager, Add-In installer), the result is the same: both applications don't work .

on the other hand, 'wine CPLua.exe' works very well

Not in my <{GNULINUX}> box. I didn't tried hard, though.
Edit: Indeed, CPLua.exe works with wine (I needed to change the wine settings a bit). However, the screenshot is not working (you can still take a screenshot by using <{GNULINUX}> programs though). Unfortunately, since CP Manager does not work, switching to Windows to save an image is currently inevitable.

Edited by PAP, 13 November 2005 - 11:48 AM.

[Orwell]

Some bad news today

I concluded from my last tests and benchmarks that the use of a custom matrix type is really hopeless. It can be done, but the result is quite too slow to be useful
I said that the index operator '[]' was too slow and I suggested to use another (and less convenient) syntax 'A:set(i,j,x)' instead of 'A[i][j]=x'. This notation was in fact a shortcut for the real call 'mat.set(A,i,j,x)'.
The problem is that even the single call to mat.set() itselfs is ~1.6 times slower than the corresponding operation on tables, altough during my tests this function was left empty. You can imagine what happens when this call performs the real assignment of the new data
Thus, if the most basis read/write operations are so slow, I think it's not reasonable to continue trying to work with an hand-made type for matrices. I spent a lot of time on this work, but unfortunately I still can't find an appropriate solution

But I'm conscious that the matrix operations could be useful, that's why I think that I will have to go back to the first idea: provide more functionalities to the existing tables, instead of creating a new type. I'm thinking about some functions 'mat.setarray()' and 'mat.setmatrix()', which could transform an existing table and give them a metatable containing their new options (arithmetic operations, to-string conversion, etc). The other functions like mat.det(), mat.maxval() etc should still be available.
One of the reasons for which I tried to make a new type was that Lua's tables require a lot of memory when they become too large; unfortunately this problem will remain for now

I'll let you know how it goes.

A good news though: I upgraded CPLua with Lua 5.1 alpha without any problem

[rafapa]

I know the difference . However, for the purposes discussed here (CP Manager, Add-In installer), the result is the same: both applications don't work .

Not in my <{GNULINUX}> box. I didn't tried hard, though.

I must dissagree. I am not able to use CP Manager nor Add-In installer with wine but, I have no problem running them using vmware (host system Suse 9.3).

Cheers.

[PAP]

Some bad news today

Bad news, indeed. If I understood well, the "loops for everything" concept is a Lua curse that will never vanish . We must learn how to live with it . Nevertheless, your (hard) work on the subject was not useless: I'm sure that you have learned plenty of useful things during this matrix-hunt. Technically, the "mat" sub-project didn't failed: you finally did it! The implementation is slow and memory-consuming, but I'm afraid that this means that we have pushed ClassPad to its hardware limits. Nevertheless, CPLua has no competitors in the ClassPad world: it is by far the best way to write something useful in ClassPad.
Btw, I will continue to develop my LuaNumAn project, with or without the "mat" package.

[CrimsonCasio]

Is there a way to create and save files/data? (currently or planned?)

[Orwell]

Is there a way to create and save files/data? (currently or planned?)

It is planned

[Nanard]

I must dissagree. I am not able to use CP Manager nor Add-In installer with wine but, I have no problem running them using vmware (host system Suse 9.3).

Cheers.

funny, ican't get vmware work... and a simple 'emerge wine && wine /path/to/CPLua.exe' work on the first attempt ^^

[rafapa]

funny, ican't get vmware work... and a simple 'emerge wine && wine /path/to/CPLua.exe' work on the first attempt ^^

Oh! I believe we are talking about different things. I wanted to report success in running the Classpad Manager and the Add-in under Windows XP using vmware and <{GNULINUX}> as host.

I hope I had made me clear now.

[PAP]

Consider the following code:

f=cas("x^2")
print(f)
print(f(2))

f is defined as x^2, and f(2)=4, as expected. Now replace the first command with

f=cas("sin(x)")

or even

cas.sin("x")

f is defined as sin(x), as it should, but f(2)=0. In fact, f(whatever)=0. I don't get it .

Furthermore, consider this code:

f=cas("y^2|y=x^3")
print(f)
print(f(2))

Here, f=x^6, and f(2)=64, as expected. Now replace the the first command with

f=cas("y^2|y=tan(x)")

This gives f=(tan(x))^2, but f(whatever)=0.

It seems that CAS functions, such as "sin", "tan" etc, are not working as math operators, such as "^", or I make something horribly wrong.

[Orwell]

Hmm
Thanks for the report, I will take a look on it.

PS: Sorry for the long time between your post and my answer, I've been quite busy recently

[PAP]

Hmm
Thanks for the report, I will take a look on it.

There is another problem concerning the CAS, which I have discovered recently. Consider the code:

require("cas")
foo1=cas("approx(1/100)")
foo2=cas("approx(1/1000)")
print(foo1,foo2)
print(foo1(0),foo2(0))

Here, foo1 and foo2 are of type "userdata", since they are CAS results. Suppose that we want to convert them to Lua numbers. We should use foo1(whatever), foo2(whatever). This is rather peculiar, but it works, and it is not a bug. However, as you can see by running the above code, foo1(0) is equal to 0.01 (as it should), but foo2(0) is equal to 0, not 0.001. This is due to the fact that the CAS returns 1E-3 for foo2, where "E" is the "small capital E", not a normal capital "E". Obviously, this character cannot be converted by CPLua, hence the erroneous result foo2(0)=0. In this case, we can get the correct result by avoiding using the "approx" function, i.e., by

foo2=cas("1/1000")

This lefts foo2 as a fraction, so foo2(0) returns 0.001. However, this is only a workaround. In general, a CAS command may return a result in exponential form (e.g., the CAS function "solve" in numerical mode). In that case, the result will be equal to 0, if converted to a CPLua variable, without any warning.

PS: Sorry for the long time between your post and my answer, I've been quite busy recently

I was wonderning what happened to you. Nice to know you are still here...

[Orwell]

This is due to the fact that the CAS returns 1E-3 for foo2, where "E" is the "small capital E", not a normal capital "E". Obviously, this character cannot be converted by CPLua, hence the erroneous result foo2(0)=0.

Huh, I see This should be easily fixed. Thanks

[Orwell]

I was wonderning what happened to you. Nice to know you are still here...

I didn't take the time to really follow the new posts here, but I did work on CPLua though
As I said before, CPLua was actually in a huge refactoring step. I needed to reorganize completely the 'Lua execution' part of the add-in, and during 2 weeks I was unable to compile or run it (I worked at the same time on the 'mat' package with a copy of CPLua 0.73). During this phase I worked on the following points:
- I upgraded the Lua version to Lua 5.1 (alpha)
- I have rewritten the entire management of the windows used during the execution. For now there are only 2 different windows (the console and the 'graph' window), but the new structure makes it really easy to create some other kinds of window if we want, for example for the CAS's 2D display or for 3D graphics etc. It should also be possible to create a 'GUI' package for CPLua, so we could manipulate windows etc from Lua programs
- I added the support for the 'tolua' converter, now we can use it to create some new Lua packages or libraries from existing C/C++ functions.
- All the elements related to the execution of Lua scripts have been put together in their own class (In the previous versions they were located in the "super window" containing the console and the graph window). I think that it is clearer now, altough this "super window" class is a bit empty now

Today I almost finished the rebuild of the Add-in, it is now up again at ~97%, and it compiles and runs without problems

As you can see there are no real impacts on the Add-in from the user's point of view (except concerning the upgrade 'Lua 5.0.2 - > Lua 5.1 alpha'), but the code is now easier to manage, and it will be easier for third parties to create new packages for CPLua if they want I'm planning to release the source code quite soon.

Concerning the 'mat' package: It needs to be rewritten once again But this is one of the tasks I will work on before the next release... Or rather would you like to test the first 0.8 version before the new implementation of the 'mat' package? We need to get used to the several new features of Lua 5.1 too...

Anyway: don't worry, CPLua 1.0 is coming, slowly but surely

[PAP]

As you can see there are no real impacts on the Add-in from the user's point of view (except concerning the upgrade 'Lua 5.0.2 - > Lua 5.1 alpha'), but the code is now easier to manage, and it will be easier for third parties to create new packages for CPLua if they want I'm planning to release the source code quite soon.

Obviously, you had a really hard work, but you do well. An easy-manageable code is heaven, the opposite is a real hell, especially if the code is changing daily.
Now, about the source code release: obviously, it's your decision, but I think I have to say something about this. I like OpenSource, but I hope that you are aware of the danger (anyone can then release a modified -and buggy- version, anyone can claim that he is the developer, etc); in other words, anyone can do whatever he likes. OpenSource projects definitely need some kind of "protection". I personally prefer the GNU general public licence: you keep the copyright, but you allow code modification, provided that the modified code is clearly declared as such (the modified executable should inform the user that it is not the original, and it should mention the original version and its developer). Others prefer to release the code only for a group of developers, which is also a good way to proceed, provided that you trust the group developers. Again, it's your decision.

Concerning the 'mat' package: It needs to be rewritten once again But this is one of the tasks I will work on before the next release... Or rather would you like to test the first 0.8 version before the new implementation of the 'mat' package?

Well, yes, yes, and yes! Since major internal changes have been made in CPLua, I think that releasing version 0.80RC1 (or wharever version name you decide) is a good idea. We could test our programs to see if there is any difference. Maybe there is an annoying bug lurking somewhere (I hope not). We could also check if there is a change concerning program execution.

We need to get used to the several new features of Lua 5.1 too...

Indeed. That's another reason to release a version before the "mat" package re-implementation.
Btw, do you know any good url (or, even better, document) describing what's new in Lua 5.1?

Anyway: don't worry, CPLua 1.0 is coming, slowly but surely

Yeaaaaaah!

[Orwell]

Okay, I finished the last 3% today, so I think that I can release a temporary version of CPLua 0.8 (let's say 0.8A ). It's not really a Release Candidate, since the 'mat' package is completely disabled, and I'd like to enable for the real version 0.8 . But this way we can already make several tests... I already tried LuaNumAn 1.40 (because LuaNumAn 1.50 uses the 'mat' package :/), and it runs correctly, except the thing that the function 'table.setn()' is obsolete in Lua 5.1.

Here is the link: http://orwell01.free...ua/CPLua08A.zip

About Lua 5.1: Well, this version has not been officially released yet (but it should come quite soon), so there is no official documentation. I can't find the list of modifications anymore, I'll browse the web to find it again
Edit: I put all the current documentation about Lua 5.1 in this archive.

Btw, I just saw that someone else is currently trying to port Lua on the TI89
Here is the corresponding page: http://lekernel.lya-fr.com/lua_en.html
I will try to contact him, so we could see if we can share the work to develop some new packages etc

Edited by Orwell, 13 November 2005 - 03:51 PM.

[PAP]

Okay, I finished the last 3% today, so I think that I can release a temporary version of CPLua 0.8 (let's say 0.8A ). It's not really a Release Candidate, since the 'mat' package is completely disabled, and I'd like to enable for the real version 0.8 . But this way we can already make several tests...

Hmmm, the bugs concerning the "cas" package are still present. Moreover, CAS expression evaluation does not work at all. Even simple CAS expressions such as

f=cas("x^3")
print(f(2))

don't work anymore. in fact, an expression such as

f=cas("any valid CAS expression")

cannot be evaluated: f(whatever) is equal to zero now. Even a simple CAS constant, such as f=cas("1/100") cannot be evaluated anymore. What happened to the "cas" package?
I tried cas.evaluate(f(2)) and, surprisigly, it was not an error (but it was not correct neither): I got "evaluate(0)" I expected at least an error message "attempt to call field 'evaluate' (a nil value)". Then I tried cas.foo("x"): it was not an error as well .

I already tried LuaNumAn 1.40 (because LuaNumAn 1.50 uses the 'mat' package :/), and it runs correctly, except the thing that the function 'table.setn()' is obsolete in Lua 5.1.

Yes, table.setn is obsolete, but it's the first time I see an "obsolete" feature to cause an error (not a warning). Anyway, this concerns Lua itself, not CPLua (plus "table.setn" was not so useful). The manual also says that table.getn (which is very useful) should be replaced by the new # operator. Apart from that, I don't see visible changes.
Note that, since LuaNumAn 1.50 has several new features, and the "mat" package will take some time to be released and debugged, I may release version 1.50 with the usual table implementation, i.e., without using the "mat" package for now. But I'm not really sure, it is all about free time available.

[Orwell]

That's strange, I didn't change much things about the 'cas' package
Thanks, I will try to debug it to see what happens.

[PAP]

There is another strange thing concerning the new version. For some reason, the LuaNumAn driver program DLMfit runs out of memory now: The first example runs flawlessly, but, in the second example, program execution becomes unexpectedly slow, and finally ClassPad runs out of memory. Adding collectgarbage() in the main iteration of the function LMfit makes the program working again (but it is slower, due to repetitive garbage collections). It reminds me the behavior of an earlier version of CPLua, before automatic garbadge collection was introduced. So, I suspect that automatic garbage collection doesn't work anymore in version 0.8A (I can almost bet that this is the reason for memory crashes).

[Orwell]

I changed the management of the garbage collector in this version because it has been completely rewritten in Lua 5.1... But I need to make several tests to find the best parameters (the new parameters 'pause' and 'multiplier' of the GC are not clear at all ).

[PAP]

There is a problem concerning data hiding. It's not new, it was present in previous versions, but, since CPLua is now in serious developement, I think I shall mention it: if chunk A requires a chunk B and a chunk C, then chunk C "knows" all variables and functions exported by B. That's bad, since it directly violates data hiding. Fortunately, the opposite is not true: if chunk C requires chunk D, then chunks A and B don't "know" any variable or function exported by chunk D (that's good).
In other words, all chunks required in the "main" chunk are also known in the "sub-chunks". It will be nice if you can correct it.

[Orwell]

Just a few words:
The problems reported by PAP about the CAS and the data hiding have been fixed
I'm now working on the memory management. CPLua 0.8B will certainly follow

[PAP]

Just a few words:
The problems reported by PAP about the CAS and the data hiding have been fixed
I'm now working on the memory management. CPLua 0.8B will certainly follow

Good. Looking forward to download the new version.

[Orwell]

CPLua 0.8B is now available for download

It contains several bug fixes (see the posts above ), but also several new features:
- You can now press [<-] when an error occurs to go the line where the problem was encountered
- There is now a cas.elem() functions to index CAS lists and matrices (thanks to SoftCalc)
- No more crashes when the calculator runs out of memory, just a soft error in the console window (thanks to SoftCalc again )
- True multi-language support, although only English and French are available for now

Enjoy

[-Tom-]

CPLua 0.8B is now available for download

It contains several bug fixes (see the posts above ), but also several new features:
- You can now press [<-] when an error occurs to go the line where the problem was encountered
- There is now a cas.elem() functions to index CAS lists and matrices (thanks to SoftCalc)
- No more crashes when the calculator runs out of memory, just a soft error in the console window (thanks to SoftCalc again )
- True multi-language support, although only English and French are available for now

Enjoy

Seems to be a problem at the end programs, they not end like before...
<-- this is great! Really helpful
Some sentences are in french some in english... is it possible to fix only one language?

[Orwell]

Yikes!
Give me 10 minutes to correct it

[Orwell]

Ok it is now corrected. Thanks, I was in a rush last time and I added a stupid error at the last minut

[-Tom-]

Ok it is now corrected. Thanks, I was in a rush last time and I added a stupid error at the last minut

Is this corrected version available now?
Becouse I tried again, with newly downloaded file, ad seems that this bug with ending of program is not fixed....

[Orwell]

It should be ok now...
Or perhaps I don't understand what's you problem exactly

[-Tom-]

It should be ok now...
Or perhaps I don't understand what's you problem exactly

When I run a program, when it should finish itis not happening. It does not want to back to editing window. I will try again now...

require("cas")

function round(m,n)
x=cas.fround(m,n)(0)
return x
end

print("Czy TETA=90? (0=T,1=N)")

repeat
i=waitkey()-48
until i==0

if i==0 then

clear()
print("Podaj blad systemu:")
us=input()
us=tonumber(us)

print("Podaj odleglosc do niebezpieczenstwa:")

dn=input()
uc=0.04*dn

t=round((25+0.5*dn)*(uc^2-us^2)^0.5,2)

if uc>=us 
then
print("Pozycja co: " .. t)
end

end

print("\r-press any button-")
waitkey()

Shortened to minimum