MeridianMERIDIAN

Decimal Number

representation.numeric.decimal_number

Number with decimal point (e.g., 3.14, -0.5, 1000.001), optionally with scientific-notation suffix (e.g., 6e-04, 1.5E+10). String representation of a floating-point number. Transforms to DOUBLE.

Worked samples

DuckDB 1.5.5 · finetype 0.6.64

ValueAs DOUBLEfractional_partinteger_part
3.143.141400003
-0.5-0.5500000-1
1000.0011000.00110001000
0.00010.00011000
6e-040.00066000
1.5E+1015000000000.0015000000000

Shape

Pattern
^-?[0-9]+(\.[0-9]+)?([eE][+-]?[0-9]+)?$
ValueLengthShape
3.144matches
-0.54matches
1000.0018matches
0.00016matches
6e-045matches
1.5E+107matches
3-144rejected: separator swapped

Told apart

Going the other way, this type's own rule accepts 4 of 4 samples of Integer Number, 1 of 4 samples of Percentage and 4 of 4 samples of Scientific Notation.

The dedicated representation.numeric.scientific_notation type still exists and remains the preferred classification when a whole column is in scientific form; this widening only ensures a mostly-decimal column with some scientific-notation values doesn't get misclassified out of decimal_number on a single failing row.

Background

Origin

The 22nd General Conference on Weights and Measures declared in 2003 that the symbol for the decimal marker shall be either the point on the line or the comma on the line.[1][2] In 1958, disputes between European and American delegates over the correct representation of the decimal separator nearly stalled the development of the ALGOL programming language.[2] Most computer languages and standard data formats, among them C, Java, Fortran and CSS, specify a dot as the decimal separator.[2]

The E notation for a power of ten, as in 6.022E23, comes from Fortran and was present in the first version released for the IBM 704 in 1956.[3] In E notation the letter E or e stands for exponent and is read as times ten raised to the power of.[3]

The first IEEE standard for floating-point arithmetic, IEEE 754-1985, was published in 1985.[4] The current version of the IEEE floating-point standard, IEEE 754-2019, was published in July 2019.[4]

Use

RFC 8259, the JSON specification, defines a number as an optional minus sign, an integer part, an optional fraction and an optional exponent.[5] RFC 8259 says that an exponent part begins with the letter E in uppercase or lowercase, which may be followed by a plus or minus sign.[5] RFC 8259 does not allow leading zeros in a JSON number.[5] RFC 8259 does not permit numeric values such as Infinity and NaN.[5] The Frictionless Table Schema number type allows an optional exponent made of an E followed by an optional + or - sign and one or more decimal digits.[6]

Python's documentation shows that 0.1 + 0.1 + 0.1 == 0.3 evaluates to False.[7] IEEE 754 binary64 values contain 53 bits of precision, according to Python's documentation.[7] DuckDB's documentation says its DOUBLE type typically has a range of around 1E-307 to 1E+308 with a precision of at least 15 digits.[8] DuckDB's documentation advises using the DECIMAL data type for exact storage of numbers with a known number of decimal digits, such as monetary amounts.[8] DuckDB's default DECIMAL width and scale, when none are given, is DECIMAL(18, 3).[8] A cast to a double is the right default for measurements, coordinates and scores, but money, quantities with a fixed number of places and identifiers that merely look numeric deserve a DECIMAL or a string instead. (Meridian's view)

Where you'll meet it

The US Geological Survey's CSV feed of significant earthquakes writes latitude, longitude and magnitude as decimal numbers with a point as the separator.[9]

Detection notes

v1 migration: Was numeric.decimal_number. Transforms to DOUBLE. Decompose extracts integer and fractional parts. v0.6.20: Validator widened to accept scientific-notation suffix (precision corpus iter 1, ac-10). The dedicated representation.numeric.scientific_notation type still exists and remains the preferred classification when a whole column is in scientific form; this widening only ensures a mostly-decimal column with some scientific-notation values doesn't get misclassified out of decimal_number on a single failing row.

In Meridian's open data

Use it

CLI · DuckDB
$ finetype infer -i "3.14" --mode column
→ representation.numeric.decimal_number

SELECT ft_infer('3.14');
-- → 'representation.numeric.decimal_number'
Cast expression
CAST({col} AS DOUBLE)

Schema

https://meridian.online/schemas/representation.numeric.decimal_number · Frictionless type number

finetype taxonomy representation.numeric.decimal_number -o json-schema

Aliases

decimalfloatfloating_point

Type Registry