Default Value
I'm reading the Python.org tutorial right now, and I found this part rather strange and incomprehensible to me> Important warning: The default value is evaluated only once. This makes a difference when the default is a mutable object such as a list, dictionary, or instances of most classes def f(a, L=[]): L.append(a) return L print(f(1)) print(f(2)) print(f(3)) This will print [1] [1, 2] [1, 2, 3] How the list is retained between successive calls? And why? -- http://mail.python.org/mailman/listinfo/python-list
Re: Short-circuit Logic
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, and exact. The problem > > is not the *equality test*, but that you don't always have the number > > that you think you have. The problem lies elsewhere, not equality! > > > Steven Well, this is taken from my python shell> >>> 0.33455857352426283 == 0.33455857352426282 True Anyway, man, those were not my words anyway, most programming books I've read state so. Here's an excerpt from the Python book, I'm currently reading> ">>> 0.0, 5.4, -2.5, 8.9e-4 (0.0, 5.4004, -2.5, 0.00088995) The inexactness is not a problem specific to Python—all programming languages have this problem with floating-point numbers." -- http://mail.python.org/mailman/listinfo/python-list
Re: Short-circuit Logic
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 be distinguished from 1.0, which is not the same thing. It is > > >> also quite arbitrary. Why 1.0? Why not (0.0001+x)? Or (0.0001+x)? > > >> Or (1.0+x)? > > > > > > That may be true for integers, > > > > What may be true for integers? > > > > > but for floats, testing for equality is not always precise > > > > And your point is? > > > > What Steven wrote is entirely correct: sys.float_info.epsilon is the > > smallest value x such that 1.0 and 1.0+x have distinct floating-point > > representations. It has no relevance for comparing to zero. 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Short-circuit Logic
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 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:
>
> > print("zero is not allowed")
>
>
>
> Follow the logic.
>
>
>
> If allow_zero is a true value, then "not allow_zero" is False, and the
>
> "and" clause cannot evaluate to true. (False and X is always False.) So
>
> print is not called.
>
>
>
> If allow_zero is a false value, then "not allow_zero" is True, and the
>
> "and" clause depends on the second argument. (True and X is always X.) So
>
> abs(x) < sys.float_info.epsilon is tested, and if that is True, print is
>
> called.
>
>
>
> By the way, I don't think much of this logic. Values smaller than epsilon
>
> are not necessarily zero:
>
>
>
> py> import sys
>
> py> epsilon = sys.float_info.epsilon
>
> py> x = epsilon/1
>
> py> x == 0
>
> False
>
> py> x * 3 == 0
>
> False
>
> py> x + epsilon == 0
>
> False
>
> py> x + epsilon == epsilon
>
> False
>
>
>
> The above logic throws away many perfectly good numbers and treats them
>
> as zero even though they aren't.
>
>
>
>
>
> > The purpose of this snippet is to print the given line when allow_zero
>
> > is False and x is 0.
>
>
>
> Then the snippet utterly fails at that, since it prints the line for many
>
> values of x which can be distinguished from zero. The way to test whether
>
> x equals zero is:
>
>
>
> x == 0
>
>
>
> 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 arbitrary. Why 1.0? Why not (0.0001+x)? Or (0.0001+x)? Or
>
> (1.0+x)?
>
>
>
>
>
>
>
> --
>
> Steven
That may be true for integers, but for floats, testing for equality is not
always precise
--
http://mail.python.org/mailman/listinfo/python-list
Re: Short-circuit Logic
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 this way!>
>
>
>
> if not allow_zero and abs(x) < sys.float_info.epsilon:
>
> print("zero is not allowed")
>
>
>
> The purpose of this snippet is to print the given line when allow_zero is
> False and x is 0.
Thank you guys! you gave me valuable insights! But regarding my original post,
I don't know why for the past two days I was looking at the code *only* this
way>
if ( not allow_zero and abs(x) ) < sys.float_info.epsilon:
I feel so stupid now :-/, may be it's the new syntax confusing me :)! Thanks
again guys.
--
http://mail.python.org/mailman/listinfo/python-list
Short-circuit Logic
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:
print("zero is not allowed")
The purpose of this snippet is to print the given line when allow_zero is False
and x is 0.
--
http://mail.python.org/mailman/listinfo/python-list
