Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Improve visual_test.py #3732

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
Feb 11, 2019
Merged

Improve visual_test.py #3732

merged 4 commits into from
Feb 11, 2019

Conversation

cgohlke
Copy link
Contributor

@cgohlke cgohlke commented Feb 7, 2019

Description

Do not run the script when running pytest on an inplace build.
Clean-up and speed-up (10x) calculations of the donuts volume.
Many style fixes, passing flake8.

Checklist

For reviewers

  • Check that the PR title is short, concise, and will make sense 1 year
    later.
  • Check that new functions are imported in corresponding __init__.py.
  • Check that new features, API changes, and deprecations are mentioned in
    doc/release/release_dev.rst.
  • Consider backporting the PR with @meeseeksdev backport to v0.14.x

Do not run the script when running pytest on an inplace build.
Clean-up and speed-up (10x) calculations of the donuts volume.
Many style fixes, passing flake8.
Copy link
Member

@jni jni left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cgohlke thanks for this improvement! I've left some comments that I think could further improve this code, but none are essential.

@@ -3,70 +3,118 @@
data.
"""

from __future__ import print_function
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't support Py2.7 on master so this is unnecessary.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added it for backport to 0.14.x

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My policy generally has been to leave any backport-required code for the backport, but to each their own. ;)

x1 *= x1
x2 = x + y2 + zc
x2 *= x2
vol[iz, iy, ix] = ((x1 - d * (x + y1)) * (x2 - d * (z + y2)))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks eminently vectorisable...?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that it'll use more memory, but I disagree that it'll be less readable. It would presumably read like an actual formula, which right now I can't for the life of me figure out based on this code. But on the other hand this was even more true in the previous version of the code! So, as mentioned before, this is fine. =)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we at least agree that constructs such as:

z = iz * a + b
z *= z

should be replaced by

z = (iz * a + b) ** 2

There are many of them in here, and github's suggestion feature doesn't see appropriate.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess not, it makes things slower. 40 ms as written, and 47 ms with the ( ) ** 2 suggestion.

Using fully vectorized code, it goes down to 2ms

def donuts():
    """Return volume of two donuts based on a formula by Thomas Lewiner."""
    n = 48
    a = 2.5 / n * 8.0
    b = -1.25 * 8.0
    c = 16.0 - 1.85 * 1.85
    d = 64.0
    
    i = np.arange(n, dtype=int)
    ia_plus_b = i * a + b
    ia_plus_b_square = ia_plus_b ** 2
    z = ia_plus_b_square[:, np.newaxis, np.newaxis]
    zc = z + c
    
    y1 = ((ia_plus_b - 2) ** 2)[np.newaxis, :, np.newaxis]
    y2 = ((ia_plus_b + 2) ** 2)[np.newaxis, :, np.newaxis]
    
    x = ia_plus_b_square[np.newaxis, np.newaxis, :]
    x1 = (ia_plus_b_square + y1 + zc) ** 2
    x2 = (ia_plus_b_square + y2 + zc) ** 2
    
    return ((x1 - d * (x + y1)) * (x2 - d * (z + y2))) + 1025

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess not, it makes things slower. 40 ms as written, and 47 ms with the ( ) ** 2 suggestion.

Well, in this case, readability trumps speed, or we wouldn't be doing such a loop in Python.

But I agree that the vectorised version is better.

@pep8speaks
Copy link

pep8speaks commented Feb 10, 2019

Hello @cgohlke! Thanks for updating the PR.

Cheers ! There are no PEP8 issues in this Pull Request. 🍻

Comment last updated on February 10, 2019 at 19:22 Hours UTC

@hmaarrfk
Copy link
Member

I don't mind pep8 so much for whiltespace lines, most of my editors remove them automatically. spyder wasn't configured correctly...

@hmaarrfk
Copy link
Member

@cgohlke I think you are right that writing a for loop isn't a terrible idea, but this would be a perfect place where a project like pythran might be useful.

range and iterables in python are horrendously slow. it is one of my biggest gripes with the language.

Whats the review process say now @jni. I can't merge this myself can I? Do we have to wait for an other core-dev?

@jni
Copy link
Member

jni commented Feb 11, 2019

@hmaarrfk

Whats the review process say now @jni. I can't merge this myself can I? Do we have to wait for an other core-dev?

Great questions all! In fact we don't have a guideline for this. In the past my internal guide has been "merge ok if changes are minor (typos, comments, variable naming), wait if changes are significant (major code restructuring, logic changes, and definitely for API changes)". We should probably add something to the core dev guide about this.

In this specific case, the changes are significant, but it is a minor file that is rarely run, so I'd be ok with merging if @cgohlke is ok with the changes you made. (Personally I like them. And I've verified locally that it works.) @cgohlke?

@hmaarrfk
Copy link
Member

Yeah. Sorry about just pushing to your branch. I figured you knew how to revise to remove the changes ;)

@jni jni merged commit 93293f7 into scikit-image:master Feb 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants