floating-accuracy

I am trying out the fast Exp(x) function that previously was described in this answer to an SO question on improving calculation speed in C#: public static double Exp(double x) { var tmp = (long)(1512775 * x + 1072632447); return BitConverter.Int64BitsToDouble(tmp << 32); } The expression is using some IEEE floating point "tricks" and is primarily intended for use in neural sets. The function is approximately 5 times faster than the regular Math.Exp(x) function. Unfortunately, the numeric accuracy is only -4% -- +2% relative to the regular Math.Exp(x) function, ideally I would like to have

assert(0.1 + 0.2 != 0.3); // shall be true is my favorite check that a language uses native floating point arithmetic. C++ #include <cstdio> int main() { printf("%d\n", (0.1 + 0.2 != 0.3)); return 0; } Output: 1 http://ideone.com/ErBMd Python print(0.1 + 0.2 != 0.3) Output: True http://ideone.com/TuKsd Other examples Java: http://ideone.com/EPO6X C#: http://ideone.com/s14tV Why is this not true for D? As understand D uses native floating point numbers. Is this a bug? Do they use some specific number representation? Something else? Pretty confusing. D import std.stdio; void main() { writeln(0.1

When a float number needs to be truncated to a certain digit after the floating point, it turns out that it is not easy to be done. For example if the truncating has to be done to second digit after the point, the numbers should be 45.8976 => 45.89, 0.0185 => 0.01 ( second digit after the point is not rounded according to the third digit after the point ). Functions like round() , number_format() , sprintf() round the number and print out 45.8976 => 45.90, 0.0185 => 0.02 I have met two solutions and I am wondering if they are good enough and which one is better to be used 1. function

I know that most decimals don't have an exact floating point representation ( Is floating point math broken? ). But I don't see why 4*0.1 is printed nicely as 0.4 , but 3*0.1 isn't, when both values actually have ugly decimal representations: >>> 3*0.1 0.30000000000000004 >>> 4*0.1 0.4 >>> from decimal import Decimal >>> Decimal(3*0.1) Decimal('0.3000000000000000444089209850062616169452667236328125') >>> Decimal(4*0.1) Decimal('0.40000000000000002220446049250313080847263336181640625') The simple answer is because 3*0.1 != 0.3 due to quantization (roundoff) error (whereas 4*0.1 == 0.4 because

The select returns right at 23,000 rows The except will return between 60 to 200 rows (and not the same rows) The except should return 0 as it is select a except select a PK: [docSVenum1].[enumID], [docSVenum1].[valueID], [FTSindexWordOnce].[wordID] [tf] is a float and and I get float is not exact But I naively thought avg(float) would be repeatable Avg(float) does appear to be repeatable What is the solution? TF is between 0 and 1 and I only need like 5 significant digits I just need avg(TF) to be the same number run to run Decimal(9,8) gives me enough precision and if I cast to decimal(9,8)

This is more of a numerical analysis rather than programming question, but I suppose some of you will be able to answer it. In the sum two floats, is there any precision lost? Why? In the sum of a float and a integer, is there any precision lost? Why? Thanks. In the sum two floats, is there any precision lost? If both floats have differing magnitude and both are using the complete precision range (of about 7 decimal digits) then yes, you will see some loss in the last places. Why? This is because floats are stored in the form of (sign) (mantissa) × 2 (exponent) . If two values have differing