From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, HTML_MESSAGE,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 12811 invoked from network); 24 Sep 2020 18:18:08 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 24 Sep 2020 18:18:08 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 0EBE09CED3; Fri, 25 Sep 2020 04:18:06 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 5C9AE9CEC7; Fri, 25 Sep 2020 04:17:25 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (2048-bit key; unprotected) header.d=ccil-org.20150623.gappssmtp.com header.i=@ccil-org.20150623.gappssmtp.com header.b="w6y66Fsp"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 9C5B19CEC4; Fri, 25 Sep 2020 04:17:21 +1000 (AEST) Received: from mail-qk1-f176.google.com (mail-qk1-f176.google.com [209.85.222.176]) by minnie.tuhs.org (Postfix) with ESMTPS id C323193D65 for ; Fri, 25 Sep 2020 04:17:19 +1000 (AEST) Received: by mail-qk1-f176.google.com with SMTP id q63so401792qkf.3 for ; Thu, 24 Sep 2020 11:17:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ccil-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/AdfsiMSETzVYxjDYjW5uhZ8AqId2T3Nei1IlPvZsPY=; b=w6y66FspebAtxXyC2ZE7nwEewNnzY81qkhdMqnEpUSOoEUScLMiAl6W40Vv+4qRlf3 hf1XPXOI9Jr+Z5qik6pdqYT4ChUH3Oyzs44jyzJ6ThLOE5wf+M5YvUVTXhUXYwlgjLGZ FvnREjPFLrKZhRs90LjKgvUs60NrE9hvBB/6AzbchXSKDuDCXhxdefz+XPGACwRzyH7S iGcA8M9WhAF5x74EX0aBkZGA+DyuTDBxBEV6UvYymQ1/7Xal+8ocMh1NCBLsVA2+MevN F9LvzhUl+iUwf7TVvNWXv113IKUnKYlloYkgwk/kieaPLdRjnQkyJs7knmOAQegBXhUY pl2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/AdfsiMSETzVYxjDYjW5uhZ8AqId2T3Nei1IlPvZsPY=; b=ScAcN3AmpPzJ6ylhRI7UEiQxNnE1YZ6j9sDS6KRrfVDltzgdJf0vP/gBJFScDbn+U2 pJrpBdnenyKLINXvKmbwEgRhlh0b+tEf1Nq9sABZhu5OEEq9AzBjyVxJAjBAu3+w9v6b SEY8fyYN+KvSjfSoxeGf49qwxB4Rn9rZpp3AP2u6WXn+J9+k0Znpl+wpFFFTR9vGAVf3 NJrc2PLza0txETVBPSejZDYu4gO6xvG6OzYPP+U888qUCXnkHmNZ2oiAiFSch/AQBH4U nVuJjgC6QDRJ4t+OGtJeQZFhO4bdK+3JpapsNfZndkMJjKdgWktq8kbm6c3IabsRIMMc SGlA== X-Gm-Message-State: AOAM530NzUaAQO+zkUUvJFMBA8iugywUyx7KIsjJzRa/RBbuBtYwR9xB F1UyJ3bwBeXswEqdY9NJm/0d3SrEAvrdTcfjIlBWkw== X-Google-Smtp-Source: ABdhPJz/NSWZapwqKu3P5+JzFt/gWSCP9JDnR2BL0OJM6oKWnx6HaHVf7zuWnLAFsrbuTIH613dDD8J/BirI9ni/KfE= X-Received: by 2002:a37:4c4e:: with SMTP id z75mr369044qka.426.1600971438664; Thu, 24 Sep 2020 11:17:18 -0700 (PDT) MIME-Version: 1.0 References: <202009190151.08J1pYnb066792@tahoe.cs.dartmouth.edu> <202009201842.08KIgn2f022401@freefriends.org> <04211470-AD63-452A-A0BB-6A7A6FD85AAE@gmail.com> In-Reply-To: From: John Cowan Date: Thu, 24 Sep 2020 14:17:07 -0400 Message-ID: To: Paul Winalski Content-Type: multipart/alternative; boundary="000000000000e5c6a805b0133502" Subject: Re: [TUHS] reviving a bit of WWB X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: The Eunuchs Hysterical Society Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --000000000000e5c6a805b0133502 Content-Type: text/plain; charset="UTF-8" On Thu, Sep 24, 2020 at 1:19 PM Paul Winalski wrote: Or separate-sign numerical representations, for that matter, such as > the IBM 1620 had. And packed decimal on the S/360/370 and the VAX. > Negative zero in packed decimal is responsible for a lot of the > "computerized bill for $0.00" bugs that were rife in the 1960s. > IEEE floats are still sign-magnitude, for that matter, both the binary ones and the little-used decimal ones, which is why MAX_FLOAT and MAX_DOUBLE are the same in both positive and negative directions. I once had to deal with some mainframe data that had been transferred to our PDP-11 or Vax (not sure which), and I noticed right away that some of the allegedly numeric data had a non-digit immediately following and one fewer significant digit than the rest. A little digging in my memory (I think this was before I got access to the Internet in 1985 or so), plus a little experimentation, established that these were trailing-overpunched-sign numbers that had been mechanically translated from EBCDIC to ASCII. So on the principle of "If a problem is not interesting, generalize it until it is", I wrote a little filter that looked for such numbers in its input and rewrote them as leading-separate-sign (i.e. the Usual Way), copying everything else. Unfortunately the source is long since lost, but I wouldn't write it in C today anyway. --000000000000e5c6a805b0133502 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Thu, Sep 24, 2020 at 1:19 PM Paul Winalski <paul.winalski@gmail.com> wrote:

Or separate-sign numerical representations, for that matter, such as
the IBM 1620 had.=C2=A0 And packed decimal on the S/360/370 and the VAX. Negative zero in packed decimal is responsible for a lot of the
"computerized bill for $0.00" bugs that were rife in the 1960s.

IEEE floats are still sign-magnitude, fo= r that matter, both the binary ones and the little-used decimal ones, which= is why MAX_FLOAT and MAX_DOUBLE are the same in both positive and negative= directions.

I once had to deal with some mainfram= e data that had been transferred to our PDP-11 or Vax (not sure which), and= I noticed right away that some of the allegedly numeric data had a non-dig= it immediately following and one fewer significant digit than the rest.=C2= =A0 A little digging in my memory (I think this was before I got access to = the Internet in 1985 or so), plus a little experimentation, established tha= t these were trailing-overpunched-sign numbers that had been mechanically t= ranslated from EBCDIC to ASCII.=C2=A0 So on the principle of "If a pro= blem is not interesting, generalize it until it is", I wrote a little = filter that looked for such numbers in its input and rewrote them as leadin= g-separate-sign (i.e. the Usual Way), copying everything else.=C2=A0 Unfort= unately the source is long since lost, but I wouldn't write it in C tod= ay anyway.




--000000000000e5c6a805b0133502--