Detect native NaN values, warn about them

[inducer]

x-ref: https://github.com/inducer/pytools/issues/287

This might be a good place, though the mapper obviously would need to be renamed.

cc @matthiasdiener

[matthiasdiener]

Hmm, for the simple test in https://github.com/inducer/loopy/blob/698f29575f795fc54fba27e66e1b035cb8eb6634/test/test_target.py#L390-L399, parse (and thus FunctionToPrimitiveMapper) does not seem to be called with a nan argument. Is there a better place to perform this replacement?

[inducer]

On second thought, replacing "native" NaNs with pymbolic NaNs in one central location is probably not happening---there are too many possible "ways in", as you point out.

My next idea was to warn about them at code gen time, but it turns out that this is already being done:

https://github.com/inducer/loopy/blob/698f29575f795fc54fba27e66e1b035cb8eb6634/loopy/target/c/codegen/expression.py#L441-L450

The analogous check for Python is missing though:

https://github.com/inducer/loopy/blob/698f29575f795fc54fba27e66e1b035cb8eb6634/loopy/target/python.py#L67-L71

So that still needs to be added.

Did you see the warning above?

[matthiasdiener]

So that still needs to be added.

I can go ahead and this warning there. Should this also do a pymbolic.primitives.NaN replacement, like in the C codegen?

Did you see the warning above?

I did see the warning in some tests; it could probably be improved though:

• also mention np.nan in addition to math.nan
• "sound pickling/unpickling of kernel objects" seems bit misleading - isn't pickling in fine general, just the cache retrieval is an issue?

[inducer]

Should this also do a pymbolic.primitives.NaN replacement, like in the C codegen?

Maybe just warn? I'm not sure Python code gen has really been tested for NaNs. If you're willing to take on that test, then sure, it's probably easiest to do NaN codegen via replacement.

I agree with your warning improvements.