You can subscribe to this list here.
2000 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}
(8) 
_{Oct}
(30) 
_{Nov}
(62) 
_{Dec}
(12) 

2001 
_{Jan}
(53) 
_{Feb}
(28) 
_{Mar}
(31) 
_{Apr}
(18) 
_{May}
(30) 
_{Jun}
(15) 
_{Jul}
(21) 
_{Aug}
(100) 
_{Sep}
(70) 
_{Oct}

_{Nov}

_{Dec}

2002 
_{Jan}
(1) 
_{Feb}

_{Mar}

_{Apr}
(1) 
_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

2003 
_{Jan}
(1) 
_{Feb}
(1) 
_{Mar}
(1) 
_{Apr}
(1) 
_{May}
(3) 
_{Jun}
(1) 
_{Jul}
(6) 
_{Aug}
(9) 
_{Sep}
(1) 
_{Oct}
(13) 
_{Nov}
(1) 
_{Dec}
(4) 
2004 
_{Jan}
(6) 
_{Feb}
(4) 
_{Mar}
(6) 
_{Apr}
(17) 
_{May}
(11) 
_{Jun}
(17) 
_{Jul}
(11) 
_{Aug}
(9) 
_{Sep}
(2) 
_{Oct}
(8) 
_{Nov}
(21) 
_{Dec}
(22) 
2005 
_{Jan}
(4) 
_{Feb}
(3) 
_{Mar}
(22) 
_{Apr}
(9) 
_{May}
(13) 
_{Jun}
(19) 
_{Jul}
(17) 
_{Aug}
(45) 
_{Sep}
(31) 
_{Oct}
(43) 
_{Nov}
(5) 
_{Dec}
(7) 
2006 
_{Jan}
(4) 
_{Feb}
(5) 
_{Mar}
(19) 
_{Apr}
(6) 
_{May}
(3) 
_{Jun}
(4) 
_{Jul}

_{Aug}
(5) 
_{Sep}
(11) 
_{Oct}
(51) 
_{Nov}
(73) 
_{Dec}
(27) 
2007 
_{Jan}
(28) 
_{Feb}
(14) 
_{Mar}
(43) 
_{Apr}
(49) 
_{May}
(39) 
_{Jun}
(33) 
_{Jul}
(25) 
_{Aug}
(48) 
_{Sep}
(38) 
_{Oct}
(30) 
_{Nov}
(30) 
_{Dec}
(19) 
2008 
_{Jan}
(10) 
_{Feb}
(8) 
_{Mar}
(47) 
_{Apr}
(29) 
_{May}
(18) 
_{Jun}
(10) 
_{Jul}
(26) 
_{Aug}
(16) 
_{Sep}
(19) 
_{Oct}
(14) 
_{Nov}
(22) 
_{Dec}
(28) 
2009 
_{Jan}
(16) 
_{Feb}
(15) 
_{Mar}
(19) 
_{Apr}
(59) 
_{May}
(120) 
_{Jun}
(95) 
_{Jul}
(61) 
_{Aug}
(25) 
_{Sep}
(20) 
_{Oct}
(37) 
_{Nov}
(11) 
_{Dec}
(18) 
2010 
_{Jan}
(8) 
_{Feb}
(9) 
_{Mar}
(39) 
_{Apr}
(56) 
_{May}
(88) 
_{Jun}
(69) 
_{Jul}
(47) 
_{Aug}
(54) 
_{Sep}
(23) 
_{Oct}
(11) 
_{Nov}
(2) 
_{Dec}

2011 
_{Jan}
(1) 
_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

2012 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}
(1) 
_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

2013 
_{Jan}
(1) 
_{Feb}
(16) 
_{Mar}
(26) 
_{Apr}
(32) 
_{May}
(4) 
_{Jun}
(8) 
_{Jul}
(14) 
_{Aug}
(3) 
_{Sep}
(7) 
_{Oct}
(11) 
_{Nov}
(6) 
_{Dec}
(9) 
2014 
_{Jan}
(14) 
_{Feb}
(15) 
_{Mar}
(11) 
_{Apr}

_{May}

_{Jun}
(3) 
_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}
(5) 
_{Dec}
(1) 
2015 
_{Jan}
(5) 
_{Feb}
(2) 
_{Mar}
(6) 
_{Apr}
(1) 
_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17
(2) 
18
(1) 
19
(1) 
20

21

22
(1) 
23
(2) 
24
(2) 
25
(3) 
26
(7) 
27
(3) 
28
(6) 
29

30
(1) 
31
(1) 




From: Yann SECQ <Yann.S<ecq@li...>  20001031 07:21:40

Hi, I've found to math library which could be helpful (and this time, the source code is available) : MPJAVA is a Java implementation of David Bailey's Fortranbased multi precision package. The package performs multi precision floating point arithmetic with arbitrary precision level. It takes advantage of Java's inheritance facility to provide smooth transition from primitive arithmetic types : http://www.cs.unc.edu/Research/HARPOON/mpjava/#intro The Java Ultimate Math Package (JUMP) is a library that offers arbitrary precision mathematical computations. It provides a base for real, rational and integer number computations : http://members.nbci.com/znerd/java/jump/index.html Cheers, yann.  Yann SECQ Thèse d'Informatique en préparation, SMAC, LIFL secq@... Studying for a PhD in Computer Science javafan@... S.M.A, Modélisation et Programmation Orientée Agents http://www.lifl.fr/~secq M.A.S & Agent Oriented Programming and Modeling 
From: David Edwards <d.edwards@li...>  20001030 23:09:27

I've done a bit of research (mainly what I can remember from Numerical Methods course and what I have in my textbooks), and I have a couple more methods that might (or might not) be relevant to calculating some of the functions you mentioned. Firstly, the sqrt(double x) code, if you use a low bestguess (such as best guess of 100 for sqrt(100000)) you will end up getting back the negative root of the equation it is trying to solve. So you will want to check for this and return the absolute value of the number. Not much of a problem really. Oh, and I tried implementing the function and it was converging in between 3 and 10 iterations using the new best guesses. exp(x) can be calculated using the sum over i (from 1 to infinity) of x^i / i! where i! is i factorial, i.e. 1 * 2 * 3 * ... * i this looks like: 1 + x + (x^2 / 2) + (x^3 / 6) + (x^4 / 24) + (x^5 / 120) + ... This converges quite quickly, if I recall. Now, ln(x) is a different matter. It seems that it is a bit more difficult to calculate  I haven't been able to find a power series (such as the one for exp(x)) that will calculate ln(x), only ones that converge if x < 1. Perhaps with a bit of work this idea could be explored. However, NewtonRaphson appears to converge for ln(x) although I have only tried it with a few values. Using ln(a) = x => a = exp(x) by taking the exponent of each side, use f(x) = exp(x)  a. Then f ' (x) = exp(x) and x_(n+1) = x_n  [(exp(x_n)  a) / exp(x_n)] so x_(n+1) = x_n + (a / exp(x_n))  1 would work. The java would be something like: public double ln(double a) { double best = a; double accuracy = 0.00000000001; double newx = a + (a / exp(a))  1; double oldx = a; while (newx < oldx  accuracy  newx > oldx + accuracy) { oldx = newx; newx = oldx + (a / exp(oldx))  1; } return newx; } but don't quote me on that! Don't know if that is what you want, or whether it will work for all values of x. Oh yes, ln(x) is not defined for x <= 0 so you might want to include a test for that, and ln(1) = 0 as well. Also log(double base, double x), can be calculated using ln(x) / ln(base). Also, I don't know how efficient this will be as it has to calculate exp(oldx) each time it iterates. I don't know of a way around this, yet. The java for exp(x) would be something like: public double exp(double x) { double sum = 1; double oldsum = 0; int i = 1; double accuracy = 0.00000000001; double powTemp = 1; double facTemp = 1; while (sum < oldsum  accuracy  sum > oldsum + accuracy) { oldsum = sum; powTemp *= x; facTemp *= i; sum += powTemp / facTemp; i++; } return sum; } I think this should work. I haven't tried it. Basically it keeps a running tally of the power of x and factorial so it doesn't have to calculate it each time. Remember that 0! = 1. pow(double x, double y) i.e. x^y can be rewritten as exp(y * ln(x)) and trust me, it works for positive values of x. If x is 0, give back 0 unless y = 0 in which case give back 1. If y is 0 always give back 1. If x is negative, use exp(y * ln(x)). I can't think of any other way of doing of doing the power function and I don't know exactly how efficient this method (or that for ln(x)) will be. Hope this has been helpful... Dave. 
From: David Edwards <d.edwards@li...>  20001028 23:52:45

> Thanks for the info on NewtonRaphson, David. I will try to put in a better > "best guess" to start the ball rolling. > > Does this mean we could compute pow(double, double) using NewtonRaphson? > If I understand the theory, power would be a thirdorder function and > require 8 floatingpoint operations per iteration. Would you be able to > come up with an equation I could use to figure out powers? I really don't > know where to begin in developing the equation  can't say I understand how > you came up with f(x) = x^2  a for sqrt, so I wouldn't have a hope of > figuring out power. I can picture it visually the way you described it with > xy axis and homing in on it using tangent, just not the math part. Sorry....I am used to talking maths with people who are on my course. ;) Like I said, NR gives you a solution to the formula f(x) = 0, in other words it finds numerically a "root" of an equation. In our case, we want x = sqrt(a) which if we square both sides, we get x^2 = a (don't need to worry about the sign), therefore in order to get an equation of the form f(x) = 0 we take f(x) = x^2  a. Does that explain it better? This formula is nice because the derivative of x^2  a = 2x which cancels down nicely when put into the NR formula to give an easy formula to calculate with. In the case of pow(double, double) we can't really do this, as you would have to dynamically differentiate (not hard with simple powers) and then you would still end up with other powers in your equation.....in the end I don't think that NR could do it. I have plenty of maths textbooks at my disposal  I will look into it if I have the time. Also, the bit I put about being able to get a thirdorder estimate was only for sqrt(x).  Dave. 
From: Brian Bagnall <bbagnall@es...>  20001028 23:13:45

Thanks for the info on NewtonRaphson, David. I will try to put in a better "best guess" to start the ball rolling. Does this mean we could compute pow(double, double) using NewtonRaphson? If I understand the theory, power would be a thirdorder function and require 8 floatingpoint operations per iteration. Would you be able to come up with an equation I could use to figure out powers? I really don't know where to begin in developing the equation  can't say I understand how you came up with f(x) = x^2  a for sqrt, so I wouldn't have a hope of figuring out power. I can picture it visually the way you described it with xy axis and homing in on it using tangent, just not the math part.  Brian  Original Message  From: "David Edwards" <d.a.edwards@...> To: <tinyvmdiscussion@...> Sent: Saturday, October 28, 2000 7:52 AM Subject: Re: [tinyvmdiscussion] sqrt code > Hi. This is my first attempt at mailing here, so I hope it works.... > > NewtonRaphson iteration is a great way of getting convergence of an > iterative sequence  it is (usually) secondorder, meaning that the error > decreases in the order x^2. > > In order to understand the NewtonRaphson method you have to look at it > graphically. It works by finding the root to the equation f(x) = 0, in this > case [ f(x) = x^2  a ] where a is the square root we are trying to find. > You probably know this, but the formula is [ x_n+1 = x_n  [f(x_n) / f ' > (x_n)] ] where f ' (x) is the first derivative of f(x). Simplifying this > down gives the formula that was used in the code posted earlier. > > Now, drawing the graph of [ f(x) = x^2  a ] shows a quadratic curve centred > at 0 shifted by a in the yaxis. Now, NewtonRaphson works by drawing the > tangent to the curve at x (the latest guess) and then taking the next guess > where the tangent crosses the xaxis. As you can see, for small numbers with > the quadratic curve this homes in quite nicely on the solution. The problem > is, that with "a" large you end up with your tangent coming down almost > vertically, so it takes a long time to converge to the solution. > > I know for a fact that there are formulae with convergence of at least > thirdorder and it is probably possible to derive an equation with 4th order > convergence, but the problem is that you end up with a lot more calculations > than you bargained for. The NR equation for sqrt(x) is nice because it > doesn't require much in the way of calculation. The thirdorder one requires > 8 flops (floating point operations) per iteration, whereas the secondorder > requires 3. > > In the end, your solution probably lies in the choice of your first "best > guess". For example, it is not a good idea to use 100000 as your best guess > for sqrt(100000). Better using something like 100 and convergence *should* > be much faster. So you need a way of choosing a suitable first guess. e.g. > if it is more than 100, divide by 10 and take as best guess, if more than > 10000, use 100 as best guess. > > Sorry for being so longwinded here, I believe it is essential to understand > how NR works in order to point out its flaws, and ways to get around it. > > One last thing  you would also need a test to check whether or not the > number you are finding out about is negative (if only we all used complex > numbers, life would be so much easier)... > > Thanks for listening, > > David Edwards. > > _______________________________________________ > tinyvmdiscussion mailing list > tinyvmdiscussion@... > http://lists.sourceforge.net/mailman/listinfo/tinyvmdiscussion 
From: David Edwards <d.edwards@li...>  20001028 13:52:19

Hi. This is my first attempt at mailing here, so I hope it works.... NewtonRaphson iteration is a great way of getting convergence of an iterative sequence  it is (usually) secondorder, meaning that the error decreases in the order x^2. In order to understand the NewtonRaphson method you have to look at it graphically. It works by finding the root to the equation f(x) = 0, in this case [ f(x) = x^2  a ] where a is the square root we are trying to find. You probably know this, but the formula is [ x_n+1 = x_n  [f(x_n) / f ' (x_n)] ] where f ' (x) is the first derivative of f(x). Simplifying this down gives the formula that was used in the code posted earlier. Now, drawing the graph of [ f(x) = x^2  a ] shows a quadratic curve centred at 0 shifted by a in the yaxis. Now, NewtonRaphson works by drawing the tangent to the curve at x (the latest guess) and then taking the next guess where the tangent crosses the xaxis. As you can see, for small numbers with the quadratic curve this homes in quite nicely on the solution. The problem is, that with "a" large you end up with your tangent coming down almost vertically, so it takes a long time to converge to the solution. I know for a fact that there are formulae with convergence of at least thirdorder and it is probably possible to derive an equation with 4th order convergence, but the problem is that you end up with a lot more calculations than you bargained for. The NR equation for sqrt(x) is nice because it doesn't require much in the way of calculation. The thirdorder one requires 8 flops (floating point operations) per iteration, whereas the secondorder requires 3. In the end, your solution probably lies in the choice of your first "best guess". For example, it is not a good idea to use 100000 as your best guess for sqrt(100000). Better using something like 100 and convergence *should* be much faster. So you need a way of choosing a suitable first guess. e.g. if it is more than 100, divide by 10 and take as best guess, if more than 10000, use 100 as best guess. Sorry for being so longwinded here, I believe it is essential to understand how NR works in order to point out its flaws, and ways to get around it. One last thing  you would also need a test to check whether or not the number you are finding out about is negative (if only we all used complex numbers, life would be so much easier)... Thanks for listening, David Edwards. 
From: Hilmer <hilmer@ma...>  20001028 07:21:52

> Subject: Re: [tinyvmdiscussion] Changes to sensor API & Alpha 5 release > Date: Fri, 27 Oct 2000 11:58:18 0600 > charset="iso88591" > > Here's a different approach: When calling the constructor for a Sensor, a > programmer must specify which input you are referring to: > Sensor x = new LightSensor(Sensor.INPUT3); > If there already exists a Sensor instance using that input, the constructor > throws a SensorException! A static variable can keep track of which inputs > have already been instantiated. This will stop programmers from trying to > create more than one instance of a sensor for a particular input so there > could be no possibility of stepping all over themselves. An API like this > would be clean and workable for a developer. This is the apporach we went for in the now late RCXJVM project, we had Input and Output ports and you would attach sensors to them. We had also defined a VirtualInputPort subclasses of which allowed the attachment of several sensors, an example subclass was a TouchLightPort which allowed you to put several TouchSensor and LightSensor instances on, the Virtual Port would then notify the attached touch sensors, if the value reached 0, otherwise the LightSensors, this was done to easily support the standard trick of putting physical touch and light sensors on the same input. The nice part was that it used standard instances of LightSensor and TouchSensor, so you could easily put this VirtualPort inbetween when you had to physically do the multiplexer trick on your model. A similar approach was in the making for those resistor multiplexers which allows to destinguish between multiple touch sensors on the same port. > > We should also recognize in the API that not all outputs for an RCX are > Motors. The Motor class should be renamed Actuator, with subclasses of > Motor, Light, etc... An API similar to the Sensor one described above could > work for this too. Again we did a similar thing defining an OutputPort which had methods like on, off, setPolaristaion, changePolarisation, setPowerLevel. Søren 
From: Brian Bagnall <bbagnall@es...>  20001028 06:53:05

Thanks, Christophe! The NewtonRaphson algorithm works great. Here's the Java code: /** * Square root function. Uses NewtonRaphson method. */ public static double sqrt(double x) { double a = x; // a is a "best guess" double xnew = x; final double accuracy = 0.00000001; while((xnew*xnew) > (x + accuracy)(xnew*xnew)<(xaccuracy)) xnew = (xnew+a/xnew)/2; return xnew; } It only does about 67 loops for smaller numbers, and as many as 50 or so for larger numbers. If anyone out there sees ways to refine this, please let me know and I'll throw the changes in. I could make it loop a set number of times and then it would use less variables, plus it wouldn't have to keep checking to see if it is close to the desired accuracy. public static double sqrt(double x) { double a = x; // a is a "best guess" for(int x=0;x<30;x++) x = (x+a/x)/2; return x; } That would really simplify the code. It wouldn't be as accurate for larger numbers and would loop more times than needed for smaller numbers. I could have it loop 20 times for numbers smaller than, say, 100000 and loop 50 times for numbers larger than 100000. I'd need to play around with these figures and do some testing. Any other ideas would be appreciated.  Brian 
From: Brian Bagnall <bbagnall@es...>  20001028 04:43:07

 Original Message  From: "Christophe Ponsard" <chp@...> To: "Brian Bagnall" <bbagnall@...> Cc: <tinyvmdiscussion@...> Sent: Friday, October 27, 2000 1:55 AM Subject: Re: [tinyvmdiscussion] Math & Positioning system > I work in a computer science lab with a wonderful library, so I'll also check > for some exp/pow algorithms and send you the information. I would appreciate it very much if you could check that out for me. pow(double, double) is the main one, and log(double) is the other one which would help. log(double) right now just works accurately between 0.0001 and 1.0 which I understand is not very helpful. > It is very simple and efficient (quadratic convergence). > Let a be the real you want to extract the square root from: > > initial "good guess" > fixed point: >1 rightshift by half the digits left to decimal point, dual > for <1 > floating point: divide exponent by two > > iteration: > xnew= (x+a/x)/2 > (1 add, 1div and 1div by 2) That looks simple enough to implement. I guess you keep iterating it and checking to see if x^2 = ~a. I'll give this a try instead of what I have. > I would like to know more about on your implementation. Where is it located > in the sources ? On what RCX hardware do you rely ? Like I said, it's a theory I'm going to try. The idea is just to recalibrate the XY coordinates when they are out of whack. Right now the only methods I have coded are gotoAngle(double), forward(x), stop(), rotate(double), gotoPoint(x, y). The x,y points are constantly kept track of when any of these methods are used. I haven't got to the stage of using sensors and interacting with the environment yet, but I'm slowly getting there. Once gotoPoint() is working I'm going to try some wall following behavior using the RCX IR receiver and a light sensor. Probably your best bet for finding the distance to an object is the Sharp GP2D02 ranging sensor. It doesn't rely on signal strength to determine how far an object is, so it doesn't really matter how reflective the surface is unless is is 0 reflectance, which is probably rare other than a black hole! It uses triangulation of a reflected beam to measure distance to an object. I think cameras use this to auto focus. I'm not sure how to adapt this for an RCX yet.  Brian 
From: Brian Bagnall <bbagnall@es...>  20001027 16:55:28

As someone who likes object oriented design, I would tend to want to implement a new sensor by extending Sensor, even if it isn't quite as efficient. Alot of the Sensor methods are final, which is efficient, but there might be some which someone might want to override, such as activate() or passivate()  possibly, since I haven't tried developing a sensor yet. Also, the constructor is private (since only the class itself is allowed to instantiate instances of Sensors) and I'm not sure if I extended the class if it would allow me to call the constructor... I think it would actually! Never mind. The basic design for this is not bad, but I think somehow there should be subclasses of Sensor included. We would want to cover RotationSensor, LightSensor, BumpSensor, or any standard Lego Mindstorms sensor types with our API  an RCX camera is coming out, which would be interesting to develop for. I know if I was developing a MicrophoneSensor I would want to be able to subclass the Sensor class. How do we do this, though, and still keep your design of accessing inputs and outputs statically? As soon as you extend the Sensor class to say, RotationSensor you are still stuck with accessing all 3 sensors from methods in RotationSensor, even though all 3 sensors are not necessarily RotationSensors. Here's a different approach: When calling the constructor for a Sensor, a programmer must specify which input you are referring to: Sensor x = new LightSensor(Sensor.INPUT3); If there already exists a Sensor instance using that input, the constructor throws a SensorException! A static variable can keep track of which inputs have already been instantiated. This will stop programmers from trying to create more than one instance of a sensor for a particular input so there could be no possibility of stepping all over themselves. An API like this would be clean and workable for a developer. We should also recognize in the API that not all outputs for an RCX are Motors. The Motor class should be renamed Actuator, with subclasses of Motor, Light, etc... An API similar to the Sensor one described above could work for this too.  Brian  Original Message  From: "Jose Solorzano" <jhsolorz@...> To: "Brian Bagnall" <bbagnall@...> Sent: Thursday, October 26, 2000 10:00 PM Subject: Re: [tinyvmdiscussion] Changes to sensor API & Alpha 5 release > Yes, you can do it via delegation. But it's > probably more efficient to implement Microphone > independently of Sensor, using the native > method readSensorValue. (In leJOS, native > methods are mapped by name only, so they > can be declared in any class). 
From: Christophe Ponsard <chp@in...>  20001027 07:53:17

Brian Bagnall wrote: > > About the implementation : int are used and interpreted as being > > rightshifted by 12 bits (2^12=4096). As a result, +,,*,/ are > > computed using interger +,,*,/ (with some corrective shifts) > > Trigonometric functions are computed from linear interpolation in a > > table, > > NewtonRaphson is used for sqrt. > > First, Christophe, I would be very interested in how pow(double, double) > could be computed. Right now my version isn't right , and only does > pow(double, int). This makes me unable to add functions for E^x and 10^x. > You seem to know a fair ammount about this stuff, so could you enlighten me > of send me a link? I heard the "Art of Computer Porgramming" by Donald > Knuth has this sort of thing in it, but I don't want to shell out for the > book. I did not look very close how MathFP implements this (right now I did not use it) but I'll have a look. I work in a computer science lab with a wonderful library, so I'll also check for some exp/pow algorithms and send you the information. > I'll find out more about NewtonRaphson for sqrt(). I whipped up the sqrt > calculation myself by just homing in on the correct answer until it is close > enough within a certain ammount of error (0.00000001 or something like > that). > It is very simple and efficient (quadratic convergence). Let a be the real you want to extract the square root from: initial "good guess" fixed point: >1 rightshift by half the digits left to decimal point, dual for <1 floating point: divide exponent by two iteration: xnew= (x+a/x)/2 (1 add, 1div and 1div by 2) > > Anyway, I think that for keeping track of the precision, fixedpoint > > maths are > > precise is enough, given the errors when controling a mobile robot and > > their accumulation... unless the robot could correct using external > > information > > through some kind of positioning system : as someone tried such a thing > > ? > > My idea for this is to map the outside border of a room by following the > wall, then periodically using the corners of the room to "recalibrate" the > XY coordinates. It's all theory now, but I hope to get into it soon. > Along similar lines, it might be possible to have the RCX home in on the RCX > transmitter and use it as a beacon to recalibrate the XY coordinates. This is an idea but it seems difficult to implement it:  is there sensor info on IR level ?  how to design a robust algorithm to convert this in "distance" from the tower (battery level of the tower, beam reflections, RCX orientation) I'll think about it. Maybe supplementary light sensor/light source could be useful (?) or other kinds of sensor (I know ultrasonic waves are good for distance computation but a new sensor has to be designed...) I would like to know more about on your implementation. Where is it located in the sources ? On what RCX hardware do you rely ? This is really a nice piece of work ! Bye Christophe 
From: Brian Bagnall <bbagnall@es...>  20001027 00:47:50

I gave it some more thought, and tried thinking of why we would want to change the API in terms of pro's and con's. Right now it has been working great for me for what I've been doing. If we allowed instantiated instances of sensors and outputs they could be stepping all over themselves. The real question is, if I make a new sensor input (such as a microphone or something) and I want my program to allow my own Microphone API, can it be done? I might want things like Microphone.listen() or something. Is it easy to do this the way things are? If I make a custom output device like a servo motor, is it easy to use the existing package to make my own (probably static) Servo classes? I haven't tried any of these things yet, so maybe you or someone else is in a better position to answer this.  Brian  Original Message  From: "Jose Solorzano" <jhsolorz@...> To: "Brian Bagnall" <bbagnall@...>; <tinyvmdiscussion@...> Sent: Thursday, October 26, 2000 3:25 PM Subject: Re: [tinyvmdiscussion] Changes to sensor API & Alpha 5 release > The difference with java.awt, as you point out, > is that there would not be a onetoone correspondence > with physical sensors. In AWT, for every instance > of java.awt.Component, there will be a visible > component. You cannot really have two instances for > the same physical component. (MVC comes to mind, > but that might be an overkill). > > Making methods static, as you suggest, would > work. But if some sensor methods apply to an > instance and others require a sensor id, would > the API be a good API? In a sense, having > Sensor.S1, S2 and S3 is similar to making > everything static, but more usable imho. > > There are other considerations, such as how > the ROM routine works, how it uses previous > values, what can be done to make the API perform > better, and so on. > > An object oriented approach is seemingly more > appropriate, but it doesn't look like it would > work out very well. In any case, the first beta > hasn't been released, and there's still a > chance for major API changes. > > Regards, > Jose > > > > > > > __________________________________________________ > Do You Yahoo!? > Yahoo! Messenger  Talk while you surf! It's FREE. > http://im.yahoo.com/ 
From: Jose Solorzano <jhsolorz@ya...>  20001026 21:25:28

> My thoughts on Peter Dekkers suggestion is this > would be an excellent architecture to follow as it > would mirror Sun's approach to the design of their > API. e.g. (java.awt.Component, then all sorts of > components like Button extend Component) Not to > mention it is just plain good object oriented design > to do it this way. > > Your current design uses only static methods for the > motors and sensors so they are never instantiated by > the programmer. If I read your email right, Peter > Dekkers suggests being able to instantiate an > instance of a sensor or motor. The main problem > with this being with Lejos there is physically only > 3 unique input's or output's. Like you said, if you > try to set different modes for the sensor types of a > single instance it could be tricky. Two instances > of the same input could have different settings. > > Could you get around this by using a static method > for setting the sensor type (along with some static > variables) so that it will keep the sensor type > variable synchronized for each instance? For > example, the Sensor class could contain 3 static > int's which represent the sensor types for the 3 > different sensor inputs (Input1 = LIGHT, Input2 = > SWITCH, Input3 = LIGHT). A nonstatic (instance) > variable would indicate which of the 3 input's the > instance refers to. So with this API if a user > changed the sensor type it would change it for all > instances of that particular input. > > These are just rough thoughts and I'm not sure what > other factors would work into this. It should take > care of the problem of having 2 instances with > different sensor types, I believe. We need more > discussion on this before actually changing the > current API, though. > >  Brian The difference with java.awt, as you point out, is that there would not be a onetoone correspondence with physical sensors. In AWT, for every instance of java.awt.Component, there will be a visible component. You cannot really have two instances for the same physical component. (MVC comes to mind, but that might be an overkill). Making methods static, as you suggest, would work. But if some sensor methods apply to an instance and others require a sensor id, would the API be a good API? In a sense, having Sensor.S1, S2 and S3 is similar to making everything static, but more usable imho. There are other considerations, such as how the ROM routine works, how it uses previous values, what can be done to make the API perform better, and so on. An object oriented approach is seemingly more appropriate, but it doesn't look like it would work out very well. In any case, the first beta hasn't been released, and there's still a chance for major API changes. Regards, Jose __________________________________________________ Do You Yahoo!? Yahoo! Messenger  Talk while you surf! It's FREE. http://im.yahoo.com/ 
From: Brian Bagnall <bbagnall@es...>  20001026 17:44:06

Thanks, Yann. I will give that a try. I used the Taylor series yesterday to implement a log() method (natural log). There is one caveat which could be pretty big: it is only accurate for numbers between 0.0001 and 1.0. After log(2.0) the numbers get way out of whack. Does anyone know enough about log() to tell me how useful this log() function would be to anyone? Or does anyone know if it is possible to extrapolate numbers greater than 1.0 using the existing log() function?  Brian  Original Message  From: "Yann SECQ" <Yann.Secq@...> To: "Brian Bagnall" <bbagnall@...> Cc: <tinyvmdiscussion@...> Sent: Thursday, October 26, 2000 3:08 AM Subject: Re: [tinyvmdiscussion] Keeping track of coordinates with Lejos >Hi Brian, I'll have a second try, with a link which could be more >interresting. >it's from SGI : http://oss.sgi.com/projects/crcalc/CRCalc.html 
From: Brian Bagnall <bbagnall@es...>  20001026 17:38:51

> About the implementation : int are used and interpreted as being > rightshifted by 12 bits (2^12=4096). As a result, +,,*,/ are > computed using interger +,,*,/ (with some corrective shifts) > Trigonometric functions are computed from linear interpolation in a > table, > NewtonRaphson is used for sqrt. First, Christophe, I would be very interested in how pow(double, double) could be computed. Right now my version isn't right , and only does pow(double, int). This makes me unable to add functions for E^x and 10^x. You seem to know a fair ammount about this stuff, so could you enlighten me of send me a link? I heard the "Art of Computer Porgramming" by Donald Knuth has this sort of thing in it, but I don't want to shell out for the book. I'll find out more about NewtonRaphson for sqrt(). I whipped up the sqrt calculation myself by just homing in on the correct answer until it is close enough within a certain ammount of error (0.00000001 or something like that). > Anyway, I think that for keeping track of the precision, fixedpoint > maths are > precise is enough, given the errors when controling a mobile robot and > their accumulation... unless the robot could correct using external > information > through some kind of positioning system : as someone tried such a thing > ? My idea for this is to map the outside border of a room by following the wall, then periodically using the corners of the room to "recalibrate" the XY coordinates. It's all theory now, but I hope to get into it soon. Along similar lines, it might be possible to have the RCX home in on the RCX transmitter and use it as a beacon to recalibrate the XY coordinates.  Brian 
From: Brian Bagnall <bbagnall@es...>  20001026 17:24:37

My thoughts on Peter Dekkers suggestion is this would be an excellent = architecture to follow as it would mirror Sun's approach to the design = of their API. e.g. (java.awt.Component, then all sorts of components = like Button extend Component) Not to mention it is just plain good = object oriented design to do it this way. Your current design uses only static methods for the motors and sensors = so they are never instantiated by the programmer. If I read your email = right, Peter Dekkers suggests being able to instantiate an instance of a = sensor or motor. The main problem with this being with Lejos there is = physically only 3 unique input's or output's. Like you said, if you try = to set different modes for the sensor types of a single instance it = could be tricky. Two instances of the same input could have different = settings. Could you get around this by using a static method for setting the = sensor type (along with some static variables) so that it will keep the = sensor type variable synchronized for each instance? For example, the = Sensor class could contain 3 static int's which represent the sensor = types for the 3 different sensor inputs (Input1 =3D LIGHT, Input2 =3D = SWITCH, Input3 =3D LIGHT). A nonstatic (instance) variable would = indicate which of the 3 input's the instance refers to. So with this = API if a user changed the sensor type it would change it for all = instances of that particular input. These are just rough thoughts and I'm not sure what other factors would = work into this. It should take care of the problem of having 2 = instances with different sensor types, I believe. We need more = discussion on this before actually changing the current API, though.  Brian  Original Message =20 From: Jose Solorzano=20 To: tinyvmdiscussion@...=20 Sent: Wednesday, October 25, 2000 4:37 PM Subject: [tinyvmdiscussion] Changes to sensor API & Alpha 5 release The object oriented approach, i.e. making Sensor abstract and inheriting various sensor classes, was appealing. I was already starting to code it, but I desisted due to several pragmatic reasons. Consider, for example, what it would be like to have two Sensor instances with different modes and types.=20 
From: Christophe Ponsard <chp@in...>  20001026 10:49:24

> > > Hi, have you had a look at the MathFP package which > > has been developped > > for the KVM ? I didn't dig in their sources, but you > > could find > > interresting things : http://www.jscience.net (then > > follow Project, > > and MathFP). > > > > Cheers, yann. > > I understand that's a fixed point library, > not a floating point one, though. I found the MathFP package too. Actually I adapted it to compile under tinyvm (some change needed on ParseInt, Exception and String, so the source are needed). Resulting library code is about 40 packets long. Precision is about 1/1000 (precisely 1/4096). As it is fixedpoint calculus, you have to be carefull when reading the results: they are bound to the number significative digits of the operands. About the implementation : int are used and interpreted as being rightshifted by 12 bits (2^12=4096). As a result, +,,*,/ are computed using interger +,,*,/ (with some corrective shifts) Trigonometric functions are computed from linear interpolation in a table, NewtonRaphson is used for sqrt. We are using MathFP to be able to keep track of the RCX coordinates (cf. the " Keeping track of coordinates with Lejos" discussion thread) Our goal is to teach mechanics/programming in an integrated way (using PBL) to first year students in applied science. An RCX equiped with a JVM is very attractive for this. We used tinyvm+MathfP because lejos was not yet supporting math operation at the time the course was prepared. I guess we will use lejos next year ! Anyway, I think that for keeping track of the precision, fixedpoint maths are precise is enough, given the errors when controling a mobile robot and their accumulation... unless the robot could correct using external information through some kind of positioning system : as someone tried such a thing ? If somebody is interested in MathFP, for further redistribution, we should first have the agreement of the MathFP author. Bye Christophe  PONSARD Christophe (UCL/FSA/INGI) Place Sainte Barbe 2, 1348 LouvainlaNeuve (Belgium) tel. : ++32 10 47 90 12 email:chp@... WWW : http://www.info.ucl.ac.be/people/chp/chp.html  ps: the geocrawler archive of tinyvmdiscussion does not seem to work (list not found) 
From: Yann SECQ <Yann.S<ecq@li...>  20001026 09:12:36

Brian Bagnall wrote: > Thanks, Yann. That site looks like it could be helpful. No sourcecode > unfortunately, but the log() documentation mentioned using the Taylor series > to calculate log, which should be useful. I'm going to see if I can find > some documentation on the Taylor series. >  Brian Hi Brian, I'll have a second try, with a link which could be more interresting. it's from SGI : http://oss.sgi.com/projects/crcalc/CRCalc.html "This is a calculator that operates on constructive real numbers. Numbers are represented exactly internally to the calculator, and then evaluated on demand to guarantee an error in the displayed result that is strictly less than one in the least significant displayed digit. It is possible to scroll the display to the right to generate essentially arbitrary precision in the result." Not sure if I could help you, but perhaps there are some good ideas inside (Two things : it relies on BigInteger :( and they're talking as well about Taylor series). Cheers, yann.  Yann SECQ Thèse d'Informatique en préparation, SMAC, LIFL secq@... Studying for a PhD in Computer Science javafan@... S.M.A, Modélisation et Programmation Orientée Agents http://www.lifl.fr/~secq M.A.S & Agent Oriented Programming and Modeling 
From: Jose Solorzano <j.solorzano@wo...>  20001026 05:36:31

I should say something about the changes to the sensor API in 1.0.0alpha5 (released Monday), since they=20 will probably affect existing programs. The main=20 difference is that a sensor now has a type (e.g. light=20 or touch) and a mode (e.g. raw, boolean or percentage). These are set with setTypeAndMode, preferably with values from SensorConstants. The kinds of values that readValue returns (i.e. canonical values) depend on the type=20 and mode. The readPercentage method was removed. Also, SensorListener has only one method, which is called only when the canonical value changes. The Sensor API that was brought over from TinyVM was inadequate for advanced use, as some of the feedback I've recevied indicates, e.g.: Peter Dekkers was the first to send me some code and a proposal to have a more object oriented Sensor API with classes such as LightSensor, TouchSensor, etc. He also suggested that Button and Sensor should have a common ancestor, InputDevice. Ryan Vander Bijl also talked about a similar object oriented approach.=20 S=F8ren Hilmer sent some code, explaining an approach to only get desired events in SensorListener's with only one notification method (using masks). Recently, David Edwards noticed that TinyVM couldn't handle rotation sensors. Not only is there a bug in the API, but there is no way to reset the previous sensor value (which can now be done with setPreviousValue).=20 The object oriented approach, i.e. making Sensor abstract and inheriting various sensor classes, was appealing. I was already starting to code it, but I desisted due to several pragmatic reasons. Consider, for example, what it would be like to have two Sensor instances with different modes and types.=20 You will also notice a performance increase in the Sensor API. The lowlevel (native) method readSensorValue can be=20 executed about 2500 times per second in a for loop. Also, sensor events are now dispatched by a single thread, which=20 was also optimized. So code that relies on SensorListener's will also benefit. Enjoy, Jose 
From: Jose Solorzano <jhsolorz@ya...>  20001025 15:45:04

 Yann SECQ <Yann.Secq@...> wrote: > Brian Bagnall wrote: > > I'm not sure what atan2() is supposed to return > with atan2(1, 0). I'll do a > > test with the official java.lang.Math.atan2() and > see if this returns NaN. > > Should have these methods to you soon! Thanks for > the help with these. > >  Brian > > Hi, have you had a look at the MathFP package which > has been developped > for the KVM ? I didn't dig in their sources, but you > could find > interresting things : http://www.jscience.net (then > follow Project, > and MathFP). > > Cheers, yann. I understand that's a fixed point library, not a floating point one, though. Jose __________________________________________________ Do You Yahoo!? Yahoo! Photos  35mm Quality Prints, Now Get 15 Free! http://photos.yahoo.com/ 
From: Brian Bagnall <bbagnall@es...>  20001025 15:38:53

Thanks, Yann. That site looks like it could be helpful. No sourcecode unfortunately, but the log() documentation mentioned using the Taylor series to calculate log, which should be useful. I'm going to see if I can find some documentation on the Taylor series.  Brian  Original Message  From: "Yann SECQ" <Yann.Secq@...> To: "Brian Bagnall" <bbagnall@...> Cc: <tinyvmdiscussion@...> Sent: Wednesday, October 25, 2000 12:53 AM Subject: Re: [tinyvmdiscussion] Keeping track of coordinates with Lejos Brian Bagnall wrote: > I'm not sure what atan2() is supposed to return with atan2(1, 0). I'll do a > test with the official java.lang.Math.atan2() and see if this returns NaN. > Should have these methods to you soon! Thanks for the help with these. >  Brian Hi, have you had a look at the MathFP package which has been developped for the KVM ? I didn't dig in their sources, but you could find interresting things : http://www.jscience.net (then follow Project, and MathFP). Cheers, yann.  Yann SECQ Thèse d'Informatique en préparation, SMAC, LIFL secq@... Studying for a PhD in Computer Science javafan@... S.M.A, Modélisation et Programmation Orientée Agents http://www.lifl.fr/~secq M.A.S & Agent Oriented Programming and Modeling _______________________________________________ tinyvmdiscussion mailing list tinyvmdiscussion@... http://lists.sourceforge.net/mailman/listinfo/tinyvmdiscussion 
From: Yann SECQ <Yann.S<ecq@li...>  20001025 06:57:12

Brian Bagnall wrote: > I'm not sure what atan2() is supposed to return with atan2(1, 0). I'll do a > test with the official java.lang.Math.atan2() and see if this returns NaN. > Should have these methods to you soon! Thanks for the help with these. >  Brian Hi, have you had a look at the MathFP package which has been developped for the KVM ? I didn't dig in their sources, but you could find interresting things : http://www.jscience.net (then follow Project, and MathFP). Cheers, yann.  Yann SECQ Thèse d'Informatique en préparation, SMAC, LIFL secq@... Studying for a PhD in Computer Science javafan@... S.M.A, Modélisation et Programmation Orientée Agents http://www.lifl.fr/~secq M.A.S & Agent Oriented Programming and Modeling 
From: Brian Bagnall <bbagnall@es...>  20001024 17:35:39

OK, now I get it. I will definitely implement the atan2() method, then. This will be much more useful than just atan(). It will be super easy to implement this one by using atan() and making contingencies for (+,+) (,+) (,) and (+,) quadrants. As a robotics programmer using atan, it will be necessary to error check for instances when the X coordinate = 0, which results in NaN. e.g. If y = 234 and x = 0, the method would choke when it tried atan(y/x). I'm not sure what atan2() is supposed to return with atan2(1, 0). I'll do a test with the official java.lang.Math.atan2() and see if this returns NaN. Should have these methods to you soon! Thanks for the help with these.  Brian  Original Message  From: "Jose Solorzano" <jhsolorz@...> To: "Brian Bagnall" <bbagnall@...>; <tinyvmdiscussion@...> Sent: Monday, October 23, 2000 6:55 PM Subject: Re: [tinyvmdiscussion] Keeping track of coordinates with Lejos > > For example, atan(1) can be 45 or 180+45. > With atan2, you can distinguish between > atan2(1,1) and atan2(1,1). > > Jose 
From: Jose Solorzano <jhsolorz@ya...>  20001024 00:56:07

 Brian Bagnall <bbagnall@...> wrote: > > I wonder if atan2() might be useful. The angles > > that atan() gives can be off by 180 degrees, but > > that might not matter in these kinds of apps. > > Could you elaborate on this, Jose? [...] For example, atan(1) can be 45 or 180+45. With atan2, you can distinguish between atan2(1,1) and atan2(1,1). Jose __________________________________________________ Do You Yahoo!? Yahoo! Photos  35mm Quality Prints, Now Get 15 Free! http://photos.yahoo.com/ 
From: Brian Bagnall <bbagnall@es...>  20001023 23:59:51

> I wonder if atan2() might be useful. The angles > that atan() gives can be off by 180 degrees, but > that might not matter in these kinds of apps. Could you elaborate on this, Jose? I don't know very much about atan() but from the tests I did on it it seemed to give very accurate results. In what situations can it be off 180 degrees? Is atan2() a function of atan()? Is it more accurate than atan()? I was talking to a coworker and he said log can be very useful when dealing with raw input. I guess signals can be exponential, so log can sort of tame the input into something linear. No idea how to implement log yet, but hopefully there's something on the web about how to do this. BTW I've got asin() and acos() working fine now. I also made abs() and I'm going to implement Math.random() which is supposed to return a random double between 0.0 and 1.0. CVS continues to vex me but I'll do some reading. I was able to login anonymously and do some commands with WinCVS.  Brian 
From: Jose Solorzano <jhsolorz@ya...>  20001023 05:04:22

[...] > First, if you haven't got Lejos, I'd strongly > recommend going to > http://lejos.sourceforge.net. It is probably a > better option than TinyVM > unless you need to squeeze every last drop of memory > from the RCX. In my > experience, a navigation program will probably only > take around 3K or so and > not grow much bigger as you add more code. I think > there is about 16k free > to play with [...] It's more like 12K. Of the 32K of RAM available, only 28K are safe to use. The rest is used by the ROM, native stack, etc. So, after you load your 3K program, you still have 9K (~ 15K in TinyVM). These sound like small amounts of memory, but you'd really have to write a lot of code or have pretty big data structures (or bugs in your program) to run out of memory. But it's true: unless you plan to program a robot pet, leJOS is the better option at present. [...] > If your angle dips below 0 (eg. 36 degrees) or goes > above 360 (eg. 456 > degrees) the trig functions will still process it > properly, so you won't > really > have to worry about making sure the angle stays > between 0 and 359.999..) [...] I wonder if atan2() might be useful. The angles that atan() gives can be off by 180 degrees, but that might not matter in these kinds of apps. Jose __________________________________________________ Do You Yahoo!? Yahoo! Messenger  Talk while you surf! It's FREE. http://im.yahoo.com/ 