lipchev

This all looks to me. As for the release, it's up to you- I am currently preparing another pull request for a `DecimalFractionFormatter`: ``` /// /// Provides functionality to format...

Nah, I don't expect a change of the default ToString() behavior- this is meant as an option- in our case our Quantities (e.g. Mass / Volume etc) have their own...

As for the release version, it's up to you, but given that we haven't introduced any breaking changes yet, I'd probably release it as the "latest stable v7" so that...

Yes, i had to switch the order (will post the PR in a bit): ``` /// /// Initializes a new instance of the Fraction struct with the specified numerator and...

I haven't got anything prepared, but some house cleaning might not be a bad idea- a solution reformat, and re-comment (I think I saw somewhere that "..NaN is not supported")....

> @lipchev If you have no further objections, I would like to release version 8.0.0. If you are okay with that, please take another look at the changelog to see...

> > @lipchev If you have no further objections, I would like to release version 8.0.0. If you are okay with that, please take another look at the changelog to...

> * Operations with `Normalized` fractions are generally faster than the equivalent operations on `Improper` fractions Upon further reflection, I realized that this may not be always the case. Consider...

Yes, the multiplications are definitely going to be the least performant operations in the case of the non-normalized fractions (even the divisions are probably going to be faster). However, if...

> I don't see any advantage in introducing two data types (one for normalized, one for non-normalized fractions). In fact, by default, users automatically generate normalized fractions. All subsequent operations...