Is this investigation going to be scheduled this year?

Was caused by a combination of:

1. Using single precision internally to calculate centroid errors, and
2. Using a threshold == 0.0 by default in the demo comparison.

Fixing the former (and regenerating the comparison tables) was sufficient to get the test to pass on both compiler versions, but probably we would like to fix the latter to some more sensible value too (at some later date).

While I limited the current changes to the centroid error calculation, I can imagine we would want to examine other cases where using single precision for internal (accumulation) variables can cause problems in the centroiding code.

I tested the fix on OSX and lsst-dev, but unfortunately, I cannot run CI because Jenkins ignores the branch for the demo (and always uses master).

Thanks for tracking this down!

I think it'd be helpful to add a bit more commentary in the commit message about exactly what's motivating this change.

Also, are there performance implications?

Relevant ticket for getting Jenkins to use the appropriate lsst_dm_stack_demo branch is DM-1357. However, if you have tested manually you can go ahead and merge — just stand by to bail Jenkins out if it breaks!

Merged. Did a quick performance test on the demo and didn't see a noticeable difference.