On 2021-09-11, Chris Angelico wrote:
> Once you accept that "perfectly representable numbers" aren't
> necessarily the ones you expect them to be, 64-bit floats become
> adequate for a huge number of tasks. Even 32-bit floats are pretty
> reliable for most tasks, although I suspect that there's l
On 2021-09-12 01:40:12 +1000, Chris Angelico wrote:
> On Sun, Sep 12, 2021 at 1:07 AM Peter J. Holzer wrote:
> > If you have any "decimals" (i.e decimal digits to the right of your
> > decimal point) then the input values won't be exactly representable and
> > the nearest representation will use a
On Sun, Sep 12, 2021 at 1:07 AM Peter J. Holzer wrote:
> If you have any "decimals" (i.e decimal digits to the right of your
> decimal point) then the input values won't be exactly representable and
> the nearest representation will use all available bits, thus losing some
> precision with most ad
On 2021-09-05 23:21:14 -0400, Richard Damon wrote:
> > On Sep 5, 2021, at 6:22 PM, Peter J. Holzer wrote:
> > On 2021-09-04 10:01:23 -0400, Richard Damon wrote:
> >>> On 9/4/21 9:40 AM, Hope Rouselle wrote:
> >>> Hm, I think I see what you're saying. You're saying multiplication and
> >>> divisio
On 2021-09-05 22:32:51 -, Grant Edwards wrote:
> On 2021-09-05, Peter J. Holzer wrote:
[on the representability of fractional numbers as floating point
numbers]
> And once you understand that, ignore it and write code under the
> assumumption that nothing can be exactly represented in floati
Joe Pfeiffer writes:
> Hope Rouselle writes:
>> Christian Gollwitzer writes:
>>>
>>> I believe it is not commutativity, but associativity, that is
>>> violated.
>>
>> Shall we take this seriously? (I will disagree, but that doesn't mean I
>> am not grateful for your post. Quite the contary.)
Hope Rouselle writes:
> Christian Gollwitzer writes:
>>
>> I believe it is not commutativity, but associativity, that is
>> violated.
>
> Shall we take this seriously? (I will disagree, but that doesn't mean I
> am not grateful for your post. Quite the contary.) It in general
> violates assoc
Chris Angelico writes:
> On Sun, Sep 5, 2021 at 1:04 PM Hope Rouselle wrote:
>> The same question in other words --- what's a trivial way for the REPL
>> to show me such cycles occur?
>>
>> >> 7.23.as_integer_ratio()
>> >>> (2035064081618043, 281474976710656)
>>
>> Here's what I did on this
"Peter J. Holzer" writes:
> On 2021-09-05 03:38:55 +1200, Greg Ewing wrote:
>> If 7.23 were exactly representable, you would have got
>> 723/1000.
>>
>> Contrast this with something that *is* exactly representable:
>>
>> >>> 7.875.as_integer_ratio()
>> (63, 8)
>>
>> and observe that 7875/1000
On 2021-09-05, Peter J. Holzer wrote:
> On 2021-09-05 03:38:55 +1200, Greg Ewing wrote:
>> If 7.23 were exactly representable, you would have got
>> 723/1000.
>>
>> Contrast this with something that *is* exactly representable:
>>
>> >>> 7.875.as_integer_ratio()
>> (63, 8)
>>
>> and observe that
On Sat, 04 Sep 2021 10:40:35 -0300, Hope Rouselle
declaimed the following:
>course, I don't even have floats to worry about.) If I'm given 1.17,
>say, I am not confident that I could turn this number into 117 by
>multiplying it by 100. And that was the question. Can I always
>multiply such IEE
> On Sep 5, 2021, at 6:22 PM, Peter J. Holzer wrote:
>
> On 2021-09-04 10:01:23 -0400, Richard Damon wrote:
>>> On 9/4/21 9:40 AM, Hope Rouselle wrote:
>>> Hm, I think I see what you're saying. You're saying multiplication and
>>> division in IEEE 754 is perfectly safe --- so long as the numb
On 2021-09-04 10:01:23 -0400, Richard Damon wrote:
> On 9/4/21 9:40 AM, Hope Rouselle wrote:
> > Hm, I think I see what you're saying. You're saying multiplication and
> > division in IEEE 754 is perfectly safe --- so long as the numbers you
> > start with are accurately representable in IEEE 754
On 2021-09-05 03:38:55 +1200, Greg Ewing wrote:
> If 7.23 were exactly representable, you would have got
> 723/1000.
>
> Contrast this with something that *is* exactly representable:
>
> >>> 7.875.as_integer_ratio()
> (63, 8)
>
> and observe that 7875/1000 == 63/8:
>
> >>> from fractions import
On 2021-09-04 09:48:40 -0300, Hope Rouselle wrote:
> Christian Gollwitzer writes:
> > Am 02.09.21 um 15:51 schrieb Hope Rouselle:
> > ls = [7.23, 8.41, 6.15, 2.31, 7.73, 7.77]
> > sum(ls)
> >> 39.594
> >>
> > ls = [8.41, 6.15, 2.31, 7.73, 7.77, 7.23]
> > sum(ls)
> >> 3
On Sun, Sep 5, 2021 at 12:58 PM Greg Ewing wrote:
>
> On 5/09/21 2:42 am, Hope Rouselle wrote:
> > Here's what I did on this case. The REPL is telling me that
> >
> >7.23 = 2035064081618043/281474976710656
>
> If 7.23 were exactly representable, you would have got
> 723/1000.
>
> Contrast thi
On Sun, Sep 5, 2021 at 12:55 PM Hope Rouselle wrote:
>
> Julio Di Egidio writes:
>
> > On Thursday, 2 September 2021 at 16:51:24 UTC+2, Christian Gollwitzer wrote:
> >> Am 02.09.21 um 16:49 schrieb Julio Di Egidio:
> >> > On Thursday, 2 September 2021 at 16:41:38 UTC+2, Peter Pearson wrote:
> >>
On Sun, Sep 5, 2021 at 12:44 PM Hope Rouselle wrote:
>
> Chris Angelico writes:
>
> > On Fri, Sep 3, 2021 at 4:29 AM Hope Rouselle wrote:
> >>
> >> Just sharing a case of floating-point numbers. Nothing needed to be
> >> solved or to be figured out. Just bringing up conversation.
> >>
> >> (*)
On Sun, Sep 5, 2021 at 1:04 PM Hope Rouselle wrote:
> The same question in other words --- what's a trivial way for the REPL
> to show me such cycles occur?
>
> >> 7.23.as_integer_ratio()
> >>> (2035064081618043, 281474976710656)
>
> Here's what I did on this case. The REPL is telling me that
On Sun, Sep 5, 2021 at 12:50 PM Hope Rouselle wrote:
>
> Christian Gollwitzer writes:
>
> > Am 02.09.21 um 15:51 schrieb Hope Rouselle:
> >> Just sharing a case of floating-point numbers. Nothing needed to be
> >> solved or to be figured out. Just bringing up conversation.
> >> (*) An introduct
On Sun, Sep 5, 2021 at 12:48 PM Hope Rouselle wrote:
>
> Chris Angelico writes:
>
> > On Fri, Sep 3, 2021 at 4:58 AM Hope Rouselle wrote:
> >>
> >> Hope Rouselle writes:
> >>
> >> > Just sharing a case of floating-point numbers. Nothing needed to be
> >> > solved or to be figured out. Just br
Am 04.09.21 um 14:48 schrieb Hope Rouselle:
Christian Gollwitzer writes:
Am 02.09.21 um 15:51 schrieb Hope Rouselle:
Just sharing a case of floating-point numbers. Nothing needed to be
solved or to be figured out. Just bringing up conversation.
(*) An introduction to me
I don't understand f
Christian Gollwitzer writes:
> Am 04.09.21 um 14:48 schrieb Hope Rouselle:
>> Christian Gollwitzer writes:
>>
>>> Am 02.09.21 um 15:51 schrieb Hope Rouselle:
Just sharing a case of floating-point numbers. Nothing needed to be
solved or to be figured out. Just bringing up conversatio
Julio Di Egidio writes:
[...]
>> I, too, lost my patience there. :-)
>
> As if I didn't know who's trolling...
I never trolled you. When we had our conversations in sci.logic, I was
Boris Dorestand --- you would remember if you have very good memory. We
talked for just a few days, I guess. T
Hope Rouselle writes:
> Greg Ewing writes:
>
>> On 5/09/21 2:42 am, Hope Rouselle wrote:
>>> Here's what I did on this case. The REPL is telling me that
>>>7.23 = 2035064081618043/281474976710656
>>
>> If 7.23 were exactly representable, you would have got
>> 723/1000.
>>
>> Contrast this w
Richard Damon writes:
> On 9/4/21 9:40 AM, Hope Rouselle wrote:
>> Chris Angelico writes:
>>
>>> On Fri, Sep 3, 2021 at 4:58 AM Hope Rouselle wrote:
Hope Rouselle writes:
> Just sharing a case of floating-point numbers. Nothing needed to be
> solved or to be figured ou
Greg Ewing writes:
> On 5/09/21 2:42 am, Hope Rouselle wrote:
>> Here's what I did on this case. The REPL is telling me that
>>7.23 = 2035064081618043/281474976710656
>
> If 7.23 were exactly representable, you would have got
> 723/1000.
>
> Contrast this with something that *is* exactly rep
Julio Di Egidio writes:
> On Thursday, 2 September 2021 at 15:52:02 UTC+2, Hope Rouselle wrote:
>
>> I don't understand floating-point numbers from the inside out, but I do
>> know how to work with base 2 and scientific notation. So the idea of
>> expressing a number as
>>
>> mantissa * base^
On 5/09/21 2:42 am, Hope Rouselle wrote:
Here's what I did on this case. The REPL is telling me that
7.23 = 2035064081618043/281474976710656
If 7.23 were exactly representable, you would have got
723/1000.
Contrast this with something that *is* exactly representable:
>>> 7.875.as_integer
Julio Di Egidio writes:
> On Thursday, 2 September 2021 at 16:51:24 UTC+2, Christian Gollwitzer wrote:
>> Am 02.09.21 um 16:49 schrieb Julio Di Egidio:
>> > On Thursday, 2 September 2021 at 16:41:38 UTC+2, Peter Pearson wrote:
>> >> On Thu, 02 Sep 2021 10:51:03 -0300, Hope Rouselle wrote:
>> >
On 9/4/21 9:40 AM, Hope Rouselle wrote:
> Chris Angelico writes:
>
>> On Fri, Sep 3, 2021 at 4:58 AM Hope Rouselle wrote:
>>>
>>> Hope Rouselle writes:
>>>
Just sharing a case of floating-point numbers. Nothing needed to be
solved or to be figured out. Just bringing up conversation.
Christian Gollwitzer writes:
> Am 02.09.21 um 15:51 schrieb Hope Rouselle:
>> Just sharing a case of floating-point numbers. Nothing needed to be
>> solved or to be figured out. Just bringing up conversation.
>> (*) An introduction to me
>> I don't understand floating-point numbers from the ins
Chris Angelico writes:
> On Fri, Sep 3, 2021 at 4:58 AM Hope Rouselle wrote:
>>
>> Hope Rouselle writes:
>>
>> > Just sharing a case of floating-point numbers. Nothing needed to be
>> > solved or to be figured out. Just bringing up conversation.
>> >
>> > (*) An introduction to me
>> >
>> > I
Chris Angelico writes:
> On Fri, Sep 3, 2021 at 4:29 AM Hope Rouselle wrote:
>>
>> Just sharing a case of floating-point numbers. Nothing needed to be
>> solved or to be figured out. Just bringing up conversation.
>>
>> (*) An introduction to me
>>
>> I don't understand floating-point numbers
On 3/09/21 8:11 pm, Christian Gollwitzer wrote:
Unless you have special numbers like NaN or signed zeros etc., a+b=b+a
and a*b=b*a holds also for floats.
The only exception I'm aware of is for NaNs, and it's kind of pendantic:
you can't say that x + NaN == NaN + x, but only because NaNs never
c
Il 03/09/2021 14:45, Chris Angelico ha scritto:
I believe the definition of "accurate" here is that, if you take all
of the real numbers represented by those floats, add them all together
with mathematical accuracy, and then take the nearest representable
float, that will be the exact value that
On Thu, 2 Sep 2021 07:54:27 -0700 (PDT), Julio Di Egidio wrote:
> On Thursday, 2 September 2021 at 16:51:24 UTC+2, Christian Gollwitzer wrote:
>> Am 02.09.21 um 16:49 schrieb Julio Di Egidio:
>> > On Thursday, 2 September 2021 at 16:41:38 UTC+2, Peter Pearson wrote:
>> >> On Thu, 02 Sep 2021 10:51
2, 2021 9:51 AM
To: python-list@python.org
Subject: on floating-point numbers
Just sharing a case of floating-point numbers. Nothing needed to be solved or
to be figured out. Just bringing up conversation.
(*) An introduction to me
I don't understand floating-point numbers from the inside out
Data
-Original Message-
From: Hope Rouselle
Sent: Thursday, September 2, 2021 9:51 AM
To: python-list@python.org
Subject: on floating-point numbers
Just sharing a case of floating-point numbers. Nothing needed to be solved or
to be figured out. Just bringing up conversation.
(*) An i
On 2021-09-03 16:13, Chris Angelico wrote:
On Sat, Sep 4, 2021 at 12:08 AM o1bigtenor wrote:
Hmmm - - - ZI would suggest that you haven't looked into
taxation yet!
In taxation you get a rational number that MUST be multiplied by
the amount in currency.
(You can, of course, multiply a curr
On Sat, Sep 4, 2021 at 12:08 AM o1bigtenor wrote:
> Hmmm - - - ZI would suggest that you haven't looked into
> taxation yet!
> In taxation you get a rational number that MUST be multiplied by
> the amount in currency.
(You can, of course, multiply a currency amount by any scalar. Just
not by
On Thu, Sep 2, 2021 at 2:27 PM Chris Angelico wrote:
> On Fri, Sep 3, 2021 at 4:58 AM Hope Rouselle wrote:
> >
> > Hope Rouselle writes:
> >
> > > Just sharing a case of floating-point numbers. Nothing needed to be
> > > solved or to be figured out. Just bringing up conversation.
> > >
> > >
On Fri, 3 Sept 2021 at 13:48, Chris Angelico wrote:
>
> On Fri, Sep 3, 2021 at 10:42 PM jak wrote:
> >
> > Il 03/09/2021 09:07, Julio Di Egidio ha scritto:
> > > On Friday, 3 September 2021 at 01:22:28 UTC+2, Chris Angelico wrote:
> > >> On Fri, Sep 3, 2021 at 8:15 AM Dennis Lee Bieber
> > >> w
On Fri, Sep 3, 2021 at 10:42 PM jak wrote:
>
> Il 03/09/2021 09:07, Julio Di Egidio ha scritto:
> > On Friday, 3 September 2021 at 01:22:28 UTC+2, Chris Angelico wrote:
> >> On Fri, Sep 3, 2021 at 8:15 AM Dennis Lee Bieber
> >> wrote:
> >>> On Fri, 3 Sep 2021 04:43:02 +1000, Chris Angelico
> >>
Il 03/09/2021 09:07, Julio Di Egidio ha scritto:
On Friday, 3 September 2021 at 01:22:28 UTC+2, Chris Angelico wrote:
On Fri, Sep 3, 2021 at 8:15 AM Dennis Lee Bieber wrote:
On Fri, 3 Sep 2021 04:43:02 +1000, Chris Angelico
declaimed the following:
The naive summation algorithm used by sum(
Am 02.09.21 um 21:02 schrieb Julio Di Egidio:
On Thursday, 2 September 2021 at 20:43:36 UTC+2, Chris Angelico wrote:
On Fri, Sep 3, 2021 at 4:29 AM Hope Rouselle wrote:
All I did was to take the first number, 7.23, and move it to the last
position in the list. (So we have a violation of the
Op 2/09/2021 om 17:08 schreef Hope Rouselle:
ls = [7.23, 8.41, 6.15, 2.31, 7.73, 7.77]
sum(ls)
> 39.594
>
ls = [8.41, 6.15, 2.31, 7.73, 7.77, 7.23]
sum(ls)
> 39.61
>
> All I did was to take the first number, 7.23, and move it to the last
> position in t
On Fri, Sep 3, 2021 at 8:15 AM Dennis Lee Bieber wrote:
>
> On Fri, 3 Sep 2021 04:43:02 +1000, Chris Angelico
> declaimed the following:
>
> >
> >The naive summation algorithm used by sum() is compatible with a
> >variety of different data types - even lists, although it's documented
> >as being
On Fri, 3 Sep 2021 04:43:02 +1000, Chris Angelico
declaimed the following:
>
>The naive summation algorithm used by sum() is compatible with a
>variety of different data types - even lists, although it's documented
>as being intended for numbers - but if you know for sure that you're
>working wit
On Thu, 02 Sep 2021 12:08:21 -0300, Hope Rouselle
declaimed the following:
>Suppose these numbers are prices in dollar, never going beyond cents.
>Would it be safe to multiply each one of them by 100 and therefore work
>with cents only? For instance
>
A lot of software with a "monetary
On Thu, 02 Sep 2021 10:51:03 -0300, Hope Rouselle
declaimed the following:
ls = [7.23, 8.41, 6.15, 2.31, 7.73, 7.77]
sum(ls)
>39.594
>
ls = [8.41, 6.15, 2.31, 7.73, 7.77, 7.23]
sum(ls)
>39.61
>
>All I did was to take the first number, 7.23, and move it
On 2021-09-02, Hope Rouselle wrote:
> Suppose these numbers are prices in dollar, never going beyond cents.
> Would it be safe to multiply each one of them by 100 and therefore work
> with cents only?
The _practical_ answer is that no, it's not safe to use floating point
when doing normal bookee
On Fri, Sep 3, 2021 at 4:58 AM Hope Rouselle wrote:
>
> Hope Rouselle writes:
>
> > Just sharing a case of floating-point numbers. Nothing needed to be
> > solved or to be figured out. Just bringing up conversation.
> >
> > (*) An introduction to me
> >
> > I don't understand floating-point num
On Fri, Sep 3, 2021 at 4:29 AM Hope Rouselle wrote:
>
> Just sharing a case of floating-point numbers. Nothing needed to be
> solved or to be figured out. Just bringing up conversation.
>
> (*) An introduction to me
>
> I don't understand floating-point numbers from the inside out, but I do
> kn
Hope Rouselle writes:
> Just sharing a case of floating-point numbers. Nothing needed to be
> solved or to be figured out. Just bringing up conversation.
>
> (*) An introduction to me
>
> I don't understand floating-point numbers from the inside out, but I do
> know how to work with base 2 and
Am 02.09.21 um 15:51 schrieb Hope Rouselle:
Just sharing a case of floating-point numbers. Nothing needed to be
solved or to be figured out. Just bringing up conversation.
(*) An introduction to me
I don't understand floating-point numbers from the inside out, but I do
know how to work with b
Am 02.09.21 um 16:49 schrieb Julio Di Egidio:
On Thursday, 2 September 2021 at 16:41:38 UTC+2, Peter Pearson wrote:
On Thu, 02 Sep 2021 10:51:03 -0300, Hope Rouselle wrote:
39.61
Welcome to the exciting world of roundoff error:
Welcome to the exiting world of Usenet.
*Plonk*
On Thu, 02 Sep 2021 10:51:03 -0300, Hope Rouselle wrote:
>
import sys
sys.version
> '3.8.10 (tags/...
>
ls = [7.23, 8.41, 6.15, 2.31, 7.73, 7.77]
sum(ls)
> 39.594
>
ls = [8.41, 6.15, 2.31, 7.73, 7.77, 7.23]
sum(ls)
> 39.61
Welcome to the excit
Just sharing a case of floating-point numbers. Nothing needed to be
solved or to be figured out. Just bringing up conversation.
(*) An introduction to me
I don't understand floating-point numbers from the inside out, but I do
know how to work with base 2 and scientific notation. So the idea of
59 matches
Mail list logo
