problem in data type f.

[Former Member]

Hi all,

where <b>a is menge data type quan</b>

i declared <b>b as type f</b>.

i have values a = .2

b = a.

then my b = 2.000000000000000<b>1</b>E-01

if a = .5

b= a.

then my b = 5.000000000000000<b>0</b>E-01

observe the difference in bold .

Its creating lot of problems .

Can anyboty tell me how to rectify this.

[Former Member]

Hi,

use type p for 'b'or

declare it the way u declared a.

hope this helps.

regards,

keerthi.

[Former Member]

Hi Kajol,

Declare b as

data: b type p decimals 3.

as MENGE is having three decimals.

Regards,

Vivek

[Former Member]

use write b to a.

[Former Member]

Hi Kajol,

Go thru this documentation on numeric type 'F' by SAP.

=======================================================

Type F values range from /- 2.2250738585072014E-308 to 1.7976931348623157E308, as well as the number 0, with an accuracy of at least 15 decimal places.

You cannot enter floating point numbers directly in your programs. Instead, you must use text literals that can be interpreted as floating point numbers. You may use the following formats:

Decimal numbers with or without sign, with or without decimal point. The form <mantissa> E<exponent>, where the mantissa is a decimal. The exponent may be specified either with or without sign. You may also use spaces before or after the number. Examples of text literals with "floating point numbers":

'1', '-12.34567', '-765E-04', '1234E5', '12E34', '+12.3E-4', '1E160'.

Use floating point arithmetic if you need a very large value range or you are making decimal calculations, but be aware of the following features of floating point arithmetic.

Internally, the exponent and the mantissa of floating point numbers are stored separately, each in two parts. This can lead to unexpected results, despite the high degree of intrinsic accuracy. These occur mainly when performing conversions from and to type F.

For example, the number 1.5 can be represented exactly in this notation, since 1.5 = 120 + 12**(-1), but the number 0.15 can only be represented approximately by the number 0,14999999999999999. If you round 0.15 up to 1 valid digit, the result is 0.1 rather than 0.2 as you would expect. On the other hand, the number 1.5E-12 is represented by the number 1.5000000000000001E-12, which would be rounded to 2E-12.

Another example which actually occurred is the calculation of 7.27% of 73050 to an accuracy of 2 decimal places. The intermediate result 5.3107349999999997E+03, since the correct result, 5310.735, cannot be represented exactly in two parts with 53 bits. (If the hardware cannot represent a real number exactly, it uses the next representable floating point number. After rounding, you therefore get 5310.73 rather than 5310.74 as you would expect.

The ABAP runtime system calculates commercially and not "numerically" like the underlying machine arithmetic. According to the rounding algorithm of the latter, the end digit 5 must always be rounded to the nearest even number (not the next largest number), i.e. from 2.5 to 2, 3.5 to 4.

You should also note that multiplication using powers of 10 (positive or negative), is not an exact operation. For example, although 100.5 can be represented exactly in two parts, after the operation

F = F / 100 * 100

F has the value 100.49999999999999.

As well as rounding errors, the restricted number of decimal places for the mantissa can lead to the loss of trailing digits. For example, 1 - 1.0000000000000001 results in zero.

This means that you cannot rely on the last digits in floating point arithmetic. In particular, you should not usually test two floating point numbers for equality; instead, you should check whether the relative difference abs((a - b)/a) is less than a predefined limit, e.g. 10**(-7).

=======================================================

Hope this clears your doubt why you are getting difference while converting it to floating point.

Regards,

Vivek