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

InformationRate * Time = Information != Ratio #189

Open
exastion opened this issue May 25, 2020 · 1 comment
Open

InformationRate * Time = Information != Ratio #189

exastion opened this issue May 25, 2020 · 1 comment

Comments

@exastion
Copy link

I'm pretty new to this library, but I think I found a bug concerning multiplication of different quantities.
Multiplying InformationRate and Time should result in Information, at least I would assume this and as far as I can see from the example, this type of multiplication should be possible.
Here a MVE that illustrates the problem:

use uom::si::f32::*;
use uom::si::information_rate::byte_per_second;
use uom::si::time::second;
use uom::si::information::byte;

fn main() {
    let r = InformationRate::new::<byte_per_second>(10.0);
    let t = Time::new::<second>(1.0);
    let b = r * t;
    let _ = b.get::<byte>();
}

According to the compiler error, it produces a ratio:

❯ cargo build    
   Compiling mve v0.1.0 (/home/sven/Documents/mve)
error[E0277]: the trait bound `uom::si::information::byte: uom::si::ratio::Unit` is not satisfied
  --> src/main.rs:11:15
   |
11 |     let _ = b.get::<byte>();
   |               ^^^ the trait `uom::si::ratio::Unit` is not implemented for `uom::si::information::byte`

error: aborting due to previous error
@iliekturtles
Copy link
Owner

Thanks for the report. This is a known limitation and I believe specialization is needed to resolve. The current work around is to use into() to force the result's Kind associated type from the default that Ratio uses to InformationKind. e.g. let b = (r * t).into();

I'm leaving the issue open for the moment to review comments when InformationRate was implemented and see if there is any better solution that wouldn't require specialization.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants