Use something other than ORTNaN Checker about nnsmith HOT 3 CLOSED

Even for onnxruntime itself, using onnxruntime for something other than compilation is a bit weird... I would say we should perform NaN checking and other sanitizing based on PyTorch at the generation phase rather than after that... This is because the model is useless if you cannot find viable inputs. And you will waste a lot of time converting it to another framework just for "NaN checking" and (de) serialization.

from nnsmith.

Thanks, Jinkun!

from nnsmith.

This is because the model is useless if you cannot find viable inputs. And you will waste a lot of time converting it to another framework just for "NaN checking" and (de) serialization.

Not really. The model is still able to detect crash bugs, which are the most common one I can foresee.

I would say we should perform NaN checking and other sanitizing based on PyTorch at the generation phase rather than after that...

Do you mean only adding a node if it doesn't trigger nan? This is what I previously proposed when I said "tailor graph gen to inputs". But now I fear this might bias the graph distribution to generate "easy graph" that won't have nan issue, though one can also argue "hard graph" is less of practical meaning and we should avoid... I am fine with both routes.

from nnsmith.