[Numpy-discussion] Re: Proposal for new function to determine if a float contains an integer
On Fri, Dec 31, 2021 at 1:36 AM Joseph Fox-Rabinovitz < jfoxrabinov...@gmail.com> wrote: > Hi, > > I wrote a reference implementation for a C ufunc, `isint`, which returns > True for integers and False for non-integers, found here: > https://github.com/madphysicist/isint_ufunc. > Shouldn't we keep the name of the stdlib float method? >>> (3.0).is_integer() True See https://docs.python.org/3/library/stdtypes.html#float.is_integer András > The idea came from a Stack Overflow question of mine, which has gotten a > fair number of views and even some upvotes: > https://stackoverflow.com/q/35042128/2988730. The current "recommended" > solution is to use ``((x % 1) == 0)``. This is slower and more cumbersome > because of the math operations and the temporary storage. My version > returns a single array of booleans with no intermediaries, and is between 5 > and 40 times faster, depending on the type and size of the input. > > If you are interested in taking a look, there is a suite of tests and a > small benchmarking script that compares the ufunc against the modulo > expression. The entire thing currently works with bit twiddling on an > appropriately converted integer representation of the number. It assumes a > standard IEEE754 representation for float16, float32, float64. The extended > 80-bit float128 format gets some special treatment because of the explicit > integer bit. Complex numbers are currently integers only if they are real > and integral. Integer types (including bool) are always integers. Time and > text raise TypeErrors, since their integerness is meaningless. > > If a consensus forms that this is something appropriate for numpy, I will > need some pointers on how to package up C code properly. This was an > opportunity for me to learn to write a basic ufunc. I am still a bit > confused about where code like this would go, and how to harness numpy's > code generation. I put comments in my .c and .h file showing how I would > expect the generators to look, but I'm not sure where to plug something > like that into numpy. It would also be nice to test on architectures that > have something other than a 80-bit extended long double instead of a proper > float128 quad-precision number. > > Please let me know your thoughts. > > Regards, > > - Joe > ___ > NumPy-Discussion mailing list -- numpy-discussion@python.org > To unsubscribe send an email to numpy-discussion-le...@python.org > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ > Member address: deak.and...@gmail.com > ___ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-le...@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: arch...@mail-archive.com
[Numpy-discussion] Re: NumPy-Discussion Digest, Vol 183, Issue 33
Hey, Stefano!
The level of being pedantic is absolutely acceptable.
I don't question any of your arguments. They are all perfectly valid.
Except that I'd rather say it is ~29 seconds if measuring against 1970.
Leap seconds were introduced in 1972 and there were
a total of 27 seconds since then, but TAI time was ticking since 1958 and
gained 10 seconds by 1970 so it is approximately 0.83 second per year at
which gives approx 28.67 sec between today and 1970.
So 1970 is a bad choice of epoch if you want to introduce a
leap-second-aware datetime.
In GPS time they chose 1980. In TAI it is 1958, but that is somewhat worse
than 1980 because it is not immediately clear how to perform the conversion
timestamp<->timedelta between 1958 and 1970.
Something like 'proleptic gps time' would be needed to estimate the number
of leap seconds in the years before 1972 when they were introduced. Or
maybe to limit the leap-second timescale
to start at 1972 and not to accept any timestamps before that date.
The system that ignores the existence of the leap seconds has a right to
exist.
But it just has limited applicability.
np.datetime64 keeps time as a delta between the moment in time and a
predefined epoch.
Which standard does it use to translate this delta to human-readable time
in years,
months, and so on?
If it is UTC, then it must handle times like 2016-12-31 23:59:60, because
it is a valid UTC timestamp.
>>> np.datetime64('2016-12-31 12:59:60')
Traceback (most recent call last):
File "", line 1, in
ValueError: Seconds out of range in datetime string "2016-12-31 12:59:60"
Datetime also fails (so far) to handle it:
>>> dt(2016,12,31,23,59,60)
Traceback (most recent call last):
File "", line 1, in
ValueError: second must be in 0..59
But `time` works. Well, at least it doesn't raise an exception:
>>> t = time.struct_time((2016,12,31,12,59,60,0,0,0)); t
time.struct_time(tm_year=2016, tm_mon=12, tm_mday=31, tm_hour=12,
tm_min=59, tm_sec=60, tm_wday=0, tm_yday=0, tm_isdst=0)
>>> time.asctime(t)
'Mon Dec 31 12:59:60 2016'
>>> time.gmtime(calendar.timegm(t))
time.struct_time(tm_year=2017, tm_mon=1, tm_mday=1, tm_hour=1, tm_min=0,
tm_sec=0, tm_wday=6, tm_yday=1, tm_isdst=0)
Imagine a user that decides which library to use to store some (life
critical!) measurements taken every 100 ms. He looks at NumPy datetime64,
reads that it is capable of handling attosecods, and decides that it is a
perfect fit. Now imagine that on 31 Dec 2022 the World Government decided
to inject a leap second. The system will receive the announcement from the
NTC servers and will
prepare to replay this second twice. As soon as this moment chimes in he'll
run into a ValueError, which he won't notice because he's celebrating a New
Year :) And guess whom he'll blame? ;)
Actually the humanity has already got used to replaying timespans twice. It
happens every year in the countries that observe daylight saving time. And
the solution is to use a more linear scale than local time, namely, UTC.
But now turns out that UTC is not linear enough and it also has certain
timespans happening twice.
The solution once again is use a _really_ linear time which is TAI. I think
python 'time' library did a right thing to introduce time.CLOCK_TAI, after
all.
Astropy handles the UTC scale properly though:
>>> t = Time('2016-12-31 23:59:60')
>>> t0 = Time('2016-12-31 23:59:59')
>>> delta = t-t0
>>> delta.sec
0.99969589
>>> t0 + delta
So the solution for that particular person with regular intervals of time
is to use astropy. I mention it in the article.
I made some corrections to the text. I'd be grateful if you had a look and
pointed me to the particular sentences
that need improvement.
Best regards,
Lev
On Wed, Dec 29, 2021 at 6:54 PM Stefano Miccoli
wrote:
> Lev, excuse me if I go in super pedantic mode, but your answer and the
> current text of the article fail to grasp an important point.
>
> 1) The proleptic Gregorian calendar is about leap *year* rules. It tracks
> days without making any assumption on the length of days. If we agree on
> using this calendar, dates like -0099-07-12 and 2021-12-29 are defined
> without ambiguity, and we can easily compute the number of days between
> these two dates.
>
> 2) Posix semantics is about the length of a day, and is based on the
> (utterly wrong) assumption that a mean solar day is constant and exactly
> 86400 SI seconds long. (For an authoritative estimate of historical length
> of day variations see https://doi.org/10.1098/rspa.2020.0776>)
>
> Knowing assumption 1) is important when coding dates before 1582-10-15:
> e.g. 1582-10-04 Julian is 1582-10-14 proleptic Gregorian. Once we agree on
> the proleptic Gregorian calendar everything works as expected: time deltas
> expressed in days are correct.
>
> Knowing assumption 2) is important if we pretend to compute time deltas
> for date-time obj
[Numpy-discussion] Re: Proposal for new function to determine if a float contains an integer
On Fri, Dec 31, 2021 at 5:46 AM Andras Deak wrote: > On Fri, Dec 31, 2021 at 1:36 AM Joseph Fox-Rabinovitz < > jfoxrabinov...@gmail.com> wrote: > >> Hi, >> >> I wrote a reference implementation for a C ufunc, `isint`, which returns >> True for integers and False for non-integers, found here: >> https://github.com/madphysicist/isint_ufunc. >> > > Shouldn't we keep the name of the stdlib float method? > > >>> (3.0).is_integer() > True > > See https://docs.python.org/3/library/stdtypes.html#float.is_integer > > This sounds obvious in hindsight. I renamed it to is_integer, including the repo itself. The new link is here: https://github.com/madphysicist/is_integer_ufunc > András > > > >> The idea came from a Stack Overflow question of mine, which has gotten a >> fair number of views and even some upvotes: >> https://stackoverflow.com/q/35042128/2988730. The current "recommended" >> solution is to use ``((x % 1) == 0)``. This is slower and more cumbersome >> because of the math operations and the temporary storage. My version >> returns a single array of booleans with no intermediaries, and is between 5 >> and 40 times faster, depending on the type and size of the input. >> >> If you are interested in taking a look, there is a suite of tests and a >> small benchmarking script that compares the ufunc against the modulo >> expression. The entire thing currently works with bit twiddling on an >> appropriately converted integer representation of the number. It assumes a >> standard IEEE754 representation for float16, float32, float64. The extended >> 80-bit float128 format gets some special treatment because of the explicit >> integer bit. Complex numbers are currently integers only if they are real >> and integral. Integer types (including bool) are always integers. Time and >> text raise TypeErrors, since their integerness is meaningless. >> >> If a consensus forms that this is something appropriate for numpy, I will >> need some pointers on how to package up C code properly. This was an >> opportunity for me to learn to write a basic ufunc. I am still a bit >> confused about where code like this would go, and how to harness numpy's >> code generation. I put comments in my .c and .h file showing how I would >> expect the generators to look, but I'm not sure where to plug something >> like that into numpy. It would also be nice to test on architectures that >> have something other than a 80-bit extended long double instead of a proper >> float128 quad-precision number. >> >> Please let me know your thoughts. >> >> Regards, >> >> - Joe >> ___ >> NumPy-Discussion mailing list -- numpy-discussion@python.org >> To unsubscribe send an email to numpy-discussion-le...@python.org >> https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ >> Member address: deak.and...@gmail.com >> > ___ > NumPy-Discussion mailing list -- numpy-discussion@python.org > To unsubscribe send an email to numpy-discussion-le...@python.org > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ > Member address: jfoxrabinov...@gmail.com > ___ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-le...@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: arch...@mail-archive.com
[Numpy-discussion] Re: No credits left in travis for 1.22.0 release
We are back in business with 100k credits. Matti On Fri, 31 Dec 2021 at 08:43, James Tocknell wrote: > I'll need to check with the other maintainers (see > https://github.com/h5py/h5py/issues/2026), but I believe h5py > shouldn't need the x86 builds any more (I'm less sure about the other > systems)? > > James > > On Fri, 31 Dec 2021 at 17:03, Matti Picus wrote: > > > > > > On 31/12/21 3:50 am, Charles R Harris wrote: > > > > > > > > > On Thu, Dec 30, 2021 at 6:26 PM Charles R Harris > > > mailto:charlesr.har...@gmail.com>> wrote: > > > > > > Hi All, > > > > > > We need to get more credits in order to run MacPython/numpy-wheels > > > builds on travis. Anyone recall how to go about this? > > > > > > Chuck > > > > > > > > > MacPython has used 800550 of 80 credits. NumPy has used 625860 of > > > 80 credits, so should be good for a couple of months. SciPy has > > > one credit left, but doesn't use travis. I think the MacPython credits > > > covers everyone who uses multibuild and travis, so NumPy is likely not > > > the only one affected. > > > > > > Chuck > > > > > I requested more OpenSource credits for MacPython. The MacPython credits > > cover many of the wheel-building projects, the main repos (numpy/numpy) > > are under different accounts. I last reqeusted credits for MacPython in > > October. > > > > > > A bit more information: > > > > Travis-ci.com bills differently for each platform. > > > > For x86, they bill > > > > 10 credits per minute on linux > > > > 20 credits per minute on windows > > > > 50 credits per minute on macos > > > > aarch64 (arm linux), ppc, and s390x are **not billed** against credits. > > I think this is because other companies provide the actual hardware > runners. > > > > > > Some of the projects under MacPython like matplotlib have migrated off > > travis and use cibuildwheel in their main repo [0], using qemu for arm64. > > > > > > Others like numpy-wheels and openblas-libs moved their x86 builds to > > other providers, their travis builds actually consume 0 credits. > > > > > > h5py-wheels, scipy-wheels, pandas-wheels and others are still consuming > > credits for their x86 builds. If all the projects moved to other > > providers it would save opening requests for more credits, admittedly it > > is easier to request credits than to move the build :). I could also be > > more proactive in tracking the credit situation and request a renewal > > before they run out, I will set a reminder to do so 2 1/2 months from > now. > > > > > > Matti > > > > > > [0] > > > https://github.com/matplotlib/matplotlib/blob/main/.github/workflows/cibuildwheel.yml > > > > ___ > > NumPy-Discussion mailing list -- numpy-discussion@python.org > > To unsubscribe send an email to numpy-discussion-le...@python.org > > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ > > Member address: aragilar+nu...@gmail.com > ___ > NumPy-Discussion mailing list -- numpy-discussion@python.org > To unsubscribe send an email to numpy-discussion-le...@python.org > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ > Member address: matti.pi...@gmail.com > ___ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-le...@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: arch...@mail-archive.com
[Numpy-discussion] Re: No credits left in travis for 1.22.0 release
On Fri, Dec 31, 2021 at 12:30 PM matti picus wrote: > We are back in business with 100k credits. > Matti > > Thanks Matti. Chuck ___ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-le...@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: arch...@mail-archive.com
