home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / atari / 8bit / 5709 < prev    next >
Encoding:
Internet Message Format  |  1992-12-27  |  2.6 KB
  1. Path: sparky!uunet!portal!cup.portal.com!Rick_Michael_Cortese
  2. From: Rick_Michael_Cortese@cup.portal.com
  3. Newsgroups: comp.sys.atari.8bit
  4. Subject: Re: My ego VS UUE
  5. Message-ID: <72473@cup.portal.com>
  6. Date: Sun, 27 Dec 92 10:57:31 PST
  7. Organization: The Portal System (TM)
  8. References: <71961@cup.portal.com> <kJ98VB2w165w@cyberden.sf.ca.us>
  9.   <72423@cup.portal.com>
  10. Lines: 37
  11.  
  12. RE: Point #1, I'll stand by my 1.5 expansion statement. Matter of fact, some
  13. of the files I D/L'd were that were in that 1.5 range were done by you. It's
  14. more then just a problem with the encoding scheme. I believe the UUE uses a
  15. 46 byte line with a two byte checksum for every line which would pump it
  16. up, the rest of the expansion I'm not sure about, but it DOES make the file
  17. 1.5 times the original. IMO: I'm sure the original authors had something in
  18. mind by adding a checksum to every line, but I really doubt if it serves a
  19. useful purpose anymore. Since most everything is transfered via Xmodem etc.
  20. it's more likely a bad file to begin with. A checksum for the entire file
  21. makes a lot more sense to me & apparently the authors of ARC, ZIP, ...
  22.  
  23. I'm aware of the bias & plan on the numbers being represented by ASCII
  24. characters from !-r or !-v, something in that range anyway. No control
  25. characters, no extended characters. I've already sent a file to myself
  26. on another BBS (ricortes@kludge.com) & I'll double check that everything
  27. gets through correctly. It shouldn't matter what character sets another
  28. computer uses *IF* (note the big if) they just echo the file as is. Who
  29. cares if computer X thinks a 65 in a file means "strip and go nude", as
  30. long as it echos the 65, were fine.
  31.  
  32. Point #3 Speed, I've already got a mutiple precision binary division
  33. routine that'll go to 255 significant figures for the operand/divisor.
  34. I'm planning on eventually getting it working as an Action! procedure
  35. along with maybe some multiplication. It may take me a while to get
  36. everything neatly done, but as long as I'm willing to code in M/L, you
  37. shouldn't worry about speed. If your really worried, I could run some
  38. tests, but even if there is a net loss in speed on the decode end, the
  39. online time/transmission/echos for the entire Internet system will be
  40. reduced by 15% (Only for files of course!). Who wouldn't take a slightly
  41. longer decode time in exchange for a shorter down load time?
  42.  
  43. BTW: I want to thank Douglas Clement for correcting my terminology on
  44. number base systems. My excuse is I was trained as a chemist so...
  45.  
  46. I guest for the doubters, I should do a little demo. Turns out Atari
  47. Basic can just manage to do the job albeit slowly. I'm sure somebody
  48. about :-)
  49.