[tor-bugs] #19259 [Metrics/Onionoo]: uncaught NFE
Tor Bug Tracker & Wiki
blackhole at torproject.org
Mon Jun 27 12:51:15 UTC 2016
#19259: uncaught NFE
-----------------------------+-----------------------------------
Reporter: iwakeh | Owner: iwakeh
Type: defect | Status: needs_information
Priority: High | Milestone:
Component: Metrics/Onionoo | Version:
Severity: Major | Resolution:
Keywords: | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor:
-----------------------------+-----------------------------------
Comment (by karsten):
Oh, sorry for misunderstanding. Let me reply to this comment instead:
Replying to [comment:10 iwakeh]:
> Test class commentary
>
> `testSetup` for warm-up, passes
Sounds good. :)
> `testWeightHistory` fails, document contains `NaN` after compression
It seems there are two problems with this test case:
1. Intervals should be at least one hour long for the internal math to
work. This is unfortunate, though the assumption is realistic for real
data. But let's relax this requirement and accept intervals shorter than
1 hour. A plausible minimum would be 1 second, because we cannot
represent anything shorter than that.
1. Entries are only compressed if they are a given number of days in the
past, calculated from the current system time. A better approach would be
to compress based on the end time of the most recent history entry to
remove yet another dependency on system time. For the test to work you'll
have to date entries back by 1 year or maybe even more.
> `testSetFromDocumentString` passes
Okay.
> `testMissingValues` fails, b/c the small negative values are not
recognized as missing
How about we represent missing values on disk as empty string (`""`),
which also saves disk space, and in memory as `-1.0` to keep the current
code working?
> `testSetFromDocumentStringWrongInput` fails, error b/c of nfe
Right, let's fix that nfe.
> `testSetFromDocumentStringWrongDateTime` failes, b/c line with later
beginning than end is not rejected.
Right, let's reject those lines. That means additional tests, but those
are cheap and might make the code more robust.
> `testCompare` fails, b/c there is an entry with the key from the first
and values from the second element.
Let's reject those lines, too.
Is that more what you had in mind?
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/19259#comment:13>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list