Re: Generating equally-spaced floats with least rounding error

[Chris Angelico]

On Sun, Sep 25, 2011 at 3:31 PM, Steven D'Aprano
 wrote:
 2.1 == F(21, 10)
> False
>

Ahh, but that may just mean that Fraction doesn't implement an == that
compares with floats.

>>> 2.1==float(F(21,10))
True

This may be because one oughtn't to use == with floats anyway.

>>> F(2.1)==F(21,10)
False
>>> F(2.1)
Fraction(4728779608739021, 2251799813685248)

That denominator is a power of 2 (2**51 as it happens), which is
unsurprising for something created from an IEEE floating point value.
Rounding F(21,10) off to fit into float produces this same value.

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Generating equally-spaced floats with least rounding error

[Terry Reedy]

On 9/25/2011 1:21 AM, Steven D'Aprano wrote:

Terry Reedy wrote:


On 9/24/2011 9:53 AM, Steven D'Aprano wrote:

[...]

[0.0 + i*width for i in range(8)]

[0.0, 0.3, 0.6, 0.8999, 1.2, 1.5, 1.7998, 2.1]

The 4th and 7th values have rounding errors, the rest are exact


No they are not. Their errors are just smaller and not visible with 16
digits.


Pardon. I meant that they were as close to exact as is possible in binary
floats. With the exception of 0.8999... and 1.7999... I don't believe any
other float can be closer to the exact value.

I did mention that "If the exact value isn't representable as a float, I'm
okay with returning the nearest possible float." :)


I do hope you did not stop with my lead-in sentence, and read to the 
end, where I gave you most of the answer you were looking for, without 
using the fractions module.


--
Terry Jan Reedy

--
http://mail.python.org/mailman/listinfo/python-list

Re: Generating equally-spaced floats with least rounding error

[Chris Angelico]

On Sun, Sep 25, 2011 at 3:31 PM, Steven D'Aprano
 wrote:>> If you look again at
the code I used, I did. I just did it inside the list> comp.
You did, but you created a Fraction from a float; my version used
Fraction(21,10) instead of (effectively) Fraction(2.1). My description
was a little sloppy, but what I meant was to use Fraction for the
actual arguments to the "function" that this is implementing.
> Something looks a tad suspicious here... the two list comps are identical,
> but give completely different results, even though you don't re-assign
> start and stop between calls. You're not editing your results are you?
> 

Whooops! I had a whole lot of other commands in the scrollback
(displaying intermediate results and such), and elided the rather
crucial reassignment of parameters along with them!

Fortunately, thanks to my reiplophobia, I still have the original
session up in IDLE. This is even the most recent thing in it.

>>> sys.version
'3.2 (r32:88445, Feb 20 2011, 21:29:02) [MSC v.1500 32 bit (Intel)]'
>>> from fractions import Fraction as F
>>> start,stop,n = F(0),F(21,10),7
>>> [float(start+i*(stop-start)/n) for i in range(n+1)]
[0.0, 0.3, 0.6, 0.9, 1.2, 1.5, 1.8, 2.1]
>>> start, stop, n = F(-1), F(11,10), 7
>>> [float(start+i*(stop-start)/n) for i in range(n+1)]
[-1.0, -0.7, -0.4, -0.1, 0.2, 0.5, 0.8, 1.1]

There, now it's honest. Sorry about that!!

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Generating equally-spaced floats with least rounding error

[John Ladasky]

On Sep 24, 6:53 am, Steven D'Aprano  wrote:
> I'm trying to generate a sequence of equally-spaced numbers between a lower
> and upper limit. Given arbitrary limits, what is the best way to generate a
> list of equally spaced floats with the least rounding error for each point?
>
> For example, suppose I want to divide the range 0 to 2.1 into 7 equal
> intervals, then the end-points of each interval are:
>
> (0.0)---(0.3)---(0.6)---(0.9)---(1.2)---(1.5)---(1.8)---(2.1)
>
> and I'd like to return the values in the brackets. Using Decimal or Fraction
> is not an option, I must use floats. If the exact value isn't representable
> as a float, I'm okay with returning the nearest possible float.

Use numpy.

>>> from numpy import mgrid
>>> seq = mgrid[0.0:2.1:8j]
>>> seq

array([ 0. ,  0.3,  0.6,  0.9,  1.2,  1.5,  1.8,  2.1])

>>> for x in seq:
print repr(x)

0.0
0.2
0.59998
0.89991
1.2
1.5
1.7998
2.1001

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Generating equally-spaced floats with least rounding error

[Steven D'Aprano]

Chris Angelico wrote:

> On Sun, Sep 25, 2011 at 3:01 AM, Steven D'Aprano
>  wrote:
>> Mark Dickinson wrote:
>>
>>> Using Fraction for intermediate calculations actually works perfectly
>>> for this, since conversions from float to Fraction are exact, while
>>> conversions from Fraction to float are correctly rounded.  So if
>>> you're using Python, you're not too bothered about efficiency, and you
>>> want provably correctly-rounded results, why not use Fraction?
>>>
>> Ah, I knew it was too easy!
> 
> Try using Fraction for the start and stop too:

If you look again at the code I used, I did. I just did it inside the list
comp. 


 from fractions import Fraction as F
 start,stop,n = F(0),F(21,10),7
 [float(start+i*(stop-start)/n) for i in range(n+1)]
> [0.0, 0.3, 0.6, 0.9, 1.2, 1.5, 1.8, 2.1]
 [float(start+i*(stop-start)/n) for i in range(n+1)]
> [-1.0, -0.7, -0.4, -0.1, 0.2, 0.5, 0.8, 1.1]


Something looks a tad suspicious here... the two list comps are identical,
but give completely different results, even though you don't re-assign
start and stop between calls. You're not editing your results are you?


But seriously, you were freaking me out there for a bit. I couldn't see why
pulling the conversion to fraction outside of the list comp was giving
different results. And then it hit me...

>>> 2.1 == F(21, 10)
False

You're testing different numbers from me. Try again with F(2.1) as the stop
value.



-- 
Steven

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Generating equally-spaced floats with least rounding error

[Steven D'Aprano]

Terry Reedy wrote:

> On 9/24/2011 9:53 AM, Steven D'Aprano wrote:
[...]
> [0.0 + i*width for i in range(8)]
>> [0.0, 0.3, 0.6, 0.8999, 1.2, 1.5, 1.7998, 2.1]
>>
>> The 4th and 7th values have rounding errors, the rest are exact
> 
> No they are not. Their errors are just smaller and not visible with 16
> digits.

Pardon. I meant that they were as close to exact as is possible in binary
floats. With the exception of 0.8999... and 1.7999... I don't believe any
other float can be closer to the exact value.

I did mention that "If the exact value isn't representable as a float, I'm
okay with returning the nearest possible float." :)



-- 
Steven

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Why is the shutil module called shutil?

[Matt Joiner]

Please continue

On Sun, Sep 25, 2011 at 8:36 AM, rantingrick  wrote:
> On Sep 23, 10:36 pm, Fletcher Johnson  wrote:
>> The topic says it all:
>> Why is shutil named shutil? What does it stand for? This is just a
>> mild curiosity of mine.
>> The shutil module for 
>> reference:http://docs.python.org/library/shutil.html#module-shutil
>
> Because even after 20 freaking years of evolution Python "heads of
> state" (or states of head) cannot be bi-partisan enough to agree on a
> freaking File and/or path object; remind you of any "body" we know?
> --
> http://mail.python.org/mailman/listinfo/python-list
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Suggested coding style

[Devin Jeanpierre]

> Padding numbers with leading zeroes is very common. I'm surprised that
> more languages don't make it a string method.

By making it a string method, instead of a function, we force all
implementations of strings to implement that method. That sort of
sucks, and it's a reason not to include it as a method. It can, after
all, be implemented as a function, and in doing so (with the
appropriate operator overloading) that function could work with
multiple implementations of strings. Instead any implementation of a
string must implement that method. That's a waste.

Of course, one could argue that there are very few string
implementations. On the other hand, there were three in the stdlib in
2.x, and there are other concepts of strings (like ropes) that are
more efficient for different use-cases. The third string in the stdlib,
mmap, didn't even bother implementing the full string interface. It's
just so damned big. (Also some methods didn't apply, like zfill, but
hey!)

At the very least, it's sort of ugly from my perspective to tack on
trivial things like this to be string methods.

But sure, yeah, as a bonus you get to do fewer imports. That's pretty
great too, I guess.

Devin

On Sat, Sep 24, 2011 at 10:36 PM, Steven D'Aprano
 wrote:
> MRAB wrote:
>
>> On 24/09/2011 20:10, Tim Johnson wrote:
>>> * Passiday  [110924 09:47]:
>>> <...>
 I have been coding in many other languages, most of the time it was
 Java and C#. I don't like the function mess of PHP (ie, loads and
 loads of functions without any namespaces etc), but I'd like to think
 that Python is different.
>>>    It is ...
>>>
 In my brief coding experience I have stumbled upon Python zfill(width)
 method, and I thought, really, do you have to include such a narrow-
 purpose method in the basic method set? Perhaps there are more such
 methods that are nice when you need them, but then again, you don't
 put all the possible methods in the standard set.
>>>    I think that you have raised an interesting question here. I've
>>>    been coding in python for 9 years and I have never used it.
>>>
 Perhaps there is reason such method is in the basic library, and my
 complaints are unbased?
>>>
>>>    It could be some sort of legacy. I imagine we will hear from some
>>>    more senior pythonists on this matter.
>>>
>> The documentation says "New in version 2.2.2".
>
> Which is about nine years old, so roughly half as old as Python itself.
> It's hardly a new feature.
>
> Just because Passiday and Tim don't use zfill doesn't mean it's not useful
> to some people. Here are examples of it in use, or people asking how to
> format numbers with leading zeroes:
>
> http://www.ruby-forum.com/topic/67378
> http://stackoverflow.com/questions/134934/display-number-with-leading-zeros
> http://stackoverflow.com/questions/733454/best-way-to-format-integer-as-string-with-leading-zeros
> http://msdn.microsoft.com/en-us/library/dd260048.aspx
> http://www.ozgrid.com/forum/showthread.php?t=64193&page=1
>
> http://www.google.com/codesearch#algXCqBNNP0/utils/zip2rep.py&q=lang:%5Epython$%20zfill%20case:yes&ct=rc&cd=7
>
> http://www.google.com/codesearch#Wnd3W7C0RPM/lives_guide.tar.bz2%7C0MIk12cLwTg/desub.py&q=lang:%5Epython$%20zfill%20case:yes
>
> Padding numbers with leading zeroes is very common. I'm surprised that
> more languages don't make it a string method.
>
>
>
> --
> Steven
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Suggested coding style

[Steven D'Aprano]

MRAB wrote:

> On 24/09/2011 20:10, Tim Johnson wrote:
>> * Passiday  [110924 09:47]:
>> <...>
>>> I have been coding in many other languages, most of the time it was
>>> Java and C#. I don't like the function mess of PHP (ie, loads and
>>> loads of functions without any namespaces etc), but I'd like to think
>>> that Python is different.
>>It is ...
>>
>>> In my brief coding experience I have stumbled upon Python zfill(width)
>>> method, and I thought, really, do you have to include such a narrow-
>>> purpose method in the basic method set? Perhaps there are more such
>>> methods that are nice when you need them, but then again, you don't
>>> put all the possible methods in the standard set.
>>I think that you have raised an interesting question here. I've
>>been coding in python for 9 years and I have never used it.
>>
>>> Perhaps there is reason such method is in the basic library, and my
>>> complaints are unbased?
>>
>>It could be some sort of legacy. I imagine we will hear from some
>>more senior pythonists on this matter.
>>
> The documentation says "New in version 2.2.2".

Which is about nine years old, so roughly half as old as Python itself. 
It's hardly a new feature.

Just because Passiday and Tim don't use zfill doesn't mean it's not useful 
to some people. Here are examples of it in use, or people asking how to 
format numbers with leading zeroes:

http://www.ruby-forum.com/topic/67378
http://stackoverflow.com/questions/134934/display-number-with-leading-zeros
http://stackoverflow.com/questions/733454/best-way-to-format-integer-as-string-with-leading-zeros
http://msdn.microsoft.com/en-us/library/dd260048.aspx
http://www.ozgrid.com/forum/showthread.php?t=64193&page=1

http://www.google.com/codesearch#algXCqBNNP0/utils/zip2rep.py&q=lang:%5Epython$%20zfill%20case:yes&ct=rc&cd=7

http://www.google.com/codesearch#Wnd3W7C0RPM/lives_guide.tar.bz2%7C0MIk12cLwTg/desub.py&q=lang:%5Epython$%20zfill%20case:yes

Padding numbers with leading zeroes is very common. I'm surprised that 
more languages don't make it a string method.



-- 
Steven

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Generating equally-spaced floats with least rounding error

[Steven D'Aprano]

Arnaud Delobelle wrote:

> On these examples, using fractions is no better than what I suggested
> in my previous post.

I'm sorry, I can't see your previous post. Perhaps it isn't available on my
news provider?



-- 
Steven

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 2.5 zlib trouble

[Christian Heimes]

Am 25.09.2011 01:33, schrieb Benjamin Kaplan:
> There is no binary installer on that page. That means you downloaded
> the source code and compiled it yourself. Yes, you didn't patch it.
> But it's still a self-compiled version of Python.
> 
> In order to get zlib in a self-compiled version of Python, you need to
> install the appropriate -dev package. From a quick look at the
> repository, I think it's zlib1g-dev but I'm not sure.
> 
> On Ubuntu, the development headers are in a different package than the
> libraries themselves. The development headers aren't needed when
> you're installing a binary that someone else compiled (for instance,
> anything you get from the package manager) but are needed if you're
> trying to build anything that uses the library. Since a good chunk of
> the Python stdlib isn't actually necessary to run Python, you can
> successfully build Python without getting a good chunk of the modules.
> ../configure will give you a list of the modules that won't get built
> at the end of its output.

On recent Ubuntu and Debian versions, the dev packages aren't enough for
old versions of Python. Anything older than Python 2.7.2 requires a
tweak in order to make Python find the shared libraries. It's all
explained in my blog posting.

Debian's new multiarch features has broken Python's main setup.py
because it tries to find the libraries itself instead of relying on
ld.so and gcc. Barry has already fixed the issue for 2.7.2 and recent 3.2.

Christian

PS: Linux 3.x is going to cause trouble with older versions of Python,
too. Wanna know more? Have a look: http://lipyrary.blogspot.com/

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python Mixins

[Tim Chase]

On 09/24/11 17:41, rantingrick wrote:

On Sep 24, 3:57 am, Steven D'Aprano  wrote:


class StandardTestMixin:
 def test_requires_one_argument(self):
 self.assertRaises(TypeError, self.func)
 def test_has_docstring(self):
 self.assertTrue(self.func.__doc__)


And this is another example of why we need doc-string reforms. Here we
have a well know "pythonista" (for lack of better word) who needs to
write a test for doc-string inclusion because he refuses to get in the
habit of writing them. People, EVERY method and function MUST have a
doc-string! What is the purpose of having doc-strings if we are too
lazy to use them!


http://www.python.org/dev/peps/pep-0257/

"""
The aim of this PEP is to standardize the high-level structure of 
docstrings: what they should contain, and how to say it (without 
touching on any markup syntax within docstrings). The PEP 
contains conventions, not laws or syntax.

"""

You keep saying the word "MUST".  I do not think it means what 
you think it means.  Just for the record [1], [2], [3], [4] all 
in my first page of search Google search results.  Pot, meet 
kettle.


-tkc

[1]
http://mail.python.org/pipermail/python-list/2009-September/1220068.html

[2]
http://mail.python.org/pipermail//python-list/2011-July/1276021.html

[3]
http://mail.python.org/pipermail/python-list/2010-March/1237898.html

[4]
http://mail.python.org/pipermail/python-list/2010-June/1246305.html
--
http://mail.python.org/mailman/listinfo/python-list

Re: Why is the shutil module called shutil?

[Terry Reedy]

On 9/23/2011 11:36 PM, Fletcher Johnson wrote:

The topic says it all:
Why is shutil named shutil? What does it stand for? This is just a
mild curiosity of mine.
The shutil module for reference: 
http://docs.python.org/library/shutil.html#module-shutil


I think it would be nice if the doc explained. Feel free to open a doc 
issue to add '(sh-ell util-ities)' or something after "The shutil " and 
add me, terry.reedy, as nosy.


--
Terry Jan Reedy

--
http://mail.python.org/mailman/listinfo/python-list

Re: Python Mixins

[Terry Reedy]

On 9/24/2011 4:57 AM, Steven D'Aprano wrote:


Python says is that issubclass(Cat, Yamlafiable) will return True. The
*interpretation* of that fact is entirely up to you. If you want to
interpret it as meaning that cats are Yamlafiables, go right ahead. If you
want to interpret it as a technical result with no semantic meaning, that's
fine too. After all, just because "ram" in "programming" returns True
doesn't actually mean anything about male sheep and computing.


Today's comics had a strip in which girl A suggests to girl B that they 
go to a disco to disco-ver someone interesting.



In fact, even in real life, the ancestor/descendant metaphor creaks. What
should we make of bacteria which exchange DNA with other species of
bacteria?


That the human concept of 'species' does not really apply to bacteria.
And similarly, that the CompSci concept of 'class' may also not always 
fit what we want to model.


> Which is the ancestor and which is the descendant? How about

symbionts like lichen? What about when we splice genes from one species
into another? So even in real life, there are multiple inheritance and
mixins.


Good point.

--
Terry Jan Reedy

--
http://mail.python.org/mailman/listinfo/python-list

Re: Python 2.5 zlib trouble

[Benjamin Kaplan]

On Sat, Sep 24, 2011 at 7:08 PM, Jesramz  wrote:
>
> I installed it from here: http://www.python.org/getit/releases/2.5.6/
>
> What do you think a solution might be?
>

There is no binary installer on that page. That means you downloaded
the source code and compiled it yourself. Yes, you didn't patch it.
But it's still a self-compiled version of Python.

In order to get zlib in a self-compiled version of Python, you need to
install the appropriate -dev package. From a quick look at the
repository, I think it's zlib1g-dev but I'm not sure.

On Ubuntu, the development headers are in a different package than the
libraries themselves. The development headers aren't needed when
you're installing a binary that someone else compiled (for instance,
anything you get from the package manager) but are needed if you're
trying to build anything that uses the library. Since a good chunk of
the Python stdlib isn't actually necessary to run Python, you can
successfully build Python without getting a good chunk of the modules.
./configure will give you a list of the modules that won't get built
at the end of its output.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 2.5 zlib trouble

[Jesramz]

I installed it from here: http://www.python.org/getit/releases/2.5.6/

What do you think a solution might be?

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python Mixins

[rantingrick]

On Sep 24, 3:57 am, Steven D'Aprano  wrote:

> class StandardTestMixin:
>     def test_requires_one_argument(self):
>         self.assertRaises(TypeError, self.func)
>     def test_has_docstring(self):
>         self.assertTrue(self.func.__doc__)

And this is another example of why we need doc-string reforms. Here we
have a well know "pythonista" (for lack of better word) who needs to
write a test for doc-string inclusion because he refuses to get in the
habit of writing them. People, EVERY method and function MUST have a
doc-string! What is the purpose of having doc-strings if we are too
lazy to use them!


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Why is the shutil module called shutil?

[rantingrick]

On Sep 23, 10:36 pm, Fletcher Johnson  wrote:
> The topic says it all:
> Why is shutil named shutil? What does it stand for? This is just a
> mild curiosity of mine.
> The shutil module for 
> reference:http://docs.python.org/library/shutil.html#module-shutil

Because even after 20 freaking years of evolution Python "heads of
state" (or states of head) cannot be bi-partisan enough to agree on a
freaking File and/or path object; remind you of any "body" we know?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Generating equally-spaced floats with least rounding error

[Terry Reedy]

On 9/24/2011 9:53 AM, Steven D'Aprano wrote:

I'm trying to generate a sequence of equally-spaced numbers between a lower
and upper limit. Given arbitrary limits, what is the best way to generate a
list of equally spaced floats with the least rounding error for each point?

For example, suppose I want to divide the range 0 to 2.1 into 7 equal
intervals, then the end-points of each interval are:

(0.0)---(0.3)---(0.6)---(0.9)---(1.2)---(1.5)---(1.8)---(2.1)

and I'd like to return the values in the brackets. Using Decimal or Fraction
is not an option, I must use floats. If the exact value isn't representable
as a float, I'm okay with returning the nearest possible float.

The width of each interval is:

width = (2.1 - 0.0)/7


Calculating width is the fundamental problem. .3 cannot be exactly 
represented in binary, and higher multiples with multiply the error.




The relevant points can be calculated in either of two methods:

#1 add multiples of the width to the starting value, 0.

#2 subtract multiples of width from the ending value, 2.1.

(Repeated addition or subtraction should be avoided, as it increases the
amount of rounding error.)

Mathematically the two are equivalent, but due to rounding, they may not be.
Here's a run using Python 3.2:


[0.0 + i*width for i in range(8)]

[0.0, 0.3, 0.6, 0.8999, 1.2, 1.5, 1.7998, 2.1]

The 4th and 7th values have rounding errors, the rest are exact


No they are not. Their errors are just smaller and not visible with 16 
digits.


>>> width = (2.1 - 0.0)/7
>>> ['%20.18f' % x for x in [0.0 + i*width for i in range(8)]]
['0.00', '0.299989', '0.599978', 
'0.899911', '1.199956', '1.50', 
'1.799822', '2.100089']


On 9/24/2011 10:18 AM, Arnaud Delobelle wrote:
>  ((n-i)*a + i*b)/n for i in range(n+1)

>>> ['%20.18f' % x for x in [((7-i)*0.0 + i*2.1)/7 for i in range(8)]]
['0.00', '0.299989', '0.599978', 
'0.900133', '1.199956', '1.50', 
'1.800266', '2.100089']


In the two places where this disagrees with the previous result, I 
believe it is worse. The *0.0 adds nothing. You are still multiplying an 
inexactly represented 2.1 by increasingly large numbers. Even 7*2.1/7 is 
not exact!


My answer is the same as Mark's. Do exact calculation with fractions 
(whether using Fraction or not) and convert to float. I believe the 
least common multiple of a.as_integer_ratio[1], b.as_integer_ratio[1], 
and n is the common denominator needed to convert the numerators to a 
range() output. For the current problem, that is lcm(10,7) = 70.


The best you can do for this example is
>>> ['%20.18f' % (i/10 ) for i in range(0, 22, 3)]
['0.00', '0.299989', '0.599978', 
'0.900022', '1.199956', '1.50', 
'1.800044', '2.100089']


Notice that the last place errors are all less than 50, so printing to 
16 places will make them appear 'exact'.


Without being fancy (to see than you can cancel 7), you get the same 
output with

>>> ['%20.18f' % (i/70 ) for i in range(0, 148, 21)]
['0.00', '0.299989', '0.599978', 
'0.900022', '1.199956', '1.50', 
'1.800044', '2.100089']


In the two places where these disagree with the first (your original) 
they are *better*, with absolute error in the last places of 22 versus 
89 and 44 versus 178 for .9 and 1.8. The last place errors greater than 
50 gave you the 'inexact' answers in your post, and indeed, they are not 
the best possible.


--
Terry Jan Reedy

--
http://mail.python.org/mailman/listinfo/python-list

Re: Python Mixins

[rantingrick]

On Sep 22, 4:14 pm, Matt  wrote:
> I'm curious about what people's opinions are about using mixins in
> Python. I really like, for example, the way that class based views
> were implemented in Django 1.3 using mixins. It makes everything
> extremely customizable and reusable. I think this is a very good
> practice to follow, however, in Python mixins are achieved by using
> (or perhaps misusing) inheritance and often multiple inheritance.

Have a look at this article also. Even though he uses java source code
anyone can follow along:

   http://berniesumption.com/software/inheritance-is-evil-and-must-be-destroyed/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Suggested coding style

[Tim Johnson]

* Arnaud Delobelle  [110924 12:04]:
> On 24 September 2011 20:34, MRAB  wrote:
> 
> >>> In my brief coding experience I have stumbled upon Python zfill(width)
> >>> method,
> [...]
> >>   It could be some sort of legacy. I imagine we will hear from some
> >>   more senior pythonists on this matter.
> >>
> > The documentation says "New in version 2.2.2".
> 
> But zfill has been in the string module for a lot longer.
 :) Like I said. See timestamp.
 http://mail.python.org/pipermail/python-bugs-list/1999-July/35.html
 I was coding C/C++ and ASM back then 

-- 
Tim 
tim at tee jay forty nine dot com or akwebsoft dot com
http://www.akwebsoft.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Generating equally-spaced floats with least rounding error

[f . derainville]

>>> import numpy
>>> numpy.arange(0, 3, 0.3)
array([ 0. ,  0.3,  0.6,  0.9,  1.2,  1.5,  1.8,  2.1,  2.4,  2.7])
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PyEval_EvalCodeEx return value

[Mateusz Loskot]

John Pinner-3 wrote:
> 
> I assume that you have read the documentation at
> http://docs.python.org/c-api/veryhigh.html,
> and I agree that it's sparse, but the entry for the next entry,
> PyEval_EvalCodeEx, tells you a little more, as does that for
> PyEval_EvalFrameEx.
> 

It does help, but only a bit.


John Pinner-3 wrote:
> 
> Obviously, it's returning a pointer to a PyObject, and Looking at the
> source code, that may be NULL, to throw an exception, or an execution
> frame, or a generator,etc, etc, depending on the code it's been given.
> I guess that you should be able to inspect the PyObject to see what it is.
> 

Yes, that's one possibility. I tried to investigate others.


John Pinner-3 wrote:
> 
> What I'm wondering is, why are you eval-ing code ? A favourite device
> of C programmers coming to Python (and mea culpa in the past), it's
> fraught with potential problems and even security risks, and is
> difficult to debug, and maybe you should be using introspection instead.
> 

My application accepts Python scripts from user and executes using embedded
Python interpreter.
So, I use this particular API.

Could you elaborate on the "using introspection"?


John Pinner-3 wrote:
> 
> And maybe you should be working in Python, and not C++ at this point,
> do the dynamic stuff in the language best suited, and then return to C++
> when needed.
> 

My application in C++ interacts with Python programs provided by users.
Depending on what these programs request, various PyObject objects are
created and returned back, etc.

I understand it's difficult to discuss it without long essays or without
providing the code, etc.
So, I can only discuss and investigate building blocks I use.
Anyway, thanks for your comments.

Best regards,

-
-- 
Mateusz Loskot
http://mateusz.loskot.net
-- 
View this message in context: 
http://old.nabble.com/PyEval_EvalCodeEx-return-value-tp32501833p32503908.html
Sent from the Python - python-list mailing list archive at Nabble.com.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Generating equally-spaced floats with least rounding error

[Stefan Krah]

Arnaud Delobelle  wrote:
>  start, stop, n = -1, 1.1, 7
>  [float(F(start) + i*(F(stop)-F(start))/n) for i in range(n+1)]
> > [-1.0, -0.7, -0.39997, -0.09996,
> > 0.20004, 0.5001, 0.8, 1.1]
> 
> >>> start, stop, n = -1, 1.1, 7
> >>> [((n-i)*start + i*stop)/n for i in range(n+1)]
> [-1.0, -0.7001, -0.39997,
> -0.09996, 0.20004, 0.5, 0.8, 1.1]
> 
> On these examples, using fractions is no better than what I suggested
> in my previous post.

Why not use Decimal if one needs exact endpoints? Something like:

def drange(start, stop, step=1):
if (step == 0):
raise ValueError("step must be != 0")
with localcontext() as ctx:
ctx.traps[Inexact] = True
x = start
cmp = -1 if step > 0 else 1
while x.compare(stop) == cmp:
yield float(x)
x += step


>>> list(drange(Decimal(1), Decimal("3.1"), Decimal("0.3")))
[1.0, 1.3, 1.6, 1.9, 2.2, 2.5, 2.8]
>>> list(drange(Decimal(-1), Decimal("1.1"), Decimal("0.3")))
[-1.0, -0.7, -0.4, -0.1, 0.2, 0.5, 0.8]
>>> list(drange(Decimal(-1), Decimal("1.1"), Decimal("0.1823612873")))
[-1.0, -0.8176387127, -0.6352774254, -0.4529161381, -0.2705548508, 
-0.0881935635, 0.0941677238, 0.2765290111, 0.4588902984, 0.6412515857, 
0.823612873, 1.0059741603]
>>> list(drange(Decimal(-1), Decimal("1.1"), Decimal(1)/3))
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 10, in drange
  File "/usr/lib/python3.2/decimal.py", line 1178, in __add__
ans = ans._fix(context)
  File "/usr/lib/python3.2/decimal.py", line 1652, in _fix
context._raise_error(Inexact)
  File "/usr/lib/python3.2/decimal.py", line 3836, in _raise_error
raise error(explanation)
decimal.Inexact: None



Stefan Krah


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Generating equally-spaced floats with least rounding error

[Arnaud Delobelle]

On 24 September 2011 18:01, Steven D'Aprano
 wrote:
> Mark Dickinson wrote:
>
>> Using Fraction for intermediate calculations actually works perfectly
>> for this, since conversions from float to Fraction are exact, while
>> conversions from Fraction to float are correctly rounded.  So if
>> you're using Python, you're not too bothered about efficiency, and you
>> want provably correctly-rounded results, why not use Fraction?
>>
> from fractions import Fraction
> start, stop, n = 0.0, 2.1, 7
> [float(Fraction(start) + i * (Fraction(stop) - Fraction(start)) / n)
> [for i in range(n+1)]
>> [0.0, 0.3, 0.6, 0.9, 1.2, 1.5, 1.8, 2.1]
>
>
> Ah, I knew it was too easy!
>
 from fractions import Fraction as F
 start, stop, n = 1, 3.1, 7
 [float(F(start) + i*(F(stop)-F(start))/n) for i in range(n+1)]
> [1.0, 1.3, 1.6, 1.9001, 2.2, 2.5, 2.8003, 3.1]

>>> start, stop, n = 1, 3.1, 7
>>> [((n-i)*start + i*stop)/n for i in range(n+1)]
[1.0, 1.3, 1.5999, 1.9001, 2.2, 2.5,
2.8003, 3.1]

 start, stop, n = -1, 1.1, 7
 [float(F(start) + i*(F(stop)-F(start))/n) for i in range(n+1)]
> [-1.0, -0.7, -0.39997, -0.09996,
> 0.20004, 0.5001, 0.8, 1.1]

>>> start, stop, n = -1, 1.1, 7
>>> [((n-i)*start + i*stop)/n for i in range(n+1)]
[-1.0, -0.7001, -0.39997,
-0.09996, 0.20004, 0.5, 0.8, 1.1]

On these examples, using fractions is no better than what I suggested
in my previous post.

-- 
Arnaud
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Suggested coding style

[Arnaud Delobelle]

On 24 September 2011 20:34, MRAB  wrote:

>>> In my brief coding experience I have stumbled upon Python zfill(width)
>>> method,
[...]
>>   It could be some sort of legacy. I imagine we will hear from some
>>   more senior pythonists on this matter.
>>
> The documentation says "New in version 2.2.2".

But zfill has been in the string module for a lot longer.

-- 
Arnaud
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Suggested coding style

[MRAB]

On 24/09/2011 20:10, Tim Johnson wrote:

* Passiday  [110924 09:47]:
<...>

I have been coding in many other languages, most of the time it was
Java and C#. I don't like the function mess of PHP (ie, loads and
loads of functions without any namespaces etc), but I'd like to think
that Python is different.

   It is ...


In my brief coding experience I have stumbled upon Python zfill(width)
method, and I thought, really, do you have to include such a narrow-
purpose method in the basic method set? Perhaps there are more such
methods that are nice when you need them, but then again, you don't
put all the possible methods in the standard set.

   I think that you have raised an interesting question here. I've
   been coding in python for 9 years and I have never used it.


Perhaps there is reason such method is in the basic library, and my
complaints are unbased?


   It could be some sort of legacy. I imagine we will hear from some
   more senior pythonists on this matter.


The documentation says "New in version 2.2.2".


Or, perhaps the language is on course to bloat
out and get filled with tens and hundreds of special-purpose methods
that render the language structure chaotic?


From my observance, python has developed with care and prudence. I
   have a feeling (instinctive of course), that Guido van Rossum
   is/was more likely to say 'no' to a request for a new
   implementation that Rasmus Lerdorf.




--
http://mail.python.org/mailman/listinfo/python-list

Re: Suggested coding style

[Tim Johnson]

* Passiday  [110924 09:47]:
<...>
> I have been coding in many other languages, most of the time it was
> Java and C#. I don't like the function mess of PHP (ie, loads and
> loads of functions without any namespaces etc), but I'd like to think
> that Python is different.
  It is ... 

> In my brief coding experience I have stumbled upon Python zfill(width)
> method, and I thought, really, do you have to include such a narrow-
> purpose method in the basic method set? Perhaps there are more such
> methods that are nice when you need them, but then again, you don't
> put all the possible methods in the standard set.
  I think that you have raised an interesting question here. I've
  been coding in python for 9 years and I have never used it. 

> Perhaps there is reason such method is in the basic library, and my
> complaints are unbased? 

  It could be some sort of legacy. I imagine we will hear from some
  more senior pythonists on this matter.

> Or, perhaps the language is on course to bloat
> out and get filled with tens and hundreds of special-purpose methods
> that render the language structure chaotic?

  From my observance, python has developed with care and prudence. I
  have a feeling (instinctive of course), that Guido van Rossum
  is/was more likely to say 'no' to a request for a new
  implementation that Rasmus Lerdorf.

  MTCW
-- 
Tim 
tim at tee jay forty nine dot com or akwebsoft dot com
http://www.akwebsoft.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Suggested coding style

[MRAB]

On 24/09/2011 18:31, Passiday wrote:

Hello,

I have started to code random stuff in Python only recently, still
lots to learn. So please bear with me if my question sounds like rant.

I have been coding in many other languages, most of the time it was
Java and C#. I don't like the function mess of PHP (ie, loads and
loads of functions without any namespaces etc), but I'd like to think
that Python is different.

In my brief coding experience I have stumbled upon Python zfill(width)
method, and I thought, really, do you have to include such a narrow-
purpose method in the basic method set? Perhaps there are more such
methods that are nice when you need them, but then again, you don't
put all the possible methods in the standard set.

Perhaps there is reason such method is in the basic library, and my
complaints are unbased? Or, perhaps the language is on course to bloat
out and get filled with tens and hundreds of special-purpose methods
that render the language structure chaotic?


Considering that Python has been around for 20 years, there's not much
bloat. Most of the risk of that was early on, when any interest in the
language might have been welcomed. Now that its use has grown, it can
be more choosy.

.zfill does have its uses:

>>> "-1".rjust(4, "0")
'00-1'
>>> "-1".zfill(4)
'-001'
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python-list Digest, Vol 96, Issue 137

[Ricardo Mansilla]

On Saturday 24 September 2011 01:48:29 you wrote:
> Ricardo wrote:
> > Hi everyone
> > I'm trying to use the cgi library to create a python script and loading
> > it from a web page. I have already done the necessary imports, and the
> > default commands to receive data from "html" are written too. The final
> > version is something like this:
> > 
> > #!/usr/bin/python
> > 
> > import subprocess
> > import cgi
> > import cgitb
> > 
> > cgitb.enable()
> > 
> > input = cgi.FieldStorage()
> > 
> > …. my code (do something with input)….
> > 
> > 
> > #printing the response
> > 
> > print "Content-Type: text/html"
> > print
> > print "My title:"
> > print ""
> > print ""
> > print ….. bla bla …
> > print "%s"%theoutput
> > print ""
> > 
> > Besides, my call from my index.html is like this:
> >  
> >  
> >   
> >   
> > 
> >  
> >  
> > 
> > well, the thing is that when i do the call from the browser:
> > 
> > http://localhost/index.html
> > 
> >   V
> > 
> > put the data and click on the "accept" button
> > 
> >   V
> > 
> > http:/localhost/scripts/python_script.py
> > 
> > I only get the python_script.py as a plain test by response (the script
> > printed on my browser). I have already changed the permissions for
> > python_script.py. I have checked the import cgi,cgitb in the python shell
> > (i am using v2.7) and they work fine. So, i don't know what it is going
> > wrong here.
> > 
> > A little help please… any idea?
> 
> Is your webserver configured to allow cgi scripts? In the scripts
> directory? For Apache see
> 
> http://httpd.apache.org/docs/current/howto/cgi.html
> 
> Python also comes with a CGI Server. A quick-and-dirty setup goes like
> this:
> 
> $ cat cgi-bin/script.py
> #!/usr/bin/python
> # -*- coding: utf-8 -*-
> 
> import cgi
> import cgitb
> 
> cgitb.enable()
> 
> input = cgi.FieldStorage()
> 
> print "Content-Type: text/html"
> print
> print "My title:"
> print ""
> print ""
> print "Hello world"
> print ""
> $ chmod a+x cgi-bin/script.py
> $ python -m CGIHTTPServer
> Serving HTTP on 0.0.0.0 port 8000 ...
> 
> If you then point your browser to http://localhost:8000/cgi-bin/script.py
> you should see
> 
> Hello world
> 
> in the browser and (something like)
> 
> localhost - - [24/Sep/2011 08:41:27] "GET /cgi-bin/script.py HTTP/1.1" 200
> -
> 
> in the shell. Note that the script must be in cgi-bin (or htbin) unless you
> start the server with a custom script that modifies
> CGIHTTPRequestHandler.cgi_directories accordingly.


Thanks a lot, for your answer. Yes, i can run scripts from /cgi-bin/. Actually 
I follow you example and it works really well. I didn't know at all about this 
CGI server. 
I am doing the hole thing over python now, it's nice. 
Thanks again.

-- 
(...)Also, since that same law states that any system able to prove its 
consistency to itself must be inconsistent; any mind that believes it can 
prove its own sanity is, therefore, insane.(...) 
Kurt Gödel. 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Generating equally-spaced floats with least rounding error

[Mark Dickinson]

On Sep 24, 6:01 pm, Steven D'Aprano  wrote:
> Ah, I knew it was too easy!
>
> >>> from fractions import Fraction as F
> >>> start, stop, n = 1, 3.1, 7
> >>> [float(F(start) + i*(F(stop)-F(start))/n) for i in range(n+1)]
>
> [1.0, 1.3, 1.6, 1.9001, 2.2, 2.5, 2.8003, 3.1]

I believe that's still giving correctly-rounded results.  Note that
the stop value of 3.1 isn't exactly 3.1 here:  it's

3.100088817841970012523233890533447265625

So the 4th value above is the closest float to 4/7 * 1.0 + 3/7 *
3.100088817841970012523233890533447265625.

--
Mark

-- 
http://mail.python.org/mailman/listinfo/python-list

Suggested coding style

[Passiday]

Hello,

I have started to code random stuff in Python only recently, still
lots to learn. So please bear with me if my question sounds like rant.

I have been coding in many other languages, most of the time it was
Java and C#. I don't like the function mess of PHP (ie, loads and
loads of functions without any namespaces etc), but I'd like to think
that Python is different.

In my brief coding experience I have stumbled upon Python zfill(width)
method, and I thought, really, do you have to include such a narrow-
purpose method in the basic method set? Perhaps there are more such
methods that are nice when you need them, but then again, you don't
put all the possible methods in the standard set.

Perhaps there is reason such method is in the basic library, and my
complaints are unbased? Or, perhaps the language is on course to bloat
out and get filled with tens and hundreds of special-purpose methods
that render the language structure chaotic?

Passiday
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Generating equally-spaced floats with least rounding error

[Chris Angelico]

On Sun, Sep 25, 2011 at 3:01 AM, Steven D'Aprano
 wrote:
> Mark Dickinson wrote:
>
>> Using Fraction for intermediate calculations actually works perfectly
>> for this, since conversions from float to Fraction are exact, while
>> conversions from Fraction to float are correctly rounded.  So if
>> you're using Python, you're not too bothered about efficiency, and you
>> want provably correctly-rounded results, why not use Fraction?
>>
> Ah, I knew it was too easy!

Try using Fraction for the start and stop too:
>>> from fractions import Fraction as F
>>> start,stop,n = F(0),F(21,10),7
>>> [float(start+i*(stop-start)/n) for i in range(n+1)]
[0.0, 0.3, 0.6, 0.9, 1.2, 1.5, 1.8, 2.1]
>>> [float(start+i*(stop-start)/n) for i in range(n+1)]
[-1.0, -0.7, -0.4, -0.1, 0.2, 0.5, 0.8, 1.1]

(Tested in Py 3.2 for Win)

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Generating equally-spaced floats with least rounding error

[Steven D'Aprano]

Mark Dickinson wrote:

> Using Fraction for intermediate calculations actually works perfectly
> for this, since conversions from float to Fraction are exact, while
> conversions from Fraction to float are correctly rounded.  So if
> you're using Python, you're not too bothered about efficiency, and you
> want provably correctly-rounded results, why not use Fraction?
> 
 from fractions import Fraction
 start, stop, n = 0.0, 2.1, 7
 [float(Fraction(start) + i * (Fraction(stop) - Fraction(start)) / n)
 [for i in range(n+1)]
> [0.0, 0.3, 0.6, 0.9, 1.2, 1.5, 1.8, 2.1]


Ah, I knew it was too easy!

>>> from fractions import Fraction as F
>>> start, stop, n = 1, 3.1, 7
>>> [float(F(start) + i*(F(stop)-F(start))/n) for i in range(n+1)]
[1.0, 1.3, 1.6, 1.9001, 2.2, 2.5, 2.8003, 3.1]
>>>
>>> start, stop, n = -1, 1.1, 7
>>> [float(F(start) + i*(F(stop)-F(start))/n) for i in range(n+1)]
[-1.0, -0.7, -0.39997, -0.09996,
0.20004, 0.5001, 0.8, 1.1]



-- 
Steven

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Generating equally-spaced floats with least rounding error

[Chris Angelico]

On Sun, Sep 25, 2011 at 12:26 AM, Mel  wrote:
> low_limit + (total_width * i) / intervals
>

Definite improvement, if the range is comparatively small. Multiply
first, then divide.

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Generating equally-spaced floats with least rounding error

[Mark Dickinson]

On Sep 24, 5:46 pm, Steven D'Aprano  wrote:
> Speed is important, but secondary to correctness. To be honest, I never even
> thought of using fractions as an intermediate result -- I was thinking of
> generating lists of Fractions. I think I can use this approach.

Speed could be improved greatly by using integer arithmetic (with some
help from the float.as_integer_ratio method) instead of using Fraction
directly, though it would require writing quite a lot more code;
Fraction's many and slow gcd calls for normalization are a problem
here, and since all denominators will be powers of 2 they're largely
unnecessary.

> But out of curiosity, how would you do it using nothing but floats? Is there
> a way?

Hmm.  Beyond writing my own multiple-precision integer library using
floats as the base type, I can't think of anything obvious. :-)

--
Mark
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Generating equally-spaced floats with least rounding error

[Steven D'Aprano]

Mark Dickinson wrote:

> On Sep 24, 2:53 pm, Steven D'Aprano  +comp.lang.pyt...@pearwood.info> wrote:
>> I'm trying to generate a sequence of equally-spaced numbers between a
>> lower and upper limit. Given arbitrary limits, what is the best way to
>> generate a list of equally spaced floats with the least rounding error
>> for each point?
>>
>> For example, suppose I want to divide the range 0 to 2.1 into 7 equal
>> intervals, then the end-points of each interval are:
>>
>> (0.0)---(0.3)---(0.6)---(0.9)---(1.2)---(1.5)---(1.8)---(2.1)
>>
>> and I'd like to return the values in the brackets. Using Decimal or
>> Fraction is not an option, I must use floats. If the exact value isn't
>> representable as a float, I'm okay with returning the nearest possible
>> float.
> 
> Can you explain why you're constrained not to use Fraction?  Speed?

Speed is important, but secondary to correctness. To be honest, I never even
thought of using fractions as an intermediate result -- I was thinking of
generating lists of Fractions. I think I can use this approach.

But out of curiosity, how would you do it using nothing but floats? Is there
a way?



-- 
Steven

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Generating equally-spaced floats with least rounding error

[Mark Dickinson]

On Sep 24, 2:53 pm, Steven D'Aprano  wrote:
> I'm trying to generate a sequence of equally-spaced numbers between a lower
> and upper limit. Given arbitrary limits, what is the best way to generate a
> list of equally spaced floats with the least rounding error for each point?
>
> For example, suppose I want to divide the range 0 to 2.1 into 7 equal
> intervals, then the end-points of each interval are:
>
> (0.0)---(0.3)---(0.6)---(0.9)---(1.2)---(1.5)---(1.8)---(2.1)
>
> and I'd like to return the values in the brackets. Using Decimal or Fraction
> is not an option, I must use floats. If the exact value isn't representable
> as a float, I'm okay with returning the nearest possible float.

Can you explain why you're constrained not to use Fraction?  Speed?

Using Fraction for intermediate calculations actually works perfectly
for this, since conversions from float to Fraction are exact, while
conversions from Fraction to float are correctly rounded.  So if
you're using Python, you're not too bothered about efficiency, and you
want provably correctly-rounded results, why not use Fraction?

>>> from fractions import Fraction
>>> start, stop, n = 0.0, 2.1, 7
>>> [float(Fraction(start) + i * (Fraction(stop) - Fraction(start)) / n) for i 
>>> in range(n+1)]
[0.0, 0.3, 0.6, 0.9, 1.2, 1.5, 1.8, 2.1]

--
Mark

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 2.5 zlib trouble

[Christian Heimes]

Am 23.09.2011 23:34, schrieb Jesramz:
> Im running on Ubuntu Natty and I am not running a self-compiled
> install, its a regular release. 

Ubuntu Natty doesn't come with Python 2.5. How did you install Python
2.5 on Natty? If you used some sort of installer or 3rd party
repository, there is a big chance that the installer doesn't understand
multiarch.

Christian

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Generating equally-spaced floats with least rounding error

[Mel]

Steven D'Aprano wrote:

> I'm trying to generate a sequence of equally-spaced numbers between a
> lower and upper limit. Given arbitrary limits, what is the best way to
> generate a list of equally spaced floats with the least rounding error for
> each point?
> 
> For example, suppose I want to divide the range 0 to 2.1 into 7 equal
> intervals, then the end-points of each interval are:
> 
> (0.0)---(0.3)---(0.6)---(0.9)---(1.2)---(1.5)---(1.8)---(2.1)
> 
> and I'd like to return the values in the brackets. Using Decimal or
> Fraction is not an option, I must use floats. If the exact value isn't
> representable as a float, I'm okay with returning the nearest possible
> float.
> 
> The width of each interval is:
> 
> width = (2.1 - 0.0)/7
> 
> The relevant points can be calculated in either of two methods:
> 
> #1 add multiples of the width to the starting value, 0.
> 
> #2 subtract multiples of width from the ending value, 2.1.
> 
> (Repeated addition or subtraction should be avoided, as it increases the
> amount of rounding error.)
> 
> Mathematically the two are equivalent, but due to rounding, they may not
> be. Here's a run using Python 3.2:
> 
 [0.0 + i*width for i in range(8)]
> [0.0, 0.3, 0.6, 0.8999, 1.2, 1.5, 1.7998, 2.1]
> 
> The 4th and 7th values have rounding errors, the rest are exact.
> 
> 
 [2.1 - (7-i)*width for i in range(8)]
> [0.0, 0.30027, 0.6001, 0.9001,
> 1.2002, 1.5, 1.8, 2.1]
> 
> The 2nd, 3rd, 4th and 5th values have rounding errors. Note that the 7th
> value is exact here, but not above.
> 
> Is there a way to pick between methods #1 and #2 (or some combination of
> the two) without human intervention so as to minimise the rounding error?
> Or is there some other way to generate equally-spaced floats? My efforts
> at googling have not been helpful.

When I've done this with ints (usually in small embedded systems) I've 
always preferred

low_limit + (total_width * i) / intervals

since it does the rounding on the biggest numbers where proportional error 
will be least, and it's guaranteed to hit the low_limit and high_limit 
exactly (as exactly as they can be represented, anyway.)

Mel.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Generating equally-spaced floats with least rounding error

[Arnaud Delobelle]

On Sep 24, 2011 2:59 PM, "Chris Angelico"  wrote:
>
> On Sat, Sep 24, 2011 at 11:53 PM, Steven D'Aprano
>  wrote:
> > #1 add multiples of the width to the starting value, 0.
> >
> > #2 subtract multiples of width from the ending value, 2.1.
>
> #3, go half and half - generate the lower half by adding to the lower
> bound, and the upper half by subtracting from the upper bound. Not

#4 the barycentric approach.

((n-i)*a + i*b)/n for i in range(n+1)

Gives you n+1 equally spaced values between a and b inclusive

Arnaud
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Generating equally-spaced floats with least rounding error

[Vlastimil Brom]

2011/9/24 Chris Angelico :
> On Sat, Sep 24, 2011 at 11:53 PM, Steven D'Aprano
>  wrote:
>> #1 add multiples of the width to the starting value, 0.
>>
>> #2 subtract multiples of width from the ending value, 2.1.
>
> #3, go half and half - generate the lower half by adding to the lower
> bound, and the upper half by subtracting from the upper bound. Not
> sure if it'll help or not but it might be worth a shot.
>
> ChrisA
> --
Just a naive way:
#4 compute the values in both directions and use the average of the
results (of, course, given, there isn't a better way to distinguish
the values showing rounding errors automatically).

(I guess dealing manually with values obtained by .as_integer_ratio()
doesn't count as pure float operation...)

   vbr
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Generating equally-spaced floats with least rounding error

[Chris Angelico]

On Sat, Sep 24, 2011 at 11:53 PM, Steven D'Aprano
 wrote:
> #1 add multiples of the width to the starting value, 0.
>
> #2 subtract multiples of width from the ending value, 2.1.

#3, go half and half - generate the lower half by adding to the lower
bound, and the upper half by subtracting from the upper bound. Not
sure if it'll help or not but it might be worth a shot.

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

Generating equally-spaced floats with least rounding error

[Steven D'Aprano]

I'm trying to generate a sequence of equally-spaced numbers between a lower
and upper limit. Given arbitrary limits, what is the best way to generate a
list of equally spaced floats with the least rounding error for each point?

For example, suppose I want to divide the range 0 to 2.1 into 7 equal
intervals, then the end-points of each interval are:

(0.0)---(0.3)---(0.6)---(0.9)---(1.2)---(1.5)---(1.8)---(2.1)

and I'd like to return the values in the brackets. Using Decimal or Fraction
is not an option, I must use floats. If the exact value isn't representable
as a float, I'm okay with returning the nearest possible float.

The width of each interval is:

width = (2.1 - 0.0)/7

The relevant points can be calculated in either of two methods:

#1 add multiples of the width to the starting value, 0.

#2 subtract multiples of width from the ending value, 2.1.

(Repeated addition or subtraction should be avoided, as it increases the
amount of rounding error.)

Mathematically the two are equivalent, but due to rounding, they may not be.
Here's a run using Python 3.2:

>>> [0.0 + i*width for i in range(8)]
[0.0, 0.3, 0.6, 0.8999, 1.2, 1.5, 1.7998, 2.1]

The 4th and 7th values have rounding errors, the rest are exact.


>>> [2.1 - (7-i)*width for i in range(8)]
[0.0, 0.30027, 0.6001, 0.9001,
1.2002, 1.5, 1.8, 2.1]

The 2nd, 3rd, 4th and 5th values have rounding errors. Note that the 7th
value is exact here, but not above.

Is there a way to pick between methods #1 and #2 (or some combination of the
two) without human intervention so as to minimise the rounding error? Or is
there some other way to generate equally-spaced floats? My efforts at
googling have not been helpful.



-- 
Steven

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: random.randint() slow, esp in Python 3

[Mark Dickinson]

On Sep 24, 10:38 am, Ian Kelly  wrote:
> On Sat, Sep 24, 2011 at 12:55 AM, Steven D'Aprano
>
>
>
>
>
>
>
>
>
>  wrote:
> > If you want unbiased, random (or at least pseudo-random) integers chosen
> > from an uniform distribution with proper error checking, you should use
> > randint or randrange.
>
> >> but if you just
> >> want a pile of more-or-less random integers, int(random.random()*top)
> >> is the best option.
>
> > "I only need random-ish ints, but I need 'em yesterday!!!"
>
> > If you want biased, not-quite-uniformly distributed integers with no error
> > checking, then the above will save you a few nanoseconds per call. So if
> > your application needs a million such ints, you might save a full five
> > seconds or so. Sounds like premature optimization to me, but what do I
> > know? If you have an application where the quality of randomness is
> > unimportant and generating random ints is a genuine performance bottleneck,
> > then go right ahead.
>
> Peeking under the hood, after all the error-checking and extra
> features, randrange basically just does int(random.random() * top).
> Any bias present in the latter will also be present in the former.
>
> Cheers,
> Ian

In Python 2.x that's true, and indeed randrange has some fairly bad
behaviour for large arguments ( see http://bugs.python.org/issue9025
).  In Python 3.2 and up, randrange is more careful:  it doesn't
introduce any extra bias beyond that already present in the random
source (Mersenne Twister).  If you look at the source, you'll see that
Python 2.x only calls _getrandbits for large arguments, while Python
3.2+ calls _getrandbits for *every* invocation of randrange.  (All
assuming that we're using the default MT random number generator.)
This may well explain the difference in timings observed by the OP.

--
Mark
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: random.randint() slow, esp in Python 3

[Chris Angelico]

On Sat, Sep 24, 2011 at 4:55 PM, Steven D'Aprano
 wrote:
> Chris Angelico wrote:
>
> If you want unbiased, random (or at least pseudo-random) integers chosen
> from an uniform distribution with proper error checking, you should use
> randint or randrange.
>
> "I only need random-ish ints, but I need 'em yesterday!!!"

All I want is some data to sort, so that I can verify that my
implementation is doing the same thing in every language that I write
it in. Doesn't have to be casino-level purity of randomness.

> You can't measure the speed of:
>
> [random.randint(0,sz*10-1) for i in range(sz)]
>
> and draw conclusions about randint alone.

Sure, but by comparing the two lines of code (one with randint and one
with random()), the other aspects can be cancelled out.

> For what (little) it's worth, it seems that Python 3.2 should be a bit
> faster than 2.6, at least if you consider the Pystone benchmark to mean
> anything.
>
> http://www.levigross.com/post/2340736877/pystone-benchmark-on-2-6-2-7-3-2

That's what I would normally expect, that the new version outperforms
the old - regardless of the program and the context. Exceptions need
justification (as in the case of int/long vs just int - Py2 often
outperforms Py3 when all the numbers fit inside machine int).

> You do know that Python's heap implementation is written in C? Don't be
> fooled by the heapq module being in Python.

I didn't know, but it doesn't surprise me. But my purpose wasn't to
sort the integers, it was to play with a particular hand-rolled
implementation of a heap sort in multiple languages and make sure it
was producing consistent results.

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: pyWin build 216

[Michel Claveau - MVP]

Hi!

Me, because some bugs in 216, I come back to 214...
(215 has another bugs).

@-salutations
-- 
MCi
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python Mixins

[Carl Banks]

On Thursday, September 22, 2011 2:14:39 PM UTC-7, Matt wrote:
> In terms of code, lets say we have the following classes:
> 
> class Animal
> class Yamlafiable
> class Cat(Animal, Yamlafiable)
> class Dog(Animal, Yamlafiable)
> 
> I've got an Animal that does animal things, a Cat that does cat things
> and a Dog that does dog things. I've also got a Yamlafiable class that
> does something clever to generically convert an object into Yaml in
> some way. Looking at these classes I can see that a Cat is an Animal,
> a Dog is an Animal, a Dog is not a Cat, a Cat is not a Dog, a Dog is a
> Yamlafiable? and a Cat is a Yamlafiable? Is that really true?

Yes.

I hope you are not confusing Cats with cats.


> If my
> objects are categorized correctly, in the correct inheritance
> hierarchy shouldn't that make more sense? Cats and Dogs aren't
> Yamlafiable, that doesn't define what they are, rather it defines
> something that they can do because of things that they picked up from
> their friend the Yamlafile.

The whole point of OOP is that objects are defined by their behavior.  A Cat is 
whatever it can do.  A Dog is whatever it can do.  If a Cat is yamlafiable, 
then it's coorect to say that a Cat is a Yamlafible (even if a cat isn't).


Carl Banks
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python Mixins

[Carl Banks]

On Thursday, September 22, 2011 2:14:39 PM UTC-7, Matt wrote:
[snip]
> class MyMixin(object):
> def one_thing(self):
> return "something cool"
> 
> @mixin(MyMixin)
> class MyClass(object):
> pass
> 
> x = MyClass()
> x.one_thing() == 'something cool'
> x.__class__.__bases__ ==  (object,)
> 
> To me, this is much more concise. By looking at this I can tell what
> MyClass IS, who it's parents are and what else it can do. I'm very
> interested to know if there are others who feel as dirty as I do when
> using inheritance for mixins

Not me.  Inheritance perfectly encompasses the mixin relationship, and because 
inheritance is so thoroughly ingrained in Python, it makes sense not to create 
a completely different mechanism to share behavior just for the case of mixins.

I know that, as someone who reads code, I would rather coders stick to 
well-known mechanisms than to create their own ad hoc mechanisms that don't 
actually add any new capability.  Take your MyClass example above.  If you had 
stuck to inheritance I could have seen what classes all the behavior was 
implemented by listing the __bases__.  But since you used an ad hoc mechanism, 
now I have to track down where the hell that one_thing() method is coming from.

No mechanism is ever perfect, and Python's MI is very far from perfect, but 
sticking to well-known and understood methods is usually more important than 
whatever little improvement you can make.  (And it is little; best as I can 
tell, your main objection is that mixins make it harder to see what the "main" 
parent is.  I'd say that's a dubious justification to spring a new 
behavior-sharing mechanism on a reader.)


> or if there are other things that Python
> developers are doing to mix in functionality without using inheritance
> or if the general populous of the Python community disagrees with me
> and thinks that this is a perfectly valid use of inheritance.

I'd guess the majority just use inheritance, although I can't say I've seen 
enough code out there to gauge it.

But there is something else a lot of Pythonistas will do in many cases: just 
define regular functions.  In your example, instead of defining one_thing() as 
a method of a mixin, define it as a function.  Personally, I find that I almost 
never use mixins, though I have absolutely nothing against them and I use MI 
and metaclasses all the time.  It's just that for most things I'd use a mixin 
for, I find that one or two regular functions work perfectly well.


Carl Banks
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: random.randint() slow, esp in Python 3

[Ian Kelly]

On Sat, Sep 24, 2011 at 12:55 AM, Steven D'Aprano
 wrote:
> If you want unbiased, random (or at least pseudo-random) integers chosen
> from an uniform distribution with proper error checking, you should use
> randint or randrange.
>
>
>> but if you just
>> want a pile of more-or-less random integers, int(random.random()*top)
>> is the best option.
>
> "I only need random-ish ints, but I need 'em yesterday!!!"
>
> If you want biased, not-quite-uniformly distributed integers with no error
> checking, then the above will save you a few nanoseconds per call. So if
> your application needs a million such ints, you might save a full five
> seconds or so. Sounds like premature optimization to me, but what do I
> know? If you have an application where the quality of randomness is
> unimportant and generating random ints is a genuine performance bottleneck,
> then go right ahead.

Peeking under the hood, after all the error-checking and extra
features, randrange basically just does int(random.random() * top).
Any bias present in the latter will also be present in the former.

Cheers,
Ian
-- 
http://mail.python.org/mailman/listinfo/python-list

MailingLogger 3.5.0 Released!

[Chris Withers]

I'm pleased to announce a new release of Mailinglogger.

Mailinglogger provides two handlers for the standard python
logging framework that enable log entries to be emailed either as the
entries are logged or as a summary at the end of the running process.

The handlers have the following features:

- customisable and dynamic subject lines for emails sent

- emails sent with a configurable headers for easy filtering

- flood protection to ensure the number of emails sent is not excessive

- support for SMTP servers that require authentication

- fully documented and tested

The only change for this release was to add an X-Log-Level header to 
emails sent. For MailingLogger, this is the level of the log message 
being emailed. For SummarisingLogger this is the highest level of any of 
the messages handled.


Full docs can be found here:

http://packages.python.org/mailinglogger/

For more information, please see:
http://www.simplistix.co.uk/software/python/mailinglogger
or
http://pypi.python.org/pypi/mailinglogger

cheers,

Chris

--
Simplistix - Content Management, Zope & Python Consulting
   - http://www.simplistix.co.uk



--
http://mail.python.org/mailman/listinfo/python-list

Re: Python Mixins

[Steven D'Aprano]

Matt wrote:

> I'm curious about what people's opinions are about using mixins in
> Python. I really like, for example, the way that class based views
> were implemented in Django 1.3 using mixins.

Mixins considered harmful:
http://www.artima.com/weblogs/viewpost.jsp?thread=246341
http://www.artima.com/weblogs/viewpost.jsp?thread=246483

Mixins are much too easy to abuse, but there are uses for them.

I have found mixins useful for testing. If I have a bunch of functions that
take mostly similar unit tests, I create a mixin for the common unit tests,
then apply them to the tests.

Suppose I have two functions, ham and spam, which are unrelated but do share
some common behaviours. Since they are unrelated, I don't want the spam
test suite to inherit from the ham test suite, or vice versa, but I don't
want to write the same tests multiple times. (Especially when I add cheese,
egg and tomato functions.) So I put the common behaviours in a mixin class:

class StandardTestMixin:
def test_requires_one_argument(self):
self.assertRaises(TypeError, self.func)
def test_has_docstring(self):
self.assertTrue(self.func.__doc__)

class TestHam(unittest.TestCase, StandardTestMixin):
...

class TestSpam(unittest.TestCase, StandardTestMixin):
...


In this case, I simply don't care that the use of a mixin implies that
TestHam is a StandardTestMixin. I treat that as an accident of
implementation: it makes no practical difference, since I write no code
that depends on isinstance(instance, StandardTestMixin).



[...]
> In terms of code, lets say we have the following classes:
> 
> class Animal
> class Yamlafiable
> class Cat(Animal, Yamlafiable)
> class Dog(Animal, Yamlafiable)
> 
> I've got an Animal that does animal things, a Cat that does cat things
> and a Dog that does dog things. I've also got a Yamlafiable class that
> does something clever to generically convert an object into Yaml in
> some way. Looking at these classes I can see that a Cat is an Animal,
> a Dog is an Animal, a Dog is not a Cat, a Cat is not a Dog, a Dog is a
> Yamlafiable? and a Cat is a Yamlafiable? Is that really true?

That depends on what you want.

Python says is that issubclass(Cat, Yamlafiable) will return True. The
*interpretation* of that fact is entirely up to you. If you want to
interpret it as meaning that cats are Yamlafiables, go right ahead. If you
want to interpret it as a technical result with no semantic meaning, that's
fine too. After all, just because "ram" in "programming" returns True
doesn't actually mean anything about male sheep and computing.

The map is not the territory, and object-oriented ancestor/descendant
relationships are not the same as real life relationships. It's a tool,
nothing more, and if the metaphor starts to creak at the edges, oh well, so
much for the metaphor.

In fact, even in real life, the ancestor/descendant metaphor creaks. What
should we make of bacteria which exchange DNA with other species of
bacteria? Which is the ancestor and which is the descendant? How about
symbionts like lichen? What about when we splice genes from one species
into another? So even in real life, there are multiple inheritance and
mixins.



> If my 
> objects are categorized correctly, in the correct inheritance
> hierarchy shouldn't that make more sense? Cats and Dogs aren't
> Yamlafiable, that doesn't define what they are, rather it defines
> something that they can do because of things that they picked up from
> their friend the Yamlafile.

The standard metaphor for inheritance in OOP doesn't include "learning
things from a friend". It is a very simple metaphor: everything is
either "is-a" or "has-a". If you inherit from a class, the is-a
relationship holds. If you don't want that, you can use composition
instead:

class Cat(Animal):
def __init__(self, yamlifier):
self.yamlifier = yamlifier
def make_yaml(self):
self.yamlifier.make_yaml(self, self.spam)

Now we say that a Cat has-a Yamlafiable.


> This is just a ridiculous example, but I think it is valid to say that
> these things shouldn't be limited to inherit functionality only from
> their parents, that they can pick other things up along the way as
> well. Which is easy to do, right?
> 
> Dog.something_new = something_new

And that works in Python. But the thing is, which would you rather write?

#1
class Dog(Animal, Yamlafiable):
pass

or this?

#2
class Dog(Animal):
pass

Dog.__dict__.update(Yamlafiable.__dict__)


But wait! The two aren't the same. There are quite big differences in
behaviour between inheritance and attribute injection:

* In the case of inheritance, attributes defined by Animal take 
  precedence over those defined by Yamlafiable. In the case of 
  injection, the opposite is the case.

* In the case of inheritance, attributes defined by Yamlafiable's
  superclasses are reachable. In the case of injection, they 
  aren't (at least not without more work).

* Inheritance is late-bind

Re: multinomial combinations

[Arnaud Delobelle]

(sorry about the top posting)

Change yield c to yield (c,)

HTH

Arnaud

PS: you could also change the if ... To

If not ns:
Yield ((),)
Else:
...
On Sep 24, 2011 8:06 AM, "Dr. Phillip M. Feldman" <
phillip.m.feld...@gmail.com> wrote:
>
> I wrote a small generator function that produces multinomial combinations.

> (Python's itertools module does ordinary combinations, but not multinomial
> combinations). The code essentially works, except that the the last
> combination in each tuple is not enclosed in a nested tuple:
>
> In [2]: x= multinomial_combinations(range(7),[2,1,2])
>
> In [3]: x.next()
> Out[3]: ((0, 1), (2,), 3, 4)
>
> (The 3 and 4 should be enclosed in a nested tuple).
>
> Any suggestions as to what I'm doing wrong will be appreciated. My code
> follows:
>
> def multinomial_combinations(items, ns):
>
> if len(ns) == 1:
> for c in itertools.combinations(items, ns[0]):
> yield c
>
> else:
> for c_first in itertools.combinations(items, ns[0]):
> items_remaining= set(items) - set(c_first)
> for c_other in multinomial_combinations(items_remaining, ns[1:]):
> yield (c_first,) + c_other
> --
> View this message in context:
http://old.nabble.com/multinomial-combinations-tp32503896p32503896.html
> Sent from the Python - python-list mailing list archive at Nabble.com.
>
> --
> http://mail.python.org/mailman/listinfo/python-list
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: multinomial combinations

[Chris Rebert]

On Sat, Sep 24, 2011 at 12:06 AM, Dr. Phillip M. Feldman
 wrote:
>
> I wrote a small generator function that produces multinomial combinations.
> (Python's itertools module does ordinary combinations, but not multinomial
> combinations).  The code essentially works, except that the the last
> combination in each tuple is not enclosed in a nested tuple:
>
> In [2]: x= multinomial_combinations(range(7),[2,1,2])
>
> In [3]: x.next()
> Out[3]: ((0, 1), (2,), 3, 4)
>
> (The 3 and 4 should be enclosed in a nested tuple).
>
> Any suggestions as to what I'm doing wrong will be appreciated.  My code
> follows:
>
> def multinomial_combinations(items, ns):
>
>   if len(ns) == 1:
>      for c in itertools.combinations(items, ns[0]):
>         yield c

FWIW, changing the base case to:

if not ns:
yield ()

appears to fix the issue. (Disclaimer: Have not done additional testing.)

Cheers,
Chris

>   else:
>      for c_first in itertools.combinations(items, ns[0]):
>         items_remaining= set(items) - set(c_first)
>         for c_other in multinomial_combinations(items_remaining, ns[1:]):
>            yield (c_first,) + c_other
-- 
http://mail.python.org/mailman/listinfo/python-list

parse html to get tr content

[contro opinion]

here is my code:
import lxml.html
sfile='http://finance.yahoo.com/q/op?s=A+Options'
root=lxml.html.parse(sfile).getroot()
t = root.xpath("//table[@class='yfnc_datamodoutline1']")[0]
trs=t.xpath(".//tr")
for  i, tr  in  enumerate(trs):
print (i, len(tr),tr.text_content())

the output is:
0 1 StrikeSymbolLastChgBidAskVolOpen Int25.00A111022C0002500010.70
0.007.007.4531528.00A111022C000280004.35
0.004.654.7520121029.00A111022C000290003.80
0.003.954.0542642530.00A111022C00033.110.013.253.35559731.00A111022C000310002.700.162.662.71740732.00A111022C000320002.110.082.122.17236433.00A111022C000330001.870.311.651.702956834.00A111022C000340001.360.151.261.302664935.00A111022C00035.960.040.940.984547736.00A111022C00036.720.120.690.724378637.00A111022C00037.510.030.490.52511,43538.00A111022C00038.35
0.000.340.354429339.00A111022C00039.16
0.000.220.26914940.00A111022C00040.180.030.150.185330141.00A111022C00041.33
0.000.100.14218442.00A111022C00042.08
0.000.060.10314745.00A111022C00045.10 0.000.010.05200243
1 8 StrikeSymbolLastChgBidAskVolOpen Int
2 8 25.00A111022C0002500010.70 0.007.007.45315
3 8 28.00A111022C000280004.35 0.004.654.75201210
4 8 29.00A111022C000290003.80 0.003.954.05426425
5 8 30.00A111022C00033.110.013.253.355597
6 8 31.00A111022C000310002.700.162.662.717407
7 8 32.00A111022C000320002.110.082.122.172364
8 8 33.00A111022C000330001.870.311.651.7029568
9 8 34.00A111022C000340001.360.151.261.3026649
10 8 35.00A111022C00035.960.040.940.9845477
11 8 36.00A111022C00036.720.120.690.7243786
12 8 37.00A111022C00037.510.030.490.52511,435
13 8 38.00A111022C00038.35 0.000.340.3544293
14 8 39.00A111022C00039.16 0.000.220.269149
15 8 40.00A111022C00040.180.030.150.1853301
16 8 41.00A111022C00041.33 0.000.100.142184
17 8 42.00A111022C00042.08 0.000.060.103147
18 8 45.00A111022C00045.10 0.000.010.05200243

i want to know  why  i=0  the  tr.text_content()'s  value  is :
StrikeSymbolLastChgBidAskVolOpen Int25.00A111022C0002500010.70
0.007.007.4531528.00A111022C000280004.35
0.004.654.7520121029.00A111022C000290003.80
0.003.954.0542642530.00A111022C00033.110.013.253.35559731.00A111022C000310002.700.162.662.71740732.00A111022C000320002.110.082.122.17236433.00A111022C000330001.870.311.651.702956834.00A111022C000340001.360.151.261.302664935.00A111022C00035.960.040.940.984547736.00A111022C00036.720.120.690.724378637.00A111022C00037.510.030.490.52511,43538.00A111022C00038.35
0.000.340.354429339.00A111022C00039.16
0.000.220.26914940.00A111022C00040.180.030.150.185330141.00A111022C00041.33
0.000.100.14218442.00A111022C00042.08
0.000.060.10314745.00A111022C00045.10 0.000.010.05200243
it's  strannge thing for me to understand.
-- 
http://mail.python.org/mailman/listinfo/python-list

parse html:strange tr problem

[守株待兔]

here is my code:
import lxml.html
sfile='http://finance.yahoo.com/q/op?s=A+Options'
root=lxml.html.parse(sfile).getroot()
t = root.xpath("//table[@class='yfnc_datamodoutline1']")[0]
trs=t.xpath(".//tr")
for  i, tr  in  enumerate(trs):
print (i, len(tr),tr.text_content())

the output is:
0 1 StrikeSymbolLastChgBidAskVolOpen Int25.00A111022C0002500010.70 
0.007.007.4531528.00A111022C000280004.35 
0.004.654.7520121029.00A111022C000290003.80 
0.003.954.0542642530.00A111022C00033.110.013.253.35559731.00A111022C000310002.700.162.662.71740732.00A111022C000320002.110.082.122.17236433.00A111022C000330001.870.311.651.702956834.00A111022C000340001.360.151.261.302664935.00A111022C00035.960.040.940.984547736.00A111022C00036.720.120.690.724378637.00A111022C00037.510.030.490.52511,43538.00A111022C00038.35
 0.000.340.354429339.00A111022C00039.16 
0.000.220.26914940.00A111022C00040.180.030.150.185330141.00A111022C00041.33
 0.000.100.14218442.00A111022C00042.08 
0.000.060.10314745.00A111022C00045.10 0.000.010.05200243
1 8 StrikeSymbolLastChgBidAskVolOpen Int
2 8 25.00A111022C0002500010.70 0.007.007.45315
3 8 28.00A111022C000280004.35 0.004.654.75201210
4 8 29.00A111022C000290003.80 0.003.954.05426425
5 8 30.00A111022C00033.110.013.253.355597
6 8 31.00A111022C000310002.700.162.662.717407
7 8 32.00A111022C000320002.110.082.122.172364
8 8 33.00A111022C000330001.870.311.651.7029568
9 8 34.00A111022C000340001.360.151.261.3026649
10 8 35.00A111022C00035.960.040.940.9845477
11 8 36.00A111022C00036.720.120.690.7243786
12 8 37.00A111022C00037.510.030.490.52511,435
13 8 38.00A111022C00038.35 0.000.340.3544293
14 8 39.00A111022C00039.16 0.000.220.269149
15 8 40.00A111022C00040.180.030.150.1853301
16 8 41.00A111022C00041.33 0.000.100.142184
17 8 42.00A111022C00042.08 0.000.060.103147
18 8 45.00A111022C00045.10 0.000.010.05200243

i want to know  why  i=0  the  tr.text_content()'s  value  is :
StrikeSymbolLastChgBidAskVolOpen Int25.00A111022C0002500010.70 
0.007.007.4531528.00A111022C000280004.35 
0.004.654.7520121029.00A111022C000290003.80 
0.003.954.0542642530.00A111022C00033.110.013.253.35559731.00A111022C000310002.700.162.662.71740732.00A111022C000320002.110.082.122.17236433.00A111022C000330001.870.311.651.702956834.00A111022C000340001.360.151.261.302664935.00A111022C00035.960.040.940.984547736.00A111022C00036.720.120.690.724378637.00A111022C00037.510.030.490.52511,43538.00A111022C00038.35
 0.000.340.354429339.00A111022C00039.16 
0.000.220.26914940.00A111022C00040.180.030.150.185330141.00A111022C00041.33
 0.000.100.14218442.00A111022C00042.08 
0.000.060.10314745.00A111022C00045.10 0.000.010.05200243
it's  strannge thing for me to understand.-- 
http://mail.python.org/mailman/listinfo/python-list

multinomial combinations

[Dr. Phillip M. Feldman]

I wrote a small generator function that produces multinomial combinations. 
(Python's itertools module does ordinary combinations, but not multinomial
combinations).  The code essentially works, except that the the last
combination in each tuple is not enclosed in a nested tuple:

In [2]: x= multinomial_combinations(range(7),[2,1,2])

In [3]: x.next()
Out[3]: ((0, 1), (2,), 3, 4)

(The 3 and 4 should be enclosed in a nested tuple).

Any suggestions as to what I'm doing wrong will be appreciated.  My code
follows:

def multinomial_combinations(items, ns):

   if len(ns) == 1:
  for c in itertools.combinations(items, ns[0]):
 yield c

   else:
  for c_first in itertools.combinations(items, ns[0]):
 items_remaining= set(items) - set(c_first)
 for c_other in multinomial_combinations(items_remaining, ns[1:]):
yield (c_first,) + c_other
-- 
View this message in context: 
http://old.nabble.com/multinomial-combinations-tp32503896p32503896.html
Sent from the Python - python-list mailing list archive at Nabble.com.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: random.randint() slow, esp in Python 3

[Steven D'Aprano]

Chris Angelico wrote:

> On Fri, Sep 23, 2011 at 4:14 AM, Steven D'Aprano
>  wrote:
>> What makes you think it's in C? I don't have Python 3.3a, but in 3.2 the
>> random module is mostly Python. There is an import of _random, which
>> presumably is in C, but it doesn't have a randint method:
> 
> True. It seems to be defined in cpython/lib/random.py as a reference
> to randrange, which does a pile of error checking and calls
> _randbelow... which does a whole lot of work as well as calling
> random(). Guess I should have checked the code before asking!
> 
> There's probably good reasons for using randint(), 

If you want unbiased, random (or at least pseudo-random) integers chosen
from an uniform distribution with proper error checking, you should use
randint or randrange.


> but if you just 
> want a pile of more-or-less random integers, int(random.random()*top)
> is the best option.

"I only need random-ish ints, but I need 'em yesterday!!!"

If you want biased, not-quite-uniformly distributed integers with no error
checking, then the above will save you a few nanoseconds per call. So if
your application needs a million such ints, you might save a full five
seconds or so. Sounds like premature optimization to me, but what do I
know? If you have an application where the quality of randomness is
unimportant and generating random ints is a genuine performance bottleneck,
then go right ahead.



>> I'm not seeing any significant difference in speed between 2.6 and 3.2:
>>
>> [steve@sylar ~]$ python2.6 -m timeit -s "from random import
>> randint" "randint(0, 100)"
>> 10 loops, best of 3: 4.29 usec per loop
>>
>> [steve@sylar ~]$ python3.2 -m timeit -s "from random import
>> randint" "randint(0, 100)"
>> 10 loops, best of 3: 4.98 usec per loop
> 
> That might be getting lost in the noise. Try the list comp that I had 
> above and see if you can see a difference - or anything else that
> calls randint that many times.

If you want to measure the speed of randint, you should measure the speed of
randint. That's what the timeit call does: it calls randint 10 times.

You can't measure the speed of:

[random.randint(0,sz*10-1) for i in range(sz)]

and draw conclusions about randint alone. Roughly speaking, you are
measuring the time taken to:

lookup range
lookup sz, twice
call range, possibly generating a massive list
iterate over the list/range object
lookup random
lookup random.randint
multiply sz by 10 and subtract 1
build a list of the results, repeatedly resizing it as you go

(in no particular order)

There is MUCH more noise in your suggestion, not my version. But for what
it's worth, I get these results:

[steve@sylar ~]$ python3.2 -m timeit -s "import random" -s "sz =
100" "[random.randint(0,sz*10-1) for i in range(sz)]"
10 loops, best of 3: 6.09 sec per loop
[steve@sylar ~]$ python2.6 -m timeit -s "import random" -s "sz =
100" "[random.randint(0,sz*10-1) for i in range(sz)]"
10 loops, best of 3: 4.67 sec per loop

So Python 3.2 is about 30% slower for the whole mess. (I would, however,
give little confidence in those results: at 4-6 seconds per loop, I expect
that OS-level noise will be significant.)

For what (little) it's worth, it seems that Python 3.2 should be a bit
faster than 2.6, at least if you consider the Pystone benchmark to mean
anything.

http://www.levigross.com/post/2340736877/pystone-benchmark-on-2-6-2-7-3-2




> Performance-testing with a heapsort (and by the way, it's
> _ridiculously_ slower implementing it in Python instead of just
> calling a.sort(), but we all knew that already!) shows a similar
> difference in performance.

You do know that Python's heap implementation is written in C? Don't be
fooled by the heapq module being in Python. About 2/3rds of the way down,
there's a sneaky little trick:

# If available, use C implementation
try:
from _heapq import *
except ImportError:
pass


-- 
Steven

-- 
http://mail.python.org/mailman/listinfo/python-list