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
<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)

Reply via email to