[ 
https://issues.apache.org/jira/browse/CASSANDRA-9224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14546049#comment-14546049
 ] 

Tyler Hobbs commented on CASSANDRA-9224:
----------------------------------------

What version of python are you running the tests with?  With 2.7.6, I get the 
problem that I mentioned in the description about using high precision values.  
Here's what I get for output on the dtest:

{noformat}
 part | id | val1                      | val2
------+----+---------------------------+-----------------------
    + |  1 |     5.999999999999999e-08 |  5.99999978589949e-08
    + |  2 |                     6e-07 | 6.000000212225132e-07
    + |  3 |                     6e-06 | 6.000000212225132e-06
    + |  4 |                     6e-05 |    5.999999848427e-05
    + |  5 |                    0.0006 |   0.00060000002849847
    + |  6 |                     0.006 |   0.00600000005215406
    + |  7 |                      0.06 |   0.05999999865889549
    + |  8 |       0.59999999999999998 |   0.60000002384185791
    + |  9 |                         6 |                     6
    + | 10 |                         6 |                     6
    + | 11 |                         6 |                     6
    + | 12 |                         6 |                     6
    + | 13 |                         6 |                     6
    + | 14 |                         6 |                     6
    + | 15 |        6.0999999999999996 |    6.0999999046325684
    + | 16 |        6.1200000000000001 |     6.119999885559082
    + | 17 |        6.1230000000000002 |    6.1230001449584961
    + | 18 |        6.1234000000000002 |    6.1234002113342285
    + | 19 |        6.1234500000000001 |    6.1234498023986816
    + | 20 |        6.1234539999999997 |    6.1234540939331055
    + | 21 |        6.1234549999999999 |    6.1234550476074219
    + | 22 |                  6.123456 |    6.1234560012817383
    + | 23 |        6.1234564999999996 |    6.1234564781188965
    + | 24 |        6.1234555000000004 |    6.1234555244445801
    + | 25 |        6.1234555500000001 |    6.1234555244445801
    + | 26 |        6.1234555555555499 |    6.1234555244445801
    + | 27 |       16.1234499999999983 |   16.1234493255615234
    + | 28 |      116.1234500000000054 |  116.1234512329101562
    + | 29 |      1116.123450000000048 |    1116.1234130859375
    + | 30 |    11116.1234499999991385 |       11116.123046875
    + | 31 |   111116.1234499999991385 |            111116.125
    + | 32 |  1111116.1234500000718981 |           1111116.125
    + | 33 | 11111116.1234499998390675 |              11111116
{noformat}

A few other comments on the patch:
* Use one space after '#' for comments in python
* Python supports conditionals like {{if -4 <= exponent < float_precision:}}
* In 2.1, the patch needs an import of {{sys}} in cql3handling.py
* The dtest should use {{\@since('2.1')}}

Overall, very nice job on the tests! Thank you for taking the time to write 
those.

> Figure out a better default float precision rule for cqlsh
> ----------------------------------------------------------
>
>                 Key: CASSANDRA-9224
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-9224
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Tools
>            Reporter: Tyler Hobbs
>            Assignee: Stefania
>              Labels: cqlsh
>             Fix For: 3.x, 2.1.x, 2.2.x
>
>
> We currently use a {{DEFAULT_FLOAT_PRECISION}} of 5 in cqlsh with formatting 
> {{'%.*g' % (float_precision, val)}}.  In practice, this is way too low.  For 
> example, 12345.5 will show up as 123456.  Since the float precision is used 
> for cqlsh's COPY TO, it's particularly important that we maintain as much 
> precision as is practical by default.
> There are some other tricky considerations, though.  If the precision is too 
> high, python will do something like this:
> {noformat}
> > '%.25g' % (12345.5555555555555555,)
> '12345.55555555555474711582'
> {noformat}
> That's not terrible, but it would be nice to avoid if we can.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to