The problem is that you have more significant digits in the input than Racket uses in its internal representation.
Let us enter the bare numbers:
> 183052866407243622723319.24395251
1.8305286640724363e+23
> 183052866407243622723319.00
1.8305286640724363e+23
Both numbers are thus represented as the same (whole) number internally. This explains why your result was 0.
This behaviour is not limited to Racket. In fact Racket follows the IEEE standard for computing with 64-bit floating-point numbers. You will get same result in other programming languages.
If you need to compute why greater precision you can use bigfloats instead.
(require math/bigfloat)
(bf-precision 128) ; use 128 bits
(bf- (bf #e183052866407243622723319.24395251)
(bfround (bf #e183052866407243622723319.00)))
The result is: (bf #e0.2439525099999997337363311089575290679932)
Note: To use bigfloats make sure you have a recent version of Racket.
Update: In case you wonder why the result wasn't .2439521 the answer is that the result and .2439521 is represented by the same internal bitpattern.
Update:
If you want to turn the result back into a standard floating point, use bigfloat->flonum
.
(bf-precision 256) ; to get more decimal digits correct
(bigfloat->flonum
(bf- (bf #e183052866407243622723319.24395251)
(bfround (bf #e183052866407243622723319.00))))
This gives the result: 0.24395251
Addendum:
Racket (and Scheme) reads numbers with decimal points as floating point numbers. If you prefix a number with #e it is read as an exact number (that is the resulting value is an exact fraction). You can use this to keep the exact decimals. You exact numbers for your entire computation, and then in the end use exact->inexact
to turn the result into a floating point number. Here is your example:
> (exact->inexact
(- #e183052866407243622723319.24395251
#e183052866407243622723319.00))
0.24395251