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 <ASSEMBLER-LIST@LISTSERV.UGA.EDU> On > Behalf Of Abe Kornelis > Sent: Tuesday, March 5, 2024 8:58 AM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > 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
