On 24/04/2013 02:59, Steven D'Aprano wrote:
> On Tue, 23 Apr 2013 17:57:17 +0100, Blind Anagram wrote:
[snip]
> In my opinion, it is more important to be efficient for large sieves, not
> small. As they say, for small N, everything is fast. Nobody is going to
> care about the difference between
On Tue, 23 Apr 2013 17:57:17 +0100, Blind Anagram wrote:
> On 23/04/2013 15:49, Steven D'Aprano wrote:
>> On Tue, 23 Apr 2013 08:05:53 +0100, Blind Anagram wrote:
>>
>>> I did a lot of work comparing the overall performance of the sieve
>>> when using either lists or arrays and I found that lists
On 23/04/2013 21:00, Terry Jan Reedy wrote:
> On 4/23/2013 12:57 PM, Blind Anagram wrote:
>
>> So, all I was doing in asking for advice was to check whether there is
>> an easy way of avoiding the slice copy,
>
> And there is.
>
>> not because this is critical,
>> but rather because it is a pity
On 23 April 2013 21:00, Terry Jan Reedy wrote:
>
> That said, I do see that tuple/list.index have had start, stop paramaters
> added, so doing the same for .count is conceivable.
Are those new? I don't remember them not being there.
You need the start/stop parameters to be able to use index for
On 4/23/2013 12:57 PM, Blind Anagram wrote:
So, all I was doing in asking for advice was to check whether there is
an easy way of avoiding the slice copy,
And there is.
not because this is critical,
but rather because it is a pity to limit the performance because Python
forces a (strictly un
On 23 April 2013 19:30, Blind Anagram wrote:
> On 23/04/2013 18:45, Oscar Benjamin wrote:
>
> [snip]
>> You keep mentioning that you want it to work with a large sieve. I
>> would much rather compute the same quantities with a small sieve if
>> possible. If you were using the Lehmer/Meissel algori
On 4/23/2013 7:45 AM, Blind Anagram wrote:
I then wondered why count for lists has no limits
Probably because no one has asked for such, as least partly because it
is not really needed. In any case, .count(s) is a generic method. It is
part of the definition of a Sequence. It can also be imp
On 23/04/2013 18:45, Oscar Benjamin wrote:
I did a lot of work comparing the overall performance of the sieve when
using either lists or arrays and I found that lists were a lot faster
for the majority use case when the sieve is not large.
>>>
>>> And when the sieve is large?
>>
>>
On 23 April 2013 17:57, Blind Anagram wrote:
> On 23/04/2013 15:49, Steven D'Aprano wrote:
>> On Tue, 23 Apr 2013 08:05:53 +0100, Blind Anagram wrote:
>>
>>> I did a lot of work comparing the overall performance of the sieve when
>>> using either lists or arrays and I found that lists were a lot f
On 23/04/2013 15:49, Steven D'Aprano wrote:
> On Tue, 23 Apr 2013 08:05:53 +0100, Blind Anagram wrote:
>
>> I did a lot of work comparing the overall performance of the sieve when
>> using either lists or arrays and I found that lists were a lot faster
>> for the majority use case when the sieve i
On Tue, 23 Apr 2013 08:05:53 +0100, Blind Anagram wrote:
> I did a lot of work comparing the overall performance of the sieve when
> using either lists or arrays and I found that lists were a lot faster
> for the majority use case when the sieve is not large.
And when the sieve is large?
I don't
On 23/04/2013 12:08, Oscar Benjamin wrote:
> On 23 April 2013 08:05, Blind Anagram wrote:
>> On 23/04/2013 00:01, Steven D'Aprano wrote:
>>> On Mon, 22 Apr 2013 15:15:19 +0100, Blind Anagram wrote:
>>>
But when using a sub-sequence, I do suffer a significant reduction in
speed for a coun
On 23 April 2013 08:05, Blind Anagram wrote:
> On 23/04/2013 00:01, Steven D'Aprano wrote:
>> On Mon, 22 Apr 2013 15:15:19 +0100, Blind Anagram wrote:
>>
>>> But when using a sub-sequence, I do suffer a significant reduction in
>>> speed for a count when compared with count on the full list. When
On 23/04/2013 00:01, Steven D'Aprano wrote:
> On Mon, 22 Apr 2013 15:15:19 +0100, Blind Anagram wrote:
>
>> But when using a sub-sequence, I do suffer a significant reduction in
>> speed for a count when compared with count on the full list. When the
>> list is small enough not to cause memory al
On 23/04/2013 02:47, Dave Angel wrote:
> On 04/22/2013 05:32 PM, Blind Anagram wrote:
>> On 22/04/2013 22:03, Oscar Benjamin wrote:
>>> On 22 April 2013 21:18, Oscar Benjamin
>>> wrote:
On 22 April 2013 17:38, Blind Anagram wrote:
> On 22/04/2013 17:06, Oscar Benjamin wrote:
>
>>
On 23/04/2013 00:28, Steven D'Aprano wrote:
> On Mon, 22 Apr 2013 22:25:50 +0100, Blind Anagram wrote:
>
>> I have looked at solutions based on listing primes and here I have found
>> that they are very much slower than my existing solution when the sieve
>> is not large (which is the majority use
On 23/04/2013 00:06, Oscar Benjamin wrote:
> On 22 April 2013 22:25, Blind Anagram wrote:
>> On 22/04/2013 21:18, Oscar Benjamin wrote:
>>> On 22 April 2013 17:38, Blind Anagram wrote:
>>
>> I also wondered whether I had missed any obvious way of avoiding the
>> slicing cost (intellectually it se
On 04/22/2013 05:32 PM, Blind Anagram wrote:
On 22/04/2013 22:03, Oscar Benjamin wrote:
On 22 April 2013 21:18, Oscar Benjamin wrote:
On 22 April 2013 17:38, Blind Anagram wrote:
On 22/04/2013 17:06, Oscar Benjamin wrote:
I don't know what your application is but I would say that my first
On Mon, 22 Apr 2013 22:25:50 +0100, Blind Anagram wrote:
> I have looked at solutions based on listing primes and here I have found
> that they are very much slower than my existing solution when the sieve
> is not large (which is the majority use case).
Yes. This is hardly surprising. Algorithms
On 22 April 2013 22:25, Blind Anagram wrote:
> On 22/04/2013 21:18, Oscar Benjamin wrote:
>> On 22 April 2013 17:38, Blind Anagram wrote:
>
> I also wondered whether I had missed any obvious way of avoiding the
> slicing cost (intellectually it seemed wrong to me to have to copy the
> list in ord
On Mon, 22 Apr 2013 15:15:19 +0100, Blind Anagram wrote:
> But when using a sub-sequence, I do suffer a significant reduction in
> speed for a count when compared with count on the full list. When the
> list is small enough not to cause memory allocation issues this is about
> 30% on 100,000,000
On 22/04/2013 22:03, Oscar Benjamin wrote:
> On 22 April 2013 21:18, Oscar Benjamin wrote:
>> On 22 April 2013 17:38, Blind Anagram wrote:
>>> On 22/04/2013 17:06, Oscar Benjamin wrote:
>>>
I don't know what your application is but I would say that my first
port of call here would be to
On 22/04/2013 21:18, Oscar Benjamin wrote:
> On 22 April 2013 17:38, Blind Anagram wrote:
[snip]
> If my description is correct then I would definitely consider using a
> different algorithmic approach. The density of primes from 1 to 1
> billlion is about 5%. Storing the prime numbers themselve
On 22 April 2013 21:18, Oscar Benjamin wrote:
> On 22 April 2013 17:38, Blind Anagram wrote:
>> On 22/04/2013 17:06, Oscar Benjamin wrote:
>>
>>> I don't know what your application is but I would say that my first
>>> port of call here would be to consider a different algorithmic
>>> approach. An
On 22 April 2013 17:38, Blind Anagram wrote:
> On 22/04/2013 17:06, Oscar Benjamin wrote:
>
>> I don't know what your application is but I would say that my first
>> port of call here would be to consider a different algorithmic
>> approach. An obvious question would be about the sparsity of this
On 22/04/2013 18:48, Skip Montanaro wrote:
>> But I was really wondering if there was a simple solution that worked
>> without people having to add libraries to their basic Python installations.
>
> I think installing numpy is approximately
>
> pip install numpy
>
> assuming you have write a
> But I was really wondering if there was a simple solution that worked
> without people having to add libraries to their basic Python installations.
I think installing numpy is approximately
pip install numpy
assuming you have write access to your site-packages directory. If
not, install u
On 22/04/2013 17:06, Oscar Benjamin wrote:
> On 22 April 2013 16:50, Blind Anagram wrote:
>>>
>>> It would be very easy to subclass list and add this functionality in
>>> cython if you decide that you do need a builtin method.
> [snip]
>>
>> But I was really wondering if there was a simple solutio
On 22 April 2013 16:50, Blind Anagram wrote:
>>
>> It would be very easy to subclass list and add this functionality in
>> cython if you decide that you do need a builtin method.
[snip]
>
> But I was really wondering if there was a simple solution that worked
> without people having to add librari
On 22/04/2013 16:14, Oscar Benjamin wrote:
> On 22 April 2013 15:15, Blind Anagram wrote:
>> On 22/04/2013 14:13, Steven D'Aprano wrote:
>>> On Mon, 22 Apr 2013 12:58:20 +0100, Blind Anagram wrote:
>>>
I would be grateful for any advice people can offer on the fastest way
to count items
On 22 April 2013 15:15, Blind Anagram wrote:
> On 22/04/2013 14:13, Steven D'Aprano wrote:
>> On Mon, 22 Apr 2013 12:58:20 +0100, Blind Anagram wrote:
>>
>>> I would be grateful for any advice people can offer on the fastest way
>>> to count items in a sub-sequence of a large list.
>>>
>>> I have
On 22/04/2013 14:13, Steven D'Aprano wrote:
> On Mon, 22 Apr 2013 12:58:20 +0100, Blind Anagram wrote:
>
>> I would be grateful for any advice people can offer on the fastest way
>> to count items in a sub-sequence of a large list.
>>
>> I have a list of boolean values that can contain many hundre
Numpy is a big improvement here. In Py 2.7 I get this output if I run
Steven's benchmark:
2.10364603996
3.68471002579
4.01849389076
7.41974878311
10.4202470779
9.16782712936
3.36137390137
(confirming his results). If I then run the numpy idiom for this:
import random
f
Blind Anagram於 2013年4月22日星期一UTC+8下午7時58分20秒寫道：
> I would be grateful for any advice people can offer on the fastest way
>
> to count items in a sub-sequence of a large list.
>
>
>
> I have a list of boolean values that can contain many hundreds of
>
> millions of elements for which I want to c
Blind Anagram wrote:
> I would be grateful for any advice people can offer on the fastest way
> to count items in a sub-sequence of a large list.
>
> I have a list of boolean values that can contain many hundreds of
> millions of elements for which I want to count the number of True values
> in a
On Mon, 22 Apr 2013 12:58:20 +0100, Blind Anagram wrote:
> I would be grateful for any advice people can offer on the fastest way
> to count items in a sub-sequence of a large list.
>
> I have a list of boolean values that can contain many hundreds of
> millions of elements for which I want to co
On 22/04/2013 13:51, Dave Angel wrote:
> On 04/22/2013 07:58 AM, Blind Anagram wrote:
>> I would be grateful for any advice people can offer on the fastest way
>> to count items in a sub-sequence of a large list.
>>
>> I have a list of boolean values that can contain many hundreds of
>> millions of
On 04/22/2013 07:58 AM, Blind Anagram wrote:
I would be grateful for any advice people can offer on the fastest way
to count items in a sub-sequence of a large list.
I have a list of boolean values that can contain many hundreds of
millions of elements for which I want to count the number of Tru
I would be grateful for any advice people can offer on the fastest way
to count items in a sub-sequence of a large list.
I have a list of boolean values that can contain many hundreds of
millions of elements for which I want to count the number of True values
in a sub-sequence, one from the start
39 matches
Mail list logo
