Feat/serde

[Roms1383]

Add support for serde, based on latest fpdec release.

Related to #8

[Roms1383]

As a side note since I bumped fpdec to rely on serde-as-str feature, and got a proc macro panic! because MAX_N_FRAC_DIGITS was reduced to 18 (introduced in commit ba41dae) while a couple of measures still have greater exponents in astronomical_quantities, for example Kilometer.

I'm not sure if I should reduce definitions' exponents accordingly in astronimical_quantities or proceed otherwise, so waiting for your feedback on this :)

[Roms1383]

@mamrhein thanks for merging the changes on fpdec, please let me know how you would like to handle fractional digits on astronimical_quantities :)

[mamrhein]

fpdec is not expected to be used with astronomical units. In fact, this has been the main reason for separating the latter into an own package. I have to figure out, how to restrict the features allowed for quantities accordingly.

[Roms1383]

I haven't dug deep enough into your crates internals, so please take this comment with a grain of salt but as a crate consumer it would seem natural to me to be able to choose to opt-in onto fpdec internal representation directly from its definition, something like:

#[quantity]
#[ref_repr(f32)] // or #[ref_repr(fpdec)]
#[ref_unit(Solar_Mass, ...)]
// ...
struct MyUnit;

As of current implementation, fpdec is gated at the crate-level making it more tedious too, if one has to mix both units with and without fpdec.

Lastly I just wondered why fallback representation depends on system's target_pointer_width since it could happen e.g. on a 64-bits architecture that someone would like to represent their types as f32, but you might have motives that I couldn't fathom, so please excuse my ignorance if there's actually very good reason to do so.

Let me know if I can be of any help :)

[mamrhein]

I do not find you ignorant and there is nothing for which you need to apologize. :-)

[mamrhein]

Using fpdec here is targeted at typical business applications, dealing with numbers representing quantities of goods, money and the like, where you don't want to stumble upon hidden rounding errors and the limited range of values compared to floats is acceptable. On the other hand, scientific computations usually have a stronger demand for the performance of hardware supported floating point math, while at the same time are more aware of the trickery to handle rounding errors. So, for me it's more or less a one-or-the-other decision. What kind of use case do you have in mind, rising a need to mix both?

[Roms1383]

Personally I'm most likely gonna use only fpdec, since I usually build business apps. The reason I initially contributed to your crates is that sooner or later I'll have to handle quantities and currencies, and yours seems the best implemented so far (as far as I can tell).

But I also think about other consumers of your crates that might have to handle both (it's probably rare but surely there's some users that at some point will use both some structs for business, and others for scientific purpose in the same app or service), hence the suggestion. A naive example of such could be someone building a online courses platform which would probably have business structs (e.g. currencies for payment in cart), and also scientific structs (e.g. units in online courses).

Of course it's not such a big deal either, because they could come up with 2 crates for all their models, one using fpdec and the other not. It's just a matter of convenience / ergonomic in the end.