Skip Menu |
 

This queue is for tickets about the Math-BigInt CPAN distribution.

Report information
The Basics
Id: 113943
Status: resolved
Priority: 0/
Queue: Math-BigInt

People
Owner: Nobody in particular
Requestors: ZDM [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: 1.999719



Subject: Possibly new bug in the Math::BigFloat
MIME-Version: 1.0
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
Message-ID: <rt-4.0.18-29053-1461433372-171.0-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 353
Download (untitled) / with headers
text/plain 353b
Hi. We found, that CBOR::XS has stpped building after latest Math::* update. After the short investigation we found, that this is, possibly, new bug in Math::BigFloat. use Math::BigFloat; $x = Math::BigFloat->new (3); $x = $x->blsft (-1, 2); warn "$x"; This should give 1.5, but results in NaN. With older versions, this works correctly.
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-29053-1461433372-171.0-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <rt-4.0.18-29053-1461433372-171.0-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-28773-1461487654-481.113943-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 1239
Download (untitled) / with headers
text/plain 1.2k
Show quoted text
> use Math::BigFloat; > > $x = Math::BigFloat->new (3); > $x = $x->blsft (-1, 2); > warn "$x"; > > This should give 1.5, but results in NaN. With older versions, > this works correctly.
Shifting floats make no sense, because the internal representation is not just a sequence of bits that can be shifted left and right. If you search the net for bit-shifting floats you will find explanations for this. Since shifting floats make no sense, core Perl truncates floats to integers when you apply bit operations to floats. In the Math::Big* modules, shifting left by -1 is equivalent to shifting right by 1. Doing this with Perl gives you 1, not 1.5: $ perl -Mstrict -wle 'print 3 >> 1' 1 Note that bits that "fall off the end" to the right are dropped, so the result of a bit-shift operation in Perl is always an integer. The intention in the latest version of Math::BigFloat (and Math::BigRat) is to behave like core Perl in this manner. I.e., bit-shifting operations on a float truncates the float to an integer, applies the bit-shifting (dropping bits that "fall of the end" to the right). So I expected the answer to be 1. I won't agree that it is a bug that you don't get 1.5, but it is certainly a bug that the result is a NaN.
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-28773-1461487654-481.113943-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <rt-4.0.18-29053-1461433372-171.0-0-0 [...] rt.cpan.org> <rt-4.0.18-28773-1461487654-481.113943-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-28202-1461573445-1180.113943-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 1070
I was wrong, when I wrote "In the Math::Big* modules, shifting left by -1 is equivalent to shifting right by 1. This was true only for Math::BigFloat, and it was not according to the documentation. The documentation says blsft() and brsft() shifts left and right, and refers to the documentation in Math::BigInt, which says "Right shifting usually amounts to dividing $x by $n ** $y and truncating the result". So, the fact that you got 1.5 rather than 1, was not according to the documentation. With Math::BigInt, shifting left by a negative amount results in a NaN, and since Math::BigFloat now lets Math::BigInt do the actual shifting, that's why you got the NaN. In Perl, shifting left by a negative amount causes the bits to wrap, so while 3 >> 2 gives 0, 3 << -2 gives 13835058055282163712 (with 64 bit integer support). The equivalent in Math::BigInt is to return inf, I believe. By the way, if what you actually want to do is to multiply by a number (base) raised to some power, replace $x -> blsft($n, $b) with $x -> bmul($b -> copy() -> bpow($n))
MIME-Version: 1.0
X-Spam-Status: No, score=-6.699 tagged_above=-99.9 required=10 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_OUR_RT=-4, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
In-Reply-To: <rt-4.0.18-28202-1461573445-377.113943-6-0 [...] rt.cpan.org>
X-Spam-Flag: NO
X-RT-Interface: API
References: <RT-Ticket-113943 [...] rt.cpan.org> <rt-4.0.18-29053-1461433372-171.113943-6-0 [...] rt.cpan.org> <rt-4.0.18-28773-1461487654-481.113943-6-0 [...] rt.cpan.org> <rt-4.0.18-28202-1461573445-377.113943-6-0 [...] rt.cpan.org>
X-Virus-Scanned: Debian amavisd-new at bestpractical.com
X-Received: by 10.25.22.193 with SMTP id 62mr5556488lfw.117.1461574316741; Mon, 25 Apr 2016 01:51:56 -0700 (PDT)
Message-ID: <5ce0e612-59ab-9f70-ad74-fe59ec89fb61 [...] gmail.com>
content-type: text/plain; charset="utf-8"
X-RT-Original-Encoding: utf-8
X-Spam-Score: -6.699
Authentication-Results: hipster.bestpractical.com (amavisd-new); dkim=pass header.i= [...] gmail.com
Received: from localhost (localhost [127.0.0.1]) by hipster.bestpractical.com (Postfix) with ESMTP id 350E22400F7 for <cpan-bug+Math-BigInt [...] hipster.bestpractical.com>; Mon, 25 Apr 2016 04:52:13 -0400 (EDT)
Received: from hipster.bestpractical.com ([127.0.0.1]) by localhost (hipster.bestpractical.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbtdoZXEpe-2 for <cpan-bug+Math-BigInt [...] hipster.bestpractical.com>; Mon, 25 Apr 2016 04:52:10 -0400 (EDT)
Received: from la.mx.develooper.com (x1.develooper.com [207.171.7.70]) by hipster.bestpractical.com (Postfix) with SMTP id 7EA892400E0 for <bug-Math-BigInt [...] rt.cpan.org>; Mon, 25 Apr 2016 04:52:10 -0400 (EDT)
Received: (qmail 1223 invoked by alias); 25 Apr 2016 08:52:10 -0000
Received: from mail-lf0-f65.google.com (HELO mail-lf0-f65.google.com) (209.85.215.65) by la.mx.develooper.com (qpsmtpd/0.28) with ESMTP; Mon, 25 Apr 2016 01:52:08 -0700
Received: by mail-lf0-f65.google.com with SMTP id p64so15301480lfg.0 for <bug-Math-BigInt [...] rt.cpan.org>; Mon, 25 Apr 2016 01:52:00 -0700 (PDT)
Received: from [192.168.0.101] ([46.219.252.114]) by smtp.gmail.com with ESMTPSA id h124sm4280680lfh.7.2016.04.25.01.51.56 for <bug-Math-BigInt [...] rt.cpan.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Apr 2016 01:51:56 -0700 (PDT)
Delivered-To: cpan-bug+Math-BigInt [...] hipster.bestpractical.com
Subject: Re: [rt.cpan.org #113943] Possibly new bug in the Math::BigFloat
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0
Return-Path: <dzagashev [...] gmail.com>
Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=f+D8BH41Ogx0o+soWw7AsTxyXN5TE5Y1fDMIPan4KoE=; b=ooR9p6jn+XP8u5LOS0PRDydoKwbFb9EDnGVOJrvHPgRHGx2JN3Qxci31RpJ9bbn424 uTWWRdFZuxL5pnOGwcNgWj0tC6aQ2j0Tpuo8PTtS+Cam2HSXLWpbcyNwQYr3OU86Nx3I W+xRFzH89cPAWgH7dJgLRmU9sir+uh9HMn2CBgberN980mnoL4VItKQBGa7zIx8yUcus 8m1W8L4Cx89/wqxNaHo+tCoem37m5Hx3E5Qn8ZrLqCCYphMp71OVfj8HGvdHSioDSbo3 FpUI5B1hTfyycWeb2PypPMhGdlBH3328IDd8gzIkrKO39K9bwIabhIYaArkx0gDp+VLq O8Bg==
X-Spam-Check-BY: la.mx.develooper.com
X-Original-To: cpan-bug+Math-BigInt [...] hipster.bestpractical.com
X-RT-Mail-Extension: math-bigint
X-Google-Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=f+D8BH41Ogx0o+soWw7AsTxyXN5TE5Y1fDMIPan4KoE=; b=RKsUZ8bnacvwV1aVTO5URfC1QNjnYZcK8sjC0qctL8wRZcvMx80VkFWMKFK6mNpRuK eiTyqaj9TgG02UzlThdyhOHk0bZolqtZQ/xPGcEysUwDmbz975hRq54aovo+NCLFpbgR 80Trj9Ui00JM3H+py7tgwuTuAxkewn4Jxs7Wz9tZN1u65GRR8w0MdrL6hcnRlEYPLmlP CJiODr4nNmqXXyKxXmCX8WD3oIzMpMCm9g5f2uQcuuz4CwOXN1c25uvJ5p0pPUtY/CGV 96CGuMj0DGjRC4D671Q7ttHg467piT97jWeFIBHnVCLnwM2oMQEGkAsUftKEEB82L8+a e/3g==
Date: Mon, 25 Apr 2016 11:51:52 +0300
X-Spam-Level:
To: bug-Math-BigInt [...] rt.cpan.org
Content-Transfer-Encoding: quoted-printable
X-GM-Message-State: AOPr4FV8kE+ZTai6bGW4EhTyU7OI7mJQ38mCsYo5CO4v7BSMicqLdfIC0dcPy2+mm0hggw==
From: "dzagashev [...] gmail.com" <dzagashev [...] gmail.com>
RT-Message-ID: <rt-4.0.18-29223-1461574334-997.113943-0-0 [...] rt.cpan.org>
Content-Length: 1340
Download (untitled) / with headers
text/plain 1.3k
Please, read this analysis report. http://blog.schmorp.de/2016-04-23-mathbigfloat-maintainer-fail.html On 25.04.2016 11:37, Peter John Acklam via RT wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=113943 > > > I was wrong, when I wrote "In the Math::Big* modules, shifting > left by -1 is equivalent to shifting right by 1. This was true > only for Math::BigFloat, and it was not according to the > documentation. The documentation says blsft() and brsft() shifts > left and right, and refers to the documentation in Math::BigInt, > which says "Right shifting usually amounts to dividing $x by > $n ** $y and truncating the result". So, the fact that you got 1.5 > rather than 1, was not according to the documentation. > > With Math::BigInt, shifting left by a negative amount results in a > NaN, and since Math::BigFloat now lets Math::BigInt do the actual > shifting, that's why you got the NaN. > > In Perl, shifting left by a negative amount causes the bits to > wrap, so while 3 >> 2 gives 0, 3 << -2 gives 13835058055282163712 > (with 64 bit integer support). The equivalent in Math::BigInt is > to return inf, I believe. > > By the way, if what you actually want to do is to multiply by a > number (base) raised to some power, replace > > $x -> blsft($n, $b) > > with > > $x -> bmul($b -> copy() -> bpow($n))
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-29223-1461574334-997.113943-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <RT-Ticket-113943 [...] rt.cpan.org> <rt-4.0.18-29053-1461433372-171.113943-6-0 [...] rt.cpan.org> <rt-4.0.18-28773-1461487654-481.113943-6-0 [...] rt.cpan.org> <rt-4.0.18-28202-1461573445-377.113943-6-0 [...] rt.cpan.org> <5ce0e612-59ab-9f70-ad74-fe59ec89fb61 [...] gmail.com> <rt-4.0.18-29223-1461574334-997.113943-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-17715-1461587410-933.113943-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 2509
Download (untitled) / with headers
text/plain 2.4k
On Mon Apr 25 04:52:14 2016, dzagashev@gmail.com wrote: Show quoted text
I have read the "analysis", and I have to admit it would be easier to take it more seriously if it weren't for all the ranting, straw man arguments, and false assumtions made there. I am more than willing to discuss my change, including how blsft() and brsft() ought to behave, but I am not going to spend time wading through a lot of ranting. I have a few replies to the "analysis". - Just because some piece of code has behaved in a certain way over many years, doesn't make that behaviour correct. Hence, changing a certain old behaviour isn't necessarily a bug. - blsft() and brsft() are so poorly documented that it is not obvious what is the correct behaviour. The documentation provided in the "analysis" is just one of several fragments. The actual documentation in the modules contain other pieces of documentation that can be interpreted differently than the one provided in the "analysis". - Considering Math::Big(Int|Float|Rat) toy modules that are too unreliable for serious use is nothing new. They have been toy modues ever since TELS redesigned these modules more than 10 years ago. Initially, my intention was to use these modules for numerical analysis of special functions, but I didn't dare, because I quickly realized that these modules contain a staggering amount of bugs, inconsistencies and a fundamentally flawed design. This has also been commented by some of the most well-known people in the Perl community. - Am I the best maintainer for these modules? Maybe not, but at least I am maintaining them. I took over as maintainer because no one else gave these modules the priority they deserved. I believe I have both reported and fixed more bugs in these modules than anyone else. And when someone has pointed out that I have, unfortunately, introduced a bug, I have fixed it quickly. - I have not claimed that Perl core has a blsft() method. However, since others have referred to << and >> as bitwise operators, and since Math::Big* overloads << and >> to directly call blsft() and brsft() I was under the impression that blsft() and brsft() were bitwise operators. - I have not claimed that << and >> in Math::Big* should emulate Perl core << and >> in every aspect. - I have not claimed that I will keep the current behaviour of blsft() and brsft().
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-17715-1461587410-933.113943-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <RT-Ticket-113943 [...] rt.cpan.org> <rt-4.0.18-29053-1461433372-171.113943-6-0 [...] rt.cpan.org> <rt-4.0.18-28773-1461487654-481.113943-6-0 [...] rt.cpan.org> <rt-4.0.18-28202-1461573445-377.113943-6-0 [...] rt.cpan.org> <5ce0e612-59ab-9f70-ad74-fe59ec89fb61 [...] gmail.com> <rt-4.0.18-29223-1461574334-997.113943-0-0 [...] rt.cpan.org> <rt-4.0.18-17715-1461587410-933.113943-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-7683-1461598195-81.113943-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 169
Download (untitled) / with headers
text/plain 169b
I see now that when blsft() is tested in the test suite file t/bigfltpm.inc, it actually runs <<, not blsft(), again indicating that << and blsft() should be equivalent.
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-7683-1461598195-81.113943-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <RT-Ticket-113943 [...] rt.cpan.org> <rt-4.0.18-29053-1461433372-171.113943-6-0 [...] rt.cpan.org> <rt-4.0.18-28773-1461487654-481.113943-6-0 [...] rt.cpan.org> <rt-4.0.18-28202-1461573445-377.113943-6-0 [...] rt.cpan.org> <5ce0e612-59ab-9f70-ad74-fe59ec89fb61 [...] gmail.com> <rt-4.0.18-29223-1461574334-997.113943-0-0 [...] rt.cpan.org> <rt-4.0.18-17715-1461587410-933.113943-0-0 [...] rt.cpan.org> <rt-4.0.18-7683-1461598195-81.113943-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-4486-1461612622-1825.113943-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 126
Download (untitled) / with headers
text/plain 126b
I have reverted the changes to blsft() and brsft() in Math::BigFloat and uploaded v1.999719 of the Math-BigInt distro to CPAN.
MIME-Version: 1.0
X-Spam-Status: No, score=-6.699 tagged_above=-99.9 required=10 tests=[AWL=-0.000, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_OUR_RT=-4, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
In-Reply-To: <rt-4.0.18-3261-1461663517-879.113943-10-0 [...] rt.cpan.org>
X-Spam-Flag: NO
X-RT-Interface: API
References: <RT-Ticket-113943 [...] rt.cpan.org> <rt-4.0.18-3261-1461663517-879.113943-10-0 [...] rt.cpan.org>
X-Virus-Scanned: Debian amavisd-new at bestpractical.com
X-Received: by 10.112.37.10 with SMTP id u10mr1284088lbj.28.1461681071322; Tue, 26 Apr 2016 07:31:11 -0700 (PDT)
Message-ID: <a107ec73-49e2-03c1-cea7-8be8885a88f9 [...] gmail.com>
content-type: text/plain; charset="utf-8"
X-RT-Original-Encoding: utf-8
X-Spam-Score: -6.699
Authentication-Results: hipster.bestpractical.com (amavisd-new); dkim=pass header.i= [...] gmail.com
Received: from localhost (localhost [127.0.0.1]) by hipster.bestpractical.com (Postfix) with ESMTP id 11CF92403B0 for <cpan-bug+Math-BigInt [...] hipster.bestpractical.com>; Tue, 26 Apr 2016 10:31:33 -0400 (EDT)
Received: from hipster.bestpractical.com ([127.0.0.1]) by localhost (hipster.bestpractical.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Gk3ocBzg-bD for <cpan-bug+Math-BigInt [...] hipster.bestpractical.com>; Tue, 26 Apr 2016 10:31:27 -0400 (EDT)
Received: from la.mx.develooper.com (x1.develooper.com [207.171.7.70]) by hipster.bestpractical.com (Postfix) with SMTP id B335724003A for <bug-Math-BigInt [...] rt.cpan.org>; Tue, 26 Apr 2016 10:31:26 -0400 (EDT)
Received: (qmail 768 invoked by alias); 26 Apr 2016 14:31:24 -0000
Received: from mail-lf0-f65.google.com (HELO mail-lf0-f65.google.com) (209.85.215.65) by la.mx.develooper.com (qpsmtpd/0.28) with ESMTP; Tue, 26 Apr 2016 07:31:22 -0700
Received: by mail-lf0-f65.google.com with SMTP id m101so2620679lfi.1 for <bug-Math-BigInt [...] rt.cpan.org>; Tue, 26 Apr 2016 07:31:15 -0700 (PDT)
Received: from [192.168.0.101] ([46.219.246.181]) by smtp.gmail.com with ESMTPSA id zw6sm5442839lbb.14.2016.04.26.07.31.10 for <bug-Math-BigInt [...] rt.cpan.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Apr 2016 07:31:10 -0700 (PDT)
Delivered-To: cpan-bug+Math-BigInt [...] hipster.bestpractical.com
Subject: Re: [rt.cpan.org #113943] Resolved: Possibly new bug in the Math::BigFloat
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0
Return-Path: <dzagashev [...] gmail.com>
Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=/VyfRJl7g5BI4bxy6RiaudbE3i0yuVP/SSWuYneAkvU=; b=hccZq3AjlY6WQUq4T8lUzU7HXgvrpdBNuqDk5gAJQnjWiwDZSo9Eohr+ZMSPfWUjx2 Gjs/wtcluijA43rEsozfqVQ0fM5TtohV1+BlKYHiA49C4RDTygw5w4ZrdZHy5DJovrwS YKnYvROpTRDFc/EIbigGQKb7KSYAkNLV5k/sP0lJ77bydwoUcD6wSTWjV5v0qT9FG8ye gCJ24yy59KdNUw7s/Ayd+hOB7UiF6Arq/A29SABjzZkYN5Tk3Edt0ZpUCGvlialQL5en GC0ocdoC/8tpRjxK6x0e3IkI3Ao9PLMTgzeOLNTqam/DVzIsQnwhUWJPlZCsVvcAcb1W 4GLQ==
X-Spam-Check-BY: la.mx.develooper.com
X-Original-To: cpan-bug+Math-BigInt [...] hipster.bestpractical.com
X-RT-Mail-Extension: math-bigint
X-Google-Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=/VyfRJl7g5BI4bxy6RiaudbE3i0yuVP/SSWuYneAkvU=; b=E+11scYSJK+vZOFwSbuh0qFYzPe/+DVSxxa10s2SFzw80KdEPILtMPBAwaSgVjt0zs WpOpMaMiyyqhLVyV3Ryba6d31xVhaQPZzEpbceTpmOwz+wi6U2Oo+O8wPUFjEDw4p3zI up49mve4WdcmR/OtvngiCeM48ng6D0zycfULUqkKMGrJg1lN3wQCZZ4VsAUvt3/UKa8C CpVdyMK4rs2YlnLAhA+Gv30+HC4RaxNP6P+oBD9leF9hXxzH0uzMxJ6ADavhLdEZxw/d y3JsDtdaGWiF8ksX9ljBDPxs8NXZUA6Z1DdsNuu1DL7mEwr/iwq50OrhjFHkVV2Zr22H RRTw==
Date: Tue, 26 Apr 2016 17:31:05 +0300
X-Spam-Level:
To: bug-Math-BigInt [...] rt.cpan.org
Content-Transfer-Encoding: quoted-printable
X-GM-Message-State: AOPr4FUORE+ZbsONzhZ/ODq+KlTDxYdfshyY/+KUrgNlowbyMMN+Hpd+A75V2EpcipiO6A==
From: "dzagashev [...] gmail.com" <dzagashev [...] gmail.com>
RT-Message-ID: <rt-4.0.18-12542-1461681093-127.113943-0-0 [...] rt.cpan.org>
Content-Length: 387
Download (untitled) / with headers
text/plain 387b
Peter, you are the best maintainer for this modules. I am sorry, if that article was too critical and thank you for your work. On 26.04.2016 12:38, Peter John Acklam via RT wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=113943 > > > According to our records, your request has been resolved. If you have any > further questions or concerns, please respond to this message.
MIME-Version: 1.0
X-Spam-Status: No, score=-5.408 tagged_above=-99.9 required=10 tests=[AWL=1.192, BAYES_00=-1.9, FROM_OUR_RT=-4, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
In-Reply-To: <rt-4.0.18-12542-1461681093-1809.113943-5-0 [...] rt.cpan.org>
X-Spam-Flag: NO
X-RT-Interface: API
References: <RT-Ticket-113943 [...] rt.cpan.org> <rt-4.0.18-3261-1461663517-879.113943-10-0 [...] rt.cpan.org> <a107ec73-49e2-03c1-cea7-8be8885a88f9 [...] gmail.com> <rt-4.0.18-12542-1461681093-1809.113943-5-0 [...] rt.cpan.org>
Importance: Normal
X-Virus-Scanned: Debian amavisd-new at bestpractical.com
Message-ID: <0012462ef172cb8c7342a997701540c8.squirrel [...] sm.webmail.pair.com>
Reply-To: nospam-abuse [...] bloodgate.com
content-type: text/plain; charset="utf-8"
X-RT-Original-Encoding: utf-8
X-Spam-Score: -5.408
Received: from localhost (localhost [127.0.0.1]) by hipster.bestpractical.com (Postfix) with ESMTP id AA7F9240123 for <cpan-bug+Math-BigInt [...] hipster.bestpractical.com>; Thu, 28 Apr 2016 15:07:41 -0400 (EDT)
Received: from hipster.bestpractical.com ([127.0.0.1]) by localhost (hipster.bestpractical.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ao4aB72yuhHV for <cpan-bug+Math-BigInt [...] hipster.bestpractical.com>; Thu, 28 Apr 2016 15:07:40 -0400 (EDT)
Received: from la.mx.develooper.com (x1.develooper.com [207.171.7.70]) by hipster.bestpractical.com (Postfix) with SMTP id 0A9A52400C9 for <bug-Math-BigInt [...] rt.cpan.org>; Thu, 28 Apr 2016 15:07:39 -0400 (EDT)
Received: (qmail 12468 invoked by alias); 28 Apr 2016 19:07:39 -0000
Received: from www4.webmail.pair.com (HELO www4.webmail.pair.com) (66.39.3.58) by la.mx.develooper.com (qpsmtpd/0.28) with ESMTP; Thu, 28 Apr 2016 12:07:35 -0700
Received: by www4.webmail.pair.com (Postfix, from userid 65534) id E0179B425BE; Thu, 28 Apr 2016 15:07:28 -0400 (EDT)
Received: from 87.79.169.187 ([87.79.169.187]) (SquirrelMail authenticated user te_123 [...] bloodgate.com) by sm.webmail.pair.com with HTTP; Thu, 28 Apr 2016 15:07:28 -0400
Delivered-To: cpan-bug+Math-BigInt [...] hipster.bestpractical.com
Subject: Re: [rt.cpan.org #113943] Resolved: Possibly new bug in the Math::BigFloat
User-Agent: SquirrelMail/1.4.23 [SVN]
Return-Path: <nospam-abuse [...] bloodgate.com>
X-Spam-Check-BY: la.mx.develooper.com
X-Original-To: cpan-bug+Math-BigInt [...] hipster.bestpractical.com
X-RT-Mail-Extension: math-bigint
X-Priority: 3 (Normal)
Date: Thu, 28 Apr 2016 15:07:28 -0400
X-Spam-Level:
To: bug-Math-BigInt [...] rt.cpan.org
Content-Transfer-Encoding: 8bit
From: "Tels" <nospam-abuse [...] bloodgate.com>
RT-Message-ID: <rt-4.0.18-20707-1461870462-1558.113943-0-0 [...] rt.cpan.org>
Content-Length: 2667
Download (untitled) / with headers
text/plain 2.6k
On Tue, April 26, 2016 10:31 am, dzagashev@gmail.com via RT wrote: Show quoted text
> Queue: Math-BigInt > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=113943 > > > Peter, you are the best maintainer for this modules. I am sorry, if that > article was too critical and thank you for your work. > > > On 26.04.2016 12:38, Peter John Acklam via RT wrote:
>> <URL: https://rt.cpan.org/Ticket/Display.html?id=113943 > >> >> According to our records, your request has been resolved. If you have >> any >> further questions or concerns, please respond to this message.
Hello together, sorry for the late reply, I seldom check my emails these days. Thank you, Peter for mainting my pileofcrap^Wmodules! This is much appeciated, and a lot of work you probably get not thanks for :) According to the bugreport, the changes have already been reverted. I'd still like to add a bit of reasoning and history here, just for the record. Maybe this helps in the future with such decisions. There was some reasoning along the lines of "<< uses blsft() so they must be equivalent.". That's not what was intended. First: the "bigfloat" etc modules where invented to get better math into Perl without having to rewrite scripts. Even after much work, that never really works except in special cases. However, to get them even to work, we need overloaded operators. And to avoid reinventing the wheel, "<<" simply uses blsft(). That does not mean, however, that blsft() should work only on or return integers, or that the "<<" operator should actually be exactly the same as blsft()! (Yes, I know, I should have added a lot more documentation. My bad.) And second: Math::BigRat should be a superset of Math::BigFloat and this should be a superset of Math::BigInt. So a method in BigRat should return (if possible) a BigRat, in BigFloat a BigFloat - and not just truncate to BigInt. I think the confusion might come from the fact that the modules share a lot of code, design and are interwined a lot. In theory, however, you should be able to use Math::BigFloat and compute with BigFloats w/o even knowing about Math::BigInt. Anyway, the Math::Big modules have indeed not had the best history - and while my rewrite back then took staggering amounts of work it still left way too many loose ends for my taste. I probably also added a few bad design choices and bugs - sorry for that, but my (Perl) knowledge was limited back then. The rewritten modules are still, IMHO, light-years ahead than what we had before. If anyone thinks they are still insufficient for real work - well, you can always roll your own :) Thanx for reading, tels -- http://bloodgate.com/galleries/
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-20707-1461870462-1558.113943-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <RT-Ticket-113943 [...] rt.cpan.org> <rt-4.0.18-3261-1461663517-879.113943-10-0 [...] rt.cpan.org> <a107ec73-49e2-03c1-cea7-8be8885a88f9 [...] gmail.com> <rt-4.0.18-12542-1461681093-1809.113943-5-0 [...] rt.cpan.org> <0012462ef172cb8c7342a997701540c8.squirrel [...] sm.webmail.pair.com> <rt-4.0.18-20707-1461870462-1558.113943-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-19939-1465051412-127.113943-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 2510
Download (untitled) / with headers
text/plain 2.4k
On Thu Apr 28 15:07:42 2016, nospam-abuse@bloodgate.com wrote: Show quoted text
> > (Yes, I know, I should have added a lot more documentation. My bad.)
The lack of documentation makes it more difficult to determine what is a big. Without the documentation there is no reference stating how it should actually work. But lack of documentation is just one part of the problem -- equally bad is all the documentation that is wrong. Here are some cases extracted from just a few lines in Math::BigFloat: - Output values are BigFloat objects (normalized), except for bstr() and bsstr(). Wrong. The parts() method returns BigInt objects, not BigFloats. - The string output will always have leading and trailing zeros stripped and drop a plus sign. Wrong. Zeros are padded to the current accuracy or precision. E.g., the number 2 with accuracy 3 prints "2.00". - The input ' -123 123 123' will cause bsstr() to print '-123123123E0'. Wrong. Firstly, the input ' -123 123 123' is invalid and will produce a NaN. Secondly, if the input was valid, the output would be '-123123123e+0', with a lower-case 'e' and a sign in the exponent. - bsstr() returns a string in scientific notation. Questionable. The value of "3141592e-6" is correct, but standard scientific notation is "3.141592e+0" or ".3141592e+1", the latter possibly with a leading zero. Show quoted text
> And second: Math::BigRat should be a superset of Math::BigFloat and this > should be a superset of Math::BigInt.
That hardly makes sense, since rational numbers is not a superset of floating point numbers. However, both rational numbers and floating point numbers are supersets of integers. In any case, I can not make sens of the way it is implemented. Currently, a Math::BigInt object is a sign and an integer. And it would make sense if a Math::BigFloat object was a Math::BigInt with an added fraction part, but that isn't at all how it is implemented. The only thing a Math::BigInt, a Math::BigFloat and a Math::BigRat have in common is the sign. And with that implementation, it doesn't make sense that they are subclasses of each other. If this wasn't enough, Math::BigFloat->isa() tells that Math::BigFloat isn't a Math::BigInt after all. There is no end to the mess. Show quoted text
> If anyone thinks they are still insufficient for real work - well, you > can always roll your own :)
That is just arrogant. Math::BigInt, Math::BigFloat, and Math::BigRat are in the Perl distribution, so people expect them to work properly.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.