Inconsistent conversion of floating number to string at 7th significant digit
On Fri, Nov 13, 2015, at 03:35 PM, Marius Kintel wrote:
On Nov 13, 2015, at 15:50 PM, Greg Frost Gregorybartonfrost@gmail.com wrote:
Most use cases of minkowski would be more simply and accurately implemented with a 3d version of the offset function. Minkowski with a sphere is a terrible way to make rounded edged objects.
3D offset is on the wishlist. It’s not a trivial operator to implement
efficiently though. Pointers are welcome :)
-Marius
Nooooo not more Poin....
*** Segmentation fault. core dumped.
On Nov 13, 2015, at 19:35 PM, don bright hmbright@fastmail.com wrote:
3D offset is on the wishlist. It’s not a trivial operator to implement
efficiently though. Pointers are welcome :)
-Marius
Nooooo not more Poin....
*** Segmentation fault. core dumped.
I should have specified that valid pointers are preferred :)
-Marius
On Fri, Nov 13, 2015 at 11:17 PM, runsun runsun@gmail.com wrote:
doug.moen wrote
If we fix the ASCII STL export code to produce super high precision output
(the equivalent of 128 bit floating point precision, or better), then it
won't help in those rare cases where truncation to
64 bit floating point
precision
is enough to create a zero width triangle. That's because the
programs that import the STL that we produce are mostly likely using 64
bit
floats for their mesh, and will throw away any extra precision beyond that
point. Any program that imports AMF is required by the standard to use
at
least 64 bit precision for the mesh, and it's rare for programs to support
better than 64 bit float precision because the software and hardware
support is lacking.
I did a little test: Let i = 1 + k, then make k smaller by 10 fold
continuously, to see how far down k goes to get ignored. When it did, we
will see 1==i.
I tested 1+0.2 and 1+0.6, so the tests go like:
1.02 == 1 ? ==> false
1.06 == 1 ? ==> false
1.002 == 1 ? ==> false
1.006 == 1 ? ==> false
and so on. This goes on until there are 16 0's:
1.0000000000000002 ==1 ? ==> false (15 0's)
1.0000000000000006 ==1 ? ==> false
1.00000000000000002 ==1 ? ==> true (16 0's)
1.00000000000000006 ==1 ? ==> true
What it means to me is:
- Openscad calculation uses 17 significant digits
I think its 53 bits (explanation is further down)
- Beyond that, anything is discarded. Note that there no rounding up. Just
cut away.
So, questions:
- is this a fare test of the internal precision ?
guess so but if you use numerically stable algorithms it will work out
most of the time. If your algorithm at some point wants to know the
ratio of:
(smallNr + hugeNr) / hugeNr
you run into problems. That's what I took away from numerics at university :)
- What does this tells us about Openscad's internal precision, in terms of
"??? bit floating-point precision" ?
this means doubles are used internally at some point :)
https://en.wikipedia.org/wiki/Double-precision_floating-point_format says:
double: 64 bit
Sign bit: 1 bit
Exponent width: 11 bits
Significand precision: 53 bits (52 explicitly stored)
if you normalize a nr (except 0) you get a binary 1 in the first
digit so they dont have to store it :)
so to get the significant decimal digits: (I used python as a calculator)
log(pow(2, 53), 10) = 15.954589770191001
pow(2, 53) gives us the biggest nr (irregardless of the
representation) that can be represented in the 53 bits and rounding up
the log10 of that we get the nr of digits we need to represent this nr
in decimal.
So your experiments led to the right answer: ~16 decimal digits
(I just saw doug allready anwered this but I still post my answer
because I think he got the nr of significant bits off by one ;)
greetings
Philipp
--
:: Philipp Tiefenbacher
:: open source hardware/magic -> http://magicshifter.net
:: open source cellular automata -> http://evocell.net
:: my homebase/hackerspace -> http://metalab.at
:: world domination -> http://kybkreis.at
Any sufficiently advanced technology is indistinguishable from a MagicShifter!
--Arthur C. Clarke about his http://MagicShifter.net
Many thx to Phillip and doug for the info on precision. Now I have a clearer
picture of what's going on there.
I manage to create a function, fullnumstr(), that displays a number
faithfully in string up to the internal significant digits OpenScad allows.
With this, we can break the 6-digit display limit set by OpenScad. The tests
show promising outcome:
ECHO: "
---================================
fullnumstr ( n )=str ( tested:23/failed:1 )
| 0> fullnumstr(123456)= "123456"
| 1> fullnumstr(1234567)= "1234567"
| 2> fullnumstr(123456789)= "123456789"
| 3> fullnumstr(123456000)= "123456000"
| 4> fullnumstr(12345670)= "12345670"
| 5> fullnumstr(123456789012345)= "123456789012345"
| 6> fullnumstr(-123456789012345)= "-123456789012345"
| 7> fullnumstr(12345678901234500)= "123456789012345"
| 8> fullnumstr(1234.5)= "1234.5"
| 9> fullnumstr(12345.6)= "12345.6"
| 10> fullnumstr(12345.67)= "12345.67"
| 11> fullnumstr(0.12345)= "0.12345"
| 12> fullnumstr(12)= "12"
| 13> fullnumstr(1230)= "1230"
| 14> fullnumstr(200)= "200"
| 15> fullnumstr(0.12)= "0.12"
| 16> fullnumstr(0.123)= "0.123"
| 17> fullnumstr(0.1234)= "0.1234"
| 18> fullnumstr(0.123456)= "0.123456"
| 19> fullnumstr(0.0000123456)= "0.0000123456"
| 20> fullnumstr(0.123456789012345)= "0.123456789012345"
| 21> fullnumstr(-0.123456789012345)= "-0.123456789012345"
|?22> fullnumstr(1/3) want: "0.333333333333333" got:
"0.3333333333333332848269492"
I haven't set the max digit limit yet. As shown, 1/3 is turned to string
down to 15 digits, after that it goes wild. It is observed that even we
enter numbers beyond 15 digits, OpenScad doesn't seem to know how to store
it correctly:
fullnumstr(0.123456789012345 ) => "0.123456789012345"
fullnumstr(0.1234567890123456)=> "0.123456789012345579976681618063..."
fullnumstr(1234567890.12345 ) => "1234567890.12345"
fullnumstr(1234567890.123456)=> "1234567890.1234559816657565352286..."
$ 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-tp14350p14478.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Float to string conversion code is notoriously difficult to get correct.
Based on the experience of people who have tackled this in other
programming languages, even after you think it is working, there might be
weird edge conditions that screw up, and the bugs might take years to find.
So we can help you to debug this code, but I won't feel real confident
about the correctness even once it seems to work.
I'd like to fix this in OpenSCAD using David Gay's open source
implementation in C, which has been under continual maintenance for 30
years. I'm pretty confident about that implementation.
On 14 November 2015 at 13:10, runsun runsun@gmail.com wrote:
Many thx to Phillip and doug for the info on precision. Now I have a
clearer
picture of what's going on there.
I manage to create a function, fullnumstr(), that displays a number
faithfully in string up to the internal significant digits OpenScad allows.
With this, we can break the 6-digit display limit set by OpenScad. The
tests
show promising outcome:
ECHO: "
---================================
fullnumstr ( n )=str ( tested:23/failed:1 )
| 0> fullnumstr(123456)= "123456"
| 1> fullnumstr(1234567)= "1234567"
| 2> fullnumstr(123456789)= "123456789"
| 3> fullnumstr(123456000)= "123456000"
| 4> fullnumstr(12345670)= "12345670"
| 5> fullnumstr(123456789012345)= "123456789012345"
| 6> fullnumstr(-123456789012345)= "-123456789012345"
| 7> fullnumstr(12345678901234500)= "123456789012345"
| 8> fullnumstr(1234.5)= "1234.5"
| 9> fullnumstr(12345.6)= "12345.6"
| 10> fullnumstr(12345.67)= "12345.67"
| 11> fullnumstr(0.12345)= "0.12345"
| 12> fullnumstr(12)= "12"
| 13> fullnumstr(1230)= "1230"
| 14> fullnumstr(200)= "200"
| 15> fullnumstr(0.12)= "0.12"
| 16> fullnumstr(0.123)= "0.123"
| 17> fullnumstr(0.1234)= "0.1234"
| 18> fullnumstr(0.123456)= "0.123456"
| 19> fullnumstr(0.0000123456)= "0.0000123456"
| 20> fullnumstr(0.123456789012345)= "0.123456789012345"
| 21> fullnumstr(-0.123456789012345)= "-0.123456789012345"
|?22> fullnumstr(1/3) want: "0.333333333333333" got:
"0.3333333333333332848269492"
I haven't set the max digit limit yet. As shown, 1/3 is turned to string
down to 15 digits, after that it goes wild. It is observed that even we
enter numbers beyond 15 digits, OpenScad doesn't seem to know how to store
it correctly:
fullnumstr(0.123456789012345 ) => "0.123456789012345"
fullnumstr(0.1234567890123456)=> "0.123456789012345579976681618063..."
fullnumstr(1234567890.12345 ) => "1234567890.12345"
fullnumstr(1234567890.123456)=> "1234567890.1234559816657565352286..."
$ 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-tp14350p14478.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
doug.moen wrote
Float to string conversion code is notoriously difficult to get correct.
Based on the experience of people who have tackled this in other
programming languages, even after you think it is working, there might be
weird edge conditions that screw up, and the bugs might take years to
find.
So we can help you to debug this code, but I won't feel real confident
about the correctness even once it seems to work.
I'd like to fix this in OpenSCAD using David Gay's open source
implementation in C, which has been under continual maintenance for 30
years. I'm pretty confident about that implementation.
@Doug, It'd be great if more people can help debugging my code.
It seems to me that David Gay's approach ( see here
http://www.exploringbinary.com/how-strtod-works-and-sometimes-doesnt/
and here
http://www.exploringbinary.com/incorrect-directed-conversions-in-david-gays-strtod/
), which converts a str representation of decimal to binary, is a bit off
topic here, 'cos what we need is convert a number to str, not the other way
around.
The reference you previously mentioned ( Printing Floating-Point Numbers
Quickly and Accurately
http://www.cs.indiana.edu/~dyb/pubs/FP-Printing-PLDI96.pdf ) is more on
the topic IMO.
But I am too lazy to go through that article, so I just follow my intuition.
After all I'm just trying to make it work in OpenScad, but not to make a
theory out of it.
I'll present my code in my next post. Let me describe my approach briefly
here:
-
log10(n) to find the order of 10
(a) n=1234567= 1.234567e+6; floor(log(n))=6 ==> p=6
(b) n=12345.67= 1.234567e+4; floor(log(n))=4 ==> p=4
(c) n=0.01234567== 1.234567*e-2; floor(log(n))=-2 ==> p=-2
This gives us an idea of the order of the number.
-
For a number 1.23456*e+p, we want to take the first 5 digits to start
with. We choose 5, because Openscad only displays 6 significant digits,
and the 6th significant digit could be result of the rounding up from the
7th, for example,1.234558
1.23456will be displays same digits (123456) but they are not the same. Taking
5 digits ensures that this pick reserves the exact same 5 digits as the
original.
This is done by:
n2= n / p2 where p2 = pow(10, p-4) :
(a) p2 = 100; n2 = n/p2 = 12345.67;
(b) p2 = 0; n2 = n/p2 = 12345.67;
(c) p2 = 1000000; n2 = n/p2 = 12345.67;
So we take the part on the left of dot: i = 12345
-
Subtract this i from n2, we get the fraction part, which is 0.67
-
Repeat 1)~3) using n=0.67 to take next 5 digits.
Usually after recursion twice ( first call gets 5 digits, 1st recursive call
gets next 5, and 2nd recursive call gets the 11~15), we reach the precision
limit of OpenScad (17 digits ) so the 3rd recursion will be unreliable.
Note that this 0.67, which is on the far right of original value, meaning
that it is relatively less significant, is moved up by an order of 5 during
the process. My intuition tells me that this kind of "rescues" the digits
from the low-significant position to prevent them from wiping out by the str
conversion of OpenScad.
So this is the main idea behind my approach. There are certainly some
patch-ups and fine-tunes during the process to take care of different
situations. But I think the idea and the code itself is pretty simple for
such a notoriously difficult problem. And currently it works with the very
limited cases I tried.
See my code next post.
$ 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-tp14350p14492.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
/* fullnumstr(n) -- Return the full number string
representation of n. Require functions:
repeat,trim,replace,num are defined in scadx
lib Runsun Pan 2015*/function fullnumstr(
n , _rtn="" // return buffer , _sign=1 //
sign to be added back when exiting , _init_int=undef // If init n
is an int , _init_p=undef // Init power of 10, needed for
inserting // . back to the string ,
_int_end0= 0 // For int that ends with 1 or more 0s
, _dep=0 // depth of recursion as a safe guard , _debug=""
)=( let( _sign = _rtn==""?sign(n):_sign ,_init_int =
_rtn==""?isint(n):_init_int ,_int_end0 = _rtn=="" // 1234000 =>
_int_end0 = 3 && _init_int? // 1234560 =>
_int_end0 = 1 ( let( end0_list= [ for( i=[0:20] )
if( n % pow(10,i))i-1] ) end0_list?end0_list[0]:0
) :_int_end0 )
_init_int && _rtn=="" && ( n< 1000000 ) && (
n>-1000000)? str(n) :let( _n = abs(n) //+_intguard) , p =
floor(log(_n)) , _init_p = _rtn==""?p:_init_p , n2= _n/pow(10,p-4)
// If n=1234567 or 0.001234567, n2=12345.7 //
Means we pick 5 digits at a time. OpenScad's //
displays only 6 significant digits, and the // 6th
one could be a result of rounding-up of // the
7th, which will not be the original 6th. // So
picking 5 is safer. , i = floor(num(str(n2))) // We know that i has to
be int. So do // a reverse type-casting
num-str-num // to get rid of garbage digits,
if exits , f = n2-i , isexit = f< 1e-6 || _dep>3 , __rtn=
str( _rtn , isexit ? // trim away ending 0's
trim(str(i), r="0") // when exiting : i
) , _rtn = isexit? str( _sign==-1?"-":""
, _int_end0? // Add ending 0s back for int str(
__rtn , repeat("0", _int_end0))
:_init_p<0? // Add preceeding 0s back for float str(
"0." , repeat("0", -_init_p-1)
// In cases like 0.~2300034~, the 000 could
// be skipped by log() when next step is 3.4~ ,
__rtn )
:_init_p< len(__rtn)-1? insert(__rtn, ".",
_init_p+1) :__rtn ) :
__rtn// , _debug = str( _debug// , "<hr/>"//
, "<br/>_dep = ", _dep // , "<br/>_init_p = ",
_init_p// , "<br/>_init_int = ", _init_int//
, "<br/>_int_end0 = ", _int_end0// , "<br/>n = ", n
// , "<br/>p = ", p // , "<br/>n2
= ", n2// , "<br/>i = floor(n2) = ", i//
, "<br/>f=n2-i = ", f // , "<br/>isexit = ",
isexit // , "<br/>__rtn = ", __rtn //
, "<br/>_rtn = ", _rtn // ) )// let isexit ?
// [_debug,_rtn] _rtn : fullnumstr( n=f, _rtn =_rtn
, _init_int = _init_int , _int_end0 = _int_end0
, _dep=_dep+1 , _init_p=_init_p , _sign=_sign
, _debug = _debug ) );
$ 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-tp14350p14493.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Obviously I'm not talking about David Gay's strtod() function. I'm talking
about his implementation of "How to print floating point numbers
accurately", which is called dtoa(). Given that I'm an experienced C/C++
programmer, and given that I think that writing a correct num->string
function in OpenSCAD is a research project, I think that the best use of my
limited resources is to integrate David Gay's code into OpenSCAD. It's a
very simple and straightforward project.
On 14 November 2015 at 19:55, runsun runsun@gmail.com wrote:
doug.moen wrote
Float to string conversion code is notoriously difficult to get correct.
Based on the experience of people who have tackled this in other
programming languages, even after you think it is working, there might be
weird edge conditions that screw up, and the bugs might take years to
find.
So we can help you to debug this code, but I won't feel real confident
about the correctness even once it seems to work.
I'd like to fix this in OpenSCAD using David Gay's open source
implementation in C, which has been under continual maintenance for 30
years. I'm pretty confident about that implementation.
@Doug, It'd be great if more people can help debugging my code.
It seems to me that David Gay's approach ( see here
http://www.exploringbinary.com/how-strtod-works-and-sometimes-doesnt/
and here
<
http://www.exploringbinary.com/incorrect-directed-conversions-in-david-gays-strtod/
), which converts a str representation of decimal to binary, is a bit off
topic here, 'cos what we need is convert a number to str, not the other way
around.
The reference you previously mentioned ( Printing Floating-Point Numbers
Quickly and Accurately
http://www.cs.indiana.edu/~dyb/pubs/FP-Printing-PLDI96.pdf ) is more
on
the topic IMO.
But I am too lazy to go through that article, so I just follow my
intuition.
After all I'm just trying to make it work in OpenScad, but not to make a
theory out of it.
I'll present my code in my next post. Let me describe my approach briefly
here:
-
log10(n) to find the order of 10
(a) n=1234567= 1.234567e+6; floor(log(n))=6 ==> p=6
(b) n=12345.67= 1.234567e+4; floor(log(n))=4 ==> p=4
(c) n=0.01234567== 1.234567*e-2; floor(log(n))=-2 ==> p=-2
This gives us an idea of the order of the number.
-
For a number 1.23456*e+p, we want to take the first 5 digits to start
with. We choose 5, because Openscad only displays 6 significant digits,
and the 6th significant digit could be result of the rounding up from the
7th, for example,1.234558
1.23456will be displays same digits (123456) but they are not the same.
Taking
5 digits ensures that this pick reserves the exact same 5 digits as the
original.
This is done by:
n2= n / p2 where p2 = pow(10, p-4) :
(a) p2 = 100; n2 = n/p2 = 12345.67;
(b) p2 = 0; n2 = n/p2 = 12345.67;
(c) p2 = 1000000; n2 = n/p2 = 12345.67;
So we take the part on the left of dot: i = 12345
-
Subtract this i from n2, we get the fraction part, which is 0.67
-
Repeat 1)~3) using n=0.67 to take next 5 digits.
Usually after recursion twice ( first call gets 5 digits, 1st recursive
call
gets next 5, and 2nd recursive call gets the 11~15), we reach the precision
limit of OpenScad (17 digits ) so the 3rd recursion will be unreliable.
Note that this 0.67, which is on the far right of original value, meaning
that it is relatively less significant, is moved up by an order of 5 during
the process. My intuition tells me that this kind of "rescues" the digits
from the low-significant position to prevent them from wiping out by the
str
conversion of OpenScad.
So this is the main idea behind my approach. There are certainly some
patch-ups and fine-tunes during the process to take care of different
situations. But I think the idea and the code itself is pretty simple for
such a notoriously difficult problem. And currently it works with the very
limited cases I tried.
See my code next post.
$ 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-tp14350p14492.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
I thought a help on debugging was offered, that's why I spent so much time
posting my algorithm and my code, which is created entirely for the need of
my doctest lib. Guess I misunderstood. Anyway, thx for the help.
I totally agree that this --- and most of any other useful feature for that
matter --- is better be implemented in the c level. OpenScad's language is
not designed for this purpose anyway.
$ 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-tp14350p14499.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
I have done some testing of my own, to ascertain what OpenSCAD does when it
generates a .stl file. First test was to create a mesh from cube(5). My
expectation was that this mesh was made up of 6 squares, one for each side
of the cube. Not so. It is made up of 12 triangles, two triangles for each
side. Each triangle can readily be removed from the .stl file, by deleting
just the seven lines that constitute that triangle. Viewing the modified
file in MeshLab shows what has been removed.
If OpenSCAD always creates triangle based meshes, then creating a mesh
without zero area triangles is a minor problem: calculate the area of the
triangle to be written, after its vertex vectors have been truncated to
final precision, and if the area is zero, do not write the triangle into the
.stl file.
The second test requires some background: polyhedron() can be used to create
individual faces, which in turn has been assembled (with nophead's help)
into a 3-dimensional primitive, as long as a function can be obtained that
describes the primitive in terms of polar coordinates. surface() does
currently the same for cartesian coordinates, but the list of vertices needs
to be calculated outside OpenSCAD. Once code has been put together to allow
creating the cartesian coordinates of each vertex inside OpenSCAD, creating
3D-offset functionality should be trivial, since all that is required is to
erect the normal onto each face, move the face by the required amount along
the normal, and reconnect each face to its neighbours.
The observations and code referred to above make it clear that any solid
created by OpenSCAD may be regarded as a collection of (connected) faces.
Thus, by choosing the right projection, any face in 3 dimensions can be
represented by a line in 2D space. When I choose here a (pentagonal) prism
and view it along the z-axis, that is just for ease of argument. The
conclusions arrived at will be applicable to any 3D geometry.
First, let's demolish the argument that, for constructing a polyhedron
(without the brackets, this is a geometrical object, not an OpenSCAD
module), faces must be specified. This is not true, as we may see from
figure 1:
http://forum.openscad.org/file/n14500/Prism_1.prism_1
Figure 1
Lines in figure 1 represent faces, as discussed above, and points represent
vertices. In that sense, ABCD represents any four-sided prism, such as
generated by cube(). ABECD, on the other hand, represents a 5-sided
(pentagonal) prism, for which OpenSCAD has no primitive. The simplest way to
specify ABECD is to make the shortest point-to-point connection, i.e. via
point E, into faces and disregard face B-C (the red line). This is not a
general rule, of course, if point E moves too close to line A-D, point E
would be disregarded, as B-C becomes shorter than B-E or E-C. For many cases
this rule suffices, and where not, why not add more vertices?
Let us now look at what happens when vertex vectors are truncated. What has
been said about the representation of points and faces for figure 1 is also
applicable to figure 2 and, later, figure 3. The yellow dots in figure 2
http://forum.openscad.org/file/n14500/Prism_2.prism_2
Figure 2
represent the values that a point vector can have, after truncation. Any
other points in the figure are represented by floats before truncation.
Those of you who are familiar with the cardinality of infinite sets will
recognise that by fixating floating point numbers to fixed positions in a
cartesian coordinate system, these floats have been translated into
integers, and I presume, it is also equivalent to Alan Cox' point
dictionary
http://forum.openscad.org/Inconsistent-conversion-of-floating-number-to-string-at-7th-significant-digit-td14350.html#a14412
.
All points of the square will be moved by truncating their vectors, to the
nearest yellow dot. The result of this "wiggling" is shown in Figure 3.
http://forum.openscad.org/file/n14500/Prism_3.prism_3
Figure 3
The square is no longer a square. If the original cube(), represented as a
square in Figure 2, had been rotated around an axis other than [0,0,1], none
of the original sides could be quadrangles any more, as truncation has moved
the vertices off the plane they originally shared.
Wolf
--
View this message in context: http://forum.openscad.org/Inconsistent-conversion-of-floating-number-to-string-at-7th-significant-digit-tp14350p14500.html
Sent from the OpenSCAD mailing list archive at Nabble.com.