Histogram changes values

[Blazingsteal]

When using a Histogram the values inserted into the dataset is changed. Picture As can be seen in the picture the data point is 54.5, but all my data is ints converted to double, i.e. 54 -> 54.0, 55 -> 55.0 etc.
I should never be able to get 54.5, and I've checked the conversion from int to double (even though it should be without precision loss).

My data is not guaranteed to be equidistant so the Histogram is created with the Histogram(String name, double[] xBins) constructor, and filled with the fill(final double x) method. I'm using an ErrorDataSetRenderer().

I've tried using the other constructors as well but in those equidistant is set to true so they are not ideal, and the result is way different i.e. points are close to original value e.g. 54 -> 53.95843957493, and as my data is not equidistant 0 values are used as fillers where I dont provide data to make it equidistant. See picture

The Histogram dataSet is nice to use as I dont have to count occurences in my data but simply insert it into the dataSet.

Environment:

• OS: Ubuntu 20.04
• Java version 8:
• ChartFx version: JDK8

[wirew0rm]

I think there is a misunderstanding about the way histogram works. What you are supplying to the constructor are the boundaries between the histogram bins. What is plotted and returned by the e.G. DataSet.get() is the center of the bin and its content. All values between the first and second value of xBins are added to the first bin, which will be drawn at the center of the Bin. That is why you will get x.5 as x-values if you have your bin boundaries as integers. For equidistant Histograms converting between centers and boundaries is trivial, but for non-equidistant it is a little bit more complex.

For your use case I would suggest to just write your own DataSet class backed by two integer arrays for x-values and counts. Just extend AbstractDataSet and it should just be a few lines of code. You can also implement the Histogram interface or just make your own API for incrementing the individual bins.

Please note that the JDK8 branch is not updated anymore. This means that it misses a lot of improvements that have been added between x.1.5 and x.2.5. There specifically have been some improvements for non equidistant Histograms, so there is a good chance, that the jdk8 version contains bugs that have already been fixed in current versions. If you can, update to JDK11 or later so you can use the current version. Even if you cannot use it in your main project, you can check against the current version to know if things have already been fixed and maybe determine workarounds for the jdk8 version.

I have also two recommendations for future issues:

1. Please provide a simple runnable example or at least a complete section of code illustrating what you are trying to do.
2. Embed Screenshots directly into the issue, imagehosters expire and also it is better to have everything in one place.

[Blazingsteal]

Ah that makes more sense. To fix my problem I've gone back to using a DoubleDataSet and doing the counting on my own.

Please note that the JDK8 branch is not updated anymore.

Sad to hear, as my project needs Java 8, and I wont be able to upgrade to the latest java anytime soon by the looks of it.

I have also two recommendations for future issues:
Please provide a simple runnable example or at least a complete section of code illustrating what you are trying to do.
Embed Screenshots directly into the issue, imagehosters expire and also it is better to have everything in one place.

Definitely a good idea, I'll keep it in mind for the future

[RalphSteinhagen]

Sad to hear, as my project needs Java 8, and I wont be able to upgrade to the latest java anytime soon by the looks of it.

Moving from JDK8 to > JDK11 isn't that hard though (if you aren't stuck with JDK8 because of Android) but the reverse is because we'd need to drop a lot of useful features and performance improvements.

Notably with the introduction of modules and since JDK11, modern Java has diverged quite a bit from the now rather old Java 8 standard. We tried to maintain both versions but since we internally use > JDK11 exclusively and due to the increased maintenance burden of two version we had to drop the active support for JDK8.

We hope you understand...

[Blazingsteal]

Moving from JDK8 to > JDK11 isn't that hard though (if you aren't stuck with JDK8 because of Android) but the reverse is because we'd need to drop a lot of useful features and performance improvements.

Actually I'm bound by it because I'm using Tornadofx, which requires JDK8 until they release Tornadofx 2.0

Notably with the introduction of modules and since JDK11, modern Java has diverged quite a bit from the now rather old Java 8 standard. We tried to maintain both versions but since we internally use > JDK11 exclusively and due to the increased maintenance burden of two version we had to drop the active support for JDK8.

I fully understand having to support two versions and I would love to use > JDK 11 since it would help with the ease of using other libraries as well, when not having to look for a JDK8 version. And just in general there's bug fixes, new feature etc. I could benefit from as well.