Add support for bytes?

[waywardmonkeys]

Would support for 'bytes' be within scope for this library? Would that work out well with using f32 / f64 storage? It seems like perhaps using u64 for bytes, but floating point for all larger units might be useful?

[iliekturtles]

Do you mean bytes as a underlying storage type ([u8; N]) or bytes as a unit of measure (megabytes, kilobytes, ...)?

For the later it can be done right now using f32/f64 as the underlying storage type and I added #29 last week that would allow the system to be setup with u64 as the underlying storage type.

#[macro_use]
mod information {
    quantity! {
        quantity: Information; "information";
        dimension: Q<P1>;
        units {
            @byte: 1; "B", "byte", "bytes";
            @kilobyte: 1024; "kB", "kilobyte", "kilobytes";
            ...
        }
    }
}

system! {
    quantities: Q {
        information: byte, B;
    }
    units: U {
        Information,
    }
}

// Requires #29.
mod u64 {
    mod s { pub use ::*; }
    Q!(u64::s, u64);
}
// Works today.
mod f64 {
    mod s { pub use ::*; }
    Q!(f64::s, f64);
}

If you looking to plug in arbitrary external types as the underlying storage type the library implicitly requires the type to implement all the necessary operations (+, -, *, /, sqrt, ...) so a [u8; N] type wouldn't work without more work. I also believe it to be possibly to remove the implicit operator implementation requirement and setup explicit requirements in appropriate where clauses (I didn't go this way originally because the where clause gets huge). This change would make it easier to use an external type without requiring changes within uom.

[valpackett]

Would be nice to see this mod information already included in the library. With correct prefixes though :) e.g. @kilobyte: 1000; "kB", "kilobyte", "kilobytes" and @kibibyte: 1024; "KiB", "kibibyte", "kibibytes"

[iliekturtles]

I added a couple very rough implementations of Information. The first creates an entirely new system as shown in my comment above. The second adds Information as an additional dimension to the ISQ. The benefit of the second is that it can be used with other SI units to create derived units such as information rate (bit/s).

I'm leaning towards the second implementation and welcome feedback.

[valpackett]

Yes of course the second one is better!

[Jezza]

Just wanna bump this as it's pretty useful functionality to have.

[Lukazoid]

Like others I would really like to see this, what's blocking this from being included?

[iliekturtles]

Mostly the time to implement is blocking this from being completed (PRs welcome!). Resolving this issue also isn't as simple as just merging the information branch linked above. Since Information isn't part of the ISQ I'd like to see it gated behind a feature. The range of values / ergonomic use may also be a bit limited until #107 is complete.

[Lukazoid]

Could Information not be implemented as a dimensionless quantity in the same way Angle is?

[iliekturtles]

If Information was implemented as a dimensionless quantity you wouldn't be able to measure quantities like bytes per second.

[Lukazoid]

I can see the crate supports angular_velocity, could baud_rate be added in the same fashion?

Or AngularVelocity have the same limitation and cannot be obtained from an Angle and Time?

[iliekturtles]

Angle, AngularVelocity, and other current types that share a dimension with another quantity have a different kind. The same thing could be done for Information but it isn't very ergonomic and I'm not sure if it's the right solution.

[Aehmlo]

The SI brochure specifically and repeatedly states that “counts” (which I would classify “number of bits” as in the context users are asking for) are of unit one. Obviously, we don’t want other dimensionless quantities to coerce as information quantities. To my mind, this is exactly the use case for kinds.

If we think a little abstractly for a moment, the difference between the “regular” kind and the angle kind is that they work in two different spaces: the basis of an angular quantity is fundamentally different from a linear quantity. By the same token, “amount of encoded information” or “rate of change in encoded information” are fundamentally different bases than “count” or “oscillation rate.”

I understand and appreciate the wariness of just slapping another kind down and what I assume is a concern about precedent), but I think this is a useful functionality to expose and also don’t know that it makes sense to develop a new, orthogonal system for separating quantities of the same dimension when we already have such a system.

I also think that “information” extends a lot more beyond “people want to describe a computer’s address space”: there are some fundamental discussions about information and information density in math and physics, and I think we also ought to expose units used in areas like these if the requested functionality is added.

With all that said (sorry for the wall of text!), I would be happy to send an implementation PR, as I know you’ve said you’re short on time and I’ve got some to spare. (I’m also planning to send a PR finishing the impl From<Time> for Duration work.)

[iliekturtles]

Considering information a "count" definitely simplifies implementation. My original intuition was that there should be a dimension, but after doing a bit more reading today a dimensionless quantity seems to be the correct way to go.

A PR would be very welcome. See the information branch for some of the work I did.

[Lukazoid]

@iliekturtles I have been working on implementing this, I just have a question, is there any way in a quantity definition for one unit to refer to the conversion of another unit either for less duplication or for unit aliases?

For unit aliases it would be cool if the following were possible:

@bit: prefix!(none) / 8.0; "b", "bit", "bits";
@shannon: @bit; "Sh", "shannon", "shannons";

And for conversions:

@deciban: prefix!(deci) * @hartley; "dHart", "deciban", "decibans";

[iliekturtles]

Great to hear you're working on a PR! Using another unit isn't supported currently. It should be possible to implement and I'll add an issue to investigate.

[iliekturtles]

@Lukazoid, thanks for taking up this issue and submitting a PR! Exciting to see it finally closed.