IEEE floating point can be made consistent, if you make the effort, at
least the standard places this requirement on language implementations. One
requirement is to set the mode bits consistently, which I don't think we
do. Trig functions (required for rotation) are usually implemented in the C
library, and I suspect that different implementations of sine or cosine (on
different OS versions) may return different results for the same input.

On Intel platforms, there is an extended precision 80 bit floating point
format. If you set the extended precision mode flag on the Intel GPU, then
intermediate results are represented with 80 bit precision, even though the
inputs and outputs of the operation are 64 bit. The ARM architecture lacks
this feature. If you disable extended precision mode, you should get the
same results on Intel and on ARM for basic operations implemented by the
FPU, although even here the standard provides a bit of wiggle room for
variation. I think that whether the extended precision flag is enabled or
disabled by default also varies with the operating system. Disabling it is
supposedly faster.

There is also a rounding mode that affects results, but that is less likely
to be the cause of your problem.

On 4 January 2016 at 03:31, nop head nop.head@gmail.com wrote:

Is the maths library statically linked? If so on a nearly identical
processor are we saying XP and Win7 set the extended precision flag
differently?

On 4 January 2016 at 13:19, doug moen doug@moens.org wrote:

I found something on stackoverflow indicating that there's a difference
between 32 and 64 bit windows w.r.t. floating point precision. Something to
do with SSE2 instructions.

"SSE2 also replaces the x87's IEEE 80-bit precision with the choice of
either IEEE 32-bit or 64-bit floating-point math. As a result, x86-64
processors running in 64-bit mode will produce floating-point results more
like those of most RISC CPUs, but those results will vary slightly from the
answers produced by legacy programs that use the x87 FPU due to the
difference in precision."

Does one of your machines have a 64 bit CPU?

On 4 January 2016 at 08:49, nop head nop.head@gmail.com wrote:

On Mon, 4 Jan 2016 08:19:01 -0500
doug moen doug@moens.org wrote:

And CPU version, compiler, compiler version, optimisations, and a few
other bits. Even static linked the CPU version can have an effect if the
library tests for CPU features and configures itself optimally.

CPU not GPU .. the GPU can't AFAIK handle extended precision at all.

Again depends on all sorts of things. Modern compilers and 64bit
toolchains will favour not emitting 8087 code in the first place.

Also to screw with your head - in some cases it matters if you are
compiling Ansi C or K&R C. The K&R standard says all floating arithemtic
is carried out double precision. Later standards allow a bit more
flexibility.

As I understand it 32bit Visual C++ uses double precision (64bit), while
the Intel compiler chain lets you select. GCC on Linux for 32bit will use
the 80bit precision for immediates, but 64bit will vary the intermediate
precision according to the types in use (eg float-float maths will
intermediate in floats)

C99: FLT_EVAL_METHOD is your "friend", although hitting yourself over the
head with a spade may feel more productive.

Alan

Thanks for testing that!
In 2014.03 and later we do indeed do some optimization to avoid CGAL usage where we don’t need it.
I didn’t expect this to trigger the behavior you mention, but I’m probably wrong.
I recently started on some refactoring where I decouple the transformation from the original object, which should improve this without having to fall back to doing everything in CGAL.
..but I’ll see if I can find the cause of your problem as well, in case I can find a more immediate fix.

-Marius

My understanding is both have 64 bit CPUs. The older one is running a 32bit
OS though. The executable is 32 bit as it runs on both.

On 4 January 2016 at 14:38, doug moen doug@moens.org wrote:

A related bug is that if the object doesn't go through CGAL show edges does
not work.

Also show edges stopped F5 displaying anything. It was only restored when
OpenScad was restarted with it off. Turning on Goldfeather seems to fix it.

On 4 January 2016 at 14:57, Marius Kintel marius@kintel.net wrote:

I was using Show Edges earlier today. It was behaving unreliably, then it
started working, but I didn't restart OpenSCAD nor enable Goldfeather. It's
working right now but I don't have a recipe for reproducing the problem.

On 4 January 2016 at 12:49, nop head nop.head@gmail.com wrote:

Yes I just turned Goldfeather off and show edges is still working, so it
seems intermittent. When it wasn't working thrown together still produced a
result but normal preview was empty.

On 4 January 2016 at 19:05, doug moen doug@moens.org wrote:

In this case, what happens is this:

• The first translate() first performs a CGAL union on the children, then transforms that while in CGAL
• The second translate() performs the transform on double precision floating point mesh, then converts to CGAL
• The final implicit union now has slightly different vertex positions for the same translation.

One workaround for such issues could be to force all calculations to be kept in CGAL as long as we have a parent node for which we’re going to need CGAL. Another workaround (as mentioned) could be to accumulate transformations and applying them only when concrete vertices are needed.
Note that using 2D objects probably also causes similar issues, which are a lot harder to avoid since all 2D operations are done in fixed point.

While chasing this, I’d strongly suggest that we try to refactor this to allow for using other CSG libraries in the future.

Cheers,

-Marius