This feels so obvious and simple how is this not already a standard thing everywhere? Is it because the mantissa and point position don't both fit into a single register?
Surely that's just normal floating point but missing e.g. normalisation? Floating point is literally an int exponent and an int mantissa. Except real floating point adjusts the exponent to avoid integer overflow in the mantissa - which is where rounding happens.
In DPA the mantissa just overflows (silently in the C implementation) and then what?
Er… this may be a stupid question, but how is this actually different to ordinary floating-point arithmetic? Ordinary IEEE-754 floating-point numbers already store the mantissa and exponent in separate fields, don’t they?
Displeased with this trend of LLM-assisted “research”. The central claims are false, the examples of floating point are false and off by a factor of 1e11, the latency numbers are complete WTF and disconnected from reality (‘cycles’ of what).
Fixed point arithmetic with a dynamic scale is presented along the way motivating floating point in probably every computer architecture class. It’s a floating point.
This guy needs to open a book. I recommend Nick Higham’s _Accuracy and Stability of Numerical Algorithms_.
There is a fundamental theorem of numerical analysis, due to Kahan, that certain, very desirable properties of modeling the real numbers on a computer are incompatible.
Again and again people try to "fix" IEEE floating points without realizing that they are trying to do something akin to creating free energy. Whenever you start out with a project like this you have to start by asking yourself what desirable property you are willing to let go of. Not presenting that flaw makes the whole thing look either dishonest or uninformed.
>Any real number x can be represented as
This statement is just false. I do not know why you would start out by making such a basic error. The real numbers are uncountable you can not represent all real numbers by a pair of integers. This is basic real analysis
>The mathematics is elementary. The impact is revolutionary.
???
>Special thanks to everyone who said "that's just how it works" - you motivated me to prove otherwise.
Maybe the people know better than you? It is after all a mathematical theorem.
This is incorrect. There are a number of eerors, as others have pointed out, but for me the most central one is not that almost all reals are uncomputable numbers, but that the product of two 64-bit integers is 128 bits, as anyone who has done arbitrary-precision rational math has noticed.
I think it's great to experiment with improving fundamental algorithms, but not to make misleading claims about your results.
11 comments
[ 1.6 ms ] story [ 38.2 ms ] threadIn DPA the mantissa just overflows (silently in the C implementation) and then what?
> Every error compounds.
https://en.wikipedia.org/wiki/Kahan_summation_algorithm
Fixed point arithmetic with a dynamic scale is presented along the way motivating floating point in probably every computer architecture class. It’s a floating point.
This guy needs to open a book. I recommend Nick Higham’s _Accuracy and Stability of Numerical Algorithms_.
Again and again people try to "fix" IEEE floating points without realizing that they are trying to do something akin to creating free energy. Whenever you start out with a project like this you have to start by asking yourself what desirable property you are willing to let go of. Not presenting that flaw makes the whole thing look either dishonest or uninformed.
>Any real number x can be represented as
This statement is just false. I do not know why you would start out by making such a basic error. The real numbers are uncountable you can not represent all real numbers by a pair of integers. This is basic real analysis
>The mathematics is elementary. The impact is revolutionary.
???
>Special thanks to everyone who said "that's just how it works" - you motivated me to prove otherwise.
Maybe the people know better than you? It is after all a mathematical theorem.
x = m * 2^p
where m is an integer(mantissa) and p is an integer (point position)
Well this is clearly wrong, take x = 1/3 for example
1/3 = m * 2^p
m = 1 / (3 * 2^p), where m is an integer, doesn't hold true for any integer p.
If the author had read first 2 pages of
https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.h...
they could have avoided the embarrassment.
If you want the serious version of the idea instead of the LLM diarrhea, just go Jonathan Shewchuk’s robust predicates work: https://people.eecs.berkeley.edu/~jrs/papers/robustr.pdf from 1997.
I think it's great to experiment with improving fundamental algorithms, but not to make misleading claims about your results.