Value truncating after multiplication



IBM's flagship sort product DFSORT for sorting, merging, copying, data manipulation and reporting. Includes ICETOOL and ICEGENER

Re: Value truncating after multiplication

Postby shankar_dh » Mon Mar 31, 2014 4:54 pm

Hi Billy,

My requirement was to multiply 2 numbers.
Var 1 --> 9(16) PD
Var 2 --> 9(5)v9(10) ZD
When I multiply these 2 numbers I lost leading 10 digits.

If I give small value, It works fine, Max value it can hold after multiplication is 9(19)v99.

If the integer part is more than 19 bytes then it would be a problem.

In SAS I declared var3 with 16.2 PD
When I did the multiplication , Var3=var1*var2, It is automatically rounded the multiplied value to 16.2 PD (COBOL equivalent for your reference 9(14)v99)

Don't you agree that we need a lot of logic in SORT just to round the value??
Don't you think, Its time to have internal function which does it??
shankar_dh
 
Posts: 41
Joined: Fri Mar 22, 2013 1:00 pm
Has thanked: 1 time
Been thanked: 0 time

Re: Value truncating after multiplication

Postby dick scherrer » Mon Mar 31, 2014 7:12 pm

Hello,

Don't you agree that we need a lot of logic in SORT just to round the value??
No, the sort does Many things. It does NOT do everything. If you are determined to do full-function report writing in a SORT process, consider an exit to do the formatting.

Don't you think, Its time to have internal function which does it??
Not really. If enough users want this, it will most likely happen at some time.

Unfortunately for many, Some Work still has to be done . . .
Hope this helps,
d.sch.
User avatar
dick scherrer
Global moderator
 
Posts: 6268
Joined: Sat Jun 09, 2007 8:58 am
Has thanked: 3 times
Been thanked: 93 times

Re: Value truncating after multiplication

Postby BillyBoyo » Mon Mar 31, 2014 7:24 pm

Are you sure about the size of 16.2 PD in SAS? From your COBOL translation, that is much shorter than the data you have shown.

The point about the rounding is that there is more than one type of rounding. When you say rounding, you have to be specific. SORT rounds down. It is a rounding, not the one you want.

If SAS has the advantage of knowing about the scaling of your second field. If SAS is multiplying your 29 digit plus two decimal places value by five with 10 decimal places, SAS has a bit of extra space to work with, but 29 + 5 is 34, so if you have a value sufficiently large that you are multiplying by, you will still have truncation.

If your multiplier is never large enough to break it (so why is it defined so big?) then you may get a result from SORT by DIViding by the reciprocal (divide your multiplier into one, then DIV by the result).

You haven't answered on the range of values your 9(5)V9(10) can take, so don't know if you still may get truncation in SAS.

If you define your rounding, it can be done in SORT through code.

If you are looking for additional functionality in DFSORT so apply a specific rounding (one of more than one possible "roundings"), then Kolusu will probably comment on that. There will certainly not be a change to the way the basic code works, cos it would break existing sort control card decks and backwards compatability is exceptionally important.
BillyBoyo
Global moderator
 
Posts: 3804
Joined: Tue Jan 25, 2011 12:02 am
Has thanked: 22 times
Been thanked: 265 times

Re: Value truncating after multiplication

Postby skolusu » Mon Mar 31, 2014 9:42 pm

shankar_dh wrote:When I multiply these 2 numbers I lost leading 10 digits.

If I give small value, It works fine, Max value it can hold after multiplication is 9(19)v99.

If the integer part is more than 19 bytes then it would be a problem.

In SAS I declared var3 with 16.2 PD
When I did the multiplication , Var3=var1*var2, It is automatically rounded the multiplied value to 16.2 PD (COBOL equivalent for your reference 9(14)v99)

Don't you agree that we need a lot of logic in SORT just to round the value??
Don't you think, Its time to have internal function which does it??


Shankar_dh,

In DFSORT the resulting values are rounded down to the nearest integer. Which programming language supports more than 31 digits currently? Even SAS only supports 31 digits for packed decimal values.
Kolusu - DFSORT Development Team (IBM)
DFSORT is on the Web at:
www.ibm.com/storage/dfsort
skolusu
 
Posts: 586
Joined: Wed Apr 02, 2008 10:38 pm
Has thanked: 0 time
Been thanked: 39 times

Re: Value truncating after multiplication

Postby shankar_dh » Mon Mar 31, 2014 10:15 pm

Sorry, COBOL equivalent of PD16.2 is 9(29)v99
Basically 9(5)v9(10) is to hold the currency exchange value. So I guess, Integer part can not be more than 3 digits. Only the decimal place will be more which will occupy all the 10 digits.
For ex, 1 USD = 60.2354809765 INR
Say Your balance is $ 23,435,234,091,765,097,765,124,678,009.87 --> This is stored in PD16.2 ( I am sure Balance can not be this much huge , This is just for example)
So while multiplying your account balance -- Your balance in USD * 60.2354809765 = Converted value in INR which should be in 9(29)v99 [PD16.2]
In SORT you need to have a logic to ROUND the multiplied value to 9(29)v99 but in SAS I did not use any logic, just declared variable of length PD16.2 and stored the multiplied result.
Yes, DFSORT is very strong TOOL. But I am feeling in this case it is the limitation. Rather we should have had internal function which takes care of the ROUNDING the results after arithmetic operations.
shankar_dh
 
Posts: 41
Joined: Fri Mar 22, 2013 1:00 pm
Has thanked: 1 time
Been thanked: 0 time

Re: Value truncating after multiplication

Postby skolusu » Mon Mar 31, 2014 11:32 pm

shankar_dh wrote:Sorry, COBOL equivalent of PD16.2 is 9(29)v99
Basically 9(5)v9(10) is to hold the currency exchange value. So I guess, Integer part can not be more than 3 digits. Only the decimal place will be more which will occupy all the 10 digits.
For ex, 1 USD = 60.2354809765 INR
Say Your balance is $ 23,435,234,091,765,097,765,124,678,009.87 --> This is stored in PD16.2 ( I am sure Balance can not be this much huge , This is just for example)
So while multiplying your account balance -- Your balance in USD * 60.2354809765 = Converted value in INR which should be in 9(29)v99 [PD16.2]
In SORT you need to have a logic to ROUND the multiplied value to 9(29)v99 but in SAS I did not use any logic, just declared variable of length PD16.2 and stored the multiplied result.
Yes, DFSORT is very strong TOOL. But I am feeling in this case it is the limitation. Rather we should have had internal function which takes care of the ROUNDING the results after arithmetic operations.


Shankar_dh,

23,435,234,091,765,097,765,124,678,009.87 X 60.2354809765 = ?????? how much in SAS? is SAS truncating it to the left or right? You are looking at an imaginary number and think it is a limitation of DFSORT but it isn't.
Kolusu - DFSORT Development Team (IBM)
DFSORT is on the Web at:
www.ibm.com/storage/dfsort
skolusu
 
Posts: 586
Joined: Wed Apr 02, 2008 10:38 pm
Has thanked: 0 time
Been thanked: 39 times

Re: Value truncating after multiplication

Postby BillyBoyo » Tue Apr 01, 2014 3:27 am

As Kolusu is indicating, multiplying that value by 60 you'd expect truncation. There is no way you can get the correct answer and store it in 29 integer digits plus two decimal places.

That's 23,435 trillion trillion anyway. Let's say the current annual GDP of the US is 16 trillion. That would mean you'd have enough space in your field to hold over 1,400 trillion accounts the size of the US of A. I haven't even bothered to check my maths, as I could be several orders of magnitude out and you'd still be looking at an absurd number of accounts of an absurd size.

Why are you taking the summed value of balances and doing a currency coversion?
BillyBoyo
Global moderator
 
Posts: 3804
Joined: Tue Jan 25, 2011 12:02 am
Has thanked: 22 times
Been thanked: 265 times

Previous

Return to DFSORT/ICETOOL/ICEGENER

 


  • Related topics
    Replies
    Views
    Last post