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 '+'.

Similar Messages

Formatting Doubles with Scientific Notation Depending on Exponent Size

Hi there. I was just wondering if there was a better way to do the following:
DecimalFormat fmt;
if (v>=1.0E9 || v<=-1.0E9 || (v>-1.0E-8 && v<1.0E-8 && v!=0.0 && v!=-0.0))
fmt = new DecimalFormat("0.########E0");
else fmt = new DecimalFormat("0.########");
return fmt.format(v);

I'm not an expert on DecimalFormat, so I may have missed something, but the only improvement I can see is to remove the v!=-0.0 check. 0.0==-0.0, so it's unnecessary.

DecimalFormat issues/Scientific notation

I have 2 issues with formatting numbers with scientific notation via the DecimalFormat class
ISSUE 1: Disregard of the number of MAXIMUM FRACTOINAL DIGITS
     in the code:
                                 NumberFormat nf = NumberFormat.getInstance();
                                DecimalFormat df = (DecimalFormat)nf;
                                df.applyPattern("#00.#E0");
                                System.out.println( df.format(12345678));
                                   it printed: 12.35E6
     Why does it violate my request for one significant digit beyond the decimal
     point?. (Note, this problem
only seems to occur when when the sum of MAX integer and Max fractional
digits in my pattern is 4)
ISSUE 2:
Number of significant digits displayed:- I really just need a sanity check on this one
The 1.4.2 API for DecimalFormat states
?     The number of significant digits in the mantissa is the sum of the minimum integer and
maximum fraction digits, and is unaffected by the maximum integer digits. For example,
12345 formatted with "##0.##E0" is "12.3E3". To show all digits, set the significant digits
count to zero. The number of significant digits does not affect parsing.
I tried this ? it displays 123.45E3, or 5 significant digits? Looks like the number of significant digits
is MAX integer + MAX fractional digits in a pattern. Am I correct (and the API not correct)?
thanks
carol

Thanks. I'm assuming you're responding to issue #1. I did try it, and it worked, as expected. I never seem to have an issue when all symbols
preceding the decimal are 0. My issue, I suppose, is the inconsistency of how the formatting
works, when it comes to the number of fractional digit positions. Most of the times it 'behaves' and
only prints out the number of digits you ask, but sometimes it does not.
I've tested quite a few combinations. I'm attaching the code (in case you need help sleeping tonight).
The only 'pattern' I've noticed is that this issue only occurs when the total number of digits specified
in the pattern (before and after decimal) is 4. (exception ... if all digits specified before the decimal
are 0s, this never occurs)
I know a simple solution ... make sure I never have
a total of 4 #s and 0s in my pattern. But again, my question is why ... and/or ... does this type of
inconsistency crop up elsewhere.
import java.util.*;
import java.text.*;
public class x {
     public static void main(String [] args) {
          NumberFormat nf = NumberFormat.getInstance();
          DecimalFormat df = (DecimalFormat)nf;
          // these 3 work like I'd expect: 3 digits to the left, one to the right w/ rounding
          // signif digits = max int digits + max fractional digits
          df.applyPattern("000.#E0");
          System.out.println( df.format(12345678)); // 123.5E5
          df.applyPattern("00.#E0");
          System.out.println( df.format(12345678)); // 12.3E6
          df.applyPattern("0.#E0");
          System.out.println( df.format(12345678)); // 1.2E7
          // signif digits = TOTAL int digits + max fractional digits
     System.out.println("X");
          df.applyPattern("###.#E0");                    // how did it decide to place decimal where it did?
          System.out.println( df.format(12345678)); // 12.35E6    // why did it violate my "1 max fractional digit"
                                             // request? I would have expected 123.5E5
          df.applyPattern("##.#E0");
          System.out.println( df.format(12345678)); // 12.3E6
          df.applyPattern("#.#E0");
          System.out.println( df.format(12345678)); // 1.2E7
          //signif digits - TOTAL int digits + max fractional didgits
     System.out.println("");
     System.out.println("XXXXXXXX");
          df.applyPattern("#000.#E0");
          System.out.println( df.format(12345678)); // 1234.6E4
          df.applyPattern("#00.#E0");
          System.out.println( df.format(12345678)); // 12.35E6      // how did it decide to place decimal where it did?
                                             // why did it violate my "1 max fractional digit"
                                             // request? I would have expected 123.5E5
          df.applyPattern("#0.#E0");
          System.out.println( df.format(12345678)); // 12.3E6
          // significant digtis = TOTAL int digits + max fractional digits
     System.out.println("");
          df.applyPattern("###0.#E0");
          System.out.println( df.format(12345678)); // 1234.6E4
          df.applyPattern("##0.#E0");                    // how did it decide to place decimal where it did?
          System.out.println( df.format(12345678)); // 12.35E6     // why did it violate my "1 max fractional digit"
                                             // request? I would have expected 123.5E5
          System.out.println( df.format(12345678)); // 12.35E6
          df.applyPattern("##.#E0");
          System.out.println( df.format(12345678)); // 12.3E6
//API example from DecimaFormat RE Scientific Notation.. api says this will print 12.3E3
          df.applyPattern("###.##E0");
          System.out.println( df.format(12345)); //12.345E3   //violates max fractiona digit request
//NOTE DOCS ARE WRONG ... the number of significant digits is = to max integer digits (number of # and 0 prior
// to decimal point) PLUS max number of digits after the decimal point... NOT Min. Integer digits + Max fractional digits
          // suggested pattern
          df.applyPattern("000000.##E0");
          System.out.println( df.format(12345678)); //123456.78

Calculator.app Version 4.5.3 (99.2) and Scientific Notation

I want to enter a number with scientific notation.
2.71e1 doesn't return 27.1, but rather 0.999...
It seems that Calculator.app is dividing by e.
This is not a common operation.
2.71E1 gives 27.1great! But ...
2.71E-1 does not return 0.271 neither does
2.71E(-1)
I have yet to figure out how to use negative exponents in Scientific notation.
This seems to be a bug in Calculator.app Version 4.5.3 (99.2)

All my spaces were deleted.
Take two.
My input ======= Calculator
2 ============ 2
2. ============ 2.
2.7 =========== 2.7
2.7E ========== 2.7 E 0
2.7E- ========== 2.7 (and the small - subscript indicating a negative number)
2.7E-1 ========= 1 (and the small - subscript indicating a negative number)
Now hitting enter === 1.7 (it appears to have subtracted 1 from 2.7)
Do our version of Calculator match?
Thanks for being interested.

DecimalFormat scientific notation if necessary

I would like to find a way to output a double value in a way that uses scientific notation only if the number of digits output would be at least 15. For instance, the value 12345000000000000 should be output as 1.2345E16, but 12345000 would not be output in scientific notation (and the same logic if the value is < 0). Is this possible with the DecimalFormat class?
I tried using String.format("%.15g", value), but that always displays trailing 0s to fill the significant digits (e.g. 12.345 outputs "12.3450000000000"). I don't want it to output the trailing 0s.

I would like to find a way to output a double value
in a way that uses scientific notation only if the
number of digits output would be at least 15. For
instance, the value 12345000000000000 should be
output as 1.2345E16, but 12345000 would not be output
in scientific notation (and the same logic if the
value is < 0). Is this possible with the
DecimalFormat class?
I tried using String.format("%.15g", value), but that
always displays trailing 0s to fill the significant
digits (e.g. 12.345 outputs "12.3450000000000"). I
don't want it to output the trailing 0s.With DecimalFormat ( http://java.sun.com/j2se/1.5.0/docs/api/java/text/DecimalFormat.html )
you can format the number in scientific notation but to control which numbers are formatted I think you must write some sort of if else

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

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.

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

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

Adding scientific notation

How do I write in Scientific notation, with numbers in
subscripts below element letters?

Hi Rachel,
How weird.. I just tried it out and just like you say it
doesn't work when you view the project.
The problem/bug seem to occur when using transparent text
boxes. If I add sub/superscript in a text caption using any of the
predefined text boxes it works fine for me.
I assume that you are using transparent text boxes as well so
to fix your problem do the following:
Insert a bulletpoint in your text caption. You can just add a
few blank lines between your text and the bullet point and then
adjust the size of the text box so that the bullet is not visible.
That takes care of the problem for me and as an added bonus
you get much better text quality by adding that bullet point.
Best regards,
Michael

Decimal Format and Scientific Notation

I am trying to print numbers in scientific notation using the Decimal Format class. What follows is a simple test program I wrote to find the bug. So far, I have not found a solution.
import java.text.*;
public class formatted {
public static void main (String Arguments[]) {
DecimalFormat form = new DecimalFormat("0.###E0");
double numb = 123456.789;
System.out.println("Nuber is: " +
form.format(numb));
The output of this program is... Nuber is: 123456E
The output is the same if numb is an int, float, or double. If I format the number as "#####.0" or "#####.00" the output is correct. I think that I am following the rules for formatting a number in scientific notation as the process is outlined in the documentation (provided below).
***** From Decimal Format under Scientific Notation ***
Numbers in scientific notation are expressed as the product of a mantissa and a power of ten, for
example, 1234 can be expressed as 1.234 x 10^3. The mantissa is often in the range 1.0 <= x < 10.0,
but it need not be. DecimalFormat can be instructed to format and parse scientific notation only via a
pattern; there is currently no factory method that creates a scientific notation format. In a pattern,
the exponent character immediately followed by one or more digit characters indicates scientific
notation. Example: "0.###E0" formats the number 1234 as "1.234E3".
Anyone understand how the short program is incorrectly written?
Marc

The problem is
format = "0.###E0"
input number = 123456.789
output = 123456E (not scientific notation!)
This is not scientific notation at all. There is no decimal point given and no value in the exponent.
I understand entirely that by adding more #'es will provide more precision. The bug I have is the output is not printed in the scientific format; other formats work.
MArc

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

Text code interpreted as scientific notation

I have an http service returning xml to populate a data grid.
The grid columns are tied to element attributes. One of these
columns is a simple text code, like a product code. When this
product code "looks like" scientific notation (e.g. "3E5"), the
grid is displaying "300000" instead of the code. Is there a way
somehow to tell the grid that this is a text field, and not a
number? How do you turn this off? I am rendering the column with a
label, but it doesn't make any difference. Thanks for any
tips.

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

External table.How to load numbers (decimal and scientific notation format)

Hi all, I need to load inside an external table records that contain 7 fields. The last field is called AMOUNT and it's represented in some records with the decimal format, in others records with the scientific notation format as, for example, below:
CY001_STATU;2009;Jan;11220020GR;'03900;CYZ900;-9,99999999839929e-03
CY001_STATU;2009;Jan;11200100;'60800;CYZ900;41380,77
The External table's script is the following:
CREATE TABLE HYP_DATA
COUNTRY VARCHAR2(50 BYTE),
YEAR VARCHAR2(20 BYTE),
PERIOD VARCHAR2(20 BYTE),
ACCOUNT VARCHAR2(50 BYTE),
DEPT VARCHAR2(20 BYTE),
ACTIVITY_LOC VARCHAR2(20 BYTE),
AMOUNT VARCHAR2(50 BYTE)
ORGANIZATION EXTERNAL
( TYPE ORACLE_LOADER
DEFAULT DIRECTORY HYP_DATA_DIR
ACCESS PARAMETERS
( RECORDS DELIMITED BY NEWLINE
BADFILE 'HYP_BAD_DIR':'HYP_LOAD.bad'
DISCARDFILE 'HYP_DISCARD_DIR':'HYP_LOAD.dsc'
LOGFILE 'HYP_LOG_DIR':'HYP_LOAD.log'
SKIP 0
FIELDS TERMINATED BY ";"
MISSING FIELD VALUES ARE NULL
REJECT ROWS WITH ALL NULL FIELDS
"COUNTRY" Char,
"YEAR" Char,
"PERIOD" Char,
"ACCOUNT" Char,
"DEPT" Char,
"ACTIVITY_LOC" Char,
"AMOUNT" Char
LOCATION (HYP_DATA_DIR:'Total.txt')
REJECT LIMIT UNLIMITED
NOPARALLEL
NOMONITORING;
If, for the field AMOUNT I use the datatype VARCHAR (as above), the table is loaded but I have some records rejected, and all these records contain the last field AMOUNT with the scientific notation as:
CY001_STATU;2009;Jan;11220020GR;'03900;CYZ900;-9,99999999839929e-03
CY001_STATU;2009;Feb;11220020GR;'03900;CYZ900;-9,99999999839929e-03
CY001_STATU;2009;Mar;11220020GR;'03900;CYZ900;-9,99999999839929e-03
CY001_STATU;2009;Dec;11220020GR;'03900;CYZ900;-9,99999999839929e-03
All the others records with a decimal AMOUNT are loaded correctly.
So, my problem is that I NEED to load all the records (with the decimal and the scientific notation format) together (without records rejected), but I don't know which datatype I have to use for the AMOUNT field....
Anybody has any idea ???
Any help would be appreciated
Thanks in advance
Alex

@OP,
What version of Oracle are you using?
Just cut'n'paste of you script and example woked FINE for me.
however my quation is... An external table will LOAD all data or none at all. How are you validating/concluding that...
I have some records rejected, and all these records contain the last field AMOUNT with the scientific notation
select * from v$version where rownum <2;
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi
select * from mydata;
CY001_STATU     2009     Jan     11220020GR     '03900     CYZ900     -9,99999999839929e-03
CY001_STATU     2009     Feb     11220020GR     '03900     CYZ900     -9,99999999839929e-03
CY001_STATU     2009     Jan     11220020GR     '03900     CYZ900     -9,99999999839929e-03
CY001_STATU     2009     Jan     11200100     '60800     CYZ900     41380,77
CY001_STATU     2009     Mar     11220020GR     '03900     CYZ900     -9,99999999839929e-03
CY001_STATU     2009     Dec     11220020GR     '03900     CYZ900     -9,99999999839929e-03
CY001_STATU     2009     Jan     11220020GR     '03900     CYZ900     -9,99999999839929e-03
CY001_STATU     2009     Jan     11200100     '60800     CYZ900     41380,77MYDATA table script is...
drop table mydata;
CREATE TABLE mydata
COUNTRY VARCHAR2(50 BYTE),
YEAR VARCHAR2(20 BYTE),
PERIOD VARCHAR2(20 BYTE),
ACCOUNT VARCHAR2(50 BYTE),
DEPT VARCHAR2(20 BYTE),
ACTIVITY_LOC VARCHAR2(20 BYTE),
AMOUNT VARCHAR2(50 BYTE)
ORGANIZATION EXTERNAL
( TYPE ORACLE_LOADER
DEFAULT DIRECTORY IN_DIR
ACCESS PARAMETERS
( RECORDS DELIMITED BY NEWLINE
BADFILE 'IN_DIR':'HYP_LOAD.bad'
DISCARDFILE 'IN_DIR':'HYP_LOAD.dsc'
LOGFILE 'IN_DIR':'HYP_LOAD.log'
SKIP 0
FIELDS TERMINATED BY ";"
MISSING FIELD VALUES ARE NULL
REJECT ROWS WITH ALL NULL FIELDS
"COUNTRY" Char,
"YEAR" Char,
"PERIOD" Char,
"ACCOUNT" Char,
"DEPT" Char,
"ACTIVITY_LOC" Char,
"AMOUNT" Char
LOCATION (IN_DIR:'total.txt')
REJECT LIMIT UNLIMITED
NOPARALLEL
NOMONITORING;vr,
Sudhakar B.

How can I get Numbers 3.2 to recognise 1e-5 as scientific notation?

I just changed from Numbers '09 (2.3) to Number 3.2 on Mavericks (OS X 10.9.3) and the new version doesn't seem to recognise "e" or "E" as scientific notation. When I set the cell format to scientific and type "0.0015", Numbers returns "1.5×10^-03". I would however prefer to obtain "1.5e-3". And vice versa: if, after setting the cell format to scientific, I type "1.5e-3", it automatically formats the cell as text and I can't get it to recognise it as scientific notation. With "E" instead of "e", the problem is exactly the same. Does anyone know how I can change this setting? I already tried to search for an answer to my question, but couldn't find anything...

if, after setting the cell format to scientific, I type "1.5e-3", it automatically formats the cell as text and I can't get it to recognise it as scientific notation.
I can't duplicate the problem here, either when the cells are formatted as Automatic or as Scientific:
When you type 1.5e-3 are you making sure not to enter a space after the e? (When I type a space the cell automatically formats as Text.)
SG

DecimalFormat bug (?) with scientific notation

Similar Messages

Maybe you are looking for