Re: Decimal Floating Point Numbers
Just to add my 2 cents to this discussion, DFP numbers retain zero digits to both the left and right of the radix point. This is different from both binary floating point and hexadecimal floating point where for normalised numbers, there is a single representation of a value (this has the advantage of increasing the precision of the fraction). DFP introduces the concept of 'cohort' - the set of different representations of the same value - and 'quantum' - the magnitude of the rightmost digit in the significand (fraction). Each member of a cohort will have a different quantum. As a result of cohorts, it is important that any comparison of DFP numbers use the compare DFP instructions - even zeroes may have differing quantums so a comparison of the binary representations would not give the correct result The Extract Biased component instruction allows you to determine the quantum of a value. While the Quantize instruction adjusts the quantum - this might be used where the value is say a balance in dollars and you just want to keep 2 digits to the right of the decimal point. Kind regards John Dravnieks
Re: Decimal Floating Point Numbers
Hi Michael, In Cobol it is no picture for comp-1 or comp-2 field. René Le mercredi 6 mars 2024 à 19:44:29 UTC+1, Schmitt, Michael a écrit : The decimal position in a COBOL field affects more than just the display*. It also affects rounding, truncation, scaling and alignment. For example: Field-1 pic 99v999 value 10.100 Field-2 pic 9v value 1.2345 Field-3 pic 999v99 Compute field-3 = field-1 + field-2 results in 11.33. Not 224.45. * and it would need to be an explicit decimal (i.e. edited) to affect the display, e.g. pic 999.99. /pedantic_mode -Original Message- From: IBM Mainframe Assembler List On Behalf Of Gary Weinhold Sent: Wednesday, March 6, 2024 12:03 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Decimal Floating Point Numbers This reminds me in a way of number representation in COBOL. The PICTURE allows you to place the implicit decimal point anywhere, which will afftect the display of the number, but internally there is just a fullword, or packed decimal or halfward, etc. So the programmer choses whether to display, for example, $12345.67 (dollars and cents) or 1234567 pennies or 12.3 Thousands of dollars. Where do you get to indicate whether you want LUV or RUV? Is it part of the convert to zoned decimal or is it an convention that an application agrees on? I can see what it is but I can't see how I can request one or the other in assemlber language. Or is an HLL concept that some asembler subroutine implements for the HLL? Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at http://www.dkl.com/ E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. From: IBM Mainframe Assembler List on behalf of Gary L Peskin Sent: March 6, 2024 11:30 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Decimal Floating Point Numbers Thanks, Abe. I'm glad I was able to help. I don't really understand why they started with this whole LUV/RUV thing anyway. They could have just picked one and said that that's the representation and left it at that (no pun intended!). But I guess that wouldn't have been confusing enough. Take care, Gary
Re: Decimal Floating Point Numbers
Gary, As Gary Peskin and Tony Harminc have pointed out, the sequence of bits is the same, and the 'value' is the same too. Please see my prior email with examples to validate that the value 7 encoded in either LUV or RUV eventually ends up having the exact same sequence of bits. Which underscores that the view chosen is no more than an aid in understanding the numbers your program is using. As I've come to understand, it makes no sense to have an option to request LUV or RUV since the bit sequence would be the very same. And no, RUV/LUV is not an HLL thingy. It is an additional layer of complexity added into the PoP to confuse us mere mortals :-) Kind regards & Happy programming! Abe === Op 06/03/2024 om 19:02 schreef Gary Weinhold: > This reminds me in a way of number representation in COBOL. The PICTURE > allows you to place the implicit decimal point anywhere, which will afftect > the display of the number, but internally there is just a fullword, or packed > decimal or halfward, etc. So the programmer choses whether to display, for > example, $12345.67 (dollars and cents) or 1234567 pennies or 12.3 Thousands > of dollars. > > Where do you get to indicate whether you want LUV or RUV? Is it part of the > convert to zoned decimal or is it an convention that an application agrees > on? I can see what it is but I can't see how I can request one or the other > in assemlber language. Or is an HLL concept that some asembler subroutine > implements for the HLL? > > > > > Gary Weinhold > Senior Application Architect > DATAKINETICS | Data Performance & Optimization > Phone:+1.613.523.5500 x216 > Email: weinh...@dkl.com > Visit us online at www.DKL.com > E-mail Notification: The information contained in this email and any > attachments is confidential and may be subject to copyright or other > intellectual property protection. If you are not the intended recipient, you > are not authorized to use or disclose this information, and we request that > you notify us by reply mail or telephone and delete the original message from > your mail system. > > > > From: IBM Mainframe Assembler List on > behalf of Gary L Peskin > Sent: March 6, 2024 11:30 > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Decimal Floating Point Numbers > > Thanks, Abe. I'm glad I was able to help. I don't really understand why they > started with this whole LUV/RUV thing anyway. They could have just picked one > and said that that's the representation and left it at that (no pun > intended!). But I guess that wouldn't have been confusing enough. > > Take care, > Gary
Re: Decimal Floating Point Numbers
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 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.00E0 - Biased Exp = 95 > 0.70E1 - Biased Exp = 96 > 0.07E2 - Biased Exp = 97 > 0.007000E3 - Biased Exp = 98 > 0.000700E4 - Biased Exp = 99 > 0.70E5 - Biased Exp = 100 > 0.07E6 - 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. > 007E0 - Biased Exp = 101 > 070E-1 - Biased Exp = 100 > 700E-2 - Biased Exp = 99 > 0007000E-3 - Biased Exp = 98 > 007E-4 - Biased Exp = 97 > 070E-5 - Biased Exp = 96 > 700E-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.00 x > 10**0 or as 700. x 10**-6. In both cases the significand is > represented the exact same as 700. 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 700. The representation in memory is the SAME. It's just a > matter of whether you want to look at as > > > > 7.00 x 10 * (95-95) > > -or- > > 700 x 10 * (95-101) > > > > I hope this example helps. > > > > Take care, > > Gary > > > > -Original Message- > > From: IBM Mainframe Assembler List 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 b
Re: Decimal Floating Point Numbers
The decimal position in a COBOL field affects more than just the display*. It also affects rounding, truncation, scaling and alignment. For example: Field-1 pic 99v999 value 10.100 Field-2 pic 9v value 1.2345 Field-3 pic 999v99 Compute field-3 = field-1 + field-2 results in 11.33. Not 224.45. * and it would need to be an explicit decimal (i.e. edited) to affect the display, e.g. pic 999.99. /pedantic_mode -Original Message- From: IBM Mainframe Assembler List On Behalf Of Gary Weinhold Sent: Wednesday, March 6, 2024 12:03 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Decimal Floating Point Numbers This reminds me in a way of number representation in COBOL. The PICTURE allows you to place the implicit decimal point anywhere, which will afftect the display of the number, but internally there is just a fullword, or packed decimal or halfward, etc. So the programmer choses whether to display, for example, $12345.67 (dollars and cents) or 1234567 pennies or 12.3 Thousands of dollars. Where do you get to indicate whether you want LUV or RUV? Is it part of the convert to zoned decimal or is it an convention that an application agrees on? I can see what it is but I can't see how I can request one or the other in assemlber language. Or is an HLL concept that some asembler subroutine implements for the HLL? Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at http://www.dkl.com/ E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. From: IBM Mainframe Assembler List on behalf of Gary L Peskin Sent: March 6, 2024 11:30 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Decimal Floating Point Numbers Thanks, Abe. I'm glad I was able to help. I don't really understand why they started with this whole LUV/RUV thing anyway. They could have just picked one and said that that's the representation and left it at that (no pun intended!). But I guess that wouldn't have been confusing enough. Take care, Gary
Re: Decimal Floating Point Numbers
On 06/03/2024 18:30, Paul Saers wrote: Where do you get to indicate whether you want LUV or RUV? In your head :-) They are two different ways of interpreting the sequence of bits according to two different rules that are designed to give the exact same mathematical number for the same sequence of bits. -- Martin Dr Martin Ward | Email: mar...@gkc.org.uk | http://www.gkc.org.uk G.K.Chesterton site: http://www.gkc.org.uk/gkc | Erdos number: 4
Re: Decimal Floating Point Numbers
Maybe this topic should also look outside the IBM mainframe, since the decimal floating point is a cross platform project. It can be found on Linux*, Windows*, HP-UX*, Solaris*, or macOS* and maybe more. Try google. /Paul Saers 2024-03-06 19:02 skrev Gary Weinhold: This reminds me in a way of number representation in COBOL. The PICTURE allows you to place the implicit decimal point anywhere, which will afftect the display of the number, but internally there is just a fullword, or packed decimal or halfward, etc. So the programmer choses whether to display, for example, $12345.67 (dollars and cents) or 1234567 pennies or 12.3 Thousands of dollars. Where do you get to indicate whether you want LUV or RUV? Is it part of the convert to zoned decimal or is it an convention that an application agrees on? I can see what it is but I can't see how I can request one or the other in assemlber language. Or is an HLL concept that some asembler subroutine implements for the HLL? Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. From: IBM Mainframe Assembler List on behalf of Gary L Peskin Sent: March 6, 2024 11:30 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Decimal Floating Point Numbers Thanks, Abe. I'm glad I was able to help. I don't really understand why they started with this whole LUV/RUV thing anyway. They could have just picked one and said that that's the representation and left it at that (no pun intended!). But I guess that wouldn't have been confusing enough. Take care, Gary
Re: Decimal Floating Point Numbers
This reminds me in a way of number representation in COBOL. The PICTURE allows you to place the implicit decimal point anywhere, which will afftect the display of the number, but internally there is just a fullword, or packed decimal or halfward, etc. So the programmer choses whether to display, for example, $12345.67 (dollars and cents) or 1234567 pennies or 12.3 Thousands of dollars. Where do you get to indicate whether you want LUV or RUV? Is it part of the convert to zoned decimal or is it an convention that an application agrees on? I can see what it is but I can't see how I can request one or the other in assemlber language. Or is an HLL concept that some asembler subroutine implements for the HLL? Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. From: IBM Mainframe Assembler List on behalf of Gary L Peskin Sent: March 6, 2024 11:30 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Decimal Floating Point Numbers Thanks, Abe. I'm glad I was able to help. I don't really understand why they started with this whole LUV/RUV thing anyway. They could have just picked one and said that that's the representation and left it at that (no pun intended!). But I guess that wouldn't have been confusing enough. Take care, Gary
Re: Decimal Floating Point Numbers
Thanks, Abe. I'm glad I was able to help. I don't really understand why they started with this whole LUV/RUV thing anyway. They could have just picked one and said that that's the representation and left it at that (no pun intended!). But I guess that wouldn't have been confusing enough. Take care, Gary -Original Message- From: IBM Mainframe Assembler List On Behalf Of Abe Kornelis Sent: Wednesday, March 6, 2024 12:31 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Decimal Floating Point Numbers 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.00E0 - Biased Exp = 95 0.70E1 - Biased Exp = 96 0.07E2 - Biased Exp = 97 0.007000E3 - Biased Exp = 98 0.000700E4 - Biased Exp = 99 0.70E5 - Biased Exp = 100 0.07E6 - 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. 007E0 - Biased Exp = 101 070E-1 - Biased Exp = 100 700E-2 - Biased Exp = 99 0007000E-3 - Biased Exp = 98 007E-4 - Biased Exp = 97 070E-5 - Biased Exp = 96 700E-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.00 x > 10**0 or as 700. x 10**-6. In both cases the significand is represented > the exact same as 700. 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 700. The representation in memory is the SAME. It's > just a matter of whether you want to look at as > > 7.00 x 10 * (95-95) > -or- > 700 x 10 * (95-101) > > I hope this example helps. > > Take care, > Gary > > -Original Message- > From: IBM Mainframe Assembler List > 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.0*10**0 > In RUV this would be 07*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
Re: Decimal Floating Point Numbers
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.00E0 - Biased Exp = 95 0.70E1 - Biased Exp = 96 0.07E2 - Biased Exp = 97 0.007000E3 - Biased Exp = 98 0.000700E4 - Biased Exp = 99 0.70E5 - Biased Exp = 100 0.07E6 - 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. 007E0 - Biased Exp = 101 070E-1 - Biased Exp = 100 700E-2 - Biased Exp = 99 0007000E-3 - Biased Exp = 98 007E-4 - Biased Exp = 97 070E-5 - Biased Exp = 96 700E-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.00 x > 10**0 or as 700. x 10**-6. In both cases the significand is represented > the exact same as 700. 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 700. The representation in memory is the SAME. It's just a matter of > whether you want to look at as > > 7.00 x 10 * (95-95) > -or- > 700 x 10 * (95-101) > > I hope this example helps. > > Take care, > Gary > > -Original Message- > From: IBM Mainframe Assembler List 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.0*10**0 > In RUV this would be 07*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
Re: Decimal Floating Point Numbers
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.00 x 10**0 or as 700. x 10**-6. In both cases the significand is represented the exact same as 700. 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 700. The representation in memory is the SAME. It's just a matter of whether you want to look at as 7.00 x 10 * (95-95) -or- 700 x 10 * (95-101) I hope this example helps. Take care, Gary -Original Message- From: IBM Mainframe Assembler List 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.0*10**0 In RUV this would be 07*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
Re: Decimal Floating Point Numbers
Abe. I think you're still missing the point. I'll reply to a later message to straighten this out. Gary -Original Message- From: IBM Mainframe Assembler List On Behalf Of Abe Kornelis Sent: Monday, March 4, 2024 3:24 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Decimal Floating Point Numbers Hi Gary, Thanks for the PoP quote. I must have missed that one. Otherwise, I roughly got as far as you did. One can move the (virtual) decimal point at will, provided you adjust the exponent value accordingly. When e.g. adding two DFP numbers, the LUV vs. RUV does not seem to matter - the addition results are the same in either case. When adding a RUV-encoded value to a LUV-encoded value the addition is bound to produce rubbish. So it seems relevant to know how to distinguish. Since the processor seems not to make the distinction, I think I must be something... Kind regards, Abe === Op 04/03/2024 om 09:08 schreef Gary L Peskin: > Hi, Abe - > > > > In the version of the PoP that I'm looking at, it states that ". Except where > otherwise indicated, ...DFP [is defined] in terms of the right-units view. So > I think that's just a convention in the documentation. > > > > As far as LUV vs RUV, a given value is represented the same in a register or > storage regardless of whether you view it as LUV or RUV. These are just > "views" at the number. You can view it as if the decimal point is either to > the right of the leftmost digit (LUV) or to the right of the rightmost digit > (RUV). In other words it's sort of like saying 1.234 * 102 (LUV) is the same > as 1234 * 10-1 (RUV). If you look carefully, you’ll see that the biases for > the exponent in figure 20-2 differ by the same amount as the number of digits > in the significand. By considering the bias as having changed, it just > accounts for where the decimal point is even though the representation is the > same. It’s just a question of how you want to view the number. I probably > didn’t explain this very well but I hope you get the idea. > > > > Frankly, I think this whole LUV vs RUV discussion is more confusing than > helpful but I guess some people like to think of their numbers as x. * > 10y and others prefer to think of them as x * 10z. > > > > And figure 9-1 is just showing the possible range of values with an unbiased > exponent. It’s not meant to indicate any representation of the top/bottom of > the range in memory which uses biased exponents. > > > > HTH, > > Gary > > > > -Original Message- > From: IBM Mainframe Assembler List > On Behalf Of Abe Kornelis > Sent: Sunday, March 3, 2024 10:29 AM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Decimal Floating Point Numbers > > > > All, > > > > There's something with decimal floating point numbers that has been eluding > me for a long time. > > > > According to PoP chapter 20, DFP numbers may be encoded as either Left-Units > View or Right-Units View. > > As shown in e.g. figure 20-2. > > > > Yet when looking at a DFP value in a dump, it seems to be impossible to tell > which view applies. > > Just like a packed decimal does not have the decimal point encoded - you just > have to know where the programmer decided it to be. > > Is it indeed like that with LUV vs. RUV - you just have to know? > > > > Additionally, figure 9-1 lists only the RUV values; no mention is made of LUV > representation limits. > > Instruction descriptions equally make no mention of LUV vs. RUV. > > > > To me it appears the instruction always treat the data as RUV. Is this > correct? > > Or am I missing something obvious? > > > > Thanks in advance, > > Abe Kornelis. > > ==
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.0*10**0 In RUV this would be 07*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
Re: Decimal Floating Point Numbers
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
Re: Decimal Floating Point Numbers
Hi Gary, Thanks for the PoP quote. I must have missed that one. Otherwise, I roughly got as far as you did. One can move the (virtual) decimal point at will, provided you adjust the exponent value accordingly. When e.g. adding two DFP numbers, the LUV vs. RUV does not seem to matter - the addition results are the same in either case. When adding a RUV-encoded value to a LUV-encoded value the addition is bound to produce rubbish. So it seems relevant to know how to distinguish. Since the processor seems not to make the distinction, I think I must be something... Kind regards, Abe === Op 04/03/2024 om 09:08 schreef Gary L Peskin: > Hi, Abe - > > > > In the version of the PoP that I'm looking at, it states that ". Except where > otherwise indicated, ...DFP [is defined] in terms of the right-units view. So > I think that's just a convention in the documentation. > > > > As far as LUV vs RUV, a given value is represented the same in a register or > storage regardless of whether you view it as LUV or RUV. These are just > "views" at the number. You can view it as if the decimal point is either to > the right of the leftmost digit (LUV) or to the right of the rightmost digit > (RUV). In other words it's sort of like saying 1.234 * 102 (LUV) is the same > as 1234 * 10-1 (RUV). If you look carefully, you’ll see that the biases for > the exponent in figure 20-2 differ by the same amount as the number of digits > in the significand. By considering the bias as having changed, it just > accounts for where the decimal point is even though the representation is the > same. It’s just a question of how you want to view the number. I probably > didn’t explain this very well but I hope you get the idea. > > > > Frankly, I think this whole LUV vs RUV discussion is more confusing than > helpful but I guess some people like to think of their numbers as x. * > 10y and others prefer to think of them as x * 10z. > > > > And figure 9-1 is just showing the possible range of values with an unbiased > exponent. It’s not meant to indicate any representation of the top/bottom of > the range in memory which uses biased exponents. > > > > HTH, > > Gary > > > > -Original Message- > From: IBM Mainframe Assembler List On > Behalf Of Abe Kornelis > Sent: Sunday, March 3, 2024 10:29 AM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Decimal Floating Point Numbers > > > > All, > > > > There's something with decimal floating point numbers that has been eluding > me for a long time. > > > > According to PoP chapter 20, DFP numbers may be encoded as either Left-Units > View or Right-Units View. > > As shown in e.g. figure 20-2. > > > > Yet when looking at a DFP value in a dump, it seems to be impossible to tell > which view applies. > > Just like a packed decimal does not have the decimal point encoded - you just > have to know where the programmer decided it to be. > > Is it indeed like that with LUV vs. RUV - you just have to know? > > > > Additionally, figure 9-1 lists only the RUV values; no mention is made of LUV > representation limits. > > Instruction descriptions equally make no mention of LUV vs. RUV. > > > > To me it appears the instruction always treat the data as RUV. Is this > correct? > > Or am I missing something obvious? > > > > Thanks in advance, > > Abe Kornelis. > > ==
Re: Decimal Floating Point Numbers
Hi, Abe - In the version of the PoP that I'm looking at, it states that ". Except where otherwise indicated, ...DFP [is defined] in terms of the right-units view. So I think that's just a convention in the documentation. As far as LUV vs RUV, a given value is represented the same in a register or storage regardless of whether you view it as LUV or RUV. These are just "views" at the number. You can view it as if the decimal point is either to the right of the leftmost digit (LUV) or to the right of the rightmost digit (RUV). In other words it's sort of like saying 1.234 * 102 (LUV) is the same as 1234 * 10-1 (RUV). If you look carefully, you’ll see that the biases for the exponent in figure 20-2 differ by the same amount as the number of digits in the significand. By considering the bias as having changed, it just accounts for where the decimal point is even though the representation is the same. It’s just a question of how you want to view the number. I probably didn’t explain this very well but I hope you get the idea. Frankly, I think this whole LUV vs RUV discussion is more confusing than helpful but I guess some people like to think of their numbers as x. * 10y and others prefer to think of them as x * 10z. And figure 9-1 is just showing the possible range of values with an unbiased exponent. It’s not meant to indicate any representation of the top/bottom of the range in memory which uses biased exponents. HTH, Gary -Original Message- From: IBM Mainframe Assembler List On Behalf Of Abe Kornelis Sent: Sunday, March 3, 2024 10:29 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Decimal Floating Point Numbers All, There's something with decimal floating point numbers that has been eluding me for a long time. According to PoP chapter 20, DFP numbers may be encoded as either Left-Units View or Right-Units View. As shown in e.g. figure 20-2. Yet when looking at a DFP value in a dump, it seems to be impossible to tell which view applies. Just like a packed decimal does not have the decimal point encoded - you just have to know where the programmer decided it to be. Is it indeed like that with LUV vs. RUV - you just have to know? Additionally, figure 9-1 lists only the RUV values; no mention is made of LUV representation limits. Instruction descriptions equally make no mention of LUV vs. RUV. To me it appears the instruction always treat the data as RUV. Is this correct? Or am I missing something obvious? Thanks in advance, Abe Kornelis. ==
