Re: [Python-Dev] PEP 564: Add new time functions with nanosecond resolution
On 22/10/17 17:06, Wes Turner wrote: > There are current applications with greater-than nanosecond precision: > > - relativity experiments > - particle experiments > > Must they always use their own implementations of time., datetime. > __init__, fromordinal, fromtimestamp ?! > > - https://scholar.google.com/scholar?q=femtosecond > - https://scholar.google.com/scholar?q=attosecond > - GPS now supports nanosecond resolution > - Sure, but in these kinds of experiments you don't have a "timestamp" in the usual sense. You'll have some kind of high-precision "clock", but in most cases there's no way and no reason to synchronise this to wall time. You end up distinguishing between "macro-time" (wall time) and "micro-time" (time in the experiment relative to something) In a particle accelerator, you care about measuring relative times of almost-simultaneous detection events with extremely high precision. You'll also presumably have a timestamp for the event, but you won't be able or willing to measure that with anything like the same accuracy. While you might be able to say that you detected, say, a muon at 01:23:45.6789 at Δt=543.6ps*, you have femtosecond resolution, you have a timestamp, but you don't have a femtosecond timestamp. In ultrafast spectroscopy, we get a time resolution equal to the duration of your laser pulses (fs-ps), but all the micro-times measured will be relative to some reference laser pulse, which repeats at >MHz frequencies. We also integrate over millions of events - wall-time timestamps don't enter into it. In summary, yes, when writing software for experiments working with high time resolution you have to write your own implementations of whatever data formats best describe time as you're measuring it, which generally won't line up with time as a PC (or a railway company) looks at it. Cheers Thomas * The example is implausible not least because I understand muon chambers tend to be a fair bit bigger than 15cm, but you get my point. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial migration readiness (was: Taking over the Mercurial Migration)
On 07/02/2010 10:33 AM, Georg Brandl wrote: > Am 02.07.2010 09:27, schrieb anatoly techtonik: >> On Thu, Jul 1, 2010 at 6:16 PM, Jesse Noller wrote: >>> >>> This migration is far from "rushed". Workflow will need to be >>> documented and we need a working hg setup a little while before the >>> official migration. Both of those said, I personally think this has >>> dragged on long enough. >> >> So, if I understand correctly - there are no Mercurial mirrors for >> testing at the moment, > > There are repositories at http://hg.python.org/; the "cpython" one > represents the result of conversion at some point in time. http://code.python.org/hg/ looks like a working mercurial mirror of current CPython svn. It's probably nothing you'd like to switch to as such since it doesn't replace svn usernames with names/e-mail addressed (as I gather was planned), but it does get updated. As one of those potential contributors that are new to the game and actually know and love Mercurial, I've never actually checked out a Python subversion branch, and have based the few patches I have written on http://code.python.org/hg/branches/py3k/ Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Function Operators
On 07/18/2010 05:52 PM, Reid Kleckner wrote: > Usual disclaimer: python-dev is for the development *of* python, not > *with*. See python-list, etc. Moving to python-list. Please keep discussion there. > > That said, def declares new functions or methods, so you can't put > arbitrary expressions in there like type(f).__mul__ . > > You can usually assign to things like that though, but in this case > you run into trouble, as shown below: > def func(): pass > ... type(func) > def compose(f, g): > ... return lambda x: f(g(x)) > ... type(func).__mul__ = compose > Traceback (most recent call last): > File "", line 1, in > TypeError: can't set attributes of built-in/extension type 'function' > > As the interpreter says, it doesn't like people mucking with operator > slots on built in types. > > Finally, if you like coding in that very functional style, I'd > recommend Haskell or other ML derived languages. Python doesn't > support that programming style very well by choice. > > Reid > > On Sun, Jul 18, 2010 at 8:34 AM, Christopher Olah > wrote: >> Dear python-dev, >> >> In mathematical notation, f*g = z->f(g(z)) and f^n = f*f*f... (n >> times). I often run into situations in python where such operators >> could result in cleaner code. Eventually, I decided to implement it >> myself and see how it worked in practice. >> >> However, my intuitive implementation [1] doesn't seem to work. In >> particular, despite what it says in function's documentation, function >> does not seem to be in __builtin__. Furthermore, when I try to >> implement this through type(f) (where f is a function) I get invalid >> syntax errors. >> >> I hope I haven't made some trivial error; I'm rather inexperienced as >> a pythonist. >> >> Christopher Olah >> >> >> [1] Sketch: >> >> def __builtin__.function.__mul__(self, f): >>return lambda x: self(f(x)) >> >> def __builtin__.function.__pow__(self, n): >>return lambda x: reduce(lambda a,b: [f for i in range(n)]+[x]) As Reid explained, you can't just muck around with built-in types like that. However, you can "use a different type". If you're not familiar with Python decorators, look them up, and then have a look at this simple implementation of what you were looking for: >>> class mfunc: ... def __init__(self, func): ... self.func = func ... self.__doc__ = func.__doc__ ... self.__name__ = func.__name__ ... def __call__(self, *args, **kwargs): ... return self.func(*args, **kwargs) ... def __mul__(self, f2): ... @mfunc ... def composite(*a, **kwa): ... return self.func(f2(*a, **kwa)) ... return composite ... def __pow__(self, n): ... if n < 1: ... raise ValueError(n) ... elif n == 1: ... return self.func ... else: ... return self * (self ** (n-1)) ... >>> @mfunc ... def square(x): return x*x ... >>> @mfunc ... def twice(x): return 2*x ... >>> (square*twice)(1.5) 9.0 >>> addthree = mfunc(lambda x: x+3) >>> addfifteen = (addthree ** 5) >>> addfifteen(0) 15 >>> ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
