From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Panicz Maciej Godek Newsgroups: gmane.lisp.guile.user Subject: Re: Double-precision floating point arithmetics behaves differently in Guile and in C Date: Sun, 26 Sep 2021 18:48:51 +0200 Message-ID: References: <83bl4fo4t0.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1964"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Guile User To: Eli Zaretskii Original-X-From: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Sun Sep 26 18:49:19 2021 Return-path: Envelope-to: guile-user@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 1mUXL5-0000L2-NN for guile-user@m.gmane-mx.org; Sun, 26 Sep 2021 18:49:19 +0200 Original-Received: from localhost ([::1]:52834 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mUXL4-0002Xw-5c for guile-user@m.gmane-mx.org; Sun, 26 Sep 2021 12:49:18 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45260) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mUXKt-0002Xn-6h for guile-user@gnu.org; Sun, 26 Sep 2021 12:49:07 -0400 Original-Received: from mail-il1-x12e.google.com ([2607:f8b0:4864:20::12e]:46762) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mUXKr-0001Nr-5x; Sun, 26 Sep 2021 12:49:06 -0400 Original-Received: by mail-il1-x12e.google.com with SMTP id h20so16408124ilj.13; Sun, 26 Sep 2021 09:49:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vNXRU5OhVPtZI8xWGWdvOrgSKZjZqnST2o2HTUc4tKk=; b=OpgFlTjvYYbe44csuv3Ib5yH77FPcM1ys6NK5f0oit3hY0VYuwG6dLgQf5eUL6VBiT jCXAYDJoAIh4t89j1JUAXMUpcNDO9bnG/o9r/taSDpbMG4nuMOxG0GQ3w0TCRdSxXb1A zfwNiGWI6C/6RFSi+n6YhD3spvYooxETv6PnXHh9hDSsCtThHQjVxWDBup//I0JvRQiK wM3Y/UVw2pxCoagBoju1PMTleAIzUJFygIcHIvXRa49ugmrfoQZ1u5JIuL7cfanbkr9V rOrNSYIJNWO6etrRXbwVeNM2LO7v64EOiSmUmVFApLSvt/KQRC6lCwF//H6jM82IwqGk 8owQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vNXRU5OhVPtZI8xWGWdvOrgSKZjZqnST2o2HTUc4tKk=; b=LnvFqH2I+J+tNWffmgdeVMWaNxhBp9c27W/NnY1rzn3OuCPnPozERZ1sjG4P6Rku4X SUxo1mMhcC4RW6Fz1g3Ni+fm6eM9raE/pXHYIbSkqm4u4cyHiV3exp1KNuEvrZaM9myN BwyRiwZYMLeZ2eAr6m8Q5QJityT3X+pT40L+F/mJsV2xLvfnIjdUD9soQG3ntxZxgHct 8Lu1YuhYE4CTGYqbB6BqkAh4Mcb+9/CLaC+iN6yFk/3eHDJpjVKlvVvPMHenYvfJwdtJ och3oK/PISyQifadisZvsCag7UePZ5S6XYyXFNyWIeosFoo0fvE99+xlKLCQQR9ONb5H xwQA== X-Gm-Message-State: AOAM532yuikG/NZl4g1Y7Fum40DjTAcFPeLnqTBKD9bK4MArbzDjHWc1 z5S9HlOZOSdFGxVqOASlE9CzwCGFzD3aUBYcbGDbndkihO4= X-Google-Smtp-Source: ABdhPJzHkAXfddX4DrRfY6uWDbQQDjt/JzQNpvnw52hQyu5Uiz5k8K3CieTpK+P/SUj8DhoByiSXk3lAB345huwS5H0= X-Received: by 2002:a05:6e02:1b8e:: with SMTP id h14mr16066206ili.18.1632674943463; Sun, 26 Sep 2021 09:49:03 -0700 (PDT) In-Reply-To: <83bl4fo4t0.fsf@gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::12e; envelope-from=godek.maciek@gmail.com; helo=mail-il1-x12e.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Original-Sender: "guile-user" Xref: news.gmane.io gmane.lisp.guile.user:17783 Archived-At: Thanks for the feedback! It turned out that SVD was fine and I was looking in the wrong place -- in the C counterpart, I was feeding my ellipsoid algorithm with uninitialized junk, and the compiler didn't shout at me. Sorry for the noise! niedz., 26 wrz 2021 o 15:16 Eli Zaretskii napisa=C5=82(a): > > From: Panicz Maciej Godek > > Date: Sun, 26 Sep 2021 13:55:20 +0200 > > > > I forgot to mention that I run Guile in an Emacs session running in a W= SL > > console on Windows 10. > > The tests of the C code that I've been performing so far were executed = in > > an MSYS terminal, but I have just tried running them in WSL console, an= d > > the radii get ridiculous values. > > > > While the values used to generate the points are the following: > > > > center '[-65.12 -50.54 88.66]: > > radii: '[83.95 47.13 45.56] > > rotation: '[[9.633871e-001 1.363818e-001 -2.308359e-001] > > [-1.734094e-001 9.735887e-001 -1.485064e-001] > > [2.044857e-001 1.830983e-001 9.615927e-001]] > > > > and the values reconstructed in Guile are: > > > > (ellipsoid > > #:center (65.10194623013226 -88.58460232582514 -50.721825868168324) > > #:radii (83.94677717528019 45.56525864722978 47.12037877216948) > > #:rotation ((-0.9633227088329351 0.2307406879308479 > 0.13699669185777974) > > (0.173638969876562 0.14674930301995573 > > 0.9738142277679884) > > (-0.20459439578586436 -0.961885324244193 > > 0.18143251146545056))) > > > > (the signs and the order of radii differ, but it seems that the rotatio= n > > matrix compensates for that) > > > > in the case of MSYS (MinGW 64-bit) I get the following values: > > > > approx_e.center =3D [90.13, -68.76, -42.46] > > approx_e.radius =3D [178.83, 97.08, 100.43] > > approx_e.rotation(3x3) =3D > > -9.634121049254586e-001 1.734020884333972e-001 > > -2.043742444879810e-001 > > -2.314281253565038e-001 -1.535574849495593e-001 > > 9.606566096217422e-001 > > -1.351966674037161e-001 -9.728061546592428e-001 > > -1.880692600613582e-001 > > > > but in the case of the WSL console, I get > > > > approx_e.center =3D [90.13, -68.76, -42.46] > > approx_e.radius =3D [1347844355973136335704668472606720.00, > > 731678657375689861259088782950400.00, > 756961648396782369967223865344000.00] > > approx_e.rotation(3x3) =3D > > -9.634121049254428e-01 1.734020884334219e-01 > > -2.043742444880351e-01 > > -2.314281253566119e-01 -1.535574849499134e-01 > > 9.606566096216593e-01 > > -1.351966674036449e-01 -9.728061546591822e-01 > > -1.880692600617213e-01 > > Forgive me for saying this, but frankly the most probable reason for > this is some bug in converting the Scheme code to C. SVD is a > remarkably stable algorithm in the face of numerical roundoff errors, > that's one of its strong points. So if the issue is with some minor > numerical inaccuracies, SVD results should be insensitive to it, as > long as the condition numbers of the matrices that you decompose are > not preposterously large, like 10^12 or something. (Did you calculate > the condition numbers, btw? what are they?) > > So I would check and recheck your C code, as IMO that's the first > suspect in this story. > > Also, please note that on Intel CPUs double-precision FP calculations > usually keep intermediate results in 10-byte (80-bit) wide "long > double" format, unless your program is built with the GCC switch that > disables that (few programs do, so I don't expect you to do that, > eneither while building Guile, nor when compiling your C > implementation of SVD). But that cannot by itself explain the > problem, because using 80-bit FP values should make the results more > accurate, not less accurate. > > So again, I suspect your C program. Does it work well when you throw > simple problems at it, like systems of linear equations where the > result is known in advance and the condition number of the matrix is > around 1? > > HTH >