> 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 read
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:: modules.
P
CODEC can mean coder/decoder, but the more common (I think) use is
compressor/decompressor (as in MP3, H.264, etc).
ENCDEC can mean encoder/decoder, but also encryptor/decryptor.
You're converting from one binary format to another...
Format often has the sense of for human consumption.
What abo
tor. 3. jun. 2021 kl. 17:59 skrev Timothe Litt :
>
> How about Number::Binary::Encode->encoder, Number::Binary::Encode->decoder?
How about Number::Binary::Codec->encoder and
Number::Binary::Codec->decoder? After all, 'codec' is an abbreviation
of "(en)coding/decoding".
Peter
On 6/3/21 11:58 AM, Timothe Litt wrote:
I would recommend against using the "top level" space,
Number::Binary, as that would reserve a namespace which seems to
cover a very broad topic, binary numbers, for just encoding/decoding.
Fair point.
Number::Encode seems to be a hash generator for s
> I would recommend against using the "top level" space, Number::Binary,
> as that would reserve a namespace which seems to cover a very broad
> topic, binary numbers, for just encoding/decoding.
Fair point.
Number::Encode seems to be a hash generator for sort-of-randomish
sort-of-hashes; not wel
The free-for-all that is CPAN namespaces is particularly hard to
navigate, and I would be enthusiastic if we could create a hierarchy
that makes it easy to understand the relationship between them.
I would recommend against using the "top level" space, Number::Binary,
as that would reserve a n
Hmmm, Number::Binary doesn't seem to be taken, at least according to
meta::cpan.
What about $enc = Number::Binary->encoder("name"); $dec =
Number::Binary->decoder("name");?
You could also make it easy to get inverse functions by accepting an
object; e.g. $dec = Number::Binary->decoder($enc);
e.
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
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 for
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 :
>
> Hi
>
> I am working on two modules for encoding and decoding numbers
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 IEEE
12 matches
Mail list logo
