[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Underflow problem on NEC SX-4 in Cray-compatible mode

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: Re: Underflow problem on NEC SX-4 in Cray-compatible mode
  • Date: Tue, 24 Feb 1998 11:14:40 -0700
On Feb 24,  2:57pm, Harvey DAVIES wrote:
> The problem occurs in Cray (float2) mode when calling a netCDF put routine.
> On the NEC SX, netCDF converts from Cray to IEEE floating point by calling
the
> NEC function fl2_ie3 from various places in src/libsrc/ncx.c.  Underflow is
> possible because the Cray format has more exponent bits. Each underflow
> generates the (normally) desired value of 0, but does not increment the
> function result, which is a count of correct conversions.  E.g. 3 underflows
> in a vector of 8 elements would give a result of 5.  NetCDF detects the fact
> that this result is less than expected & generates error -60.  There appears
> to be no way of modifying the behaviour of fl2_ie3 to count underflows as
> normal conversions.
>
> One solution would be to count the values small enough in magnitude to
> underflow before calling fl2_ie3.  However, I suspect this would be too
costly
> in time to be worthwhile.  So (unless I am being too pessimistic here and
> Glenn Davis implements some such solution in ncx.c) the user should
anticipate
> the possibility of error -60 occuring in put routines.
>
> Harvey Davies, CSIRO Mathematical and Information Sciences,
> Email: address@hidden
> Phone: +61 3 9669 8110 or +61 3 9239 4556
>   Fax: +61 3 9669 8112

I had some correspondence with NEC engineers about similar problems at
the "high end" of the range. The upshot is that fl2_ie3() do the fastest
thing, error semantics be damned. I suspect that this "low end" thing
is more problematic.

We already ship routines which convert between CRAY1 floating point and IEEE,
in ncx_cray.c. On non-ieee Cray's it is the default to use these rather than
the CRI CRAY2IEG and IEG2CRAY routines, because our code is as fast and it
has the error semantics we desire. It should be possible to coerce this
code into working on NEC -float2.

My personal recommendation is to join the 1980's and use IEEE floating point
on your IEEE NEC machine.

-glenn