(fix): use typesize on Blosc codec

[ilan-gold]

Fixes #2766 and fixes #2171
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 in docs/user-guide/*.rst
• Changes documented as a new file in changes/
• GitHub Actions have all passed
• Test coverage is 100% (Codecov passes)

[d-v-b]

this looks good @ilan-gold, we just a release note

[ilan-gold]

Apologies did not mean for you guys to do an immediate review, will keep that in mind next time, this was mostly to remind myself to finish up :)

[d-v-b]

no worries, I was trigger-happy here

[dstansby]

Is it worth adding a test for this that asserts a certain compressed size, so we can catch regressions in the future? The doctest is a nice way to catch this, but I worry that it might get removed or changed whereas a test is more likely to stay around.

[ilan-gold]

Does anyone have access to a windows machine? Or should we just xfail this and move on? I am not sure if the issue is numpy or the python version interacting with numcodecs here causing the sizes to be off. We can open an issue if someone can come up with access to a windows machine can create a repro

[dstansby]

Suggested change

	a = np.arange(1000000)
	a = np.arange(2**16, dtype=np.uint16)

As a thought, worth explicitly specifying the data type (and making the data smaller)? Don't know if it will fix the windows issue, but I think worth doing anyway os there's a concrete bytesize, and perhaps using integer data type will help with linux/windows because perhaps they have different floating point implementations (although that's wild speculation on my part...)

[ilan-gold]

arange is default uint64 so I'll push something with that added.

[ilan-gold]

The first four dumped characters on the failing windows case are:

\x02\x01\x91\x04@

while they should be

\x02\x01\x91\x08

This would indicate to me the typesize is being incorrectly encoded but I (a) don't know why and (b) don't know what the @ means.

[dstansby]

This would indicate to me the typesize is being incorrectly encoded but I (a) don't know why and (b) don't know what the @ means.

Weird... I'm guessing that would be an upstream numcodecs issue/fix, so we could probably cut our losses here and just xfail the test on windows for now.

[ilan-gold]

Ok @dstansby great call - it looks like it was just being explicit, there must be different behavior on windows for that version. There is a warning in the documentation https://numpy.org/doc/stable/reference/generated/numpy.arange.html but I figured we hadn't actually hit any of those conditions.

[rabernat]

Thank you @ilan-gold and @dstansby for working on this bug! I really appreciate your efforts. 🙏