Trig etc functions on fractions?

Question

Fraction.java with trig methods?
I've been playing with geospatial stuff for a while now, and I've been striking a lot of problems with the inherent inaccuracies of floating point number representations, especially in complex-calculated values.
Here's a simple but pertinent example:
class TheSumOfSevenSevethsIsNotOne
  public static void main(String[] args) {
    double f = 1.0/7.0;
    double sum = 0.0;
    for (int i=0; i<7; i++) {
      sum += f;
    System.out.println("sum = "+sum);
// OUTPUT:
// sum = 0.9999999999999998
// not 1 as you might expectThe numbers I'm storing are latitudes and longitudes in degrees, so the max_value is just 360, but the requirement is that lat/lon must be accurate to 9 decimal places, which equates to about +/- 0.6 millimetres, which is (apparently) close enough to be regarded as "millimetre accuracy" by cartographers, even though total ambiguity is 1.2 mm.
So three digits, plus six digits, is only nine digits, right?... and the humble int can store a tad more than 9 digits...
                                 123.123 456
Integer.MAX_VALUE = (2^31)-1 = 2,147,483,647So I got to thinking... How would it be if I stored all lat/lons in the database as integers (multiplied by a million)? and did all my calculations rounded (not truncated) to the nearest 1. I could even save a few hundred million bytes that way... But that still leaves the same ole ambiguity around the actual calculations, many of which involve division ;-(.
So I got to thinking maybe I could use fractions? How would a Fraction.java look?
I googled around and found some great stuff, including:<ul>
<li>[Diane Kramers Fraction.java|http://aleph0.clarku.edu/~djoyce/cs101/Resources/Fraction.java]
<li>[Working with Fractions in Java|http://www.merriampark.com/fractions.htm] (includes BigFraction.java - very handy)
<li>[Doug Leas Fraction.java|http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/misc/Fraction.java]
</ul>
But I haven't found anything which implements the basic trigonometry functions like sin, cos, tan, cot (and whatever else)... but [Daves Short Trig Course|http://www.clarku.edu/~djoyce/trig/] might give me the understanding required to do so... nor does any existing Fraction.java (which I've found so far) implement handy things like x^y, log, modulo (and whatever else) ... and not being a mathematician myself, I'm not overly eager to implement them... I'd never be sure I'd done the job properly.
Please is anyone aware of any such implementations, even partial ones? Or could someone perhaps be persuaded to do part(s) of it just for the challenge?
Cheers all. Keith.

Answer 1

Sir Turing Pest,
I do geospatial stuff amost exclusively and I dont understand this post.
Why not just use doubles? The "error" you're seeing is so trivial.
Put into perspective, if you were positioning something from the
Sun to Pluto you'd be off by half a millimeter.
How do you figure that you only need 9 digits?
ignore 360 degrees. the circumference of the earth is 41k km and you need
accuracy to .6 mm = 11 places
(40 075.02 kilometers) / (.5 millimeters) = 80,150,040,000I didn't figure it, our local GIS expert did, based mainly on the size of an integer,
When I do the math I get to 9 decimal places == about 1.11 mm, and that's allways rounded (not truncated) to 9 decimal places which I think means our points are accurate to plus or minus about 0.6 mm.... but I'm just a humble computer programmer, NOT a mathemetician or a geospatial expert.
We're storing lat/lon to 9 decimal places... So 1 is 1 degree.
               40,075.160000000     kilometers     circumference of the earth
equals     40,075,160.000000000     meters        circumference of the earth
equals        111,319.888888889     meters        meters per degree at the equator
equals              0.000000001     degrees         storage accurracy
equals              0.000111320     meters         
equals              1.113198889     millemeters     storage accurracy in millimeters
So sure you established that aggregate double addition comes out "wrong".
Then dont do it, lol. Dont waste your time trying to invent new number
storage. Just try to write your algorithms so you don't do aggregate addition as much.We try not to aggregate calculated values... but there are certain algorithms, like the reverse/mercator transforms where it's unavoidable... So opportunities for improvement is this area a likely to be NOT very cost effective, ie: bigger than Ben Hur, harder than a bulls azz, and uglier than an extreme closeup of my scotum... My main concern has been (rightly or wrongly) the inherent inaccuracy in our storage of numbers.... thinking that improvements in this area just might be cost-effective, and therefore doable.
Iterestingly... we had a tree-clearing case kicked out of court recenctly because we couldn't define the boundaries of the national park in question to the satisfaction of the court... a "satisfaction level" which was based on our own "millimeter accuracy" definition of the required accuracy of survey data, which is based on international standards for GIS. ie: It's a bit of sore spot around the office at the moment, and I'm trying to do some bluddy thing about it... I'm just at a bit of a loss as to exactly what, without throwing literally millions of dollars at the problem to upgrade ALL our systems to 11 decimal places (or better). I'm in stress city.
Cheers. Keith.