Path: csiph.com!eternal-september.org!feeder.eternal-september.org!nntp.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.arch Subject: Re: endian history Date: Wed, 23 Sep 2026 13:15:06 -0700 Organization: A noiseless patient Spider Lines: 88 Message-ID: <86cxu3sp11.fsf@linuxsc.com> References: <10uks4f$1dqo$1@gal.iecc.com> <10vns1f$3a252$1@dont-email.me> <10vpblp$3mkd1$1@dont-email.me> <10vphh0$3o9jl$1@dont-email.me> <117gj6t$1b95v$2@dont-email.me> <6a9c1c93.39172234@news.eternal-september.org> <117j3es$24qgq$6@dont-email.me> <117n6ho$35j69$1@paganini.bofh.team> <6a9f7664.1891062@news.eternal-september.org> <2026Sep8.125659@mips.complang.tuwien.ac.at> <117pnpg$f179$2@dont-email.me> <11898n9$1nc06$2@dont-email.me> <118d6ld$1tkm9$1@paganini.bofh.team> <118dl5f$37cfv$1@dont-email.me> <118e8kg$3f05h$1@dont-email.me> <868q4zuhz4.fsf@linuxsc.com> <118jitv$1cm6b$1@dont-email.me> <86ik42tcf4.fsf@linuxsc.com> <118uf6m$12tta$1@dont-email.me> <86ld8srnq9.fsf@linuxsc.com> <1790188863-5857@newsgrouper.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Wed, 23 Sep 2026 20:15:07 +0000 (UTC) Injection-Info: dont-email.me; logging-data="2179758"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+HmLbEEvxstMgLphawF8yX1Cxuzfhm30k="; posting-host="e854bcdde9edbfa449147ac38d1c2707" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:WBvO3dWYj75qM0oV2r26Z51D8R8= sha1:JMcctYf2GpV8tStdnCvNz2Xpmac= sha256:bWwVrbcm6Wsg/CFnnvQ0H3vey1Tt9iQGxd2GwN/S8fE= sha1:bPTzIyVcnJPdik5EsB4byKlUNfs= sha256:Uu6qetr5/owpnSKfCy4OctACso1eca3Sls+uBSpSS2Q= Xref: csiph.com comp.arch:118162 MitchAlsup writes: > Tim Rentsch posted: > >> Terje Mathisen writes: >> >>> Tim Rentsch wrote: >>> >>>> Terje Mathisen writes: >>>> >>>>> Tim Rentsch wrote: >>>>> >>>>>> Terje Mathisen writes: >>>>>> >>>>>> [...] >>>>>> >>>>>>> There was an Advent of Code puzzle in 2022 (last day) where you >>>>>>> had to work in symmetrical base-5, using '-' and '=' for -1 and >>>>>>> -2, along with '0', '1', '2'. >>>>>>> >>>>>>> You had to parse 113 such numbers, all happened to be positive, >>>>>>> but they did of course not need to be. With symmetrical encoding, >>>>>>> there is no extra minus sign in front, just a negative first >>>>>>> digit. >> >> [...] >> >>>>>>> Just like decimal, it is a lot easier to convert ascii to binary >>>>>>> than binary to ascii, the difference between div/mod every digit >>>>>>> and a single mul. >>>>>> >>>>>> Now I'm curious to see how you implemented the binary-to-ascii part >>>>>> of the problem. Do you still have the code around? >>>>> >>>>> Sure: >>>>> >>>>> const BASE:i64 = 5; >>>>> const VALUE:[i8;256] = [ >>>>> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, >>>>> 0,0,0,0,0,0,0,0,0,0,0,0,0,-1,0,0,0,1,2,0,0,0,0,0,0,0,0,0,0,-2,0,0, >>>>> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, >>>>> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, >>>>> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, >>>>> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, >>>>> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, >>>>> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]; >>>>> >>>>> const DIGITS:[u8;5] = [b'0',b'1',b'2',b'=',b'-']; >>>>> >>>>> fn tobase(n:i64) -> String >>>>> { >>>>> let mut n = n; >>>>> let mut buf:[u8;32] = [0;32]; >>>>> let mut p = buf.len(); >>>>> loop { >>>>> let r = n % BASE; // positive remainder for positive $BASE >>>>> let d = DIGITS[r as usize]; >>>>> n = (n-VALUE[d as usize] as i64) / BASE; // Exact division! >>>>> p -= 1; >>>>> buf[p] = d; >>>>> if n == 0 {break;} >>>>> } >>>>> std::str::from_utf8(&buf[p..buf.len()]).unwrap().to_string() >>>>> } >>>> >>>> I'm guessing this code is in Rust. Can I ask you to translate it >>>> to C for me? Mostly I can guess at the meaning, but as I am only >>>> a novice with Rust I worry that my guessing would be wrong in some >>>> cases, and wrong functionality would result. >>> >>> The only non-C part here is the final library call to convert a >>> slice of bytes into a Rust String, the rest is simply what it seems >>> like for a C programmer. >> >> It looks like this statement cannot be right. In C, if n is >> negative and not a multiple of 5, then n%5 is negative. But after > > An obvious case where n should be unsigned not signed. Yes and no. It is possible to solve this problem where the divisions and remainders are always done on non-negative values (and so could be unsigned rather than signed). I did in fact code up a solution that has this property. But such code can be harder to write and harder to understand. In contrast, it's fairly easy to solve this problem using signed quantities and simply deals with the negative remainders appropriately. Which approach is better? As usual that can depend on other factors, including performance.