On Thu, Sep 5, 2013 at 5:45 AM, Roland Mainz <[email protected]> wrote: > On Tue, Sep 3, 2013 at 2:46 PM, Glenn Fowler <[email protected]> wrote: >> On Tue, 3 Sep 2013 02:50:31 +0200 Tina Harriott wrote: >>> I'm currently looking into a complex mathematical simulation (fluid >>> dynamics) and found references to NaN (Not A Number) with payloads. >>> The Nan values are used to represent 'no data' in the datasets and the >>> payloads are used for context information. The code has almost 2 >>> million lines of code and removing the feature would be a major >>> effort. >> >>> As we are in the process of using ksh93 as "interface" to the >>> simulation using libshell we need access to Nan values and their >>> payloads. >> >>> Can anyone give an estimate how hard it would be to add support for >>> Nan payloads to ksh93? >> >> I'm aware of NaN payload but have not seen C code that >> * has MIN/MAX macros for the min/max payload value for a give FP type > > See code attached code example... the maximum is the mask-1 ... the > minimum is either 0 or 1... I don't remember anymore... > >> * sets a NaN value with a specific payload >> * extracts a payload from a NaN >> are there standard api's for this? > > Yes... the function |nan()| - see > http://pubs.opengroup.org/onlinepubs/009695399/functions/nan.html > -- snip -- > double nan(const char *tagp); > float nanf(const char *tagp); > long double nanl(const char *tagp); > -- snip -- > > The trouble is... the exact string input is > compiler/libc/platforms-specific... and beyond highend HPC platforms > most platforms do not implement |nan()| with payload support. > > The other issue is that often compiler/libc/platforms-combinations to > not preserve the payload when a value is casted between _different_ > floating-point types. That problem isn't new and has haunted HPC > programmers since eternity... but the solution is to simply test with > C99 |isnan()| and then add some copy-payload code. Since |isnan()| is > basically a bit-pattern test the overhead is insignificant (on SX-8X > that's around 8 instructions more compared to a plain cast). > > If we implement NaN's with payloads we have to make sure that _every_ > cast between |Sfdouble| (basically a |long double|) and another > floating-point type is guarded with such copy-payload code... except > when we pass the value to a arithmetricfunction like |sin()|/|cos()| > etc. which (intentionally) discard the payload if they pass the Nan > through. > > Attached (as "nan_payload_test1_20130904_001.c.txt") is some prototype > code which shows now to handle NaN payloads... > > * Notes: > - The code explicitly requires ISO C99 semantics > - The code relies on |__int128_t| to handle |long double|. Originally > I thought about handling the code using byte-by-byte masking... but it > turned out that this creates a lot of mess and is endian-specific. The > final code may have to resort to that to be portable but for now I > use |__int128_t| to keep the code readable
Uhm... any feedback/suggestions ? Adding Nan payload support seems to be easy and doesn't come with a measureable performance penalty (since we only do extra work *if* there is a payload, otherwise most code has only "wrapper" overhead) ... if there are no objections I can try my luck and add this to ksh93's arithmetic engine... ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) [email protected] \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) _______________________________________________ ast-developers mailing list [email protected] http://lists.research.att.com/mailman/listinfo/ast-developers
