It optimizes the hardware implementation of computation with real numbers
wmv (33 MB) mp4 (14 MB)
URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=7349231&isnumber=7476004
URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=7465754&isnumber=4358609
URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=7270998&isnumber=7486166
URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=7094576&isnumber=7094373
· Hormigo, J.; Villalba, J. Multiplicadores coma flotante y conversores asociados, ES2546895B2, 2014. (Link)
· Hormigo, J.; Villalba, J. Dispositivos coma flotante y conversores, ES2546898B2, 2014. (Link)
· Hormigo, J.; Villalba, J. Sumadores coma flotante y conversores, ES2546916B2, 2014. (Link)
· Hormigo, J.; Villalba, J. Unidades aritméticas en coma fija y conversores asociados, ES2546915B2, 2014. (Link)
· Hormigo, J.; Villalba, J. Dispositivos para operaciones de multiplicación-suma fusionadas en coma flotante y conversores asociados, ES2546899B2, 2014. (Link)
International patent application (PCT)
PCT 30-month deadline is 28th September 2016.
Not
at all. "Rounding by injection" is a technique to simplify rounding
which produces a conventional number rounded to the nearest.
However, HUB is new format with the characteristic that when a
value is truncated to generate a HUB number, this number is the nearest
to the original value in HUB format. It doesn't matter where this
original value come from (an operation with either conventional numbers
or HUB numbers, or even just an input number).
When
injection
is applied, the exact results is shifted by an error (injected). Then,
this shifted result is rounded to obtain a conventional number by
truncation. The introduced error produces that truncation generates
rounding. However, when under HUB approach, the ILBS
is explicitly
appended to the input values, no error is introduced, it is the same
value but now represented in conventional format. Then, It could ve
operate in a conventional way( because, it is a conventinoal number),
and the intermediate value obtained is exact. When rounding is
required, a HUB number rounded to the nearest is obtained at the output
by truncation. In this case, the targeted new format (HUB) is what
produces the rounding by truncation.
Yes, of course. Conversion to HUB at the input and rounding could be fused in one operation without additional error, and similarly, conversion from HUB to conventional at the output.
The conventional input values could be regularly operated and only when a rounding is required, a truncation is used to produce a HUB number rounded-to-nearest. Similarly, the last intermediate results (which is a conventional value although it came from an operation with HUB numbers), could be rounded in a conventional way to generate the output in conventional format. Using this procedure, no extra rounding error is introduced by conversions.
No, it doesn't, but it provides the same precision. This means that, although the value of the result is different, the bound and other statistical properties of the rounding errors are the same. This point has been proved theoretically and experimentally as it is shown in references [4],[5] and [6].
This example does
not prove that HUB format has less precision than IEEE standard.
It is absolutely
true that if a value can be exactly represented by IEEE format (that is an
ERN), HUB will cause an error which is actually the higher possible, 0.5 ULP.
Since the ERN of IEEE format has been shifted 0.5 ULP on HUB format by
definition, ERNs on IEEE format will be represented with maximum error under
HUB format.
However, that does
not mean that HUB format is less accurate than IEEE format since that also works
the other way around, i.e., the ERNs under HUB format will be represented with the
maximum error (0.5 ULP) under IEEE format. For single precision, the values in
the form 2^(-n)+2^(-n-24) are represented under IEEE standard with an error of
0.5 ULP whereas they are exactly represented under HUB format. Indeed, as it is
said in the paper, both errors are always complementary, i.e.,|eIEEE|+|eHUB|=0.5
ULP. Therefore, the better a value is represented under one format, the worst it
is represented under the other.
I cannot imagine any
floating-point application where values in the form 2^(-n) appear more likely
than values in the form 2^(-n)+2^(-n-24). However, there are lots of
applications where the probability to have numbers better represented under
IEEE is the same that the probability to
have numbers better represented under HUB format, such as, DSP, physics
simulation, neural networks, computer graphics…
Conversions between HUB-FP and conventional FP numbers is addressed in references [4]. In both cases this conversion implies rounding, but no explicit operation is required for tie-to-away or just forcing the value of the LSB for tie-to-even-like rounding.
Yes, It can.Actually, the tie case is not possible rounding a HUB number and no sticky bit computation is required in floating-point computation. However, under certain circumstances the intermediate result of an FP addition may be the tie case, but some simple hardware can be utilized to guarantee an unbiased rounded results. The general theory of unbiased rounding is explained in [7] and the unbiased rounding for conversion between HUB and conventional FP is explained in [4].