I'm currently trying to perform the small changes about the 'doscript', 'require' and 'export' functions. If it takes me more than 20 minutes, I will release the current version and include those changes lateryes, yes, yes!

Posted 23 October 2005 - 02:56 PM
I'm currently trying to perform the small changes about the 'doscript', 'require' and 'export' functions. If it takes me more than 20 minutes, I will release the current version and include those changes lateryes, yes, yes!
Posted 23 October 2005 - 03:33 PM
Posted 23 October 2005 - 04:11 PM
Posted 23 October 2005 - 06:18 PM
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 MondayWhew, 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
Posted 23 October 2005 - 07:29 PM
Posted 23 October 2005 - 08:03 PM
You're right, I announced that nil values would be available for matrix too, but I had to remove it very quickly because it was really horrible to handle.(1) Suppose that we define a 4x4 matrix by A=mat.new(4,4). Now, printing that matrix reveals that each element is equal to zero. This is not a bug, but I was expecting the matrix A filled with nils, instead of zeros. Wouldn't this be more natural? It will prevent the user to use a matrix before setting its elements; as it is now, if the user forgets to do so (a common error), it will be rather difficult to find the error, especially in large programs.
Hmmm... in fact, a matrix (like the CAS expressions) is a userdata. I could probably find a workaround to change the string returned by the "type" function for userdata if you want...(2) if A=mat.new(4,5) then type(A) returns "userdata". It's one of the Lua predifined data types, and it's ok, although I was expecting "matrix".
This is not a bug, it is my choiceBut 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.
Oops, this time it is really a bug: I wrote "luaL_checkint(L,1)" instead of "luaL_checkint(L,2)" in my code to get the dimension argument. Nice catch(3) mat.sizedim(A,2) returns "Bad argument #1 to 'sizedim' (number expected, got userdata)". According to the documentation, it should return 5. Suspecting that the arguments of sizedim were inverted by mistake, I tried mat.sizedim(2,A), and I got "bad parameter #1: matrix reference required". In other words, mat.sizedim is buggy.
Posted 23 October 2005 - 08:26 PM
In my opinion, Matlab's (and Fortran's) implementation is preferrable, but it's not really important, provided that you inform us how it worksThis 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?
Bug-hunting is one of my hobbies, especially if someone else will correct themNice catch
Posted 23 October 2005 - 08:40 PM
I had writtenIn my opinion, Matlab's (and Fortran's) implementation is preferrable, but it's not really important, provided that you inform us how it works
.
* d1, d2, ... = mat.size(matrix) // Return the size of each dimension of a matrixin the file functions.txt, but yes, I know, I really need to write a decent documentation
Hmm so 'resize' should return a resized copy of the matrix, instead of changing it... Why not. (Note that it was also written in the function list but it seems definitely unclear(4) If A=mat.new(2,3,{1,2,3},{4,5,6}}) then print(mat.resize(A,3,2)) prints an empty line (it should print a 3x2 matrix). Furthermore, if foo=mat.resize(A,3,2) then print(foo) returns "nil", and A is changed to {{1,2},{4,5},{0,0}}; I was expecting to leave A untouched, and to set foo to {{1,2},{3,4},{5,6}}. In other words, resize seems to change its first argument, it changes it incorrectly, and it does not seem to return anything. Btw, when you correct this, be sure to explain how the resized matrix will be filled: row-wise or column-wise? (I prefer column-wise, as it's done in Fortran, but this is not really important).
So you didn't try to simply perform ordinary operations on the matrices?Btw, mat.mul (matrix multiplication) is missing. Are you planning to add it later?
Posted 23 October 2005 - 10:11 PM
Indeed, you really need to write a decent documentation. However, I was too hurry to test the new version, and I have felt to the same mistake once again: thinking as in Fortran, I was almost sure that size works as I was expected, and I didn't mentioned the syntax you adopted. Thinking of it again, getting accustomed to one language is not always a good thing, especially if you test another one.but yes, I know, I really need to write a decent documentation
Well, in all languages that I know, "resize" actually "shuffles" the elements of a matrix. For example, if A=mat.new(2,3,{1,2,3},{4,5,6}}) then mat.resize(A,3,2), if implemented 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).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, you asked for itSo you didn't try to simply perform ordinary operations on the matrices?
Posted 23 October 2005 - 11:17 PM
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 functionIn any case, foo=mat.resize(A,3,2) should not affect A itself; I think that it's very confusing; it should return a new matrix instead. Afterall, if the user wants to convert A itself, he can always write A=mat.resize(A,3,2).
In fact, the interpreter expects a table or a matrix, of the same size as the part of the matrix A written at the left of the sign '='. In that case, you should give a 2*3 matrix/table for the new content of 'A[{}][{}]'. But here '{33}' is a simple table and the interpreter cannot guess by himself that the value '33' must be assigned to each element of A. However, 'A[{}][{}]=33' is okay.(1) A[{}][{}]={33} returns {{0,0,0},{0,0,0}}; I think that an error message should be printed in this case, say "expected number, got table/matrix".
Hmm, that's right. I'm just not used to make additions between matrices and scalar, so I didn't implement it. But I agree it could be convenient(2) B=A+1 does not work. the same holds true for B=math.new(A+1). In general, you cannot add, subtract or devide any scalar from the elements of a matrix this way. Only multiplying a matrix by a scalar is implemented, i.e., B=A*2 works as expected.
(3) [font=Courier New]A+B[/font] and [font=Courier New]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
Wah(4) B=A should return {4,5,6}, but returns {1,2,3}. More worse than that, [{}]print(A[{}][ 1 ]) sometimes returns {{},{}}, sometimes causes a fatal error
.
Posted 24 October 2005 - 07:02 AM
Posted 24 October 2005 - 07:16 AM
Well, take a pencil and a paper, and write 1000 million times: "Lua is not C". I will also take a pencil and a paper, and I will write 1000 million times: "Unfortunately, Lua is not Fortran"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.
I know that the interpreter expects a matrix, and A[{}][{}]={33} is clearly an error, but the interpreter should detect this, and print an appropriate error message. As it is now, it will be realy hard to find the error in a large program.In fact, the interpreter expects a table or a matrix, of the same size as the part of the matrix A written at the left of the sign '='. In that case, you should give a 2*3 matrix/table for the new content of 'A[{}][{}]'. But here '{33}' is a simple table and the interpreter cannot guess by himself that the value '33' must be assigned to each element of A. However, 'A[{}][{}]=33' is okay.
Believe me, it will be very convenient. Don't forget to implement subtraction and division by a scalar, too.Hmm, that's right. I'm just not used to make additions between matrices and scalar, so I didn't implement it. But I agree it could be convenient
Well, see it from another point of view: the + and - operators can be used to perform matrix addition 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 thingI designed the matrix type as an algebric object, and not really as a programming tool... That's why the algebric operations are implemented like that (that's also why you cannot add a scalar to a matrix or divide a matrix by another). The problem is that you can consider the matrices with two different points of view (programmer or mathematicist (I hope this is the correct spelling)), and there are many things that will seem very confusing for some users or simply natural for other ones, depending on what you want to do
Yes, I noticed that the fatal error occurs when trying to print A, not when evaluating it. Btw, wouldn't be useful to add a more sophisticated printing function, such as [{}]printf for formatted printing? I think that it will be very easy to do this.Okay this is a problem in the "tostring" operation, not on the manipulation of the matrix: A
[{}] indicates the second row correctly, it just prints something stupid. But it should be easily fixed
Please, think of it again, and consider how * and / is used in matrix-oriented languages.Every problems have been corrected, there is just the '*' operation that I didn't replace because I'm not sure if it is a good idea or not...
Ehm, what about divisions?However, the matrices are now printed correctly, the 'resize' function returns a resized copy, and you can perform additions/substractions between matrices and scalars.
Posted 24 October 2005 - 07:35 AM
Okay, but I guess you will have to wait a little bit for the next release of CPLua then =)Well, take a pencil and a paper, and write 1000 million times: "Lua is not C".
I don't wish to debate again about this (altough we could), but the main advantage of the C language here is the fact that you don't have to make a copy of an object just to modify it: in most case, this is really importantWhen I saw for the first time that in C this is not the case, and that there are no pure subroutines, I said "Baaah! How can they even think that this is the language?"
That's why I said that A[{}][{}]=33 was okBtw, what if you want to fill a matrix with a constant?
So how can I see the difference between a 3*2 matrix filled with 33's and a 3*2*33 matrix filled with zeros then?Of course, you can use loops for this, but I think that an automatic fill machanism can be easily implemented: for example, A=math.new(3,2,33) should be vallid, and should return a 3x2 matrix with all elements equal to 33 (similar to the Matlab's functions ones and zeros, but more sophisticated).
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 would, it is in my to-do listBtw, wouldn't be useful to add a more sophisticated printing function, such as printf for formatted printing? I think that it will be very easy to do this.
*Still thinking* :/Please, think of it again, and consider how * and / is used in matrix-oriented languages.
Posted 24 October 2005 - 08:54 AM
Noooooo! Don't write it 1000 million times then.Okay, but I guess you will have to wait a little bit for the next release of CPLua then =)
I don't wish to debate again about this as well, so I won't answer to your arguments, although one can mention some 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 languageI don't wish to debate again about this (altough we could), but the main advantage of the C language here is the fact that you don't have to make a copy of an object just to modify it: in most case, this is really important
I know, I know, I already noticed it, and edited my previous post accordingly. I was in a hurry again (damn weekend, it doesn't last forever)So how can I see the difference between a 3*2 matrix filled with 33's and a 3*2*33 matrix filled with zeros then?
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.
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.
Yes, but who said that ClassPad's CAS is perfect? It's not even decentHowever, this "rather strange" behaviour is the default comportement of the CP's matrices
Wish you will take the "right" decision...*Still thinking* :/
Posted 24 October 2005 - 10:32 AM
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)
Posted 24 October 2005 - 10:36 AM
Posted 24 October 2005 - 01:09 PM
///////// 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}
Posted 24 October 2005 - 05:37 PM
Posted 24 October 2005 - 09:56 PM
Posted 24 October 2005 - 09:58 PM
Posted 24 October 2005 - 10:01 PM
Posted 25 October 2005 - 10:23 AM
The link in the download topic points to the current version, 0.73 RC2, i.e., it is correct. However, the latest version referred to the topic is 0.72, and there is no link for this. This might be confusing for someone who wants to download CPLua for the first time (he thinks that the link refers to version 0.72, which is not true). That's probably what unique33 wants to say. Maybe it will be better if Orwell adds a link for the latest "stable" version, which is 0.72. However, every version until now is considered as "beta", and that's probably the reason for linking the latest version.I mean the post in the download Cplua topic .
Posted 25 October 2005 - 10:26 AM
Posted 25 October 2005 - 11:52 AM
How one will be able to download version 0.73 RC2 then? I think that you should leave it as it is, or add two links, one for 0.72 and one for 0.73.RC2.That's true, I must say I forgot this link when I uploaded the latest versions of CPLua
I will change it to points to CPLua 0.72
Posted 25 October 2005 - 12:07 PM
I finally gave the two links in the topic.How one will be able to download version 0.73 RC2 then? I think that you should leave it as it is, or add two links, one for 0.72 and one for 0.73.RC2.
Well, it's good to knowThanks for implementing all 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!
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(1) If A=mat.new(2,3,{1,2,3}{4,5,6}) then A[{}][ 2 ] is equal to {2,5}; this is not a bug; although one could expect {{2},{5}}, it is perharps preferable as it is. However, mat.dim(A[{}][ 2 ]) returns 1, instead of 2.
That's right, I didn't consider the case where you pass a matrix after the dimensions, simply because you can write 'B=mat.new(A[{}][ 2 ])' (or 'B=mat(A[{}][ 2 ])') directly; since it is possible to get the dimensions of a matrix directly (that's not the case of the tables) there is no need to specify it in the mat.new functionFurthermore, B=mat.new(A[{}][ 2 ]) is valid, but B=mat.new(1,2,A[{}][ 2 ]) is not, probably because, in the latter case, the third argument is expected to be a table, not a matrix.
It seems like I forgot to add this error message in CPLua 0.73RC2(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).
Posted 25 October 2005 - 01:44 PM
As I said, the fact that A[{}][ 2 ] is considered as a simple 1D matrix is not a problem at all. Btw, would't be useful to implement good equality test of matrices? As it is now, mat.new(2,{3,5})==mat.new(2,{3,5}) returns "false"Hmmm... In the way I implemented it (and the whole package is based on it), 'A[{}][ 2 ]' is considered exactly like a simple 1D matrix, because you only let one dimension free. This is why it prints the text '{2,5}' and why the mat.dim function returns 1 and not 2. I think everything is coherent, supposed that we know exactly what is done
If something seems very strange though, don't hesitate to ask me
It's ok, although it will be more "robust", if mat.new could also handle matrices.That's right, I didn't consider the case where you pass a matrix after the dimensions, simply because you can write 'B=mat.new(A[{}][ 2 ])' (or 'B=mat(A[{}][ 2 ])') directly; since it is possible to get the dimensions of a matrix directly (that's not the case of the tables) there is no need to specify it in the mat.new function
Nice.It seems like I forgot to add this error message in CPLua 0.73RC2
but it is easy to do so it should be okay
Posted 25 October 2005 - 01:52 PM
Posted 25 October 2005 - 02:06 PM
I'm not surprised; CPLua is obviously the largest Add-In ever madeJust for your information, the entire CPLua project comprises currently something like 23200 lines of C/C++ code, split in 86 files, for more than 600 Kb of code.
Altough 10550 lines from this total concern the core of the Lua interpreter, that I didn't write myself and on which I would like to avoid modifications as much as possible, it's starting to be a consistent project
Wow, cool stuff. There is even a <{GNULINUX}> version of Lua, and, together with its IDE made by eclipse, it makes it a real programming environment, for whoever wants to run Lua on his PC.Did anyone already take a look on the Lua stuff available on the web, and particularly on the links of this page? I've just seen several interesting things, such as the "tolua" wrapper (which should be really useful), and also the other versions of the Lua Reference Manual.
Cheater!Perhaps I will use one of those 'summaries' and booklets and complete it with the ClassPad's specific stuff for the future documentation of CPLua
Of course it's not. But mat.new itself is more robust, if it can handle B=mat.new(A) as well as B=mat.new(2,3,A). But it's not really important: if you can implement it easily, it will be nice; if it needs time, forget it.But Is it really more robust to write "B=mat.new(2,3,A)" instead of "B=mat.new(A)"?
Posted 25 October 2005 - 09:56 PM
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)
Posted 26 October 2005 - 12:23 AM
yeah . It was exactly what I wanted to say.The link in the download topic points to the current version, 0.73 RC2, i.e., it is correct. However, the latest version referred to the topic is 0.72, and there is no link for this. This might be confusing for someone who wants to download CPLua for the first time (he thinks that the link refers to version 0.72, which is not true). That's probably what unique33 wants to say. Maybe it will be better if Orwell adds a link for the latest "stable" version, which is 0.72. However, every version until now is considered as "beta", and that's probably the reason for linking the latest version.
nice.I finally gave the two links in the topic.
Posted 26 October 2005 - 12:12 PM
function LUinverse(LU,indx) local n,Ainv,Id if LU~=nil then n=mat.sizedim(LU,1) Id=mat.ident(n) Ainv=mat.new(n,n) for i=1,n do Ainv[{}][i]=LUsubstitute(LU,indx,mat.new(Id[{}][i])) end return Ainv end end(this function calls the function LUsubstitute, which is correct, so I'm not posting it to save space). Unfortunately, the above code does not work. The problem is in the line
Ainv[{}][i]=LUsubstitute(LU,indx,mat.new(Id[{}][i]))which result a runtime error ("Dimension mismatch"). However, the dimensions of Ainv[{}][i] and LUsubstitute(LU,indx,mat.new(Id[{}][i])) are both equal to 1, and both vectors contain the same number of elements
foo=LUsubstitute(LU,indx,mat.new(Id[{}][i])) Ainv[{}][i]=fooeverything is ok. Note that the alternative code does exactly the same thing, except that it uses a temporary variable foo. I really don't get it
Posted 26 October 2005 - 02:01 PM
Posted 26 October 2005 - 11:17 PM
What kind of problem?"*" sign in draw.text have a problem.
That's true, a function to draw a table would be greatwhat is your Idea about draw.title? (...)
Posted 26 October 2005 - 11:37 PM
I tried to do such a thing in the console window (it's actually the function MatPrint, included in LuaNumAn), but there is an obvious problem: the ClassPad screen is not wide enough to print even a 4x4 matrix, with elements having several decimal digits. Of course, in the graph window, one can use a smaller font, and a specified format with a fixed number of decimal digits, so it's possible to print wider matrix rows in a single line. But the problem remains. I personally gave up.That's true, a function to draw a table would be great
But there are many possibilities, depending on the size/dimensions of the table, the type of its element, the "style" of the frame etc... We should make a standard implementation for this
Posted 27 October 2005 - 12:08 AM
Orwell :
what kind of problem ?
yeah .you are right.Orwell :
there is no need for draw.title
I tried to do such a thing in the console window (it's actually the function MatPrint, included in LuaNumAn), but there is an obvious problem: the ClassPad screen is not wide enough to print even a 4x4 matrix, with elements having several decimal digits. Of course, in the graph window, one can use a smaller font, and a specified format with a fixed number of decimal digits, so it's possible to print wider matrix rows in a single line. But the problem remains. I personally gave up.
Posted 28 October 2005 - 06:28 PM
Posted 28 October 2005 - 06:37 PM
With draw.point() you can draw a point with a custom width for example, and with draw.pixel() you can only turn a single pixel on or off.I noticed something a bit strange:what is the difference between draw.point() and draw.pixel() ?
Posted 28 October 2005 - 09:44 PM
Posted 28 October 2005 - 10:07 PM
> 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 /
> > 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 /-----------------------------------------------------------------------------------------------------------
> > 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( 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-----------------------------------------------------------------------------------------------------------------------
Posted 29 October 2005 - 06:51 AM
0 members, 5 guests, 0 anonymous users