Dne 28.10.2015 v 20:31 Lisandro Dalcin napsal(a):
On 28 October 2015 at 19:29, Jed Brown <[email protected]> wrote:Barry Smith <[email protected]> writes:I don't want to be in the business of providing NaNs. They are nasty little beasts. PETSc should allow users to use NaN but should not enable them.FP non-normal values are also extremely slow on some architectures so it's a bad portability move to use them to identify missing values. (Or maybe future hardware will embrace in-band missing values and make sure NaN is fast.) In any case, signaling NaN is extremely useful for debugging.I would also like to have PETSC_SNAN define for signaling NaN.
Thumbs up!It is for me in some cases also the only or at least the least error-prone way to signalize e.g. value that needs to be set somewhere else, or value that is invalid, or invalidated value that needs to be recomputed etc etc.
In case of objects you have NULL but in case of numbers when you need all negative, 0 and positive values as valid, it's a problem. You need e.g. an extra PetscBool flag which can be tedious. Additionally, NaN value typically spoils the things quickly just like a NULL object so that a bug can be caught early.
Vaclav
smime.p7s
Description: Elektronicky podpis S/MIME
