yes, +1 for IntFloatNoneButNotStrangeNans as well. It seems like the best
we can do, and it probably covers 99.9% of the real world use cases
On Fri, Nov 15, 2013 at 8:07 AM, Maciej Fijalkowski wrote:
> On Thu, Nov 14, 2013 at 11:07 PM, Armin Rigo wrote:
> > Hi Antonio,
> >
> > On Thu, Nov 14,
On Thu, Nov 14, 2013 at 11:07 PM, Armin Rigo wrote:
> Hi Antonio,
>
> On Thu, Nov 14, 2013 at 2:35 PM, Antonio Cuni wrote:
>> W_FloatObjectPresevingTheBits will be created only by operations like
>> struct.unpack, cffi.cast, etc.
>
> That's not enough: if you read one such float into a variable a
Hi Antonio,
On Thu, Nov 14, 2013 at 2:35 PM, Antonio Cuni wrote:
> W_FloatObjectPresevingTheBits will be created only by operations like
> struct.unpack, cffi.cast, etc.
That's not enough: if you read one such float into a variable and then
append that variable into another list, then the other
Hi Eli,
On Thu, Nov 14, 2013 at 9:31 PM, Eli Stevens (Gmail)
wrote:
> From http://en.wikipedia.org/wiki/NaN#Encoding :
>
> "The state/value of the remaining bits (i.e. other than the ones used
> to identify a NaN as NaN, including the quiet/signaled bits) are not
> defined by the standard except
>From http://en.wikipedia.org/wiki/NaN#Encoding :
"The state/value of the remaining bits (i.e. other than the ones used
to identify a NaN as NaN, including the quiet/signaled bits) are not
defined by the standard except that they must not be all zero. This
value is called the 'payload' of the NaN.
On 14/11/13 10:57, Armin Rigo wrote:
Bah, there is another issue. The following code happens to work right now:
x, = struct.unpack("d", "ABCDxx\xff\x7f")
y = struct.pack("d", x)
assert y == "ABCDxx\xff\x7f"
This works even though x happens to be a NaN; its bit pattern is
preser
Hi Laurence,
On Thu, Nov 14, 2013 at 10:47 AM, Laurence Tratt wrote:
> I think that question can only really be answered by trying it out and seeing
> what the benchmarks say. My guess is that you still want both, but if people
> mix ints and floats even more often than I think they do, it may be
On Thu, Nov 14, 2013 at 09:30:21AM +0100, Armin Rigo wrote:
Hi Armin,
> Yes, but the question is whether we want both FloatIntegerListStrategy and
> FloatListStrategy. The same arguments apply about the JIT not needing to
> check the value of a float grabbed out of the list in the FloatListStrat
Hi,
On Wed, Nov 13, 2013 at 8:35 AM, Maciej Fijalkowski wrote:
>> So, if we decide
>> to do this, I think we would still want IntegerListStrategy
>
> Yes, we want both.
Yes, but the question is whether we want both FloatIntegerListStrategy
and FloatListStrategy. The same arguments apply about t
On Wed, Nov 13, 2013 at 2:01 AM, Laurence Tratt wrote:
> On Tue, Nov 12, 2013 at 09:48:23AM +0100, Armin Rigo wrote:
>
> Hi Armin,
>
>> Ok, but then it seems that the first problem we hit down this road, before
>> arriving at the __contains__ performance, is actually mixing ints and
>> floats in t
On Tue, Nov 12, 2013 at 09:48:23AM +0100, Armin Rigo wrote:
Hi Armin,
> Ok, but then it seems that the first problem we hit down this road, before
> arriving at the __contains__ performance, is actually mixing ints and
> floats in the same list. We need to do something to store such lists
> effi
Hi Laurence,
On Fri, Nov 8, 2013 at 5:28 PM, Laurence Tratt wrote:
> my experience, Python programs that nominally use floats actually end up
> slinging lots of integers around since very few people can be bothered to
> write "x = 1.0" instead of "x = 1". I expect the other types are similarly
>
On Fri, Nov 08, 2013 at 10:19:30AM +0100, Armin Rigo wrote:
> I fear a bit that *all* cases are on the clearly nonsense side of things.
> I don't particularly think there is code out there that would see any
> speed-ups using these cases. As Amaury pointed out this introduces
> delicate correctne
Hi,
On Fri, Nov 8, 2013 at 12:14 AM, William ML Leslie
wrote:
> I wonder a bit if it is worth introducing additional fast paths for
> clearly nonsense (eg, string) cases, when it's the sensible case
> (user-provided types that provide __eq__) that we should be optimising
> for. Did you menchbark
On 8 November 2013 09:18, Laurence Tratt wrote:
> Looking up floats and longs is
> now much faster; for many other types (e.g. strings or user objects whose
> class does not override __eq__) these return immediately.
I wonder a bit if it is worth introducing additional fast paths for
clearly nons
int(f) == f should be correct.
Alex
On Thu, Nov 7, 2013 at 2:51 PM, Laurence Tratt wrote:
> On Thu, Nov 07, 2013 at 11:42:47PM +0100, Amaury Forgeot d'Arc wrote:
>
> > Hum, [1,2,3].__contains__(1.9)?
>
> Good point. This is something I clearly got wrong.
>
> Is there a practical way to tell if
On Thu, Nov 07, 2013 at 11:42:47PM +0100, Amaury Forgeot d'Arc wrote:
> Hum, [1,2,3].__contains__(1.9)?
Good point. This is something I clearly got wrong.
Is there a practical way to tell if a float could ever compare True to an
integer? I suppose I could convert it to an int, and do a compariso
2013/11/7 Laurence Tratt
> The patch itself is here:
>
>
> https://bitbucket.org/pypy/pypy/commits/599ed4285a6de348c7e7e732e303336d3160ce78
>
Hum, [1,2,3].__contains__(1.9)?
--
Amaury Forgeot d'Arc
___
pypy-dev mailing list
pypy-dev@python.org
https
On Thu, Nov 07, 2013 at 02:30:21PM -0800, Alex Gaynor wrote:
> What is t1 in this context? That's a pretty dramatic slow-down, so I'd like
> to understand it better.
And here's the point where I realise I didn't attach the benchmarks. Mea
culpa. Attached this time (with luck).
Laurie
import tim
What is t1 in this context? That's a pretty dramatic slow-down, so I'd like
to understand it better.
Alex
On Thu, Nov 7, 2013 at 2:18 PM, Laurence Tratt wrote:
> I've been fiddling with extending some of the strategies in PyPy. My first
> port of call has been to provide fast paths in IntegerL
I've been fiddling with extending some of the strategies in PyPy. My first
port of call has been to provide fast paths in IntegerListStrategy.find,
which is the basis of "x in l" and "l.index(x)". Previously this was very
fast if you looked up an integer, but rather slow if you tried up looking
any
21 matches
Mail list logo
