Re: Module namespace for IEEE754 encoder/decoder

Hmm, I was going to bring up Math::Int128, but it allows arithmetic on 
128-bit integers, which might count towards your objection.

I'm not keen on using the Convert namespace which is overwhelmingly used 
for text conversion. I suppose you could break it down with 
Convert::Number::<IEEEType> modules.

Pondering some more: is the intent to put all of the conversion 
operations into one module? I am typing in ignorance, but would it make 
sense to separate the integer conversions from the floating point 
conversions? In which case you would have Convert::Integer::<IEEEType> 
and Convert::Float::<IEEEType>.

      --john

On 2021-06-03 06:22, Timothe Litt wrote:
> I'd be a bit careful about assuming floating point - will someone want
> to pack/unpack BCD? Or PDP-10 Gfloat (well, OK that's a floating
> format)?  Or...
> 
> I don't like Math:: - it implies that it does arithmetic (or calculus,
> or statistics, or - more than a conversion).
> 
> And I'd rather not have a format name encoded in the module that the
> user calls.
> 
> How about Number::Encode->new("name") & Number::Decode->new("name")?
> 
> Let "name" get to a subclass, so other formats can be supported just
> by adding a module - e.g. "Number:Encode::BCD" could be require'd if
> *->new('bcd') called.  Obviously, you'd implement IEEE754, Intel80,
> and whatever else...
> 
> Define the API for the subclasses - encode(),decode(), perhaps some
> info functions (e.g. a printable name, perhaps exponent and fraction
> range/#bits, ...)
> 
> Then someone who wants Number::Decode::VAX_DFLOAT just calls
> Number::Decode->new('vax_dfloat') - after writing it.
> 
> Some of these can get interesting if you want to decode and actually
> do math - presumably you'll support Math::BigXxx / bignum? (binary128,
> VAX H_Floating are, IIRC about 36 decimal digits)
> 
> And some program that reads archived data can have a description
> language that is simply "name"  "format" "byte offset" "length", and
> not worry about what module handles what format.  In fact, such a
> program might appreciate the trivial modules Number::Encode::INTEGER32
> (and perhaps the less obvious
> Number::Encode::INTEGER32_ONESCOMPLEMENT)...
> 
> I suspect there are better names for the format, but the idea is to
> export a simple wrapper so the next format can be added by anyone, and
> the callers don't have to know too much.
> 
> FWIW.
> 
> On 03-Jun-21 06:23, Peter John Acklam wrote:
> 
>> I also plan to implement the 80 bit "extended precision" format,
>> which
>> is not IEEE 754 compatible. Perhaps the best and simplest is
>> Number::Pack and Number::Unpack?
>> 
>> Peter
>> 
>> tor. 3. jun. 2021 kl. 11:43 skrev Peter John Acklam
>> <[email protected]>:
>> 
>>> Hi
>>> 
>>> I am working on two modules for encoding and decoding numbers as
>>> per IEEE754. The pack() function can encode and decode the formats
>>> binary32 (single precision) and binary64 (double precision). My
>>> module can also handle binary128 (quad precision), binary16 (half
>>> precision), bfloat16 (not an IEEE754 format, but it follows the
>>> IEEE754 pattern), and a few other formats.
>>> 
>>> My question is about the namespace. Is Math::IEEE754::Encoder (and
>>> ...::Decoder) OK? Or is Number::IEEE754::Encoder better? Or any
>>> other?
>>> 
>>> Here is an example showing how I use it:
>>> 
>>> my $encoder = Math::IEEE754::Encoder -> new("binary16");
>>> my $bytes = $encoder -> (3.14159265358979);  # = "\x42\x48"
>>> 
>>> my $decoder = Math::IEEE754::Decoder -> new("binary16");
>>> my $number = $decoder -> ($bytes);               # = 3.140625
>>> 
>>> The reason for returning an anonymous function rather than
>>> implementing the function directly, is speed. There are some
>>> constants involved, and I don't want to compute them for each
>>> function call.
>>> 
>>> Cheers,
>>> Peter John Acklam (PJACKLAM)