NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/sys/atari/8bit/5706

Internet Message Format | 1992-12-26 | 2.7 KB

Path: sparky!uunet!portal!cup.portal.com!Chris_F_Chiesa
From: [e-mail]
Newsgroups: comp.sys.atari.8bit
Subject: Re: My ego VS UUE
Message-ID: <[e-mail]>
Date: Sat, 26 Dec 92 01:23:01 PST
Organization: The Portal System (TM)
References: <[e-mail]> <[e-mail]>
Lines: 44

Oops... sorry about that partial posting!  It's 4AM and I'm on an unfamil-
iar keyboard...

I was starting to say:

First, Rick, standard UUencode takes 3 bytes of 8-bit "original" data
(24 bits) and reorganizes it as 4 6-bit "encoded" quantities (also 24 bits).
Current computer architectures require an entire 8-bit byte to store any
less-than-8-bit quantity, hence a UUencoded file has essentially 4 bytes
for every 3 in the original: an "expansion factor" of 1.3333...., not 1.5.
Among other things, this reduces the advantage of your proposed base-85
technique from "a significant improvement over UUencode," to "just slightly
better," and since base-85 doesn't correspond exactly to a power of 2,
i.e. to a particular, fixed number of bits in the UUencoded values, your
encoding algorithm would of necessity be somewhat messier than UUencoding
which can be implemented just by moving bytes around: NO MATH is needed
for UUencoding.

Second, the use of 6 bits for UUencoded data values yields, of course,
64 different possible values.  As noted in previous articles in this
thread, the values 0-31 would be control characters, some of the very
values it is desired to avoid in an e-mailed file, so the UUencode algo-
rithm adds a "bias" value of 63 decimal, shifting the UUencoded values
to the range 63-127 decimal, representing ASCII characters "!" through
"~".  These are ALL "printable" characters, in ASCII anyway.  I don't
think it should be the encoding program's responsibility to deal with
ASCII-to-EBCDIC translation peculiarities; that is the responsibility
of file-exchange software: the ASCII-file-reading program on the EBCDIC
system, or the EBCDIC-file-reading program on the ASCII system.  These
exist and have been refined over the years to quite a high state...

Third, I think it would still be interesting to see a base-85 file-
encoder, at least as proof that it could be made to work.  I don't
expect it would make any significant impact on the near-universal
use of the existing UUencode scheme, since UUencode is firmly estab-
lished and the base-85 encoder would be more complex, and therefore
somewhat slower, than an equivalent (whatever THAT means) UUencoder,
for only about a 8% improvement in file size.  Of course, there will
be that minority (possibly including me myself) to whom even an 8%
improvement will be worth a loss of speed, and such people ought
to have the choice.

Chris Chiesa
  [e-mail]