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.

[privatepatrick]

Bump

I am working with ASN.1 records using the REAL type, which has some incompatibility with the compiler's assigning hash and Eq to all generated structs. It's something I can work around by using a fork of the Rust Backend, but ideally everything would be mainline.

[6d7a]

I like the idea of allowing the user to override the #derives that the compiler generates. I opened an issue in the compiler repo. However, this does not solve the incompatibility between f32/f64 and SetOf.

[XAMPPRocky]

However, this does not solve the incompatibility between f32/f64 and SetOf.

I think it would make sense in the compiler to check if the components when it is generating derives. If it checked it's components and subcomponents for any presence of REAL, then if none are found, add the Hash and Eq definitions.

[6d7a]

v0.8.0 of the compiler allows the user to override #[derive] macros though the Rasn backend's config.

[Nicceboy]

I like the idea of allowing the user to override the #derives that the compiler generates. I opened an issue in the compiler repo. However, this does not solve the incompatibility between f32/f64 and SetOf.

SetOf has also currently dependency of the deterministic hasher - I wonder if there is any better alternative implementation? It currently represents ASN.1 type correctly but maybe there is better way to do it.

[XAMPPRocky]

I wonder if there is any better alternative implementation? It currently represents ASN.1 type correctly but maybe there is better way to do it.

Sounds like worth writing down thoughts on at least. Would you care to open a follow up issue with your initial thoughts and we can discuss it further?

[nathaniel-bennett]

I'm curious if there are plans to add REAL type support for PER/BER encodings. I noticed this issue was marked complete just a few days ago (and I realize there could likely still be work in the pipeline as a result of that), but I just wanted to check.

[XAMPPRocky]

I'm curious if there are plans to add REAL type support for PER/BER encodings.

"Plans" is a strong word 😄 They should support REAL but we should open new issues for those as the framework supports REAL types generally.

If someone wants to contribute those implementations, PR are encouraged 😄

[Nicceboy]

I wonder if there is any better alternative implementation? It currently represents ASN.1 type correctly but maybe there is better way to do it.

Sounds like worth writing down thoughts on at least. Would you care to open a follow up issue with your initial thoughts and we can discuss it further?

I was more likely seeking new opinions elsewhere since the current implementation was made by me 😄

[6d7a]

What speaks against an implementation as you initially proposed?

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

I guess with BigInt mantissa and exponent the performance would be worse than f64. Perhaps a middle ground would be to use built-in integer types. That limits the precision, but less than f64 does currently. Also, Eq and Hash wouldn't be a problem.

[Nicceboy]

Sorry, I was speaking about the SetOf and the hash derive problem. Any other solution that I tried required PartialOrd and it does not fit well, since SetOf should be unordered.