> On 03-Jun-21 15:11, John M. Gamble wrote: You're replying to a fairly early post in this now long thread. Not sure you're up-to-date...
I didn't suggest Convert at top level. I suggested Number::Binary::Convert.
I wouldn't split integer and FP, since one obvious use is for a utility
that reads some set of mixed integer & floating values from an archived
tape and spits out Perl values. Or one that actually manipulates them.
Using generic "convert" (or whatever) allows such tools to have a
configuration format that's just a name, and a single 'use'. statement -
the needed type implementations get dynamically loaded as needed.
Splitting would complicate that.
No, if you read the history of this thread, the consensus is NOT one
module; just one expandable class that instantiates implementations for
types.
And besides being top level, Convert::ASN1, BER, or Base85 isn't exactly
"text conversion".
Convert::Integer::<IEEEType> and Convert::Float::<IEEEType> would beg
for Convert::<IEEEType>::Integer and Convert::IEEEType::Float, rather
than getting a encoder or decoder object. And Peter has indicated that
there are lots of non-Perl types - not all are IEEE. So I don't think
that's attractive.
But I ought to quit here, and let the person doing the work make his
decision....
On 03-Jun-21 15:11, John M. Gamble wrote:
> 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)
OpenPGP_signature
Description: OpenPGP digital signature
