Dear list!
I noticed that integer division (`//`) is slower than floating-point
division and integer cast. For example:
from __future__ import division
from time import time
t = time()
for i in range(1, 1):
for j in range(1, 1):
# k = i//j # 2.12 second
Created at https://bitbucket.org/pypy/pypy/issues/2563/slow-round
Thank you for the explanation!
On Fri, May 26, 2017 at 10:34 PM, Armin Rigo wrote:
> Hi Tuom,
>
> On 26 May 2017 at 19:04, Tuom Larsen wrote:
>> I noticed that `round` seem to run very slow. Is this a known issue
Dear list!
I noticed that `round` seem to run very slow. Is this a known issue or
should I file an bug report? Or am I missing something?
from timeit import timeit
print timeit('int(sqrt(123.456)+0.5)', 'from math import sqrt')
print timeit('int(round(sqrt(123.456)))', 'from math impo
anks for the report!
>
> Cheers,
>
> Carl Friedrich
>
>
> On 26/09/16 22:57, Tuom Larsen wrote:
>> Dear list!
>>
>> I stumbled upon a problem and I was wondering if someone would by so
>> kind and explain to me what is going on.
>>
>> The pr
igger/smaller lists to see how they
> behave. (also warming up both jit engines might be necessary)
>
>
> On Mon, Sep 26, 2016 at 10:57 PM, Tuom Larsen wrote:
>>
>> Dear list!
>>
>> I stumbled upon a problem and I was wondering if someone would by so
>> kin
Dear list!
I stumbled upon a problem and I was wondering if someone would by so
kind and explain to me what is going on.
The problem is sorting 2 000 000 points by `x` coordinate:
from random import random
from time import time
class point(object):
def __init__(self, x, y):
> On Mon, Apr 4, 2016 at 3:53 PM, Tuom Larsen wrote:
>> So other than numpy, do you think:
>>
>> a[0] = (2**63 << 1) & (2**64 - 1)
>>
>> is the best way I can do?
>>
>> On Mon, Apr 4, 2016 at 3:52 PM, Tuom Larsen wrote:
>>> Yes, I
So other than numpy, do you think:
a[0] = (2**63 << 1) & (2**64 - 1)
is the best way I can do?
On Mon, Apr 4, 2016 at 3:52 PM, Tuom Larsen wrote:
> Yes, I just want to write code which is portable (as for example that
> `& ...`) but still favors PyPy.
>
> On M
t;> so numpy64 will give you wrap-around arithmetics. What else are you
>>> looking for? :-)
>>>
>>> On Mon, Apr 4, 2016 at 3:38 PM, Tuom Larsen wrote:
>>>> You mean I should first store the result into numpy's `int64`, and
>>>> then to `ar
ooking for? :-)
>
> On Mon, Apr 4, 2016 at 3:38 PM, Tuom Larsen wrote:
>> You mean I should first store the result into numpy's `int64`, and
>> then to `array.array`? Like:
>>
>> x = int64(2**63 << 1)
>> a[0] = x
>>
>> Or:
>>
c.
>
> Feel free to complain "no, I want real types that I can work with" :-)
>
> Cheers,
> fijal
>
> On Mon, Apr 4, 2016 at 3:10 PM, Tuom Larsen wrote:
>> Hello!
>>
>> Suppose I'm on 64-bit machine and there is an `a = arrar.array('L',
Hello!
Suppose I'm on 64-bit machine and there is an `a = arrar.array('L',
[0])` (item size is 8 bytes). In Python, when an integer does not fit
machine width it gets promoted to "long" integer of arbitrary size. So
this will fail:
a[0] = 2**63 << 1
To fix this, one could instead write:
Awesome, thank you!
On Tue, Oct 20, 2015 at 4:41 PM, Richard Plangger wrote:
> Hi,
>
> glad you liked the post! See the answers below...
>
> On 10/20/2015 04:20 PM, Tuom Larsen wrote:
>> Hello all!
>>
>> I just read with great interest the blog post "Auto
Hello all!
I just read with great interest the blog post "Automatic SIMD
vectorization support in PyPy".
Please, I have a few questions:
- Does regular Python code benefit from the vectorization? I mean, the
article on one hand says "it is not specifically targeted for the
NumPy library" but on
Dead list,
not sure if this is the right place to share but there is a
presentation by a Mozilla dev being currently discussed on Reddit
where PyPy received quite some praise:
https://www.reddit.com/r/golang/comments/3oztwi/from_python_to_go_and_back_again_mozilla_dev/
Cheers!
__
So I just tried it with the latest nightly build and `[:]` is now even
a bit faster than `list()`! Thank you once more!
On Tue, Sep 29, 2015 at 12:27 PM, Tuom Larsen wrote:
> Hi Armin,
>
> thanks a lot, both for the explanation and the fix! I will try it soon.
>
> Have a nic
can try the nightly?
>
> On Wed, Oct 7, 2015 at 2:14 PM, Tuom Larsen wrote:
>> Hello!
>>
>> I have a fairly long code here so I have yet to distill a short test
>> case but I started to get a crash in 2.6.0 (I never saw this kind of
>> error in earlier versions)
Hello!
I have a fairly long code here so I have yet to distill a short test
case but I started to get a crash in 2.6.0 (I never saw this kind of
error in earlier versions). Is there anything I can do to give you
more helpful information besides the following error message?
RPython traceback:
Fi
the heuristic to always trace a function that's the only one
> maybe though
>
> On Tue, Oct 6, 2015 at 7:32 PM, Tuom Larsen wrote:
>> Hello!
>>
>> I have a piece of auto-generated code and I noticed that if a function
>> has more than certain number of expressio
first line it drops to 5.3 seconds.
Thanks,
Tuom Larsen
def f(x):
a0 = x*0.1; a1 = x*0.1; a2 = x*0.2; a3 = x*0.3; a4 = x*0.4
a5 = x*0.5; a6 = x*0.6; a7 = x*0.7; a8 = x*0.8; a9 = x*0.9
b0 = x*0.1; b1 = x*0.1; b2 = x*0.2; b3 = x*0.3; b4 = x*0.4
b5 = x*0.5; b6 =
, thanks a lot once more!
On Tue, Sep 29, 2015 at 9:25 AM, Armin Rigo wrote:
> Hi Tuom,
>
> On Tue, Sep 29, 2015 at 7:31 AM, Tuom Larsen wrote:
>> Please, let me rephrase my question: currently I use `[:]` because it
>> is faster in CPython (0.131 usec vs 0.269 usec pe
Hello Armin,
Thanks for the answer!
On Mon, Sep 28, 2015 at 8:17 PM, Armin Rigo wrote:
>
> In addition to the other comments, this is not testing what you think
> it is: 'range(100)' returns a list optimized for being a range, and
> 'list(range(100))' does it too. You can see it like this:
>
>>
Dear PyPy developers!
In CPython, a common idiom to copy a list is to use slice, as in:
copy = original[:]
I noticed that under PyPy 2.6.0 it seems quite a bit slower than using
`list` constructor:
from timeit import timeit
print timeit('b = a[:]', 'a = list(range(100))')# 0.073
23 matches
Mail list logo
