`NaN`s and `infinity`s are displaying as null
See original GitHub issueContext
NaN
s and ±Infinity
s (possible float values in PostgreSQL) are displayed as null values, leading to problems with summaries (e.g., max(column) will strangely say null
is the largest value of a dataset). Even further, they cause the widgets to break.
Steps to Reproduce
- Import a dataset (which is a CSV but GitHub won’t let me do CSVs) with
NaN
s andInfinity
s: inf-nan-values.txt - Change the column type of column
val
to ‘number’ in the Builder - Observe that the
val
column has values1.2
,null
, andnull
. - Run this query to see if those values are actually null-valued:
SELECT val is null FROM inf_nan_values
- Observe that the results are all
false
, indicating that the values are not null valued. - Casting
val
to text producesinfinity
andNaN
. - Calculate the max of the dataset produces
null
, but casting to text givesNaN
again. - Create a widget on the column
val
and observe that the widget does not work.
Current Result
Infinity
and NaN
are shown as Null
when they are actually not and produces different information when used in calculations. These values break the widgets.
Expected result
The values of infinity
and NaN
are displayed in the builder what they really are to avoid confusion. These values should also not break the widgets, but the user should be able to remove these values easily so that the widgets can work as expected. For example, a broken widget could say ‘Cannot make widget because column
has values of Infinity’.
Browser and version
Chrome 58.0.3029.110 (64-bit), macOS 10.12.4
.carto file
None, but this ‘csv’: inf-nan-values.txt
Additional info
Information can be displayed to communicate that there are NaNs and Infinitys in the dataset, and that they are removed when constructing the widgets. NumPy has very good behavior for dealing with these two values.
Issue Analytics
- State:
- Created 6 years ago
- Comments:14 (14 by maintainers)
Top GitHub Comments
Acceptance plan:
CDB_CreateOverviews
(the dataset well need enough rows for the overviews to be populated)I’m moving this to deploy, since the acceptance tests are successful regarding the fixes done here to SQL-API and WIndshaft-Cartodb and having this in production is a big improvement over the current situation (where widgets break in the presence of NaNs, etc).
The issues revealed during acceptace affecting various CARTO components can be handled independently in separate tickets.