@KodeDaemon:
Are your math lib sources open?
Have you tested any of the functions for performance? (seems to me you're using double and that is heavy for Netduino)
Could we join our efforts to build an unique lib, so that will substitute the original MF math?
@Chris:
Once we have a well-done library, could you manage any way to cut-off the original MF math and insert the ours? (Just to save space)
Cheers
Cosine function
#21
Posted 12 April 2011 - 05:33 AM
#22
Posted 12 April 2011 - 06:53 AM
#23
Posted 12 April 2011 - 12:08 PM
public static double convRange(double x) { double temp = ((x / (2 * Math.PI)) - (int)(x / (2 * Math.PI))) * (2 * Math.PI); return temp; }
Using it IM able to get Math.Cos(convRange(257)) = 0.81930151916611216. Its much closer than before, accurate to a few decimal points.
#24
Posted 12 April 2011 - 12:48 PM
It seems like the cos function is fairly accurate up to 2pi. I wrote this piece of code that takes the input and scales it down to a comaparable angle below 2pi so the Math.Cos function can evaluate it.
public static double convRange(double x) { double temp = ((x / (2 * Math.PI)) - (int)(x / (2 * Math.PI))) * (2 * Math.PI); return temp; }
Using it IM able to get Math.Cos(convRange(257)) = 0.81930151916611216. Its much closer than before, accurate to a few decimal points.
I don't know how that function could be act as a "cosine".
Bear in mind that the sin/cos functions embedded in the MF take the integer argument in degrees and give an integer result from -1000 to 1000, inclusive. Clearly for performance reasons.
#25
Posted 12 April 2011 - 01:10 PM
Or simply giving it to Microsoft to include in the .net mf framework ? Solving the problem, not patching it ?could you manage any way to cut-off the original MF math and insert the ours?
Just a thought
And as a physicist ... I want a real math library ...
#26
Posted 12 April 2011 - 06:18 PM
This function doesnt act as the cosine, it simlpy converts whatever angle I give it in radians to a comparable angle less than 2pi radians so that the Math.Cos function can use it. The library I was using is the Elzekool math library.I don't know how that function could be act as a "cosine".
Bear in mind that the sin/cos functions embedded in the MF take the integer argument in degrees and give an integer result from -1000 to 1000, inclusive. Clearly for performance reasons.
I still have to use the Math.Cos function like normal, I just put in a smaller value for the angle.
My original angle was 257 radians, the function I posted then converted that to 5.6725807189941353. Then I take the cosine of that, Math.Cos(5.6725807189941353). That gives me the approximate cos of 257.
My function doesnt replace the cosine function, it just creates a usable(acoording to the apparent constraints on this library) input for it.
#27
Posted 12 April 2011 - 06:27 PM
I had the same issue with the Math library (it being incomplete and somewhat not to spec), I decided to go for Elze Kool's, http://www.microframework.nl
That one is open and works like a charm.... with two modifications, one of them related to your Cos issue
FIX: (line numbers) 195 public static double Cos(double x) 196 { 197 x = x % TwoPI;
that will enable you using values greater than 2*Pi for lookups, otherwise you end up with the exact same issue you had (insanely large values being returned)
The other issue was in the Atan funcion, which had its incoming values in the wrong order*
*"wrong" meaning swapped with respect to the standard atan2 math implementation, where one enters 'y' and then 'x'.
FIXED VERSION: 149 public static double Atan2(double y, double x) 150 { 151 152 if ((y + x) == y) 153 { 154 if ((y == 0F) & (x == 0F)) return 0F; 155 156 if (y >= 0.0F) 157 return pio2; 158 else 159 return (-pio2); 160 } 161 else if (x < 0.0F) 162 { 163 if (y >= 0.0F) 164 return ((pio2 * 2) - atans((-y) / x)); 165 else 166 return (((-pio2) * 2) + atans(y / x)); 167 168 } 169 else if (y > 0.0F) 170 { 171 return (atans(y / x)); 172 } 173 else 174 { 175 return (-atans((-y) / x)); 176 } 177 }
Other than that that library works very well in general, there might be other issues though
PS: I could post these to a public repo so that other changes could be contributed, any interest on that?
#28
Posted 13 April 2011 - 03:44 AM
#29
Posted 13 April 2011 - 09:32 AM
#30
Posted 13 April 2011 - 10:00 AM
#31
Posted 13 April 2011 - 10:24 AM
it should readIf ints and doubles are roughly as fast then
I was talking about moving all the code to floats, not doubles (I fixed my post now)If ints and floats are roughly as fast then
#32
Posted 13 April 2011 - 11:56 AM
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users