Convert Scientific Notation to Numeric (ABAP)

I am currently consuming a WebService from XIgnite, that is returning a 7.5863900E-01 and I need to update the TCURR (Exchange Rate table) with .758639. 
I need an ABAP example to use to place within the program that is importing the data for exchange rates.
Thanks.

try this:
DATA: W_EXPO TYPE QPMK-SOLLWERT,
      W_PCKDECI(16)  TYPE P DECIMALS 3.
MOVE : '7.5863900E-01' TO W_EXPO,
       W_EXPO TO W_PCKDECI.

Similar Messages

  • Scientific notation in numeric fields

    I need to be able to input scientific notation in numeric fields for my adobe forms.  I can put the pattern to num{9.99E} and it will allow me to put positive exponents and negative exponents to -3.  However, I need to input the number 4.76E-19 and it always changes it to 0.00E0.  What kind I do to keep this small of a number as 4.76E-19?

    Hi,
    Unfortunatly in approach with text field numbers will not be formatted in scientific  notation, users will have to type numbers in correct format.
    In approach with NumericField and patter {9.99E} i think there is some bug.
    I can type this number:
    After i lost focus from this field it will be formatted in tis style:
    And sfter button click i will get this:
    For big values everything working fine.
    Is this bug!?
    BR

  • Converting scientific notation string to number?

    This is raising an error:
    > ToNumber (u201C2.75E-05u201D)
    How do you convert scientific notation strings to numbers?
    This is coming from XML. I can probably have the XML written so that it's not scientific notation.
    Tim

    Here's a not-so-pretty way:
    Local StringVar Array x;
    Local StringVar mantissa;
    Local StringVar exponent := "0";
    // Split into mantissa and exponent parts.
    x:= Split("24.2233E+2", "e", 2, 1);
    mantissa := x[1];
    If (UBound(x) = 2)
    Then
        exponent := x[2];
    // CDbl cannot interpret leading positive sign, so removie
    If Left(mantissa, 1) = "+"
    Then
        mantissa := Right(mantissa, Length(mantissa) - 1);
    If Left(exponent, 1) = "+"
    Then
        exponent := Right(exponent, Length(exponent) - 1);
    // Compute number
    CDbl(mantissa) * 10 ^ CDbl(exponent);
    Sincerely,
    Ted Ueda

  • Convert Scientific Notation to Float

    Hello
    How can we convert Scientific notation to float.
    e.g.
    1.23E-3(string) as  0.00123(float)
    Thanks
    Solved!
    Go to Solution.

    Use Fract/EngStringToNumber. Or ScanFromString with format %f…
    Best regards,
    GerdW
    CLAD, using 2009SP1 + LV2011SP1 + LV2014SP1 on WinXP+Win7+cRIO
    Kudos are welcome

  • Convert scientific notation value into normal number

    hi,
    I am importing excel(.csv) file into Oracle database, a value in excel file 8.70773E+11 is displaying in scientific notation format, i want to store it like 870772521002.

    i have already run this query, it gave me 871000000000.0000000000 this result.
    Table Structure,
    SQL> desc cdr;
    Name Null? Type
    INVOICENO VARCHAR2(50)
    OCEANREGION NUMBER
    CALLDATE DATE
    CALLTIME VARCHAR2(10)
    ORIGINATORNO                             VARCHAR2(50)
    SUBSCRIBER VARCHAR2(75)
    DESTNO VARCHAR2(50)
    VOLUME FLOAT(50)
    UNIT VARCHAR2(5)
    this above Originatorno field had Number data type, but it wasnt working.

  • Numeric Values Converted to Scientific Notation

    My BPEL process converts numeric values to scientific notation (eg. 12345678 is converted to 1.2345678E7). This then causes problems when I try to perform any mathematical operations on these values during an XSL transformation (output - NaN)
    Is there any way I can stop this data conversion?
    This occurs with BPEL 10.1.2.0.2. I'm loading the data from an Oracle 9.2 database using the DbAdapter.
    I've written an XSL routine to convert these values back to the correct decimal notation, but would prefer to stop this happening rather than workaround the problem.

    On further investigation, this occurs for values loaded from Oracle FLOAT database type.
    The XSD generated for the DbAdapter uses type xs:double for this field, but I've also tried changing this to xs:decimal & xs:float and still get the same problem.

  • Convert from scientific notation

    Can someone help me with this? I cannot get this working even using some of the tips I found on this site and elsewhere:
    Round this and format this with 2 decimals: '-2.58069E-11'.
    Now I realize this would end up -2.58, but it is giving me an error instead.
    Error converting data type varchar to numeric.
    SELECT CAST('2.58069E-11' AS NUMERIC(24,2))
    SELECT CAST('2.58069E-11' AS NUMERIC(24,12))
    I tried 12 just to make sure that there was enough room for the decimals
    If I use ISNUMERIC, it returns 1, so SQL Server considers it a number (at least with that function)
    The next example works, but it is not what I want.
    SELECT CAST('2.58069E-11' AS REAL) just returns the same thing with the 'E', (as REAL, of course)
    In these example I haven't done the rounding yet.
    I get all kinds of negative and positive numbers with different decimal lengths, but the scientific notation is particularly tricky.

    Before I put this to bed, I have found out both the above solutions are wrong when using a regular decimal:
    Try this:
    SELECT CAST(CAST('-1131658.27' AS REAL) AS NUMERIC(24,2))
    And this:
    SELECT CAST(CONVERT(REAL, -1131658.27) as DECIMAL(24,12))
    They both yield -1131658.25, and -1131658.250000000000, respectively.
    This is probably some floating point error, but how do I take care of it?

  • Numeric value and scientific notation

    Hi,
    with Oracle 8 or 10, the query (via TOAD or my app : Delphi + BDE)
    SELECT 0.0008 FROM DUAL returns 0.0008,
    but the query
    SELECT 0.00008 FROM DUAL returns 8E-5.
    Is there a way to avoid this display in scientific notation, except changing all my queries ? Or to push the limit for this display one digit later ?
    Maybe with an Oracle parameter ?
    Thanks for your help !

    duplicate for thread
    numeric value and scientific notation

  • Converting from a double to scientific notation

    does anyone know how I can convert a double value to scientific notation?

    java.text.DecimalFormat can do that.

  • Select Query resulting in Scientific Notation

    Hello all,
    I am running a Select query through a batch file that extracts data from an Oracle database. Several of the fields that I am extracting from contain numbers that are up to 38 digits long. When I extract the data, it converts the numbers into scientific notation and it is important for me to have the entire field. Is there something I can change to my query that will pull the data in its entire form? This is what I'm running now:
    select * FROM ML.APPT where APPTDATE >= to_date('01/1/2010','mm/dd/yyyy'
    I apologize in advance if this has been answered already.
    Thanks!

    >
    When the extractor finishes, it returns the data into a flat file.
    don't quite understand the TO_CHAR function. Does this function mean I need to say something like this: select "TO_CHAR('column name', 99999999999999999999999999999999999999" FROM ML.APPT where APPTDATE >= to_date('01/1/2010','mm/dd/yyyy')
    >
    Yes- if the tool you use to extract the data (your 'extractor') is converting the numeric data to a string then it is responsible for creating the string in the proper format. If the number is an integer that can have as many digits as you have '9's in your sample format string then that is what you need to do.
    Here is how sql*plus (Oracle's tool) will display the data using default settings
    SQL> select 12345678901234567890123456789012345678 no_format,
      2  to_char(12345678901234567890123456789012345678, '99999999999999999999999999
    999999999999') with_format
      3   from dual;
    NO_FORMAT WITH_FORMAT
    1.2346E+37  12345678901234567890123456789012345678
    SQL>
    ----- TOAD will display something similiar but the default uses more decimal digits in the scientific notation data
    NO_FORMAT,WITH_FORMAT
    1.23456789012346E37, 12345678901234567890123456789012345678You can either format the numeric data in the query using TO_CHAR or the 'extractor' can do it when it converts the data to a string.

  • WKT Contains Scientific Notation

    I have a table with an SDO geometry column. Our data is stored in Web Mercator to simplify displaying maps on a web page. My team's preferred way of shuffling geometries around is via its WKT since this is human readable and widely used. So we are fetching the WKT directly from the database using the GET_WKT() method (right term?) on the SDO geoemtry.
    The problem is that when coordinates exceed 10 million in magnitude, those coordinates are represented in E notation (see http://en.wikipedia.org/wiki/Scientific_notation#E_notation). I need to convert this WKT to a .NET object for use with a particular library, and while it supports conversion from WKT, it blows up on the E notation. I'd call it a bug with the library except for the fact that Oracle itself can't parse WKTs with E notation, either. SDO_UTIL.VALIDATE_WKTGEOMETRY returns FALSE for the WKT that GET_WKT() generated, and SDO_UTIL.FROM_WKTGEOMETRY throws an error. I've also tested that SDO_UTIL.SDO_UTIL.TO_WKTGEOMETRY returns the same WKT.
    A large amount of code already depends on the geometry being in WKT format, which means that switching to another format would not be an easy change. For the moment, I'm parsing the WKT using SQL Server's geometry type (see http://msdn.microsoft.com/en-us/library/microsoft.sqlserver.types.sqlgeometry_methods.aspx), and then converting it back to a WKT without E notation using its STAsText() method.
    Is there a way to force Oracle to not return E notation coordinates?
    This is occurring in both of the following versions of Oracle:
    Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod
    PL/SQL Release 10.2.0.1.0 - Production
    "CORE     10.2.0.1.0     Production"
    TNS for 32-bit Windows: Version 10.2.0.1.0 - Production
    NLSRTL Version 10.2.0.1.0 - Production
    Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
    PL/SQL Release 11.1.0.6.0 - Production
    "CORE     11.1.0.6.0     Production"
    TNS for 32-bit Windows: Version 11.1.0.6.0 - Production
    NLSRTL Version 11.1.0.6.0 - Production
    Sample SQL:
    The SRID in the following queries does not seem to exist out of the box in version 10 or Oracle. I ran these queries through Oracle SQL Developer.
    Query:
    SELECT MDSYS.SDO_GEOMETRY(2003,3785,NULL,MDSYS.SDO_ELEM_INFO_ARRAY(1,1003,1),MDSYS.SDO_ORDINATE_ARRAY(-13426771.266146,5334024.8870015,-13425624.710722,5326534.0582305,-13412553.978887,5325922.5620044,-13412936.164029,5333719.1388884,-13426771.266146,5334024.8870015)).GET_WKT() FROM DUAL;
    Result:
    POLYGON ((-1.3426771266146E7 5334024.8870015, -1.3425624710722E7 5326534.0582305, -1.3412553978887E7 5325922.5620044, -1.3412936164029E7 5333719.1388884, -1.3426771266146E7 5334024.8870015))
    Query:
    SELECT SDO_UTIL.VALIDATE_WKTGEOMETRY(MDSYS.SDO_GEOMETRY(2003,3857,NULL,MDSYS.SDO_ELEM_INFO_ARRAY(1,1003,1),MDSYS.SDO_ORDINATE_ARRAY(-13426771.266146,5334024.8870015,-13425624.710722,5326534.0582305,-13412553.978887,5325922.5620044,-13412936.164029,5333719.1388884,-13426771.266146,5334024.8870015)).GET_WKT()) FROM DUAL;
    Result:
    FALSE
    Query:
    SELECT SDO_UTIL.FROM_WKTGEOMETRY(MDSYS.SDO_GEOMETRY(2003,3785,NULL,MDSYS.SDO_ELEM_INFO_ARRAY(1,1003,1),MDSYS.SDO_ORDINATE_ARRAY(-13426771.266146,5334024.8870015,-13425624.710722,5326534.0582305,-13412553.978887,5325922.5620044,-13412936.164029,5333719.1388884,-13426771.266146,5334024.8870015)).GET_WKT()) FROM DUAL;
    Result:
    ORA-29532: Java call terminated by uncaught Java exception: java.lang.RuntimeException
    ORA-06512: at "MDSYS.SDO_UTIL", line 172
    29532. 00000 - "Java call terminated by uncaught Java exception: %s"
    *Cause:    A Java exception or error was signaled and could not be
    resolved by the Java code.
    *Action:   Modify Java code, if this behavior is not intended.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       

    Hello jpmc26,
    I am going to guess that most of us live our lives between the 180s and have not really noticed this before. I would call it a bug that needs an SR opened but is the bug on the coming or the going? If you look in the Simple Features 1.2.1 specification on pages 52 and 53 they clearly say that an "approximate numeric literal" of mantissa + E + exponent is valid. However, Oracle Spatial does not support the 1.2.1 spec. Rather they support something akin to the 1.1.0 specification. On pages 28 and 29 of that version there is no mention of approximate numeric literals as it first shows up in the 1.2.0 specification.
    So I would say either:
    1) Oracle Spatial supporting only the 1.1.0 specification and not much interested in updating to current specifications, should remove the output of scientific notation from the SDO_UTIL.to_WKTGEOMETRY procedure (match 1.1.0 spec).
    -or-
    2) Oracle Spatial looking forward to future compatibility with new OGC standards, should add support for parsing scientific notation to the SDO_UTIL.from_WKTGEOMETRY procedure (prepare for 1.2.1 spec).
    I guess its a policy decision on their side. Please update the posting as to what they say as I am curious about the topic.
    Many folks have largely abandoned these java-based, outdated, OGC converters. Feel free to search the forum for complaints, myself being one of the complainers. When you said "a large amount of code already depends" on WKT, my first thought was that must be really slow. Writing your own SDO to WKT converter in PLSQL is really easy and I believe that's what most of us have done. The other direction is more challenging but doable - I need to rewrite mine but its works well enough for straightforward stuff.
    Cheers,
    Paul

  • Scientific notation SSIS

    Hi,
    the situation is that I receive a column on excel, with format nvarchar, for example "8.0442 E +18" and I wanted to get "8044200073000360000" how do this transformation in ssis. From excel to sql server, using -> SSIS.
    the format is varchar (on excel), but I wanted to make an automated ETL, without going to excel every month to change format column. If I made derive a column "(DT_NUMERIC, 19.0)Value" has not worked for me. I tried to change from 19 to 35 but also
    gives error.
    David

    Its a float data and represents approximate numeric. As such I dont think you will able to get full
    precision as you like. Try using
    datatype like Decimal (38,2) in
    SQLServer
    Also try this
    http://www.sentientbeings.com/2012/03/how-to-stop-ssis-from-converting-text-to-scientific-notation-when-importing-from-excel/
    Please Mark This As Answer if it helps to solve the issue
    Visakh ---------------------------- http://visakhm.blogspot.com/ https://www.facebook.com/VmBlogs

  • TO_CHAR not Scientific Notation

    I want to convert a number to a string but guarantee that the result will NOT be in scientific notation.
    TO_CHAR(num, '9999999999.99999999999999') is not very convenient since the data type of the number is BINARY_DOUBLE and I will not know how many significant figures the number will have.

    user3975338 wrote:
    So is it safe to say there there is no built in feature that would ever output a the numeric string
    '0.00000000000000000000000000000000000000000000000000000000000000000000000000000009'The scientific notation is only a matter of how the particular interface is displaying the number and how your NLS settings are for converting automatically between numbers and varchar.
    e.g. in SQL*Plus you can change the format of a column easily...
    SQL> ed
    Wrote file afiedt.buf
      1  with t as (select cast(1.0000000000000001E-001 as binary_double) as dbl from dual union all
      2             select 4.0144896E+008 from dual union all
      3             select 3.0976E+005 from dual union all
      4             select 2.78784E+006 from dual union all
      5             select 6.4E+001 from dual union all
      6             select 2.7878400000000001E+003 from dual union all
      7             select 2.4909766860524436E-011 from dual union all
      8             select 1.0000000000000001E-001 from dual union all
      9             select 7.7160493827160492E-005 from dual union all
    10             select 6.9444444444444436E-004 from dual)
    11  --
    12  select dbl, dbl2, length(trim(dbl2)) as ldbl
    13  from (
    14    select dbl, rtrim(rtrim(to_char(dbl,'99999999999999990.999999999999999999999999999'),'0'),'.') as dbl2
    15    from t
    16*   )
    SQL> /
           DBL DBL2                                                 LDBL
      1.0E-001                  0.10000000000000001                   19
    4.014E+008          401448960                                      9
    3.098E+005             309760                                      6
    2.788E+006            2787840                                      7
      6.4E+001                 64                                      2
    2.788E+003               2787.8400000000001                       18
    2.491E-011                  0.000000000024909766860524436         29
      1.0E-001                  0.10000000000000001                   19
    7.716E-005                  0.000077160493827160492               23
    6.944E-004                  0.00069444444444444436                22
    10 rows selected.
    SQL> col dbl format 999999999990.9999999999999999999999999999999
    SQL> /
                                              DBL DBL2                                                 LDBL
                0.1000000000000000100000000000000                  0.10000000000000001                   19
        401448960.0000000000000000000000000000000          401448960                                      9
           309760.0000000000000000000000000000000             309760                                      6
          2787840.0000000000000000000000000000000            2787840                                      7
               64.0000000000000000000000000000000                 64                                      2
             2787.8400000000001000000000000000000               2787.8400000000001                       18
                0.0000000000249097668605244360000                  0.000000000024909766860524436         29
                0.1000000000000000100000000000000                  0.10000000000000001                   19
                0.0000771604938271604920000000000                  0.000077160493827160492               23
                0.0006944444444444443600000000000                  0.00069444444444444436                22
    10 rows selected.
    SQL>... see ... no scientific notation any more.

  • Float Data Value and Scientific Notation

    Hello All,
    SQL Server converts some of the float value into scientific notation for example 0.00001 will be stored as
    1E-05.
    Is there any simple method\formula\threshold to precisely tell when some particular value will be converted to scientific notation?
    Also I think oracle store same value above i.e. 0.00001 as it is with float data type but not the case with SQL Server. Any reason for the same?
    Thanks in Advance.
    -Malkesh

    Thanks Erland.
    I got your point that internal storage as you mentioned will be 53 bit and 11 bit exponent of 2. However my question remains the same that is there any method\threshold from which we can say that after this numeric value stored data will be represented in
    scientific notation or any rule of thumb? For example
    drop
    table #t
    CREATE
    TABLE #T (T1
    FLOAT)
    INSERT
    INTO #T (T1)
    SELECT 0.000001
    INSERT
    INTO #T (T1)
    SELECT 0.00001
    INSERT
    INTO #T (T1)
    SELECT 0.0001
    INSERT
    INTO #T (T1)
    SELECT 0.001
    INSERT
    INTO #T (T1)
    SELECT 0.01
    INSERT
    INTO #T (T1)
    SELECT 0.1
    INSERT
    INTO #T (T1)
    SELECT 1.
    INSERT
    INTO #T (T1)
    SELECT 1.0
    INSERT
    INTO #T (T1)
    SELECT 1.01
    INSERT
    INTO #T (T1)
    SELECT 1.001
    INSERT
    INTO #T (T1)
    SELECT 1.0001
    INSERT
    INTO #T (T1)
    SELECT 1.00001
    INSERT
    INTO #T (T1)
    SELECT 1.000001
    INSERT
    INTO #T (T1)
    SELECT 1.0000001
    INSERT
    INTO #T (T1)
    SELECT 1.00000001
    INSERT
    INTO #T (T1)
    SELECT 1.000000001
    INSERT
    INTO #T (T1)
    SELECT 1.0000000001
    INSERT
    INTO #T (T1)
    SELECT 1.00000000001
    INSERT
    INTO #T (T1)
    SELECT 1.000000000001
    INSERT
    INTO #T (T1)
    SELECT 1.1
    INSERT
    INTO #T (T1)
    SELECT 10.1
    INSERT
    INTO #T (T1)
    SELECT 100.1
    INSERT
    INTO #T (T1)
    SELECT 1000.1
    INSERT
    INTO #T (T1)
    SELECT 10000.1
    INSERT
    INTO #T (T1)
    SELECT 100000.1
    INSERT
    INTO #T (T1)
    SELECT 1000000.1
    INSERT
    INTO #T (T1)
    SELECT 10000000.1
    INSERT
    INTO #T (T1)
    SELECT 100000000.1
    INSERT
    INTO #T (T1)
    SELECT 1000000000.1
    INSERT
    INTO #T (T1)
    SELECT 10000000000.1
    INSERT
    INTO #T (T1)
    SELECT 100000000000.1
    INSERT
    INTO #T (T1)
    SELECT 1000000000000.1
    SELECT T1
    FROM #T
    Here you can see value < 0.0001 i.e. 0.00001 and 0.000001 both are in scientific notation. So which rule or formula drives this behavior that is what my question is. Sorry I am somewhat poor in mathematics fundamentals So if you can make it simple.
    Thanks Again.

  • BIGINT in scientific notation

    Hi,
    New here and new to CF8. I'm using MySQL 5.0.51b with the
    latest JDBC connector and am getting unsigned BIGINT columns larger
    than 10^12 back in scientific notation instead of a whole number.
    Here's an example:
    <cfquery name="get_bigint" datasource="ds">
    select cuid,convert(cuid,signed) as c_cuid
    from ctable
    where id=17
    </cfquery>
    <cfdump var="#get_bigint#">
    cuid is an unsigned BIGINT in ctable. In the CF dump, cuid is
    displayed in scientific notation and c_cuid is displayed as a whole
    number. If I try to use cuid, say as a URL parameter, it also ends
    up in scientific notation, which is obviously undesirable. Is there
    a configuration setting I need to change somewhere or is the CF /
    JDBC way to deal with this to use CAST / CONVERT on BIGINT columns
    to ensure they stay in whole number format?
    Thanks

    Hi,
    the function FIXED (<your expression>, <number of digits) may help
    Elke

Maybe you are looking for