Result in scientific notation

Hi,
We migrated an instance from 7.3 to 7.6 x64 (no unicode) and I get an expression result in scientific notation.
How can I make the notation use decimal? I cannot find anything in the documentation.
sqlcli
EXPRESSION1
1.3192E7
1 row selected (449 msec)
Cheers,
Jan

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

Similar Messages

  • 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.

  • Calculator: removing scientific notation in results?

    This seems like it must be a bug or a corrupted app, but I'd just like to confirm: with the calculator in "basic" mode, dividing two numbers which only have one significant digit returns a result like so: 1/3000 = 0.000333 (the setting for decimal places seems to be irrelevant).
    However, changing either number to have more than one significant digit returns the result in scientific notation, like so: 1/3100 = 3.225806e-04.
    Can anyone else duplicate this or help me correct it? It's obnoxious to have to keep adjusting the numbers. And yes, I realize that means my math skills suck. Thanks in advance.

    Bumpty-bump. Can anyone at least confirm or deny? TIA.

  • 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

  • Powershell / Scientific Notation Woes / Formatting Output to Live Excel Sheet

    I have a WMI query in a script that dumps machine information to a live excel sheet.
    I find when I query the model # of the machine using (this line of code from the script):
    $Sheet.Cells.Item($count,4) = (Get-WmiObject win32_computersystem -ComputerName $computer).Model
    The output almost always changes into Scientific Notation, because this is a typical model number :   "3500-E52"
    Is there a way to modify the formatting of the:
    $Sheet.Cells.Item($count,4)
    so that Excel uses "text" formatting for that cell?  I know you can change the fonts etc... but have not been lucky in finding a powershell > excel reference
    that explains how to change a cell or column's formatting beyond the basics.
    I have seen recommendations to others to dump the results queries to a CSV first, and then import into Excel (which would allow a manual change of that column's format).  I'm just
    hoping to bypass the extra "hands on" and format more directly to a sheet in Excel.
    If .csv is the best way to go, I'll muddle through it and change the code.
    Any help is greatly appreciated.
    Ben

    $sheet.Cells(1,1).NumberFormat
    = "@"
    ¯\_(ツ)_/¯

  • Scientific Notation to Integer?

    I have a string like 1.780657E7 that I need to convert to an integer. I think that might be too big for Integer, so maybe BigInt would be better.
    Anyway, I can't figure out how to do this! I guess I could write my own method, but I'm sure it's already out there somewhere. I'm pretty new to Java.
    Thanks a lot,
    - Andrew.

    A small exegesis of prometheuzz's perfectly accurate, if slightly terse solution.
    Scientific notation is assumed to be floating-point. You must therefore parse a scientific-notation string using Float.parseFloat() or Double.parseDouble() and "integerise" the result if an integer is what you want.
    The last line is to show that your sample number is easy to fit in an int variable.

  • Why Number displayed in  scientific notation

    I have tried to add two numbers and got a result displayed in scientific notation.
    Then I have used the 'decimalformat()' function and result is wrong.
    How can display the correct result. Please help
    Please see the code I have used
    <cfset N1=1>
    <cfset N2=9999999999999899999999>
    <cfset RESULT = N1+ N2>
    <cfoutput>
    #RESULT#
    <br />
    #decimalformat(RESULT)#
    </cfoutput>
    result :
    1E+022
    92,233,720,368,547,760.00
    Thanks in advance

    I think in floating point math adding 1 to 9999999999999899999999 is going to be a meaningless operation as by the time one converts 1 to a floating point of the scale & precision needed to represent 9999999999999899999999, it's going to lose any significance (ie: it's going to basically be represented as zero).
    You'll need to do a search on how to deal with numbers of very high precision & scale.  I don't have any code to hand.  Have you done any of your own investigation on how to deal with this?
    Adam

  • 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.

  • Formating scientific notation

    Hi,
    I'm working with a small program where at one point a number, in scientific notation will need to be formated into a string containing plane numbers.
    I use the code below, and it works in up to large numbers where the formatting doesen't do aything at all.
    String InputValue = "7,584995286E7";
    NumberFormat format = NumberFormat.getNumberInstance();
    Number number = format.parse(InputValue);
    String OutputValue = number.toString();
    System.out.println(OutputValue);The example above gives the result input back as output value: 7.584995286E7
    With the value 7,584995286E6 the result is: 7584995.286 just as I want it to work.
    What can I do to solve this?
    All help is appreciated.
    Thanks
    /H�kan

    Hi ,
    Below is the code posted by you.
    String InputValue = "7,584995286E7";
    NumberFormat format = NumberFormat.getNumberInstance();
    Number number = format.parse(InputValue);
    String OutputValue = number.toString();
    System.out.println(OutputValue);Add these two methods, and you will get the code working as you needed.
    format .setMaximumFractionDigits(3)
    format .setMinimumFractionDigits(3);
    Best regards
    Aneesh A.V

  • Calculator and Scientific Notation

    My Calculator App seems to randomly switch back to scientific notation instead of displaying results in regular x.xx format.
    I tried deleting the com.apple.calculator.plist file and then relaunching Calculator but that didn't work.
    Any other suggestions on how to get the calculator app back to displaying results in normal (non-scientific notation) mode?
    thanks

    Then, I'm at a loss. Mine only shows scientific notation when the value exceeds whatever's set as the number's max range. You might want to peruse Calculator's help files.

  • Preventing automatic scientific notation conversion for excel output?

    I have a column in a report that contains a mixture of numbers and letters and hyphens. If the only letter is E, then I get scientific notation instead of the actual text when I run the report for excel output and open it in excel.
    For example:
    185701E-02 becomes 1.86E+03
    4962E6 becomes 4.96E+09
    Any ideas how to fix or work around this in the template, data definition, or excel config?
    Thanks,
    Kevin

    I tried pre-pending an apostrophe in the SQL and in the rtf template to indicate to excel that it is a text field, but this just resulted (not surprisingly) in '185701E-02 instead of 185701E-02

  • How to input a number of scientific notation in equations

    On new version of Numbers, I try to input a equation, such as "=A1 x 6.02E+23" , but I cannot input the equation, because "E" regarded as "columnE".
    Please tell me how to imput a a number of scientific notation in equations.

    You can override the parser using escape. This might be new to version 3.2, I don't remember it in 3.0 or 3.1. It used to override it until you hit Enter, then it would revert back into a cell reference. Now it is working correctly.
    = A1*6.02E (then hit ESC) 23
    The result will be
    =A1×6.02E+23

  • 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.

  • Int printing out as scientific notation

    maybe doing something stupid here but I can't seem to pick it up.
    I have a Window that calls a subclass to display a calculator, and then returns the final value to the Window, if I input 10 digits it prints on as a 12345678E5
    something like that.
    Anywho here's the two methods that deal with value in the subclass( calculator )
    public int ReturnNumber(){//the method that will return the value from the keyboard
       int final_number = Integer.parseInt(number); 
        return final_number;   // returns value to question screen
      private void NextButtonActionPerformed (java.awt.event.ActionEvent evt) {
       if ( value.length() != allowable_answers[currentQuestionNumber] ){
                     JOptionPane.showMessageDialog(this, "Please make a valid entry.", "Invalid",
                     JOptionPane.WARNING_MESSAGE );
                     value.replace(0,counter,""); 
                     jTextField1.setText( null );
                     return;
        else {
                number = value.toString();
               setVisible(false);
               frame.final_number = ReturnNumber();
               frame.userMakeSelection = true;
               frame.FinalTimer.start();
               frame.ButtonSelected();Code from window that deals with the number
    if(Numeric[currentQuestionNumber]){
                currentAnswers[currentQuestionNumber][1] = final_number;// currentAnswers is a float[][]
                numeric_question_value[currentQuestionNumber][0] = final_number;// used in poll frequency
              }// numeric is a int[]
            else
                currentAnswers[currentQuestionNumber][currentChoice] = currentChoice;Is from trying to jam an int into float?
    Any suggestions
    Jim

    Is from trying to jam an int into float?That's exactly the cause. Here are some solutions:
    - Use java.text.DecimalFormat to format the output or cast the float to an integer type when you want to print it (presicion might become a problem).
    - Keep the number in an int or long all the time. This way you'll not lose any presicion.
    Explanation can be found in the API docs of Float.toString():"If the argument is NaN, the result is the string "NaN".
    Otherwise, the result is a string that represents the sign and magnitude (absolute value) of the argument. If the sign is negative, the first character of the result is '-' ('-'); if the sign is positive, no sign character appears in the result. As for the magnitude m:
    If m is less than 10^-3 or not less than 10^7, then it is represented in so-called "computerized scientific notation." Let n be the unique integer such that 10n<=m<1; then let a be the mathematically exact quotient of m and 10n so that 1<a<10. The magnitude is then represented as the integer part of a, as a single decimal digit, followed by '.' (.), followed by decimal digits representing the fractional part of a, followed by the letter 'E' (E), followed by a representation of n as a decimal integer, as produced by the method Integer.toString(int) of one argument."

  • DecimalFormat bug (?) with scientific notation

    Hi there,
    i'm currently developing an application dealing with scientific notation of double values.
    When i was curious about forcing the DecimalFormat formatter to print an explicit sign character in the exponential part, i found this strange behaviour:
    Source code (example generated to show effect):
    import java.text.*;
    public class DecimalFormatBugTest {
    public static void main(String[] arguments) {
    DecimalFormat decimalFormat = new DecimalFormat("+0.00000E00");
    double testValue1 = 1.23456d;
    double testValue2 = 0.98765d;
    System.out.println("Test 1: " + testValue1 + " --> " + decimalFormat.format(testValue1));
    System.out.println("Test 2: " + testValue2 + " --> " + decimalFormat.format(testValue2));
    Output:
    Test 1: 1.23456 --> +1,23456E+00
    Test 2: 0.98765 --> +9,87650E-+01
    This is what i don't understand:
    The "workaround" with the explicit "+" in front of the whole format expression is already strange, but when the exponent turns negative, i have output like "E-+00" which is completly senseless.
    This output was generated using Java2 1.4.0 @ Win2k.
    Thanks for your comments!
    Greets, Marvin

    i have no clue why thats behaving that way but i can tell u another workaroun for doing what u want...
    I think u got to take that "+" sign off from the format u are giving while constructing the object DecimalFormat. Convert the result of decimalFormat.format(testValue1) into string and check for the character at 0. If its negative then prefix the result with '-' else with '+'.

Maybe you are looking for