Path: ...!goblin1!goblin.stu.neva.ru!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Gremlin Newsgroups: alt.comp.os.windows-10,alt.computer.workshop,comp.os.linux.advocacy,comp.sys.mac.advocacy,talk.politics.guns Subject: Re: What it's like to interact with Snit - a video perspective Date: Thu, 6 Aug 2020 01:36:19 -0000 (UTC) Organization: A noiseless patient Spider Lines: 315 Message-ID: References: Injection-Date: Thu, 6 Aug 2020 01:36:19 -0000 (UTC) Injection-Info: reader02.eternal-september.org; posting-host="ef3bd0c7dce8848aee0728b9a96f5831"; logging-data="18491"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/8URS+9qPH/GUqrGN6+J/aS6Cc9tANPGc=" User-Agent: Xnews/5.04.25 Cancel-Lock: sha1:ahdp7Ivgdo1av/j/hppKTA+vUgs= Bytes: 13900 Snit news:houhmuFbga3U8@mid.individual.net Wed, 05 Aug 2020 01:52:31 GMT in alt.computer.workshop, wrote: [snip] >> Hey, that's not too bad of an idea, except for a few little >> problems I can think of off the top of my head. Snit, due to >> previous, and quite severe 'misunderstandings', I'm being *very* >> sarcastic by using the word 'little'. I do hope I've dumbed this >> down enough so that you understand without issue, but I won't bet >> on it. > > Here come your excuses for not having a Zoom session. excuses? > The reality is you fear being utterly humiliated in a new medium. > You clearly have a lot of trouble understanding the written word, > but for you to show you cannot understand interactive voice even > with a video would be even worse for you. I don't fear anything of the sort, but, I do agree, one of us has a severe reading comprehension problem. Let's see an example of it here: Message-ID: http://al.howardknight.net/?ID=159667571100 This is what you were provided from the AZ documentation, fully explaining the algorithm: ENCODING IN THE AZ FORMAT EXPLAINED: Step 1. Determine the ASCII value of the character we intend to encode Step 2. Set A1 and A2 variables at the ascii value for A (On the IBM platform that value is 65) Set counter to 0. Step 3. Check to see if counter is equal to the ascii value obtained in Step 1. if so, convert A1 and A2, each to a character. Combine them in reverse order, as in A2 A1. This is our 2 byte encoded "AZ" format. Write this to the output file and return to Step 1. If the counter and the ascii value do not match, add 1 to A1. If A1 goes past the ascii value for Z (which is 90 on IBM), reset it to A (65 on IBM) and add 1 to A2. Add 1 to the counter and repeat Step 3. DECODING IN THE AZ FORMAT EXPLAINED: Step 1. Determine the "AZ" code to process. (As in read it from a file or a device, be sure to read in two characters :-)) Step 2. Set A1 and A2 variables at the ascii value for A (On the IBM platform that value is 65) Set counter to 0. Step 3. Convert A1 and A2, each to a character. Combine them in reverse order, as in A2 A1. This is a test "AZ" code to match with the one we read in, If they match, convert the counter into its character value and write it to the device or file (we have found the match, and the original code, we can now return to step 1 for more "AZ" codes). If they do not match, add one to the counter, and A1, if A1 is greater then 90, reset it to 65 and add one to A2. Return to step 3. If the counter hits 255, then no possible match has been found, Return to step 1. And this is your reply. I've also included the entire thread so anyone else can see for themselves how bad your comprehension actually is. https://groups.google.com/forum/#!searchin/alt.computer.workshop/az $20snit%7Csort:date/alt.computer.workshop/T5-Mammb0IA/SIvvu0IxBQAJ Message-ID: http://al.howardknight.net/?ID=159658625100 OK, looking at the encoding provided by Diesel... seems odd. Could be my lack of understanding in places, but clearly he also has some areas of confusion. ----- ENCODING IN THE AZ FORMAT EXPLAINED: Step 1. Determine the ASCII value of the character we intend to encode ----- Presumably this is just the first character. Then the second. Then the third. Until we get to the end. In simple language: Repeat with theCharacter from 1 to count of characters in theText Maybe it is count -1 since he seems to look at two characters at a time (though he never really says that). But so far so good. ----- Step 2. Set A1 and A2 variables at the ascii value for A (On the IBM platform that value is 65) Set counter to 0. ----- This is odd. Why not just set A1 and A2 to 65 given how that is ALWAYS the ASCII value of "A". This is true not only of 7 bit ASCII, but also 8 bit (extended) ASCII. So to use our simple language it is just: Set A1 to 65 Set A2 to 65 Set Counter to 0 So far so good. Ish. Why not just say that? ----- Step 3. Check to see if counter is equal to the ascii value obtained in Step 1. if so, convert A1 and A2, each to a character. Combine them in reverse order, as in A2 A1. This is our 2 byte encoded "AZ" format. Write this to the output file and return to Step 1. If the counter and the ascii value do not match, add 1 to A1. If A1 goes past the ascii value for Z (which is 90 on IBM), reset it to A (65 on IBM) and add 1 to A2. Add 1 to the counter and repeat Step 3. ------ This is where things get weird, at least to me. The Counter is set to the ASCII value of A, and then in the next round to the value of B. But with the A1 and A2 he is just rotating them 1 (similar to what I said with ROT-13 but only one character). And he has the wrap-around... so "A" becomes "B", "B" becomes "C".... "Z" becomes "A". But he has no such wrap around described for the counter... so after the first 26 additions to the Counter the value of Counter goes past the values of A-Z and would never match the ASCII value of a character. Seems the counter would have to be reset. And having the counter and comparing it to the value really adds very little except the occasional "bumping" of a character to rotate more than once. Oh, and does he ever say to look at the next character? He again talks about the ASCII value on "IBM", as if a "American Standard Code for Information Interchange" would be different on different systems when it is, by definition, a "standard". Seems amazingly odd a programmer would not know this... not putting Diesel down here but I am curious as to what he was thinking when he wrote that! Anyway, seems the counter needs to go back to the value of "A" (65) but he never says that. Again, maybe I am missing something. Diesel, can you explain? ----- As you can see, the AZ format is really not that hard to code for other programs such as OffLine Mail Readers and the like. ========== REMAINDER OF ARTICLE TRUNCATED ==========