Display format for numerical values for LSST data

XMLWordPrintable

Details

• Type: Story
• Status: Done
• Resolution: Done
• Fix Version/s: None
• Component/s:
• Labels:
• Story Points:
4
• Sprint:
SUIT Sprint 2018-09, SUIT Sprint 2018-10, SUIT Sprint 2018-11, SUIT Sprint 2018-12, SUIT Sprint 2019-01, SUIT Sprint 2019-02, SUIT Sprint 2019-03, SUIT Sprint 2019-04
• Team:
Science User Interface

Description

This ticket is to gather information for numerical data display for LSST data in SUIT.

Current Firefly displays 6 digits after decimal point by default. This may not be best for some data. We need to have a plan either specify the precision for each column in table data, or have a guideline for precision for different type of data, i.e ra, dec, magnitude, flux, error, ...

Activity

Hide
Tatiana Goldina added a comment - - edited

Currently Firefly uses %9g for FITS tables, guessing with minimum of 8 decimal digits - for VO Tables.  If the first value is in scientific format with 1 digit precision, all values will be formatted like this.

To Illustrate the problem, consider the following result table:

                                      
10.6810.68
287.3287.3
1.2e-91.2e-9
        

Displayed in Firefly, the table will look like this:

 Float Column Double Column 10.68000031 10.68000000 287.29998779 287.30000000 0.00000000 0.00000000

I see at least 3 issues here:

1. Float precision is exceeded
2. Trailing zeroes are making wrong statement about the source data precision
3. Guessing takes into account only the first non-null value. If the first value has 8 digit precision, all values will be formatted with this precision.
Show
Tatiana Goldina added a comment - - edited Currently Firefly uses %9g for FITS tables, guessing with minimum of 8 decimal digits - for VO Tables.  If the first value is in scientific format with 1 digit precision, all values will be formatted like this.    To Illustrate the problem, consider the following result table: <TABLE name="results">     <FIELD name="Float Field"  datatype="float"/>     <FIELD name="Double Field"  datatype="double"/>     <DATA>       <TABLEDATA>           <TR><TD>10.68</TD><TD>10.68</TD></TR> <TR><TD>287.3</TD><TD>287.3</TD></TR> <TR><TD>1.2e-9</TD><TD>1.2e-9</TD></TR> </TABLEDATA> </DATA> </TABLE>   Displayed in Firefly, the table will look like this: Float Column Double Column 10.68000031 10.68000000 287.29998779 287.30000000 0.00000000 0.00000000  I see at least 3 issues here: Float precision is exceeded Trailing zeroes are making wrong statement about the source data precision Guessing takes into account only the first non-null value. If the first value has 8 digit precision, all values will be formatted with this precision.
Hide
Gregory Dubois-Felsmann added a comment -

We discussed this ticket a bit in the FireflyCCB meeting today.  We are going to talk about this in the FireflyCCB-D advisory group now, possibly under a new ticket in IPAC Jira (which we'll post here).

Show
Gregory Dubois-Felsmann added a comment - We discussed this ticket a bit in the FireflyCCB meeting today.  We are going to talk about this in the FireflyCCB-D advisory group now, possibly under a new ticket in IPAC Jira (which we'll post here).
Hide
Tatiana Goldina added a comment -

When deciding how to be user friendly, we should understand, that whatever algorithm we choose to limit the precision of the displayed numbers, there will be a scenario (a set of numbers), when it fails. Hence if we are limiting the precision, we should allow to change it. And we should allow users to see the original data from the data provider. Hence, preserving the original precision in the absence of other information is the first step toward being user friendly.

We should avoid displaying wrong data or misrepresenting precision.

Loi has suggested using Java’s toString(). There is no loss of data and no trailing zeros. The disadvantage is that the formatting of a column might be inconsistent: since the trailing zeros are omitted, the numbers in a column might appear with the different number of decimal places. Also, choosing scientific or decimal format depends on the data value, see https://docs.oracle.com/javase/7/docs/api/java/lang/Double.html#toString(double)

Using Java’s toString() works very well when the input data came as strings. With binary data (like binary FITS table), we’d display the original number. For example, if 0.1 is represented by 0.0999999999999659, we’d display 0.0999999999999659. This is not user friendly, but as long as we are not displaying wrong data — and we are displaying exactly what we have received — the rounding issues can be addressed later by allowing users to adjust the format.

Show
Tatiana Goldina added a comment - When deciding how to be user friendly, we should understand, that whatever algorithm we choose to limit the precision of the displayed numbers, there will be a scenario (a set of numbers), when it fails. Hence if we are limiting the precision, we should allow to change it. And we should allow users to see the original data from the data provider. Hence, preserving the original precision in the absence of other information is the first step toward being user friendly. We should avoid displaying wrong data or misrepresenting precision. Loi has suggested using Java’s toString(). There is no loss of data and no trailing zeros. The disadvantage is that the formatting of a column might be inconsistent: since the trailing zeros are omitted, the numbers in a column might appear with the different number of decimal places. Also, choosing scientific or decimal format depends on the data value, see https://docs.oracle.com/javase/7/docs/api/java/lang/Double.html#toString(double ) Using Java’s toString() works very well when the input data came as strings. With binary data (like binary FITS table), we’d display the original number. For example, if 0.1 is represented by 0.0999999999999659, we’d display 0.0999999999999659. This is not user friendly, but as long as we are not displaying wrong data — and we are displaying exactly what we have received — the rounding issues can be addressed later by allowing users to adjust the format.
Hide
Emmanuel Joliet added a comment -

Gregory Dubois-Felsmann could you post here the CCB ticket. I can't find it. Thanks.

Show
Emmanuel Joliet added a comment - Gregory Dubois-Felsmann could you post here the CCB ticket. I can't find it. Thanks.
Hide
Xiuqin Wu [X] (Inactive) added a comment -

DM-15826 recognizes the VOTable precision for values and Firefly will respect that attribute. Specifically the following was in that ticket:

Note: values of attributes precision and width are concatenated like 'wwEn' or 'wwFn'  and stored as 'precision' in DataType, where 'ww' stands for the value from attribute width and  'En' or 'Fn' stands for value from  attribute precision. If the original precision value contains numeric digit only like '2', it is converted to be 'F2'.

Show
Xiuqin Wu [X] (Inactive) added a comment - DM-15826 recognizes the VOTable precision for values and Firefly will respect that attribute. Specifically the following was in that ticket: Note: values of attributes precision and width are concatenated like ' wwEn'  or ' wwFn'   and stored as ' precision ' in  DataType,  where 'ww' stands for the value from attribute width and  'En' or 'Fn' stands for value from  attribute precision. If the original precision value contains numeric digit only like '2', it is converted to be 'F2'.

People

Assignee:
Gregory Dubois-Felsmann
Reporter:
Xiuqin Wu [X] (Inactive)
Watchers:
Emmanuel Joliet, Gregory Dubois-Felsmann, Loi Ly, Tatiana Goldina, Vandana Desai, Xiuqin Wu [X] (Inactive)