On Mon, Oct 16, 2017 at 08:40:33AM +0200, Stephan Houben wrote:
> "The problem is that Python returns time as a floatting point number
> > which is usually a 64-bit binary floatting number (in the IEEE 754
> > format). This type starts to loose nanoseconds after 104 days."
> >
> >
> Do we realize t
Hi all,
I realize this is a bit of a pet peeve of me, since
in my day job I sometimes get people complaining that
numerical data is "off" in the sixteenth significant digit
(i.e. it was stored as a double).
I have a bunch of favorite comparisons to make this clear
how accurate a "double" really i
2017-10-16 3:19 GMT+02:00 Juancarlo Añez :
> It could be: time.time(ns=True)
Please read my initial message:
"""
[PEP 410] was rejected for different reasons:
(...)
* Guido van Rossum rejected the idea of adding a new optional
parameter to change the result type: it's an uncommon programming
pr
Hi,
> What if we had a class, say time.time_base. The user could specify the base
> units (such as "s", "ns", 1e-7, etc) and the data type ('float', 'int',
> 'decimal', etc.) when the class is initialized. (...)
It's easy to invent various funny new types for arbitrary precision.
But I prefer r
On Sun, 15 Oct 2017 22:00:10 -0700
Guido van Rossum wrote:
> On Sun, Oct 15, 2017 at 8:40 PM, Nick Coghlan wrote:
>
> > Hopefully by the time we decide it's worth worrying about picoseconds in
> > "regular" code, compiler support for decimal128 will be sufficiently
> > ubiquitous that we'll be a
I'm completely +1 to Victor.
nanosecond integer timestamp is used these days.
And no complex newtype or newmodule is not needed for supporting it.
INADA Naoki
On Fri, Oct 13, 2017 at 11:12 PM, Victor Stinner
wrote:
> Hi,
>
> I would like to add new functions to return time as a number of
> n
On Mon, Oct 16, 2017 at 2:44 AM, Guido van Rossum wrote:
> Sorry, that's an in-joke. Koos is expressing his disappointment in the
> rejection of PEP 555 in a way that's only obvious if you're Dutch.
>
>
Hmm, or more accurately, it has to do with me going crazy because of the
frustration of how th
Stephan Houben wrote:
Do we realize that at this level of accuracy, relativistic time
dilatation due to continental drift starts to matter?
Probably also want an accurate GPS position for your computer
so that variations in the local gravitational field can be
taken into account.
--
Greg
w/r relativistic effects and continental drift - not really. The speed is
about 1cm/yr or v = 1e-18 c. Relativistic effect would go like 0.5 *
(v/c)**2, so more like 5E-37 in relative rate of proper time. You can just
barely capture a few minutes of that even with int128 resolution. As for
fina
> Interestingly, thinking about the problem in terms of exception handling
> flow reminded me of the fact that having a generator-iterator yield while
> inside a with statement or try/except block is already considered an
> anti-pattern in many situations, precisely because it means that any
> exce
Hi,
FYI I proposed the PEP 564 directly on python-dev.
The paragraph about "picosecond":
https://www.python.org/dev/peps/pep-0564/#sub-nanosecond-resolution
Let's move the discussion on python-dev ;-)
Victor
___
Python-ideas mailing list
Python-ideas
On 16 October 2017 at 21:08, Juancarlo Añez wrote:
>
> Interestingly, thinking about the problem in terms of exception handling
>> flow reminded me of the fact that having a generator-iterator yield while
>> inside a with statement or try/except block is already considered an
>> anti-pattern in m
Stephan Houben wrote:
Interestingly, that 2.2e-16 pretty much aligns with the accuracy of the
cesium atomic clocks which are currently used to *define* the second.
So we move to this new API, we should provide our own definition
of the second, since those rough SI seconds are just too imprecise
2017-10-16 9:46 GMT+02:00 Stephan Houben :
> Hi all,
>
> I realize this is a bit of a pet peeve of me, since
> in my day job I sometimes get people complaining that
> numerical data is "off" in the sixteenth significant digit
> (i.e. it was stored as a double).
> (...)
Oh. As usual, I suck at expl
Hi,
FYI I proposed the PEP 564 on python-dev.
"PEP 564 -- Add new time functions with nanosecond resolution"
https://www.python.org/dev/peps/pep-0564/
Victor
___
Python-ideas mailing list
[email protected]
https://mail.python.org/mailman/listinfo
On 2017-10-16 13:30, Greg Ewing wrote:
Stephan Houben wrote:
Interestingly, that 2.2e-16 pretty much aligns with the accuracy of the
cesium atomic clocks which are currently used to *define* the second.
So we move to this new API, we should provide our own definition
of the second, since those
On Mon, Oct 16, 2017 at 4:10 PM, Victor Stinner
wrote:
> 2017-10-16 9:46 GMT+02:00 Stephan Houben :
> > Hi all,
> >
> > I realize this is a bit of a pet peeve of me, since
> > in my day job I sometimes get people complaining that
> > numerical data is "off" in the sixteenth significant digit
> >
Sorry about your frustration. I should not have given you hope about PEP
555 -- it was never going to make it, so I should just have spared you the
effort. Do you want to withdraw it or do I have to actually reject it?
On Mon, Oct 16, 2017 at 1:56 AM, Koos Zevenhoven wrote:
> On Mon, Oct 16, 201
On Mon, Oct 16, 2017 at 3:58 AM, Victor Stinner
wrote:
> Hi,
>
> > What if we had a class, say time.time_base. The user could specify the
> base
> > units (such as "s", "ns", 1e-7, etc) and the data type ('float', 'int',
> > 'decimal', etc.) when the class is initialized. (...)
>
> It's easy to
On 2017-10-16 16:42, MRAB wrote:
> On 2017-10-16 13:30, Greg Ewing wrote:
>> Stephan Houben wrote:
>>
>>> Interestingly, that 2.2e-16 pretty much aligns with the accuracy of the
>>> cesium atomic clocks which are currently used to *define* the second.
>>> So we move to this new API, we should provi
2017-10-16 18:13 GMT+02:00 Todd :
> I am not suggesting implementing a new numeric data type. People wouldn't
> use the class directly like they would an int or float, they would simply
> use it to define the the precision and numeric type (float, int, decimal).
> Then they would have access to th
I agree, we shouldn't pursue Todd's proposal. It's too complicated, for too
little benefit.
On Mon, Oct 16, 2017 at 9:49 AM, Victor Stinner
wrote:
> 2017-10-16 18:13 GMT+02:00 Todd :
> > I am not suggesting implementing a new numeric data type. People
> wouldn't
> > use the class directly like
I recently came across a bug where checking negative membership (__contains__
returns False) of an infinite iterator will freeze the program.
It may seem a bit obvious, but you can check membership in range for example
without iterating over the entire range.
`int(1e100) in range(int(1e101))`
On Mon, Oct 16, 2017 at 6:12 PM, Guido van Rossum wrote:
> Sorry about your frustration. I should not have given you hope about PEP
> 555 -- it was never going to make it, so I should just have spared you the
> effort. Do you want to withdraw it or do I have to actually reject it?
>
>
That's def
On 10/15/2017 9:12 PM, Jason Campbell wrote:
I recently came across a bug where checking negative membership
(__contains__ returns False) of an infinite iterator will freeze the
program.
It may seem a bit obvious, but you can check membership in range for
example without iterating over the e
בתאריך יום ג׳, 17 באוק׳ 2017, 00:13, מאת Terry Reedy :
> On 10/15/2017 9:12 PM, Jason Campbell wrote:
> ...
> > itertools.cycle could use membership from the underlying iterable
>
> If the underlying iterable is an iterator, this does not work. You
> could define a Cycle class that requires that
Paul Moore writes:
> But I do agree with MAL, it seems wrong to need a helper for this,
> even though it's a logical consequence of the other semantics I
> described as intuitive :-(
It seems to me this is an argument for using Haskell if you want life
to be simple. :-)
Or, in the spirit of t
Given that:
- it doesn't break anything;
- the behavior makes sense;
- it can avoid the machine freezing when one is not careful;
It can be a good idea.
Those generators could have iterators that are not themselves and have a
__contains__ method behaving accordingly.
I only did the mistake of u
On 16 October 2017 at 11:12, Jason Campbell wrote:
> I recently came across a bug where checking negative membership
> (__contains__ returns False) of an infinite iterator will freeze the
> program.
>
> It may seem a bit obvious, but you can check membership in range for
> example without iterati
On 17 October 2017 at 16:32, Nick Coghlan wrote:
> So this sounds like a reasonable API UX improvement to me, but you'd need
> to ensure that you don't inadvertently change the external behaviour of
> *successful* containment tests.
>
I should also note that there's another option here beyond ju
30 matches
Mail list logo
