Average profile

[githubdoe]

Fixed the highlight slope error bug.
close #312

[gr5]

The errors above are pretty easy to fix. the qt5 pro file was never edited (that causes the qt5 errors). The main pro file seems to have an error in the pro file. I might just do the fixes myself but try building myself later today.

[github-actions]

Cpp-Linter Report ⚠️

Some files did not pass the configured checks!

clang-tidy (v18.1.3) reports: 1 concern(s)

• profileplot.cpp:431:5: warning: [clang-analyzer-security.FloatLoopCounter]

  Variable 'rad' with floating point type 'double' should not be used as a loop counter

    431 |     for (double rad = -1.0; rad < 1.0; rad += steps) {
        |     ^                       ~~~        ~~~
  profileplot.cpp:431:5: note: Variable 'rad' with floating point type 'double' should not be used as a loop counter
    431 |     for (double rad = -1.0; rad < 1.0; rad += steps) {
        |     ^                       ~~~        ~~~

Have any feedback or feature suggestions? Share it here.

[github-actions]

Cpp-linter Review

Used clang-tidy v18.1.3

Have any feedback or feature suggestions? Share it here.

[github-actions]

Cpp-linter Review

Used clang-tidy v18.1.3

Have any feedback or feature suggestions? Share it here.

[github-actions]

Cpp-linter Review

Used clang-tidy v18.1.3

Have any feedback or feature suggestions? Share it here.

[github-actions]

🚀 New build available for commit b8fdb79
Download installer here

[github-actions]

🚀 New build available for commit fc97675
Download installer here

[github-actions]

🚀 New build available for commit 2c01f57
Download installer here

[atsju]

Even if this is old code, I suggest we get rid of the for loops using double I had to ask AI to explain the logic behind the loop while it's just going from minus wf->m_outside.m_radius to plus wf->m_outside.m_radius pixel by pixel.

Would be easier to read, less bugprone and cleaner.

Do you agree or do I leave it alone ?

[github-actions]

Cpp-linter Review

Used clang-tidy v18.1.3

Have any feedback or feature suggestions? Share it here.

[github-actions]

clang-tidy diagnostic

profileplot.cpp:431:5: warning: [clang-analyzer-security.FloatLoopCounter]

Variable 'rad' with floating point type 'double' should not be used as a loop counter

  431 |     for (double rad = -1.0; rad < 1.0; rad += steps) {
      |     ^                       ~~~        ~~~
profileplot.cpp:431:5: note: Variable 'rad' with floating point type 'double' should not be used as a loop counter
  431 |     for (double rad = -1.0; rad < 1.0; rad += steps) {
      |     ^                       ~~~        ~~~

[gr5]

I think it's fine as is. I don't think the outer radius (wf->m_outside.m_radius) is specified in an integral number of pixels anyway - that's a float that can be for example 300.5 (it can be integral or on the halves).

Yes you could have a fp summation rounding error and get one too few in the profile plot. At the end of the plot. At this time I don't think it's a problem (I don't think you can get one too many as there is also code to see if we go beyond the outer radius).

What I don't love is that we aren't grabbing the nearest wavefront point under the line but rounded down to the nearest integer: wf->workData(dy, dx). Dy could be 100.9 and we get the point from dy position 100.

Ideally do a weighted average of the nearest 4 points, weighted by the distance to each point. And handle edge cases where some of the 4 points are outside the mask. We do all that when we rotate wavefronts if I remember right.

But really it's all fine as is.

[atsju]

yes 0.5 pixels. This makes it more difficult to "fix" than first reading.
OK for me.

[github-actions]

🚀 New build available for commit 91c4d4b
Download installer here

[gr5]

I just played with this PR and I love the new way of doing surface error. I think we should go ahead and merge.

I'm hoping we can do a release today as well. I promise to test this version a lot more than usual. I have a QA list now that I go through. It's not 100% comprehensive but will hopefully catch everything important.

I'll go add this feature to the revisionHistory PR...

[githubdoe]

Thanks all guys. I notice that sometimes not all when more than one wave is selected and you select show all 3D surface it displals them twice. I don't know the trigger. But it happens most when a new wave front has been added to the list. I putting that here just to see if you see it and to test that.

[gr5]

and you select show all 3D surface

You mean this button below?

I think it just displayed the entire window with the expected 3d plots but it created 2 windows. I think. Maybe. Is that what you mean? I think I closed the window and there was another one behind it. I can't duplicate.

[githubdoe]

Yes two windows sometime. Usually the first time and sometime then again.

[gr5]

Well it's not a serious problem for the user. I guess somehow I double clicked on the button? I mean I tried to double click on purpose and it didn't do it.

I'll keep my eye out to simplify duplicating the issue.

[githubdoe]

As far as I can tell I don't double click the button yet it happens. Sometimes for many times in a row. But, yes it is not too much of a problem. Eventually when we can figure out a cause then write up an issue.

[githubdoe]

The double in the for loop is not going to cause any problem. It gives a much better idea as to what the loop is doing than if you tried something else. It could be an issue if you were comparing to equal but not with a less than or greater than.