Re: floating point precision control

[John W. Eaton]

On 07/15/2016 04:35 AM, siko1056 wrote:

> This is true, but I vote against using binary80. I am afraid one might rely
> on 80 bits, and one day, all code gets compiled to 128 bits and subtle
> errors occur.

It's fine with me if we try setting the options for strict 64-bit 
operations and attempt to keep that setting after any library calls that 
are known to reset it.

> By "saturation semantics" I think you mean "uint64 (10-20) == 0" and alike.

Yes.

> For Octave 4.2 this code should not be touched. But afterwards I can try to
> propose a standardized integer solution.

OK.

> Enforcing saturation in the
> standard operations, Stackoverflow has plenty of ideas. Maybe compiler
> instructions like __builtin_add_overflow [2], [3] or Intrinsics might help
> for speed.

But functions like that are also system dependent.  And I think the 
solution we have now works, so changing it is not important to me unless 
there is a much cleaner, faster, and/or portable method that we can use.

> But same here, one day the semantics might change...

What semantics might change?

> I was too vague. My opinion is, we should introduce an option to get and set
> this FP control word using C++ standard routines [4] where possible (this
> was also interesting for e.g. the interval package too, regarding rounding
> modes). Then, if 32-bit Users, Mac Users, ... experiences problems, they can
> quickly help themselves by calling a m-language routine like
> "__octave_set_default_FP_environment__ ()" to save their day and keeping our
> code "clean" from hardware dependencies.

Yes, we should definitely isolate the system dependencies.  Death to the 
#ifdefs!

jwe