I had the idea of rounding twice...
2016-08-12, 12:07 (This post was last modified: 2016-08-12, 12:11 by Nils Schmidt.)
2016-08-12, 12:07 (This post was last modified: 2016-08-12, 12:11 by Nils Schmidt.)
(2016-08-12, 5:46)Philippe Hurbain Wrote:Quote:I got a 0.5036499999999999.I feel your pain... At least I learnt things about rounding ;)
LDPE says it's 0.5036.
PrimGen2 says it's 0.5037.
Arrgh!
Looks like we were lucky when we cloned the original primgen, once we figured out things, file comparison sturned out OK. Or maybe we didin't stumble on a tricky case? Now I am not sure that a 1/10000 error from time to time would be a real issue...
This last problem is related to this https://en.wikipedia.org/wiki/Rounding#T...7s_dilemma ?
Finally, I found a practical solution to this :)
I simply round twice.
Code:
private String formatDec(double d) { // d is 0.00004999999 (string representation)
return bigDecimalToString(
new BigDecimal(String.valueOf(d))
.setScale(8, RoundingMode.HALF_UP) // Round to 8 decimal places (to transform 0.00004999999 into 0.00005)
.setScale(4, RoundingMode.HALF_UP)); // Round to 4 decimal places (0.00005 -> 0.0001)
}
Assume that N is < 9 and X > 4.
This will convert any 0.0000N999X number to the next 0.0000(N+1) number. It solves the problem for the trailing 9's.
Okay.. 0.000049990 will not work, but I guess this has no practical impact.
Just for demonstration, the following primitve is now identical in both tools (PrimGen2 and LDPE):
Code:
0 Torus Outside 1 x 0.5455 x 1
0 Name: 17\t01o5455.dat
0 Author: Primitive Generator 2
0 !LDRAW_ORG Unofficial_Primitive
0 !LICENSE Redistributable under CCAL version 2.0 : see CAreadme.txt
0 BFC CERTIFY CCW
0 // Major Radius: 11
0 // Tube(Minor) Radius: 6
0 // Segments(Sweep): 17/17 = 1.00
0 // 1 9 0 0 0 1 0 0 0 1 0 0 0 1 4-4edge.dat
0 // 1 12 1 0 0 0.5455 0 0 0 0 0.5455 0 1 0 4-4edge.dat
Nobody would even need that torus...
Nevertheless, I can sleep well again ;)