Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

fix: check for non-int 0 fill values#3345

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Open
ilan-gold wants to merge9 commits intozarr-developers:main
base:main
Choose a base branch
Loading
fromilan-gold:ig/fill_val_0_nonint

Conversation

@ilan-gold
Copy link
Contributor

@ilan-goldilan-gold commentedAug 5, 2025
edited
Loading

A bit of an "oops" from me, but hopefully this is more robust (than#3082)! It worked for my one example but testing this without using a spy object seems impossible (happy to contribute that though, or some other test).

TODO:

  • Add unit tests and/or doctests in docstrings
  • Add docstrings and API docs for any new/modified user-facing classes and functions
  • New/modified features documented indocs/user-guide/*.rst
  • Changes documented as a new file inchanges/
  • GitHub Actions have all passed
  • Test coverage is 100% (Codecov passes)

@ilan-goldilan-gold changed the titlefix: check for non-int fill valuesfix: check for non-int 0 fill valuesAug 5, 2025
@github-actionsgithub-actionsbot added the needs release notesAutomatically applied to PRs which haven't added release notes labelAug 5, 2025
@codecov
Copy link

codecovbot commentedAug 6, 2025
edited
Loading

Codecov Report

❌ Patch coverage is50.00000% with1 line in your changes missing coverage. Please review.
✅ Project coverage is 61.85%. Comparing base (14b372c) to head (8ba90ce).
⚠️ Report is 1 commits behind head on main.

Files with missing linesPatch %Lines
src/zarr/core/buffer/cpu.py50.00%1 Missing⚠️
Additional details and impacted files
@@            Coverage Diff             @@##             main    #3345      +/-   ##==========================================- Coverage   61.86%   61.85%   -0.01%==========================================  Files          85       85                Lines       10111    10112       +1     ==========================================  Hits         6255     6255- Misses       3856     3857       +1
Files with missing linesCoverage Δ
src/zarr/core/buffer/cpu.py37.50% <50.00%> (-0.69%)⬇️
🚀 New features to boost your workflow:
  • ❄️Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@d-v-b
Copy link
Contributor

to test this, could we perhaps patchnp.full andnp.zeros to raise exceptions, that you would then catch in the test? I'm thinking there would be 2 test functions, 1 testing the various inputs that should hit thenp.full branch, and another testing the various inputs that should hit thenp.zeros branch. This could also work for a single test function that internally checks which numpy routine the input scalar should trigger

Copy link
Contributor

@dstansbydstansby left a comment

Choose a reason for hiding this comment

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

Looks good to me - needs a release note entry, and I left one suggestion to improve the test too.



@pytest.mark.parametrize("dtype", [np.int8,np.uint16,np.float32,int,float])
@pytest.mark.parametrize("fill_value", [None,0,1])
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
@pytest.mark.parametrize("fill_value", [None,0,1])
@pytest.mark.parametrize("fill_value", [None,0,0.0,1])

Worth explicitly including a float here?

Copy link
ContributorAuthor

Choose a reason for hiding this comment

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

I think everything is cast anyway bydtype, so it shouldn't matter, no?

@dstansbydstansby added this to the3.1.2 milestoneAug 11, 2025
@ilan-gold
Copy link
ContributorAuthor

I've done some digging into this topic, I'll post in a bit but I would like to hold off on merging for a bit.

@ilan-gold
Copy link
ContributorAuthor

Ok apologies, I know that Tom's PR supercedes this in many ways but for anyone curious, my worry was about how memory is allocated.

I learned thatzeros is only faster thanfull because it doesn't allocate memory when requested, lazily doing so later when needed (seehttps://stackoverflow.com/questions/70055063/how-is-memory-handled-once-touched-for-the-first-time-in-numpy-zeros/70056188#70056188). In benchmarks, I see the times of subsequent operations on the matrix, whether something likesum that should touch all elements or__setitem__ to be identical independent of initialization so I definitely think this should be merged!

importnumpyasnpbuf=np.arange(100_000,dtype=np.float64)# cell 1%%timeitfull=np.full((1_000_000,),0,dtype=np.float64)full[900_000:]=buf# cell 2%%timeitzeros=np.zeros((1_000_000,),dtype=np.float64)zeros[900_000:]=buf# cell 3%%timeitfull=np.full((1_000_000,),0,dtype=np.float64)full.sum()# cell 4%%timeitzeros=np.zeros((1_000_000,),dtype=np.float64)zeros.sum()
Screenshot 2025-08-25 at 16 46 16

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

1 more reviewer

@dstansbydstansbydstansby requested changes

Reviewers whose approvals may not affect merge requirements

At least 1 approving review is required to merge this pull request.

Assignees

No one assigned

Labels

needs release notesAutomatically applied to PRs which haven't added release notes

Projects

None yet

Milestone

3.1.2

Development

Successfully merging this pull request may close these issues.

3 participants

@ilan-gold@d-v-b@dstansby

[8]ページ先頭

©2009-2025 Movatter.jp