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=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HTML_MESSAGE,MAILING_LIST_MULTI,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 10401 invoked from network); 11 Sep 2022 15:10:13 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 11 Sep 2022 15:10:13 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 2B686428F5; Mon, 12 Sep 2022 01:10:08 +1000 (AEST) Received: from mail-vk1-f175.google.com (mail-vk1-f175.google.com [209.85.221.175]) by minnie.tuhs.org (Postfix) with ESMTPS id C255C428F0 for ; Mon, 12 Sep 2022 01:10:03 +1000 (AEST) Received: by mail-vk1-f175.google.com with SMTP id h5so3079013vkc.5 for ; Sun, 11 Sep 2022 08:10:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ccil-org.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=dp9lAUJZI87fpQzoac43xtYDA/bmjcgsbhaSaqE1Fj0=; b=7zfWGWQ84j0SrmFS0sCcGh1B/jNPODdGDoMG4oSLmGqR4QQMcnY0qj9z5U08kGFU7+ DGZNSTuegLIZB/ZPANeacBpv3efAi/WdZiCXYrsqDB4fposlyw8lzzdeHVbeFP0Cvy/H HUd0xvZA0cH9gWBRT9th9V77GNqkz6kCqvt747vX87qqYjpsbttiiURhPZS9S2Et6cKE Agj1TMTrd2Ok3zHT7EIAkYd7FaQUkbwTQevQdK3pfY9DMm54+TBmhr4NQZupQZicF3in R44ulbZd+fLbpnkV3UCpVd3+j/HevjdVGJmV5g1/vDlv+kW4aDaXmZwK1KQHteIdTXcV DqTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=dp9lAUJZI87fpQzoac43xtYDA/bmjcgsbhaSaqE1Fj0=; b=xAe9Jv/suhWwjNNhxi7oROvkg2uYyfv3mxLGHFwXWli9hO8MXX3KvDMSymOhCH+pWM PMkj4n7m+5H6iD98HLw2y9QYHCo2HYfGXUbTzLlaKH50aa9hhGJMIZ+XwVrEr1s/Q5Xh D9jsTWgmAXrw60BCp1uZGgNEusKkdvUc+o+7A/1lTLRWh9xY5tYWBdhTus8MdQmGSO6x KBCVrcFpkY2riHx9d5HUCUvDfh/QuUxS+wD6tdtWNqjKQzlzOz0dpW1cyD4rSqnXHcE6 2HxB8kbKj0DdIlnLrtl0tWP/k4ii9sYb6+rI2TojrXwkwsbBG37bamfdLnfEfKGYnYwA hQRA== X-Gm-Message-State: ACgBeo15KAhsiQVKnYt19cLvWE2E4o071Lqe2sn3+Q7gjViZ6B1Zz376 +ib4w3u1AFD9Fov3XzW6AKcCs8RkU+a/Tg4qn7z0cn727Z/xJWrg X-Google-Smtp-Source: AA6agR41q2qTid0NHRhLgVh3KVva8PcX/j+YbzDNrTDCq8VfuQXjWfrcuaTimJw2B2gAtWBjMYpmgrX7fiEEaJKNW8o= X-Received: by 2002:a1f:2983:0:b0:3a1:cb5c:83cf with SMTP id p125-20020a1f2983000000b003a1cb5c83cfmr5176966vkp.13.1662908942804; Sun, 11 Sep 2022 08:09:02 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: John Cowan Date: Sun, 11 Sep 2022 11:08:51 -0400 Message-ID: To: Douglas McIlroy Content-Type: multipart/alternative; boundary="000000000000d4832105e8682878" Message-ID-Hash: 4LVPFF323JKQIFRYVHBIDVOGTIZQPW2Z X-Message-ID-Hash: 4LVPFF323JKQIFRYVHBIDVOGTIZQPW2Z X-MailFrom: cowan@ccil.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tuhs.tuhs.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: TUHS main list X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: Does anybody know the etymology of the term "word" as in collection of bits? List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000d4832105e8682878 Content-Type: text/plain; charset="UTF-8" On Sun, Sep 11, 2022 at 9:31 AM Douglas McIlroy < douglas.mcilroy@dartmouth.edu> wrote: > [Algol 68's presupposition is visible in declarations like "long long > long ... int". An implementation need support only a limited number of > "longs", To clarify things for A68 n00bs, you can *write* an indefinite number of "longs", but after an implementation-defined point they don't add any further range (and/or precision in the case of floats). This is true in a truncated way in C as well, where "long" (which is the same as "long int") may be the same as "int". > but each supported variety must have a definite maximum > value, which is returned by an "environment enquiry" function. For > amusement, consider the natural idea of implementing the longest > variety with bignums.] > In actual bignum implementations, there is a biggest bignum, but it may not be possible to actually construct it. In GMP using 64-bit digits, it is theoretically 2^((2^31 - 1) * (2^64 - 1)), or 2^39,614,081,238,685,424,720,914,939,905, which is Very Big Indeed. But there is nothing preventing an implementer from watching intermediate results and throwing an exception if they get too big. --000000000000d4832105e8682878 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Sep 11, 2= 022 at 9:31 AM Douglas McIlroy <douglas.mcilroy@dartmouth.edu> wrote:
=C2=A0<= /div>
[Algol 68's pres= upposition is visible in declarations like "long long
long ... int". An implementation need support only a limited number of=
"longs",

To = clarify things for A68 n00bs, you can *write* an indefinite number of "= ;longs", but after an implementation-defined point they don't add = any further range (and/or precision in the case of floats).=C2=A0 This is t= rue in a truncated way in C as well, where "long" (which is the s= ame as "long int") may be the same as "int".
In actual bignum implementations, there is a biggest bignum, but it ma= y not be possible to actually construct it.=C2=A0 In GMP using 64-bit digit= s, it is theoretically 2^((2^31 - 1) * (2^64 - 1)), or 2^39,614,081,238,685= ,424,720,914,939,905, which is Very Big Indeed.=C2=A0 But there is nothing = preventing an implementer from watching intermediate results and throwing a= n exception if they get too big.
--000000000000d4832105e8682878--