[Numpy-discussion] Disabling Extended Precision in NumPy (like -ffloat-store)
Fri Apr 23 12:36:40 CDT 2010
On 21 April 2010 23:04, Adrien Guillon <firstname.lastname@example.org> wrote:
> Thank you for your questions... I'll answer them now.
> The motivation behind using Python and NumPy is to be able to "double
> check" that the numerical algorithms work okay in an
> engineer/scientist friendly language. We're basically prototyping a
> bunch of algorithms in Python, validating that they work right... so
> that when we move to the GPU we (hopefully) know that the algorithms
> are okay sequentially... any problems we come against therefore would
> have to be something else with the implementation (i.e. we don't want
> to be debugging too much at once). We are only targeting GPUs that
> support IEEE floating point... in theory the results should be similar
> on the GPU and CPU under certain assumptions (that the floating point
> is limited to single precision throughout... which Intel processors
> are a bit funny about).
> The main concern I have, and thus my motivation for wanting a
> restricted mode, is that parts of the algorithm may not work properly
> if done in extended precision. We are trying to ensure that
> theoretically there should be no problems, but realistically it's nice
> to have an extra layer of protection where we say "oh, wait, that's
> not right" when we look at the results.
> The idea here, is that if I can ensure there is never extended
> precision in the Python code... it should closely emulate the GPU
> which in fact has no extended precision in the hardware. Ordinarily,
> it's probably a silly thing to want to do (who would complain about
> extended precision for free)? But in this case I think it's the right
Funny you should ask: if you look in the mailing list archive you'll
find that we were just recently bitten by this in the function
log10_1p: the algorithm was one of those clever numerical analyst's
hacks where the roundoff in one part was supposed to cancel the
roundoff in another part, but extended precision was being used for
one part and not the other. The ultimate solution is to just use the
base e log1p, which we either get from the standard library or
implement ourselves in a way that doesn't require this delicate
> Hope this clarifies the reasons and intentions.
> On Wed, Apr 21, 2010 at 1:20 PM, Christopher Barker
> <Chris.Barker@noaa.gov> wrote:
>> Adrien Guillon wrote:
>>> I use single-precision floating point operations.
>>> My understanding, however, is that Intel processors may use extended
>>> precision for some operations anyways unless this is explicitly
>>> disabled, which is done with gcc via the -ffloat-store operation.
>> IIUC, that forces the FPU to not use the 80 bits in temps, but I think
>> the fpu still uses 64 bits -- or does that flag actually force singles
>> to stay single (32 bit) through the whole process as well?
>> Christopher Barker, Ph.D.
>> Emergency Response Division
>> NOAA/NOS/OR&R (206) 526-6959 voice
>> 7600 Sand Point Way NE (206) 526-6329 fax
>> Seattle, WA 98115 (206) 526-6317 main reception
>> NumPy-Discussion mailing list
> NumPy-Discussion mailing list
More information about the NumPy-Discussion