Re: floating point precision control

[siko1056]

Mike Miller wrote
> All bugs are not related to Windows though. As I mentioned, the first time
> I was aware of this was on 32-bit GNU/Linux.

Sorry for my hasty conclusion. I read "Windows" too often in the bug
reports, that finally I got it wrong.


John W. Eaton wrote
> [...] the only place where we attempt to specifically use floating point
> types wider than 64-bits is in the code that deals with operations on
> 64-bit integers. [...] For actual floating point operations, we don't
> explicitly use extended precision [...] So I think the question is whether
> we should allow any computations for floating point type to use extended
> precision internally.

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. 


John W. Eaton wrote
> If you have some idea of a better way to handle operations for int64 types
> in a way that is compatible with Matlab's saturation semantics for integer
> operations, then please propose a patch.

By "saturation semantics" I think you mean "uint64 (10-20) == 0" and alike.
For Octave 4.2 this code should not be touched. But afterwards I can try to
propose a standardized integer solution. 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 same here, one day the semantics might change...


Mike Miller wrote
>> To sum up: Please stay with IEEE-754 binary64 and binary32. Fix the
>> Windows 
>> issues regarding the FP control word with some #ifdef __WIN32__ and a 
>> comment to drop all the code, if the floating-point issues are fixed in
>> the 
>> future and leave the FP control word as it is, but allow the user to set
>> it 
>> manually from command line. 
> 
> Here you are referring to the 64-bit integer computations in 
> oct-inttypes (#40607), correct? 

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.

Best,
Kai

[1]
https://www.gnu.org/software/octave/doc/interpreter/Integer-Arithmetic.html#Integer-Arithmetic
[2]
http://clang.llvm.org/docs/LanguageExtensions.html#checked-arithmetic-builtins
[3] https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html
[4] http://en.cppreference.com/w/cpp/header/cfenv



--
View this message in context: 
http://octave.1599824.n4.nabble.com/floating-point-precision-control-tp4678363p4678517.html
Sent from the Octave - Maintainers mailing list archive at Nabble.com.