Timeline for Custom double parser optimized for performance
Current License: CC BY-SA 4.0
24 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 10, 2020 at 13:24 | history | edited | Community Bot |
Commonmark migration
|
|
| Aug 3, 2018 at 18:25 | answer | added | Alain | timeline score: 0 | |
| Aug 2, 2018 at 16:50 | answer | added | chux | timeline score: 3 | |
| Aug 2, 2018 at 16:21 | comment | added | Alain |
I had noticed this too. I have my tests checking for things like that: Warning: Minor difference between the native parse result and custom parser for "123456789000000000000000". Native: 1.23456789E+23 Custom: 1.2345678899999999E+23 Difference of 16777216 I just figured it was to be expected that different methods would yield slightly different results in the least significant bits. Is there a way to correct this? Could this lead to new issues that aren't already inherently present when dealing with doubles?
|
|
| Aug 2, 2018 at 16:08 | answer | added | Alain | timeline score: 0 | |
| Aug 2, 2018 at 16:06 | comment | added | chux |
@Alain This approach (accumulating left to right, whole and fractional values separately) fails to result in the optimal answer when the whole number part undergoes rounding in one direction that it otherwise would not had the fraction been considered. This would first appear with values somewhere above (2 ^53)/100. Perhaps "18014398509481985.5"? Yet perhaps large text values like that (They derive from code with precision that exceeds Double) are not important for this code to find the best answer.
|
|
| Aug 2, 2018 at 15:55 | comment | added | Alain |
Just to clarify further - my statement was meant to indicate that I only care about being as performant as possible in handling strings in the format "0.00". I certainly don't want to preclude greater flexibility if there is no performance impact in that case. In this situation, checking if we've reached the end of the string is just as expensive as checking if we've reached 2, so the added flexibility won't slow down parsing strings with fractions of length 2.
|
|
| Aug 2, 2018 at 15:44 | history | edited | Alain | CC BY-SA 4.0 |
Removing test case to discourage pedantry.
|
| Aug 2, 2018 at 15:43 | comment | added | Alain | @chux Edited test cases to clarify. | |
| Aug 2, 2018 at 15:12 | comment | added | chux |
"Just millions of "0.00" format doubles." and test cases like ".12345678901234" seem to contradict as the test case has more than 2 digits past the decimal point. If this code is to handle many places past the '.', then there are correctness issues. Please clarify you precision goals.
|
|
| Aug 1, 2018 at 0:27 | history | edited | Alain | CC BY-SA 4.0 |
Slight tweak seems to help
|
| Aug 1, 2018 at 0:08 | comment | added | Alain |
I found a bug in my 1st while loop that caused an invalid chacater to erronously return a double from all characters up to it. The fix was to use while(true) and have a separate check for if (currentIndex >= length). It brought performance gain down by almost 80%, so I'm looking for ways to merge the two again while still handling the failure scenario correctly.
|
|
| Aug 1, 2018 at 0:02 | history | edited | Alain | CC BY-SA 4.0 |
Fixed two bugs - one where strings without a decimal were parsed incorrectly, and an index out of bounds on NegPow
|
| Jul 31, 2018 at 20:45 | history | edited | 200_success | CC BY-SA 4.0 |
deleted 10 characters in body; edited tags; edited title
|
| Jul 31, 2018 at 9:01 | history | tweeted | twitter.com/StackCodeReview/status/1024218566822907904 | ||
| Jul 31, 2018 at 6:12 | history | edited | t3chb0t |
edited tags
|
|
| Jul 31, 2018 at 4:22 | comment | added | Alain | Added comments and test cases to better indicate what formats are and aren't meant to be supported. | |
| Jul 31, 2018 at 4:18 | history | edited | Alain | CC BY-SA 4.0 |
Improved formatting
|
| Jul 31, 2018 at 4:02 | history | edited | Alain | CC BY-SA 4.0 |
Support for unlimited significant digits.
|
| Jul 31, 2018 at 2:47 | comment | added | Alain |
@RonBeyer I just discovered that Stopwatch uses DateTime.UTCNow behind the scenes unless you use it in high resolution mode.if (!Stopwatch.IsHighResolution) return DateTime.UtcNow.Ticks; Looks like it's only necessary if you're timing things at sub-20ms resolution. We're at seconds resolution here, so it should be okay.
|
|
| Jul 31, 2018 at 1:55 | comment | added | Ron Beyer |
You should use a Stopwatch instead of just two time differences when doing benchmarks.
|
|
| Jul 31, 2018 at 1:47 | history | edited | Alain | CC BY-SA 4.0 |
added 1786 characters in body
|
| Jul 31, 2018 at 1:34 | comment | added | Ron Beyer |
You missed 3 cases, ∞, -∞ and NaN. These should parse out as Double.PositiveInfinity, Double.NegativeInfinity and Double.NaN. Actually there is one more, your tests should be able to parse the positive symbol, ie: +1234.5678
|
|
| Jul 31, 2018 at 0:25 | history | asked | Alain | CC BY-SA 4.0 |