This post is about how OpenScad type-casts a floating point number to a
string(str()) or displays it in the console (echo()). I.e., nothing to do
with the internal calculation. Observation is carried out with OpenSCAD
version 2015.06.21.nightly (git 68e41af) running on Linux Mint 17.

I. First we know that round() gets rid of 4, advances 5:

II. OpenScad displays only 6 significant digits. I would expect extra
significant digits to be treated as the way round() works, i.e., cut 4,
advance 5. But it is not:

II-1. Integer -- When extra significant digit is 5, simply cut away:

II-2. Float (>=1) -- Rounded up normally to 6 significant digits: cut 4,
advance 5:

II-3. Float (<1) -- 5 sometimes cut, sometimes advances:

III. This section is to test 6 digits + a 5, like 0.1111115, 0.2222225, etc,
and multiply them with 0.1 repeatedly. It appears that the extra-5 is
treated in an irregular manner:

IV. In this observation, 7 digits of 5 (5555555) is multiplied by pow(10,n).
Again, this shows the extra-5 is treated unpredictably:

$  Runsun Pan, PhD

$ libs: doctest , faces ( git ), offline doc ( git ),runscad.py( 1 , 2 , git );

$ tips: hash( 1 , 2 ), sweep , var , lerp , animGif

--
View this message in context: http://forum.openscad.org/Inconsistent-conversion-of-floating-number-to-string-at-7th-significant-digit-tp14350.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

FYI: The test framework now has a better way of dealing with cross-platform rounding differences, so that aspect of the problem isn’t an issue any longer.

-Marius

@clothbot: Thx for the links. After reviewing them, however, I do believe
this is a different issue. What bothers me is not "how many digits" in
specific cases (like 8 vs 8.0000000004) nor "different platforms", but what
looks like a totally irregular manner of handling the number 5 --- sometimes
it is rounded up, sometimes it is rounded down, and for all the time I spent
in investigation, I couldn't figure out what rule OpenSCAD follows to decide
rounding up or down number 5.

clothbot wrote

$  Runsun Pan, PhD

$ libs: doctest , faces ( git ), offline doc ( git ),runscad.py( 1 , 2 , git );

$ tips: hash( 1 , 2 ), sweep , var , lerp , animGif

--
View this message in context: http://forum.openscad.org/Inconsistent-conversion-of-floating-number-to-string-at-7th-significant-digit-tp14350p14375.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

The round(x) function rounds away from zero. So round(0.5) == 1 and
round(-0.5) == -1.

The conversion from floating point to string is, in my opinion, broken. I
wrote a long explanation of why it is broken, and what I'd like to do
instead, in an earlier post. I should create an issue for this.

But briefly, I would like the float->string conversion to produce the
shortest floating point literal that, when read, exactlly reproduces the
original floating point number. This means no information is thrown away.

On 11 November 2015 at 16:04, runsun runsun@gmail.com wrote:

doug.moen wrote

Consider the many many things (some are quite challenging) that
still need adding/fixing/improving in OpenSCAD, I'm not sure str(n)
is high (or even mid-) priority.

It seems almost easy to just port sprintf() to OpenSCAD and that's
that.  But in an odd way, I almost relish the various handicaps OpenSCAD
throw at us.  The subtle message is: DON'T use OpenSCAD for
conventional programming, don't do text processing (don't even dream
about adding regular expression to OpenSCAD), don't do general
file I/O (fopen, fread, fwrite, fclose), don't do advanced computations (I
was
toying with the masochistic(???)  idea of writing a matrix inversion
algorithm
in OpenSCAD).

Sticks to making solids (STL) on OpenSCAD.  A true geek would just mix-
language program (Java+OpenSCAD) to solve his practical problems and
leaving the masochism (matrix inversion in OpenSCAD) to the nut jobs.

(hmmm I am assuming no one had actually done it... have I called some
very smart person a nut job? ... oh wait... it seems really probably
possible
to write it... eh...)

(oops sorry for empty post previous)

--
View this message in context: http://forum.openscad.org/Inconsistent-conversion-of-floating-number-to-string-at-7th-significant-digit-tp14350p14391.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

Advanced rounding algorithms may cast 0.5 to either 1 or 0 depending on
the preceding bit in the binary representation of the number.

See e.g. "Round half to even" https://en.wikipedia.org/wiki/Rounding

Just my $0.02
Tim

On 12.11.2015 0:04, runsun wrote:

ctchin said "Consider the many many things (some are quite challenging) that
still need adding/fixing/improving in OpenSCAD, I'm not sure str(n)
is high (or even mid-) priority."

I agree, but I'm not saying that. OpenSCAD uses the same float->string
conversion everywhere, including the export to ASCII STL, and the export to
AMF. In the export case, severely truncating each float to 6 significant
digits often damages the mesh, so that OpenSCAD can't read STL files that
it itself has generated. (The conversion from CGAL rational numbers to
floats can also damage the mesh, but the float->string conversion is
responsible for most of the damage.) I'd like to fix this, and str(n) will
get fixed at the same time, as a bonus.

On 12 November 2015 at 00:16, ctchin c.t.chin@szu.edu.cn wrote:

Tim V. Shaporev wrote

Thx, Tim. But this doesn't explain those examples I raised in the first
post, where the rounding of 5 is handled differently even the preceding
number is the same.

$  Runsun Pan, PhD

$ libs: doctest , faces ( git ), offline doc ( git ),runscad.py( 1 , 2 , git );

$ tips: hash( 1 , 2 ), sweep , var , lerp , animGif

--
View this message in context: http://forum.openscad.org/Inconsistent-conversion-of-floating-number-to-string-at-7th-significant-digit-tp14350p14406.html
Sent from the OpenSCAD mailing list archive at Nabble.com.