> 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
11 matches
Mail list logo
