> From: oscar.j.benja...@gmail.com
> Date: Thu, 30 May 2013 23:57:28 +0100
> Subject: Re: Short-circuit Logic
> To: carlosnepomuc...@outlook.com
> CC: python-list@python.org
>
> On 30 May 2013 22:03, Carlos Nepomuceno wrote:
&
On 30 May 2013 22:03, Carlos Nepomuceno wrote:
>> Here's another way, mathematically equivalent (although not necessarily
>> equivalent using floating point computations!) which avoids the divide-by-
>> zero problem:
>>
>> abs(a - b) < epsilon*a
>
> That's wrong! If abs(a) < abs(a-b)/epsilon you w
> From: steve+comp.lang.pyt...@pearwood.info
> Subject: Re: Short-circuit Logic
> Date: Fri, 31 May 2013 08:45:13 +
> To: python-list@python.org
>
> On Fri, 31 May 2013 17:09:01 +1000, Chris Angelico wrote:
>
>> On Fri, May
On 2013-05-30 08:29:41 +, Steven D'Aprano said:
On Thu, 30 May 2013 10:22:02 +0300, Jussi Piitulainen wrote:
I wonder why floating-point errors are not routinely discussed in terms
of ulps (units in last position). ...
That is an excellent question! ...
I have a module that works with ULPs.
In article <51a86319$0$29966$c3e8da3$54964...@news.astraweb.com>,
Steven D'Aprano wrote:
> In an early talk Ken was explaining the advantages of tolerant
> comparison. A member of the audience asked incredulously,
> âSurely you donât mean that when A=B and B=C, A may not equal C
On Fri, 31 May 2013 17:09:01 +1000, Chris Angelico wrote:
> On Fri, May 31, 2013 at 3:13 PM, Steven D'Aprano
> wrote:
>> What makes you think that the commutative law is relevant here?
>>
>>
> Equality should be commutative. If a == b, then b == a. Also, it's
> generally understood that if a == c
On Fri, 31 May 2013 09:42:38 +0300, Carlos Nepomuceno wrote:
>> From: steve+comp.lang.pyt...@pearwood.info Subject: Re: Short-circuit
>> Logic
>> Date: Fri, 31 May 2013 05:13:51 + To: python-list@python.org
>>
>> On Fri, 31 May 2013 00:03:13 +0300, Carlos Nepo
On Fri, May 31, 2013 at 3:13 PM, Steven D'Aprano
wrote:
> What makes you think that the commutative law is relevant here?
>
Equality should be commutative. If a == b, then b == a. Also, it's
generally understood that if a == c and b == c, then a == b, though
there are more exceptions to that (esp
> From: steve+comp.lang.pyt...@pearwood.info
> Subject: Re: Short-circuit Logic
> Date: Fri, 31 May 2013 05:13:51 +
> To: python-list@python.org
>
> On Fri, 31 May 2013 00:03:13 +0300, Carlo
On Fri, 31 May 2013 00:03:13 +0300, Carlos Nepomuceno wrote:
>
>> From: steve+comp.lang.pyt...@pearwood.info Subject: Re: Short-circuit
>> Logic
>> Date: Thu, 30 May 2013 05:42:17 + To: python-list@python.org
> [..
On 05/30/2013 07:10 PM, Nobody wrote:
> This is why technical drawings which include regularly-spaced features
> will normally specify the positions of features relative to their
> neighbours instead of (or as well as) relative to some origin.
If I am planting trees, putting in fence posts, or dri
Steven D'Aprano於 2013年5月30日星期四UTC+8上午10時28分57秒寫道：
> On Wed, 29 May 2013 10:50:47 -0600, Ian Kelly wrote:
>
>
>
> > On Wed, May 29, 2013 at 8:33 AM, rusi wrote:
>
> >> 0.0 == 0.0 implies 5.4 == 5.4
>
> >> is not a true statement is what (I think) Steven is saying. 0 (or if
>
> >> you prefer 0
On Fri, May 31, 2013 at 10:13 AM, Rick Johnson
wrote:
> What if you need to perform operations on a sequence (more than once) in a
> non-linear fashion? What if you need to modify the sequence whilst looping?
> In many cases your simplistic "for loop" will fail miserably.
What has this to do w
In article ,
Nobody wrote:
> On Thu, 30 May 2013 19:38:31 -0400, Dennis Lee Bieber wrote:
>
> > Measuring 1 foot from the 1000 foot stake leaves you with any error
> > from datum to the 1000 foot, plus any error from the 1000 foot, PLUS any
> > azimuth error which would contribute to shorte
On Thu, 30 May 2013 19:38:31 -0400, Dennis Lee Bieber wrote:
> Measuring 1 foot from the 1000 foot stake leaves you with any error
> from datum to the 1000 foot, plus any error from the 1000 foot, PLUS any
> azimuth error which would contribute to shortening the datum distance.
First, let's
> On Fri, May 31, 2013 at 2:58 AM, rusi wrote:
> > On May 30, 5:58 pm, Chris Angelico wrote:
> > > The alternative would be an infinite number of iterations, which is far
> > > far worse.
> >
> > There was one heavyweight among programming teachers -- E.W. Dijkstra
> > -- who had some rather extre
> To: python-list@python.org
> From: wlfr...@ix.netcom.com
> Subject: Re: Short-circuit Logic
> Date: Thu, 30 May 2013 19:38:31 -0400
>
> On Thu, 30 May 2013 08:48:59 -0400, Roy Smith declaimed
> the following in gmane.comp.python.gene
On Thu, 30 May 2013 12:07:40 +0300, Jussi Piitulainen wrote:
> I suppose this depends on the complexity of the process and the amount
> of data that produced the numbers of interest. Many individual
> floating point operations are required to be within an ulp or two of
> the mathematically correct
On Fri, May 31, 2013 at 5:22 AM, Steven D'Aprano
wrote:
> On Thu, 30 May 2013 16:40:52 +, Steven D'Aprano wrote:
>
>> On Fri, 31 May 2013 01:56:09 +1000, Chris Angelico wrote:
>
>>> You're assuming you can casually hit Ctrl-C to stop an infinite loop,
>>> meaning that it's trivial. It's not. N
> From: steve+comp.lang.pyt...@pearwood.info
> Subject: Re: Short-circuit Logic
> Date: Thu, 30 May 2013 05:42:17 +
> To: python-list@python.org
[...]
> Here's another way, mathematically equivalent (although not necessarily
> eq
On Thu, May 30, 2013 at 1:30 PM, Neil Cerutti wrote:
> On 2013-05-30, Chris Angelico wrote:
>> On Thu, May 30, 2013 at 3:10 PM, Steven D'Aprano
>> wrote:
>>> # Wrong, don't do this!
>>> x = 0.1
>>> while x != 17.3:
>>> print(x)
>>> x += 0.1
>>
>> Actually, I wouldn't do that with integers
On 2013-05-30, Chris Angelico wrote:
> On Thu, May 30, 2013 at 3:10 PM, Steven D'Aprano
> wrote:
>> # Wrong, don't do this!
>> x = 0.1
>> while x != 17.3:
>> print(x)
>> x += 0.1
>
> Actually, I wouldn't do that with integers either.
I propose borrowing the concept of significant digits f
On Thu, 30 May 2013 16:40:52 +, Steven D'Aprano wrote:
> On Fri, 31 May 2013 01:56:09 +1000, Chris Angelico wrote:
>> You're assuming you can casually hit Ctrl-C to stop an infinite loop,
>> meaning that it's trivial. It's not. Not everything lets you do that;
>> or possibly halting the proce
On Fri, May 31, 2013 at 2:58 AM, rusi wrote:
> On May 30, 5:58 pm, Chris Angelico wrote:
>> The alternative would be an infinite number of iterations, which is far far
>> worse.
>
> There was one heavyweight among programming teachers -- E.W. Dijkstra
> -- who had some rather extreme views on th
On 05/30/2013 08:56 AM, Chris Angelico wrote:
On Fri, May 31, 2013 at 1:02 AM, Ethan Furman wrote:
On 05/30/2013 05:58 AM, Chris Angelico wrote:
If you iterate from 1000 to 173, you get nowhere. This is the expected
behaviour; this is what a C-style for loop would be written as, it's
what rang
On May 30, 5:58 pm, Chris Angelico wrote:
> The alternative would be an infinite number of iterations, which is far far
> worse.
There was one heavyweight among programming teachers -- E.W. Dijkstra
-- who had some rather extreme views on this.
He taught that when writing a loop of the form
i
On Fri, 31 May 2013 01:56:09 +1000, Chris Angelico wrote:
> On Fri, May 31, 2013 at 1:02 AM, Ethan Furman
> wrote:
>> On 05/30/2013 05:58 AM, Chris Angelico wrote:
>>> If you iterate from 1000 to 173, you get nowhere. This is the expected
>>> behaviour; this is what a C-style for loop would be wr
On Fri, May 31, 2013 at 1:02 AM, Ethan Furman wrote:
> On 05/30/2013 05:58 AM, Chris Angelico wrote:
>> If you iterate from 1000 to 173, you get nowhere. This is the expected
>> behaviour; this is what a C-style for loop would be written as, it's
>> what range() does, it's the normal thing. Going
On 05/30/2013 05:58 AM, Chris Angelico wrote:
On Thu, May 30, 2013 at 10:40 PM, Roy Smith wrote:
if somebody were to accidentally drop three zeros into the source code:
x = 1000
while x < 173:
print(x)
x += 1
should the loop just quietly not execute (which is what it will do
here)
On Thu, May 30, 2013 at 10:40 PM, Roy Smith wrote:
> if somebody were to accidentally drop three zeros into the source code:
>
>> x = 1000
>> while x < 173:
>> print(x)
>> x += 1
>
> should the loop just quietly not execute (which is what it will do
> here)? Will that make your program co
In article ,
Jussi Piitulainen wrote:
> I wonder why floating-point errors are not routinely discussed in
> terms of ulps (units in last position).
Analysis of error is a complicated topic (and is much older than digital
computers). These sorts of things come up in the real world, too. For
In article ,
Chris Angelico wrote:
> On Thu, May 30, 2013 at 3:10 PM, Steven D'Aprano
> wrote:
> > # Wrong, don't do this!
> > x = 0.1
> > while x != 17.3:
> > print(x)
> > x += 0.1
> >
>
> Actually, I wouldn't do that with integers either. There are too many
> ways that a subsequent e
Steven D'Aprano writes:
> On Thu, 30 May 2013 10:22:02 +0300, Jussi Piitulainen wrote:
>
> > I wonder why floating-point errors are not routinely discussed in
> > terms of ulps (units in last position). There is a recipe for
> > calculating the difference of two floating point numbers in ulps,
>
On Thu, 30 May 2013 10:22:02 +0300, Jussi Piitulainen wrote:
> I wonder why floating-point errors are not routinely discussed in terms
> of ulps (units in last position). There is a recipe for calculating the
> difference of two floating point numbers in ulps, and it's possible to
> find the previ
On Thu, May 30, 2013 at 3:42 PM, Steven D'Aprano
wrote:
> On Thu, 30 May 2013 13:45:13 +1000, Chris Angelico wrote:
>
>> Let's suppose someone is told to compare floating point numbers by
>> seeing if the absolute value of the difference is less than some
>> epsilon.
>
> Which is usually the wrong
Steven D'Aprano writes:
> On Thu, 30 May 2013 13:45:13 +1000, Chris Angelico wrote:
>
> > Let's suppose someone is told to compare floating point numbers by
> > seeing if the absolute value of the difference is less than some
> > epsilon.
>
> Which is usually the wrong way to do it! Normally one
On Thu, 30 May 2013 13:45:13 +1000, Chris Angelico wrote:
> Let's suppose someone is told to compare floating point numbers by
> seeing if the absolute value of the difference is less than some
> epsilon.
Which is usually the wrong way to do it! Normally one would prefer
*relative* error, not a
On Wed, 29 May 2013 20:23:00 -0400, Dave Angel wrote:
> Even in a pure decimal system of (say)
> 40 digits, I could type in a 42 digit number and it would get quantized.
> So just because two 42 digit numbers are different doesn't imply that
> the 40 digit internal format would be.
Correct, and
On Thu, May 30, 2013 at 3:10 PM, Steven D'Aprano
wrote:
> # Wrong, don't do this!
> x = 0.1
> while x != 17.3:
> print(x)
> x += 0.1
>
Actually, I wouldn't do that with integers either. There are too many
ways that a subsequent edit could get it wrong and go infinite, so I'd
*always* use
On Wed, 29 May 2013 07:27:40 -0700, Ahmed Abdulshafy wrote:
> On Tuesday, May 28, 2013 3:48:17 PM UTC+2, Steven D'Aprano wrote:
>> On Mon, 27 May 2013 13:11:28 -0700, Ahmed Abdulshafy wrote:
>>
>>
>>
>> > That may be true for integers, but for floats, testing for equality
>> > is
>>
>> > not a
On Thu, May 30, 2013 at 12:28 PM, Steven D'Aprano
wrote:
> * de facto exact equality testing, only slower and with the *illusion* of
> avoiding equality, e.g. "abs(x-y) < sys.float_info.epsilon" is just a
> long and slow way of saying "x == y" when both numbers are sufficiently
> large;
>
The pro
On Wed, 29 May 2013 10:50:47 -0600, Ian Kelly wrote:
> On Wed, May 29, 2013 at 8:33 AM, rusi wrote:
>> 0.0 == 0.0 implies 5.4 == 5.4
>> is not a true statement is what (I think) Steven is saying. 0 (or if
>> you prefer 0.0) is special and is treated specially.
>
> It has nothing to do with 0 bei
On 05/29/2013 12:50 PM, Ian Kelly wrote:
On Wed, May 29, 2013 at 8:33 AM, rusi wrote:
0.0 == 0.0 implies 5.4 == 5.4
is not a true statement is what (I think) Steven is saying.
0 (or if you prefer 0.0) is special and is treated specially.
It has nothing to do with 0 being special. A floating
On Wed, May 29, 2013 at 8:33 AM, rusi wrote:
> 0.0 == 0.0 implies 5.4 == 5.4
> is not a true statement is what (I think) Steven is saying.
> 0 (or if you prefer 0.0) is special and is treated specially.
It has nothing to do with 0 being special. A floating point number
will always equal itself (
On May 29, 7:27 pm, Ahmed Abdulshafy wrote:
> On Tuesday, May 28, 2013 3:48:17 PM UTC+2, Steven D'Aprano wrote:
> > On Mon, 27 May 2013 13:11:28 -0700, Ahmed Abdulshafy wrote:
>
> > > That may be true for integers, but for floats, testing for equality is
>
> > > not always precise
>
> > Incorrect.
On Thu, May 30, 2013 at 12:27 AM, Ahmed Abdulshafy wrote:
> Well, this is taken from my python shell>
>
0.33455857352426283 == 0.33455857352426282
> True
>>> 0.33455857352426283,0.33455857352426282
(0.3345585735242628, 0.3345585735242628)
They're not representably different.
ChrisA
--
ht
On Tuesday, May 28, 2013 3:48:17 PM UTC+2, Steven D'Aprano wrote:
> On Mon, 27 May 2013 13:11:28 -0700, Ahmed Abdulshafy wrote:
>
>
>
> > That may be true for integers, but for floats, testing for equality is
>
> > not always precise
>
>
>
> Incorrect. Testing for equality is always precise,
On Tue, 28 May 2013 15:14:03 +, Grant Edwards wrote:
> On 2013-05-28, Steven D'Aprano
> wrote:
>> On Tue, 28 May 2013 01:39:09 -0700, Ahmed Abdulshafy wrote:
>>
>>> He just said that the way to test for zero equality is x == 0, and I
>>> meant that this is true for integers but not necessaril
On 2013-05-28, Steven D'Aprano wrote:
> On Tue, 28 May 2013 01:39:09 -0700, Ahmed Abdulshafy wrote:
>
>> He just said that the way to test for zero equality is x == 0, and I
>> meant that this is true for integers but not necessarily for floats. And
>> that's not specific to Python.
>
> Can you sh
On Tue, May 28, 2013 at 11:48 PM, Steven D'Aprano
wrote:
> py> y = 1e17 + x # x is not zero, so y should be > 1e17
> py> 1/(1e17 - y)
> Traceback (most recent call last):
> File "", line 1, in
> ZeroDivisionError: float division by zero
You don't even need to go for 1e17. By definition:
>>>
On Tue, 28 May 2013 01:39:09 -0700, Ahmed Abdulshafy wrote:
> He just said that the way to test for zero equality is x == 0, and I
> meant that this is true for integers but not necessarily for floats. And
> that's not specific to Python.
Can you show me a value of x where x == 0.0 returns False,
On Mon, 27 May 2013 13:11:28 -0700, Ahmed Abdulshafy wrote:
> That may be true for integers, but for floats, testing for equality is
> not always precise
Incorrect. Testing for equality is always precise, and exact. The problem
is not the *equality test*, but that you don't always have the numbe
On 28/05/2013 09:39, Ahmed Abdulshafy wrote:
And that's not specific to Python.
Using google products is also not specific to Python. However whereever
it's used it's a PITA as people are forced into reading double spaced
crap. Please check out the link in my signature.
--
If you're usi
> Date: Tue, 28 May 2013 01:39:09 -0700
> Subject: Re: Short-circuit Logic
> From: abdulsh...@gmail.com
[...]
>> What Steven wrote is entirely correct: sys.float_info.epsilon is the
>>
>> smallest value x such that 1.0 and 1.0+x h
On Tuesday, May 28, 2013 2:10:05 AM UTC+2, Nobody wrote:
> On Mon, 27 May 2013 13:11:28 -0700, Ahmed Abdulshafy wrote:
>
>
>
> > On Sunday, May 26, 2013 2:13:47 PM UTC+2, Steven D'Aprano wrote:
>
> >
>
> >> What the above actually tests for is whether x is so small that (1.0+x)
>
> >> cannot
On Mon, 27 May 2013 13:11:28 -0700, Ahmed Abdulshafy wrote:
> On Sunday, May 26, 2013 2:13:47 PM UTC+2, Steven D'Aprano wrote:
>
>> What the above actually tests for is whether x is so small that (1.0+x)
>> cannot be distinguished from 1.0, which is not the same thing. It is
>> also quite arbitrar
On Sun, 26 May 2013 04:11:56 -0700, Ahmed Abdulshafy wrote:
> I'm having a hard time wrapping my head around short-circuit logic that's
> used by Python, coming from a C/C++ background; so I don't understand why
> the following condition is written this way!>
>
>
On Sunday, May 26, 2013 2:13:47 PM UTC+2, Steven D'Aprano wrote:
> On Sun, 26 May 2013 04:11:56 -0700, Ahmed Abdulshafy wrote:
>
>
>
> > Hi,
>
> > I'm having a hard time wrapping my head around short-circuit logic
>
> > that's used by
On Sunday, May 26, 2013 1:11:56 PM UTC+2, Ahmed Abdulshafy wrote:
> Hi,
>
> I'm having a hard time wrapping my head around short-circuit logic that's
> used by Python, coming from a C/C++ background; so I don't understand why the
> following condition is written
On 27May2013 06:59, Vito De Tullio wrote:
| Cameron Simpson wrote:
| > if s is not None and len(s) > 0:
| > ... do something with the non-empty string `s` ...
| >
| > In this example, None is a sentinel value for "no valid string" and
| > calling "len(s)" would raise an exception because No
Cameron Simpson wrote:
> if s is not None and len(s) > 0:
> ... do something with the non-empty string `s` ...
>
> In this example, None is a sentinel value for "no valid string" and
> calling "len(s)" would raise an exception because None doesn't have
> a length.
obviously in this case an
On May 27, 5:40 am, Steven D'Aprano wrote:
> On Sun, 26 May 2013 16:22:26 -0400, Roy Smith wrote:
> > In article ,
> > Terry Jan Reedy wrote:
>
> >> On 5/26/2013 7:11 AM, Ahmed Abdulshafy wrote:
>
> >> > if not allow_zero and abs(x) < sys.float_info.epsilon:
> >> > print("
On 27May2013 00:40, Steven D'Aprano
wrote:
| On Sun, 26 May 2013 16:22:26 -0400, Roy Smith wrote:
|
| > In article ,
| > Terry Jan Reedy wrote:
| >
| >> On 5/26/2013 7:11 AM, Ahmed Abdulshafy wrote:
| >>
| >> > if not allow_zero and abs(x) < sys.float_info.epsilon:
| >> >
On Sun, 26 May 2013 16:22:26 -0400, Roy Smith wrote:
> In article ,
> Terry Jan Reedy wrote:
>
>> On 5/26/2013 7:11 AM, Ahmed Abdulshafy wrote:
>>
>> > if not allow_zero and abs(x) < sys.float_info.epsilon:
>> > print("zero is not allowed")
>>
>> The reason for the orde
On 5/26/2013 4:22 PM, Roy Smith wrote:
In article ,
Terry Jan Reedy wrote:
On 5/26/2013 7:11 AM, Ahmed Abdulshafy wrote:
if not allow_zero and abs(x) < sys.float_info.epsilon:
print("zero is not allowed")
The reason for the order is to do the easy calculation fir
In article ,
Terry Jan Reedy wrote:
> On 5/26/2013 7:11 AM, Ahmed Abdulshafy wrote:
>
> > if not allow_zero and abs(x) < sys.float_info.epsilon:
> > print("zero is not allowed")
>
> The reason for the order is to do the easy calculation first and the
> harder one only i
On 5/26/2013 7:11 AM, Ahmed Abdulshafy wrote:
if not allow_zero and abs(x) < sys.float_info.epsilon:
print("zero is not allowed")
The reason for the order is to do the easy calculation first and the
harder one only if the first passes.
--
http://mail.python.org/mail
On Sun, 26 May 2013 04:11:56 -0700, Ahmed Abdulshafy wrote:
> Hi,
> I'm having a hard time wrapping my head around short-circuit logic
> that's used by Python, coming from a C/C++ background; so I don't
> understand why the following condition is written this way!
>
In article <5f101d70-e51f-4531-9153-c92ee2486...@googlegroups.com>,
Ahmed Abdulshafy wrote:
> Hi,
> I'm having a hard time wrapping my head around short-circuit logic that's
> used by Python, coming from a C/C++ background; so I don't understand why the
> fo
Hi,
I'm having a hard time wrapping my head around short-circuit logic that's used
by Python, coming from a C/C++ background; so I don't understand why the
following condition is written this way!>
if not allow_zero and abs(x) < sys.float_info.epsilon:
70 matches
Mail list logo
