Your way of using NaNs without them following the math out is reasonable. I would much rather be considering how glean which places in the spaces I review are best candidates for visits from participatory quiet nans, and how to speak that language without garbling words. The part that is most thought-provoking for me is where I may preposition a small, quiet flotilla somehow having equiped them with how to know when to gobble some context into the payload, and knowing they will --surf the math-- on out. It is a bit unquantumly -- these observers observe as the electromath happens, and they can ride it to our benefit, presumably. It seems that there is software architectural strength to accompany knowing productive ways of applying this tool and the mist or swarm of many at once. Its the sort of technology that is better understood when used.
On Monday, August 3, 2015 at 5:00:15 PM UTC-4, Jason Riedy wrote: > > And Jeffrey Sarnoff writes: > > IEEE 754-2008 makes it clear that QNaN payload values are fare game: > > (is says details of NaN propagtion may have vender differences, and) > > Having been in the room at the time of utter despair... (And > admittedly not having looked at your package yet.) > > One "right" way of using the NaN values without following their > propagation is the following: > - ensure the input has NaN payloads denoting something about > their origin and the likelihood of causing issues later, > - check the invalid flag at a felicitous time, then > - scanning to the inputs to rank the possible issues. > > This somewhat fits a Lispy with-NaN-debugging macro style (that > can at compile time ignore absolutely everything depending on the > safety level). Naturally, it's not guaranteed to work, and I'm > not at all sure how a user could fill in the payloads > appropriately. If there is a good answer to filling in the > payloads, well, the standard is up for revision... > >
