-
Notifications
You must be signed in to change notification settings - Fork 1
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
Releasing v: 0.2 #57
Releasing v: 0.2 #57
Conversation
Integrated the Planner. |
/// Uncompresses the input file/directory | ||
#[arg(short, action)] | ||
uncompress: bool, | ||
|
||
/// Verbose output, dumps everysample in the input file (for compression) and in the ouput file (for decompression) | ||
#[arg(long, action)] | ||
verbose: bool, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe we should emit these as a debug!()
or trace!()
level logs instead.
That way the user can configure the log level to their needs and we avoid introducing multiple logging systems.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Moving this comment into a new PR with a discussion around this. I would also prefer that route, but, traditional UNIX CLI tools always have a flag for verbosity, that is why I created this one.
My idea is that Logs are more of a developer thing, we enable a certain level of logs to check the internals of the code. A user might want to have a flag to have more insight into the functioning of the tool.
Another option is: Can we fuse the flag with the logging levels?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You could certainly set the flag to enable a specific log level.
@@ -22,6 +22,23 @@ pub fn calculate_error(vec1: &[f64], vec2: &Vec<f64>) -> Option<f64> { | |||
Some(squared_error / min_length as f64) | |||
} | |||
|
|||
/// Computes the Normalized Mean Square Error between 2 signals | |||
pub fn nmsqe(original: &[f64], generated: &[f64]) -> Option<f64> { | |||
if original.len() != generated.len() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this is an error case maybe we should return an Err instead of None here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now that you touch this topic, I think we should panic
here. Error calculation is fundamental for getting the compressor settings right. Failing to calculate an error is not recoverable (Which samples should we drop? How did we even get different sizes to start with?).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Panicking sounds good to me!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would leave as an error if there is any possible input to brro that could trigger this case. Otherwise if it's purely internal then panic away.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice!
Releasing 0.2