REAL type support

[Nicceboy]

Continuing from the issue #58 and writing some ideas

Well Real types should have {encode, decode}_real methods on Encoder and Decoder. I just haven't added it yet, because real types are the most difficult to understand and implement IMO. Another unresolved question is what would be the appropriate type to use in Rust for Real types, as I'm pretty sure (though could be wrong, see X.680) real types can be wider than f64. Help figuring out a good enough solution would be appreciated.

I also noticed that real type is missing, but it might not be actually that hard to add (while some codecs might be)!

In ASN.1, real type is often approximated and not precise. Usually a single or double-precision approximation has been used to limit the size in codecs. The X.680 definition itself does not set any limits, but for practical reasons codecs often do.

Usually the real is presented with integers. Instead of one integer, you have three integers.

$m * b^e$, where $m$ is the mantissa, $b$ for the base (2 or 10), and $e$ the exponent.

Representing real type is like bit shifting, but instead moving the comma. The shifting changes the exponent relatively moving the comma, so in the end you have just integers.

Based on that, maybe the easiest approach would be to provide Real as Enum type with following options:

• REAL_NUMBER (from::f64 by default)
  • Mantissa (Integer)
  • Base (Integer, 2 or 10)
  • Exponent (Integer)
  • Sign (maybe)
• PLUS-INFINITY
• MINUS-INFINITY
• NOT A NUMBER
• PLUS ZERO
• NEGATIVE ZERO

Internally rasn could contain the f64 conversion to ASN.1 Real value as three integers, possibly with sign. BER seems to use sign with unsigned integers when binary encoding.
Mapping from f64 type might be good enough for default, since it is sufficient for double-precision approximation.

Any application which requires higher precision is more likely to use rations with integers anyway in current Rust.

To support very large numbers, BigInt could be used to present these three integers internally.
For larger values than f64, we could provide alternatively something like Real_number::from_ints function which takes three integers to construct the ASN.1 Real. BigInt as mantissa, u8 as base (2 or 10) and BigInt as exponent will already give us practically as much range as hardware is able to handle.

Alternatively, BigUint as mantissa and additional sign parameter. For this we might need to study which (sign as mark with unsigned integer or signed integer) is more used in the codecs.

It is up to the user of rasn to calculate these three integers if they need higher accuracy than f64.

Maybe this REAL type overall would be good to add at the same time when the possibly for optional BigInt usage is added and end user could configure to use primitive integers instead, if we want to consider the performance of REAL values as well.

It might also take time before we would have other than f32 or f64 types.
There is a recent RFC coming with additional float types: rust-lang/rfcs#3451

This RFC proposes new floating point types f16 and f128 into core language and standard library. Also, this RFC introduces f80, f64f64, and bf16 into core::arch for target-specific support, and core::ffi::c_longdouble for FFI interop.

[6d7a]

@Nicceboy I like the approach of staying close to ASN1's understanding of the REAL type, while providing converters for ease of use. Personally, I would prefer a triple of BigInt mantissa, enum Base { Two, Ten } base, and BigInt exponent, so that ASN1's restriction on the base are expressed in rasn's REAL type.