NewsForumsCodeLogsGallerySpecsSearch

Cos() bug? BMax v1.44

BlitzMax Forums/BlitzMax Programming/Cos() bug? BMax v1.44

Docster(Posted 2011) [#1]
Using BMax v1.44

Is there a bug with the Cos() command in BlitzMax?

For Local angle:int=0 To 90
	Local ccos:Float=Cos(angle)
	Print ccos
Next


The following code gives me the following results:


1.00000000
0.999847710
0.999390841
0.998629510
0.997564077
0.996194720
0.994521916
0.992546141
0.990268052
0.987688363
0.984807730
0.981627166
0.978147626
0.974370062
0.970295727
0.965925813
0.961261690
0.956304729
0.951056540
0.945518553
0.939692616
0.933580399
0.927183867
0.920504868
0.913545430
0.906307817
0.898794055
0.891006529
0.882947564
0.874619722
0.866025388
0.857167304
0.848048091
0.838670552
0.829037547
0.819152057
0.809017003
0.798635483
0.788010776
0.777145982
0.766044438
0.754709601
0.743144810
0.731353700
0.719339788
0.707106769
0.694658399
0.681998372
0.669130623
0.656059027
0.642787635
0.629320383
0.615661502
0.601815045
0.587785244
0.573576450
0.559192896
0.544639051
0.529919267
0.515038073
0.500000000
0.484809607
0.469471574
0.453990489
0.438371152
0.422618270
0.406736642
0.390731126
0.374606580
0.358367950
0.342020154
0.325568169
0.309017003
0.292371690
0.275637358
0.258819044
0.241921902
0.224951059
0.207911685
0.190808997
0.173648179
0.156434461
0.139173105
0.121869341
0.104528464
0.0871557444
0.0697564706
0.0523359552
0.0348994955
0.0174524058
2.65358482e-017 <-- What is this ?



This can't be right?


Floyd(Posted 2011) [#2]
It's approximately right, which is all you can hope for.

The e-17 means to move the decimal point left 17 places:

0.0000000000000000265358482

Likewise, the notation e+ means to move the decimal point to the right.

Last edited 2011


Jesse(Posted 2011) [#3]
http://en.wikipedia.org/wiki/Scientific_notation



Scientific notation is a way of writing numbers that accommodates values too large or small to be conveniently written in standard decimal notation. Scientific notation has a number of useful properties and is commonly used in calculators, and by scientists, mathematicians, doctors, and engineers.




*(Posted 2011) [#4]
Its always been a flaw in processors and floating point math


Noobody(Posted 2011) [#5]
It's not only a problem with lack of precision of floating point numbers, but also that all mathematical functions such as sin/cos/tan/acos/sqr/^ only do numerical approximation (i.e. power series). Since these functions are usually optimized for high performance and not necessarily high numerical accuracy, they only compute the first few iterations of the approximation scheme.

While the numerical error is still very small (as in, it will not mess with your calculations except you're into high accuracy scientific computing), it's still more than the precision limit of doubles/floats, so it will turn up if you print the number. If that is a readability issue, just round the result to the first 10 decimal places or so.


Docster(Posted 2011) [#6]
Oh. Thanks for the information ppl. Just testet with 360 degrees. Seems like the same problem occur every 90 degrees. But, I can live with that.. I think. :P


xlsior(Posted 2011) [#7]
Note that this is not a fault/limitation of blitzmax, but how floating points work in general, all programming languages run into the same issue. (Although some may hide it by rounding the numbers upon printing)


Russell(Posted 2011) [#8]
Brucey's MAPM module can handle SUPER HUGE numbers, if you need extreme accuracy (which 99.99% of the time, you don't). Get it here:
http://code.google.com/p/maxmods/wiki/MapmModule

It can handle, in theory, numbers with BILLIONS of digits...(although few computers can make use of such numbers ;) )

Russell