It optimizes the hardware implementation of computation with real numbers
wmv (33 MB) mp4 (14 MB)
· 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)
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 , and .
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 . 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  and the unbiased rounding for conversion between HUB and conventional FP is explained in .