I'm interested in a version of Prolongation=None which results in poisoning of the boundary region during the prolongation step. Does such a thing exist?
Cheers, Steve
That's a clever idea. We should implement this.
No, it doesn't exist yet.
-erik
On Thu, Sep 17, 2015 at 2:41 PM, Steven R. Brandt sbrandt@cct.lsu.edu wrote:
I'm interested in a version of Prolongation=None which results in poisoning of the boundary region during the prolongation step. Does such a thing exist?
Cheers, Steve _______________________________________________ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
On 17 Sep 2015, at 21:12, Erik Schnetter schnetter@cct.lsu.edu wrote:
That's a clever idea. We should implement this.
No, it doesn't exist yet.
I agree - this is a very nice idea.
One of my favourite rants is this:
Don't use NaN for poison! If you do, then you cannot tell the difference between NaNs generated because of numerical problems, and poison generated due to programming bugs. These are really two different classes of problem, and it is very useful to be able to tell them apart. Instead of NaN, you can use a specific floating-point value, such as 10^200, or something that is obviously not a correct part of the simulation (you would have to be extremely unlucky, 1 in 2^64) to numerically-generate the exact floating point value that you chose, assuming it is large) . If you see that value in the simulation, then you are seeing poison, and it's a programming error. If you see NaN, it's a numerical problem.
Hello all,
Don't use NaN for poison! If you do, then you cannot tell the difference between NaNs generated because of numerical problems, and poison generated due to programming bugs.
Not true really. There are multiple "nan" values. See eg http://en.cppreference.com/w/c/numeric/math/nan and if you use nan("17") for poison you will be able to tell it apart from the nan that you get out of 1./0 and sqrt(-1.) type errors.
Attached it is a simple C99 program to demonstrate this. Basically it means that to detect poison you need to use memcmp (which we already do) and that in floating point arithmetic a nan("17") propagates as a nan("17") when combined with other non-NaN numbers but may be wiped when combined with a NaN (which would also wipe a non-NaN poison value though).
Yours, Roland
On 18 Sep 2015, at 08:27, Roland Haas rhaas@aei.mpg.de wrote:
Hello all,
Don't use NaN for poison! If you do, then you cannot tell the difference between NaNs generated because of numerical problems, and poison generated due to programming bugs.
Not true really. There are multiple "nan" values. See eg http://en.cppreference.com/w/c/numeric/math/nan and if you use nan("17") for poison you will be able to tell it apart from the nan that you get out of 1./0 and sqrt(-1.) type errors.
Attached it is a simple C99 program to demonstrate this. Basically it means that to detect poison you need to use memcmp (which we already do) and that in floating point arithmetic a nan("17") propagates as a nan("17") when combined with other non-NaN numbers but may be wiped when combined with a NaN (which would also wipe a non-NaN poison value though).
Fascinating. I had no idea that there was more than one NaN value. The wikipedia page https://en.wikipedia.org/wiki/NaN explains it is more detail than the cppreference page.
The conversion from the character representation to the binary representation appears to not be defined by the C/C++ standard, so presumably is left up to the compiler / libc / platform. Also, I suspect that this usage of NaN payloads is not well supported by most analysis software.
Apart from those concerns, yes, it would be very good to use a specific type of NaN to represent poison.
users@lists.einsteintoolkit.org
-
Erik Schnetter -
Ian Hinder -
Roland Haas -
Steven R. Brandt