Re: base26 Encoder/Decoder

Cri-Cri wrote:

On Sat, 27 Apr 2024 17:31:29 +0200, Stefan Claas wrote:
 

In this case, NOM = 851 and DENOM = 500, which means that the length of
the output is about 85.1% of the length of the input when the input is
being encoded, and about 58.8%
of the length of the input when the input is being decoded.

 
Yeah, magic numbers. I don't like the concept of "about" here, since there
is nothing "about" about it. ;)
 
I suspect the concept of "about" is what is wrong with the implementation,
since it isn't the same as what you got with your code. Or both are flawed
and it should be something different altogether.
 
Why didn't you ask your friend to write the encoder/decoder for you from
scratch?
 
If you used this approach with your Rust code, you should be able to use
the same description to get it in whatever language you wanted.
 

My Rust version works 100% the same as the Python3 implementation from the PyPI
site and I needed an encoder/decoder that works with letters and not with digits,
like the French site does.

So, in the end people are free to choose which base26 approach they like to use,
because there is no standard, like an RFC, available.

If you use other base n encoders you will see, like in base64, base32, base58,
base85, base91 etc. the base n system relies always on letters (and some digits and special characters).

So I really see no problem here.

--
Regards
Stefan