I made this change in my code after some performance analysis.
Great catch. Looks like a free speedup to me.
There are tab/space issues that are messing with the whitespace.
The original file uses a mix of tabs and spaces for indentation. I have not be able to find any documentation on indentation style for Enzo, so I use two spaces for an indent. That is what seems the most common practice in the existing Enzo code. In this file, I only touched the lines in this section, so all the other lines are using the tab/space combination that they had before.
I can go through the rest of the file and make the indentation consistent, using whatever indentation style people like. The only down-side is that a lot of lines will change, merely because the indentation has been made consistent. (Not a big down-side, just more work for reviewers.)
I think it makes sense to maintain tab/spaces in files that already have it. I realize it's a bit of a lost cause. I generally use 4 spaces for tabs since it aligns with bitbucket's default (which also makes it easier for reviewers).
After playing around with my editor's interpretation of the tab character, I managed to understand the indentation style of the original file.
Do you like this better?
Much better, and the PR diff view is clearer to understand too!
Four approvals. I'm merging.
I think this sneaked in without the testing while the testing bot was down for a few days. I believe this may have introduced a FP roundoff change due to the summation order, which likely just requires a new gold standard, but it may be causing all the current PRs to fail. If someone could run the tests on this changeset and the one before it got merged to verify, that'd be great! Then I'll set up a new gold once verified.
Yes, this change does introduce a floating point roundoff change.
I'll take a quick look to double-check, but I think it's fine. (Also, I will push along the rest of the PRs soon.)