From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: John Yates Newsgroups: gmane.emacs.help Subject: Re: What is 0.01 here not 0.01 here 0.009999999999999? Date: Fri, 2 Apr 2021 18:04:14 -0400 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14213"; mail-complaints-to="usenet@ciao.gmane.io" To: John Yates , Stefan Monnier , Help Gnu Emacs mailing list Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Sat Apr 03 00:05:51 2021 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lSRvJ-0003UW-Bn for geh-help-gnu-emacs@m.gmane-mx.org; Sat, 03 Apr 2021 00:05:49 +0200 Original-Received: from localhost ([::1]:56696 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lSRvI-0004g4-7V for geh-help-gnu-emacs@m.gmane-mx.org; Fri, 02 Apr 2021 18:05:48 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39084) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lSRu3-0004eh-Pp for help-gnu-emacs@gnu.org; Fri, 02 Apr 2021 18:04:31 -0400 Original-Received: from mail-lj1-f172.google.com ([209.85.208.172]:37886) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lSRu2-0000qi-07 for help-gnu-emacs@gnu.org; Fri, 02 Apr 2021 18:04:31 -0400 Original-Received: by mail-lj1-f172.google.com with SMTP id r20so6830195ljk.4 for ; Fri, 02 Apr 2021 15:04:26 -0700 (PDT) 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; bh=/SvcR9iirSBo3FHJo0OvH7AsQh9FX/q/+EQFppK1GzQ=; b=EQz+covyOPD1AkKQIoDJ8wIgqhUaGqvItB6fgJiiZisFgdOdUmWYD2RTCmOysb2UNX rc3V1oEc/OncmhCVWFpYy1i/bODwYOb1HBmVfeweeNe0NZUje2b2IqSi7Lrx0bCt4Cyq rGTK6YdPc8ASHv6BnEP9XoZxTOrJr5Res4qmXs+HmIe0D5tY/OexphpdQZYjUwaujVMG PkIm1EClLO7AE+gG1mFLuejeqkdxgi70Nvux8awyLiV8Ww9zgFoWRUjUEnrSBVvvXBc4 Fa45M3nmlJIYluCHjzK2XN3+RikFPx3aG0rUmOVXvtOC9lz0a8wzWxSuBR/9tZWp6fr9 9L2w== X-Gm-Message-State: AOAM531kWn/Lv4X1qQ6z+pvXf8Ih+dRGVbkbIutuyPUxL9M/aTJ2svg/ VivFKlASd2/183/SeMRQq4i1/kQrHJIoR7JR+Dg= X-Google-Smtp-Source: ABdhPJwoULTO1lF+6RxhwhzXjgbQMhwTIJ/WSjjfiG+Zv3CFk94Wr2eetC/AlSR3DdbKE6PWuNUkl3AMspJZGjN79hk= X-Received: by 2002:a2e:98c6:: with SMTP id s6mr9164309ljj.335.1617401065518; Fri, 02 Apr 2021 15:04:25 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=209.85.208.172; envelope-from=john.yates.sheets@gmail.com; helo=mail-lj1-f172.google.com X-Spam_score_int: -13 X-Spam_score: -1.4 X-Spam_bar: - X-Spam_report: (-1.4 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.io gmane.emacs.help:128824 Archived-At: > I did not find the word "significand", but I think you mean that above > definition. https://en.wikipedia.org/wiki/Significand > Yes, I need arithmetic on imprecise representations... to deliver what > I want, and it is doing what I want. `calc-eval' is doing it, and my > function is delivering me string that is increased for 0.01 -- well > that is what I wanted, and is happening... several times per hour > those numbers are increasing, function is working ;-p This will probably work because each time you increment by an approximation of 0.01 you convert back to a decimal representation via a path that applies a number of heuristics to guess what value you want to see. Having rendered your incremented value as a decimal string, when you read it back in you _do not_ recreate a bit for bit copy of the earlier sum, but rather a floating point number that is the closest approximation possible to the decimal number being presented. Put another way, each output / input iteration prevents you from accumulating errors. If you wanted to support more general arithmetic on your version numbers I would advise using scaled integer arithmetic. Assuming that you can guarantee the granularity of your version numbers will always be 0.01 then you can represent 0.01 as 1 and 11.07 as 1107. Then to recover the major version you just divide by 100 and to recover the minor version you mod by 100. Using 100 is necessary if you want 10.99 + 0.01 to return 11.00. If you never expect to handle a carry from your minor version field into your major version field then you could scale by a power of two (e.g. 128). Then division reduces to right shifting and mod to masking (e.g. for 128 that means anding with 127). /john