For me (reading not only about DFP but also the overview to all three supported FP formats), the key to understanding was that there are several "views" mentioned and described beyond left-units and right-units. In particular, there is this snippet from Chapter 9: (Page 9-2 in the -13 edition).
"The value of the bias depends on the view. In the fraction view, the radix point is considered to be the left of the significand. In the left-units view, the radix point is considered to be to the right of the leftmost digit. In the right-units view, the radix point is considered to be on the right of the significand. By choosing the appropriate bias, any finite floating-point number can be considered in any of these views, or even in another view. For the first three of these views, the bias is called the fraction-view bias, left-units-view bias, and right-units-view bias, respectively. Except where otherwise indicated, HFP is defined in terms of the fraction view, BFP terms of the left-units view, and DFP in terms of the right-units view." And indeed they do describe at least two other views - common-rounding-point view and integer view - and as the first paragraph above suggests, you can probably invent your own view for whatever purpose you like. It's also relevant that the concept of views applies to all three FP data formats (yes, even the original HFP from 1964). I think the PofO could be improved with a sentence or two describing that these views are an aid to defining and understanding rather than something that forms part of the floating point representation and manipulation on the machine. Tony H. On Wed, 6 Mar 2024 at 03:31, Abe Kornelis <[email protected]> wrote: > Gary, > > thanks for explaining. I had to enumerate the options to get to > understand it... > > When encoding 7 with LUV, the decimal point is always after the first > digit. > Within the cohort, there are - as you mentioned - various members: > 7.000000E0 - Biased Exp = 95 > 0.700000E1 - Biased Exp = 96 > 0.070000E2 - Biased Exp = 97 > 0.007000E3 - Biased Exp = 98 > 0.000700E4 - Biased Exp = 99 > 0.000070E5 - Biased Exp = 100 > 0.000007E6 - Biased Exp = 101 > > When encoding 7 with RUV, the decimal point is always after the last digit. > Within the cohort, there are - again - various members. E.g. > 0000007E0 - Biased Exp = 101 > 0000070E-1 - Biased Exp = 100 > 0000700E-2 - Biased Exp = 99 > 0007000E-3 - Biased Exp = 98 > 0070000E-4 - Biased Exp = 97 > 0700000E-5 - Biased Exp = 96 > 7000000E-6 - Biased Exp = 95 > > Which clearly shows that in the encoded format the RUV vs LUV is not > relevant. > Thanks a lot for helping me understand. > > Kind regards, > Abe > === > > > > Op 05/03/2024 om 18:19 schreef Gary L Peskin: > > But you need to look at the bias for the exponent. Both views would be > encoded the same. I guess I didn't explain this very well before but this > example will help. For the short format, there are 7 significant digits. > For the LUV, bias of the exponent is 95. For the RUV, bias of the exponent > is 101. See this in figure 20-2 that we mentioned before. > > > > Also, I think we're getting cohorts mixed up with LUV/RUV. What you're > showing below are two different members of a cohort. Not too different > views of the same representation. But that's another story. I think you'll > see what I mean below. > > > > Let's take the number 7. This can be encoded with the LUV as 7.000000 x > 10**0 or as 7000000. x 10**-6. In both cases the significand is > represented the exact same as 7000000. For LUV, the decimal point is > implied to the right of the seven. For RUV, the implied decimal is to the > right of the rightmost zero. > > > > For LUV, the unbiased exponent is 95 since 95 - 95 = 0. > > For RUV, the unbiased exponent is 95 since 95 - 101 = -6. > > > > So in BOTH cases, the unbiased exponent (which is what is encoded in the > representation in memory) is 95. And in both cases the significand is > encoded as 7000000. The representation in memory is the SAME. It's just a > matter of whether you want to look at as > > > > 7.000000 x 10 * (95-95) > > -or- > > 7000000 x 10 * (95-101) > > > > I hope this example helps. > > > > Take care, > > Gary > > > > -----Original Message----- > > From: IBM Mainframe Assembler List <[email protected]> On > Behalf Of Abe Kornelis > > Sent: Tuesday, March 5, 2024 8:58 AM > > To: [email protected] > > Subject: Re: Decimal Floating Point Numbers > > > > Hi Peter, > > > > thanks for your response. Nice to hear from you :-) > > > > They would be encoded quite differently. > > Say you'd encode the value seven. > > In LUV this would be 7.00000*10**0 > > In RUV this would be 000007*10**0 > > > > In either case the number of zero digits would depend on the format of > the DFP: D/E/X > > > > For the sake of completeness: > > In LUV the digit 7 would go into the combination field In RUV the digit > would be at the end of the significand. > > > > Unless I am quite mistaken, which is still quite conceivable :-( > > > > Kind regards, > > Abe > > === > > > > > > Op 05/03/2024 om 15:19 schreef Peter Relson: > >> I am imagining (and could easily be wrong) that the hex data is > identical across the views (and thus the instruction implementation does > not care about the view), and it's only a question of which bits you choose > to look at (or what arithmetic logical manipulation you use) if formatting > the value for human consumption. > >> > >> For example, the exponent differs, as does the significand (a term I > had not known of until seeing it in the POp). > >> > >> I don't know what kind of dump was being looked at, but perhaps there's > a formatting option within the dump viewing program that might say "show me > this as a Right-Unit View DFP value". > >> > >> Peter Relson > >> z/OS Core Technology Design >
