#654 closed defect (fixed)
time command overly precise after 7756d8b
Reported by: | Jim Ursetto | Owned by: | felix winkelmann |
---|---|---|---|
Priority: | minor | Milestone: | 4.9.0 |
Component: | core libraries | Version: | 4.7.x |
Keywords: | Cc: | ||
Estimated difficulty: |
Description
Looks like the change to C_cpu_milliseconds causes (time) to display artificially precise numbers. Not immediately clear why, it should just be displaying up to usec.
Example: results of csi -script tests/port-test.scm
is
slow... 0.166863s CPU time, 0.00136399999999999s GC time (major), 13414 mutations, 3/2039 GCs (major/minor) fast... 0.00144299999999998s CPU time, 30 mutations, 0/3 GCs (major/minor)
versus previously:
slow... 0.036s CPU time, 0.001s GC time (major), 2740 mutations, 3/409 GCs (major/minor) fast... 0s CPU time, 30 mutations, 0/1 GCs (major/minor)
Attachments (1)
Change History (6)
comment:1 Changed 13 years ago by
Changed 13 years ago by
Attachment: | 0001-Limit-flonum-print-precision-to-6-in-sys-display-tim.patch added |
---|
comment:2 Changed 13 years ago by
Component: | unknown → core libraries |
---|---|
Owner: | set to felix winkelmann |
Status: | new → assigned |
comment:3 Changed 13 years ago by
I have changed C_cpu_milliseconds to floor the result, which should reduce the precision accordingly (see master). Does this work for you?
comment:4 Changed 13 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Seems to work fine. I liked the new microsecond precision too, but if you want to cap it at ms that's fine.
Note: See
TracTickets for help on using
tickets.
After screwing around with it for a while, the only reliable way I found to avoid it is to limit the flonum precision to 6 (i.e. microseconds), as in the attached patch.
The root cause could be that Chicken doesn't print or round flonums correctly sometimes -- for example it may print 0.00144299999999998 when the C library would print 0.001443 (with %.15g, precision 15). I've noticed this several times, but have not tracked it down yet. This happens when the bitwise representation of the flonum is verifiably correct, so I assume it is a bug in the printer. The fmt egg prints many, but not all, of these correctly.
In the meantime, maybe just limit the output precision?