-
Notifications
You must be signed in to change notification settings - Fork 6
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
Different behavior on amd64 and arm #38
Comments
Thank you for reporting! On arm, are you using the precompiled In case you indeed compiled from source: I'd be happy to provide precompiled python packages for your platform going forward, but I'd need someone to test them, at least initially. Would you mind telling me what platform you're developing for and would you consider testing a precompiled python package on it? BackgroundThe second symbol in your example is encoded with a Laplace distribution with scale parameter Notes to Self
|
Assert that the scale (or equivalent) parameters of a Gaussian, Laplace, or Cauchy distribution is positive, and state this requirement in the python API reference. Previously, encoding and decoding with a Laplace distribution with zero scale did not raise any error but failed to reproduce the original message in general, see first comment on #38. Implements the first to-do item in #38.
This is probably what most people who build the python module want (and those who *don't* want to build in `--release` mode are probably rust developers, who know what the `--release` flag does). Implements the second to-do item in #38.
Thanks for your reply! I compiled from source following
and
Because I am pretty new to rust, I am not very sure whether I compiled the package in release mode at that moment. Unfortunately I dont have the original device to test the solution now. If the behavior is reproduciable on other platform in debug mode, I think this may be the main reason. By the way, when |
I make another test on amd64 import constriction
import numpy as np
message = np.array([10, 5, 6], dtype=np.int32)
entropy_model = constriction.stream.model.QuantizedLaplace(
-20, 20 + 1
)
encoder = constriction.stream.queue.RangeEncoder()
encoder.encode(message, entropy_model, np.array([10., 10., 10.]), np.array([10., 0., 0.]))
compressed = encoder.get_compressed()
print(f"compressed representation: {compressed}")
print(f"(in binary: {[bin(word) for word in compressed]})")
decoder = constriction.stream.queue.RangeDecoder(compressed)
decoded = decoder.decode(entropy_model, np.array([10., 10., 10.]), np.array([10., 0., 0.]))
print(decoded)
assert np.all(decoded == message) # (verifies correctness) the result is
May be there is some fallback when |
You are right, leakily quantized Laplace distributions with
This compiles in debug mode (i.e., it will result in a python package that contains more checks and fewer run-time optimizations). This explains the difference in behavior between your two builds. (For completeness, if you want to compile in release mode, use: I'm a bit unsure what the conclusion should be. On the one hand, one could interpret a Laplace distribution with On the other hand, there are two reasons against allowing
Request for feedbackTo help me decide, could you give me some more background on why you tested with a Laplace distribution with |
Thanks for your explanations! I am doing some research on Cool-Chic and encountered the case |
Thanks for the background information. I like the idea about a
Proposed SolutionThe problem of Regarding Precompiled Packages for armUnrelated to the specific issue reported here, please let me know if you'd be willing to test a precompiled python package for your computer architecture so I can upload official |
Thanks for your reply! Adding a small regularization is a good idea. As in previous comment, I don't have access to that device for now. If I get more detailed information, I will update the information here. |
Hi, I have got the original device, and I would like to know if you can provide a precompiled version now. I would be happy to do some testing. The system info is
The device is a Jetson nano and the recommanded version of python is 3.6. I found release v0.2.4 support 3.6 but failed to install it. Is it feasible to compile a newer version to the platform? |
Hi, I'm trying to use this package on arm devices, but I found inconsistent behavior on arm and amd64 platforms, what's the reason for this?
This is the test code
On amd64
On arm
The full traceback is
Thanks!
The text was updated successfully, but these errors were encountered: