Skip to content
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

Finalization for first release #8

Open
soroushzargar opened this issue Aug 31, 2019 · 0 comments
Open

Finalization for first release #8

soroushzargar opened this issue Aug 31, 2019 · 0 comments
Assignees
Labels
bug Something isn't working documentation Improvements or additions to documentation enhancement New feature or request help wanted Extra attention is needed

Comments

@soroushzargar
Copy link
Collaborator

Here are things we are supposed to do currently to have a tested, completed working package release:

  1. Inside lilcom_c_extension.c: There shouldn't be any miss-calculation on parameter passing and procedure inside extension functions. Following notes should be considered;
  • There are no default value and optional arguments passed to function. Any of these should be postponed to the wrapper module.

  • Return codes from both lilcom_c_extension.c and lilcom.c must be documented in the readme.md

  • Error codes must be the same as what is commented inside the code. All error values are better to be more than 100 in order not to be mistaken with conversion exponent.

  1. The wrapper:

I want to have the top-level interface callable from c as just lilcom.compress() and lilcom.decompress(), you can add import statements in the init file to make this possible.
Also, please test with close-to-denormal and close-to-infinite numbers.

  • Double-checking the code to check whether all conditions of the input array are handled.
  1. Test Procedure: These are the main testing procedures we might design:
  • Testing all possible workflows which call any function inside lilcom_c_extension.c.

  • Testing all possible workflows calling the wrapper

  • Quoted by @danpovey:

Please test with close-to-denormal and close-to-infinite numbers. I suggest to generate random normal data and then multiply by 2^n for n in, say, [-40, 40]. It should work as long as, when converted to single precision float, there is no inf or nan.

I'd like some graphs of SNR versus lpc_order for some real speech or music data; and also time taken versus lpc_order (to check it's roughly linear).

This is what I am going to figure out.

After doing these we are ready to go for a finalized distribution.

@soroushzargar soroushzargar added bug Something isn't working documentation Improvements or additions to documentation enhancement New feature or request help wanted Extra attention is needed labels Aug 31, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working documentation Improvements or additions to documentation enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

2 participants