prettyprint is changing my decimals

[jonolds]

For example, I'll copy and paste in:

[{"idx":0,"start":0.0,"end":1073.11,"duration":1073.11,"frameDetails":{"start_frame":430,"end_frame":46215,"start_pts":440320,"end_pts":47324160,"start_pts_time":9.98458,"end_pts_time":1073.11}},{"idx":1,"start":2143.89,"end":2175.41,"duration":31.5114,"frameDetails":{"start_frame":92760,"end_frame":93686,"start_pts":94986240,"end_pts":95934464,"start_pts_time":2153.88,"end_pts_time":2175.38}},{"idx":2,"start":2254.69,"end":2317.25,"duration":62.5537,"frameDetails":{"start_frame":97532,"end_frame":99795,"start_pts":99872768,"end_pts":102190080,"start_pts_time":2264.69,"end_pts_time":2317.24}}]

and I'll hit pretty print and get:

[ { "idx": 0, "start": 0.0, "end": 1073.1099999999999, "duration": 1073.1099999999999, "frameDetails": { "start_frame": 430, "end_frame": 46215, "start_pts": 440320, "end_pts": 47324160, "start_pts_time": 9.9845799999999993, "end_pts_time": 1073.1099999999999 } }, { "idx": 1, "start": 2143.8899999999999, "end": 2175.4099999999999, "duration": 31.511399999999998, "frameDetails": { "start_frame": 92760, "end_frame": 93686, "start_pts": 94986240, "end_pts": 95934464, "start_pts_time": 2153.8800000000001, "end_pts_time": 2175.3800000000001 } }, { "idx": 2, "start": 2254.6900000000001, "end": 2317.25, "duration": 62.553699999999999, "frameDetails": { "start_frame": 97532, "end_frame": 99795, "start_pts": 99872768, "end_pts": 102190080, "start_pts_time": 2264.6900000000001, "end_pts_time": 2317.2399999999998 } } ]

What did you do with my 1/1000000000000?! j/k, I love your plugin. This is the first beef I've ever had over years of use, and I will not be shocked at all if it's something I messed up. Thank you!

[molsonkiko]

@jonolds

This is effectively a duplicate of #81, which I foolishly closed because at the time I didn't feel like dealing with this issue even though it's obviously unacceptable.

I'm in the process of working on a fix, and I hope to have it solved by the end of the day.

[molsonkiko]

This commit should address this issue. If you follow my instructions for downloading an unreleased version, you can test out this fix and see if it is too your liking.

As I noted in the changelog, this fix comes at the cost of noticeably worse performance when reformatting very large files (say, several megabytes or more). I wish I could think of a way to do this with less of a hit to performance, but I don't think I'm a competent enough programmer to implement a performant and correct double-formatting algorithm from scratch.

Please let me know if you have any thoughts. If you are satisfied with this fix, I will be including it in v8.2 of JsonTools, which I aim to release in the next few weeks.

[jonolds]

Awesome, I'll give it a try tonight. thank you so much!

[molsonkiko]

JsonTools version 8.2, incorporating a fix for this issue, is now live. I will soon submit a PR to include v8.2 in the plugins manager.

[Souldrinker]

Hmm, are you sure the issue is fixed in 8.2? I noticed on a colleagues computer that when he pretty printed the same JSON file as me the output looked different. Turned out I had an ancient version (4.4) and for me this json attribute:
"RealPlannedHours":0.10
...got converted into 0.1 but 0.10000000000000001 on his (with 8.1).

I updated through the npp plugin admin to the latest available 8.1 version and then I got the same.

Then I found this repo and downloaded the 8.2 x64 release and replaced the plugin in the plugin folder (plugin admin now shows 8.2) and still I get the same incorrect response as with 8.1.

[molsonkiko]

@Souldrinker
That's really weird; when I reformat 0.1 with JsonTools v8.2, I get 0.1 back.

Could you do me a favor and report what you get when you parse the input in the original comment of this issue? If it has a lot of unnecessarily long representations, I'm going to need to do some soul-searching to decide how best to handle this issue. Because unfortunately this is a situation where it's literally impossible to please everyone; I've looked at several potential solutions for this issue and my current one seems the best, at least on my machine.

My current implementation for serializing a decimal number (call that d) works like this:

1. Get a short but imprecise representation for d (the same algorithm I used back in v4.4), call that representation dstr
2. Parse dstr, call that dstr_parsed
3. If dstr_parsed is equal to d, return dstr
   • Since you're getting 0.10000000000000001 instead of 0.1, your machine seems to think that d is closer to 0.10000000000000001 than it is to 0.1. So I'm guessing that this issue is caused by a hardware difference between your computer and mine.
4. Otherwise, return the most precise representation possible (this is the algorithm that was always used in v8.1).

In short, I'm trying to avoid unnecessarily losing precision when I reformat numbers, as that could cause a regression of #78, but at the same time I want to default to the old shorter representation, so that I can close this issue.

[Souldrinker]

Hmm, unfortunately looks rather similar to what the issue creator got also when I do it with 8.2 for me:

Going back to 8.0 fixes it:

[molsonkiko]

@Souldrinker

Thank you so much for testing this for me. This is bizarre and really frustrating. Since I can't replicate your problem on my machine, coming up with a reliable solution for this issue (without regressing on #78) is going to be a lot more of a PITA than I anticipated.

I'll do my best to come up with a new release that fixes this issue before Notepad++ 8.7.2 releases, so that people can get an actual fix on that NPP's version of the Plugins Manager.