0.8 is an irrational number in binary floating point so it is not
surprising it doesn't exactly equal an integer when multiplied by 10.

On 4 June 2015 at 10:33, Ian Gibbs realflash.uk@googlemail.com wrote:

I had a feeling there might be floating point reason. I've made it
work by counting from 1 to 10 instead and then dividing by 10
elsewhere.

Thanks!

On 4 June 2015 at 10:38, nop head nop.head@gmail.com wrote:

I was about to suggest:

for( i = [0:10] )
{
x_offset = i % 2 ==0 ? 0 : -3;
echo(str(i, ” - ‘, x_offset));
translate([x_offset, 0, 5 * i])
cube([3, 3, 1]);
}

Regards,
Jean-Paul
AC9GH

No need to divide by 10... just don't multiply by 10... try this (untested)

for(i = [0: 1: 10])
{
x_offset = i%2==0 ? 0 : -3;
echo(i);
echo(x_offset);
translate([x_offset,0, 5*i])
cube([3,3,1]);
}

On Thu, Jun 4, 2015 at 10:24 PM, Ian Gibbs realflash.uk@googlemail.com
wrote:

nophead wrote

I'm a little confused here. Isn't the point of the multipe precison
libraries MPIR/GMP/MPFR to prevent 0.8 becoming irrational en use an
internal representation like  (8/10) to represent 0.8  ?

--
View this message in context: http://forum.openscad.org/Odd-ternary-behaviour-2015-05-15-nightly-git-5451fab-tp12784p12800.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

Rational numbers are very slow compared to floating point. They also take
up a lot of memory, especially if you do long chains of multiply/divides,
which causes the denominators to get increasingly bigger.

The OpenSCAD language uses floating point to represent numbers (which is
good, for speed). But then it uses CGAL for rendering, which involves
translating those floats into rational numbers. CGAL is incredibly slow,
and one significant reason is the use of rational numbers.

In the long term, I expect OpenSCAD will replace CGAL with a floating point
geometry kernel, and then it will become much faster and use less memory,
which will make it possible to build more complex models than what are
currently feasible. Of course, to do this we'll need to find and use
techniques to deal with the imprecision that accumulates during a chain of
floating point operations. But the advantages of faster operation and the
ability to model more complex objects will make this approach compelling.

It would also be possible to change the OpenSCAD language to use rational
numbers, but this is less helpful than it might first appear. This might
address some of the problems recently raised in the forum, such as Ian
Gibbs' issue with the % operator. But there's another current issue with
rotating a polygonal face and having it become non-planar. Unfortunately,
certain common operations, like rotation, involve trigonometric functions
whose results are irrational, so rational numbers don't help. If the
language used rationals, it would still have to convert back to float to
handle sqrt and trig.

Doug Moen.

On 5 June 2015 at 16:15, Ivo ivo.knutsel@gmail.com wrote:

On 2015-06-05 23:39, doug moen wrote:

Please define "rational numbers" in terms of CGAL. This sounds like some
none-native object replacing C++ double. If that is so, no wonder
OpenSCAD takes forever to complete computing slightly non-trival models,
using insane amounts of memory.

I have recently created an OpenSCAD model that was somewhat non-trivial,
although quite small compared to models I used to work with 10+ years
ago, using a commercial library (ACIS). I managed to complete my
OpenSCAD model, but it was painfully slow and I will not attempt
anything larger as things stand.

Perhaps the argument for "rational numbers" in CGAL is some illusion of
infinite precision. The fact that you may end up with non-manifold STL
files anyway, shows it really isn't worth it. In ACIS the stated
precision was 1E-6 using ordinary doubles, and we had success using it
(of course there were numerical problems at times). 1E-6  means one
millionth of a millimeter if the model units is in mm. For 3d printing
purposes it is sufficient.

I have a long term goal of revisiting OpenCascade, but it will take time
to do so. It is 20 years since I (briefly) looked at it.

Is it possible to use CGAL with only native double variables, avoiding
"rational numbers" entirely? If yes, this would be an interesting short
term thing to try and see if it would speed things up. If no, then a
replacement such as OpenCascade might become a desired goal sooner.

Carsten Arnholm

Rational numbers in OpenSCAD :
https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/Building_OpenSCAD_from_Sources#CGAL_and_GMPQ

I was slightly surprised to find rational numbers used as well, it does
explain the speed and size requirements which had always puzzled me. CGAL
offers different kernels, I don't know how much work is required to change
to a native floating point kernel.

I am just looking at changing the backend code in OpenScad to support
colors etc, I had planned to adapt the Nef polyhedra but now I am wondering
if it would be better to start with a different backend.

Last time I looked at OpenCascade I was unable to build it, I had trouble
getting the demo to run. Hopefully the community edition OCE is now more
polished.

On 7 June 2015 at 12:52, Carsten Arnholm arnholm@arnholm.org wrote:

On 06/07/2015 01:52 PM, Carsten Arnholm wrote:

The issue is not so much the actual values, but the algorithms go
unstable. E.g. if the algorithm needs to decide if a point is left
or right of a line and totally fails when getting the wrong answer,
it's essentially useless when using floating point.

It would be interesting to get some information about other options.
For some additional pointers/libs, see
https://github.com/openscad/openscad/wiki/Project%3A-Survey-of-CSG-algorithms

I'm not sure a huge thing like OpenCascade is the right way to go.
A big question would be how to get issues solved that involve the
CSG kernel. Right now my impression is that it's quite hard to do
with CGAL. Of cause that's not easy to find out...

I think CGAL does need exact predicates to work for the CSG stuff
(currently Exact_predicates_inexact_constructions_kernel is used).

ciao,
Torsten.