Thanks for the feedback!
I see your point regarding the Math:: namespace and agree that it
isn't the best. Alas, Number::Encode is already taken. I suggested
Number::Pack and Number::Unpack because they aren't taken and because
of the module's similar functionality to pack() and unpack().
I agree that there should be a simple wrapper and that the format
should not be a part of the module name specified by the user. I also
agree about not assuming floating point. Actually, one of the use
cases is encoding/decoding unsigned 24 bit integers, which are used by
ImageMagic when reading/writing PAM (portable anymap) images.
There is also Data::IEEE754, but I think the Data:: namespace is too
general. I will only be dealing with numbers.
Peter
tor. 3. jun. 2021 kl. 13:22 skrev Timothe Litt <tlhack...@cpan.org>:
>
> 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 <pjack...@gmail.com>:
>
> 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)
