there is a proposal to add some Intel specific fast math routine to
part of numerical algorithms is that there is always a speed vs.
precision trade-off, giving a more precise result is slower.
So there is a question what the general precision expectation should be
in NumPy. And how much is it acceptable to diverge in the
precision/speed trade-off depending on CPU/system?
I doubt we can formulate very clear rules here, but any input on what
precision you would expect or trade-offs seem acceptable would be
Some more details
This is mainly interesting e.g. for functions like logarithms,
trigonometric functions, or cubic roots.
Some basic functions (multiplication, addition) are correct as per IEEE
standard and give the best possible result, but these are typically
only correct within very small numerical errors.
This is typically measured as "ULP":
where 0.5 ULP would be the best possible result.
Merging the PR may mean relaxing the current precision slightly in some
places. In general Intel advertises 4 ULP of precision (although the
actual precision for most functions seems better).
Here are two tables, one from glibc and one for the Intel functions:
(Mainly the LA column) https://software.intel.com/content/www/us/en/develop/documentation/onemkl-v…
Different implementation give different accuracy, but formulating some
guidelines/expectation (or referencing them) would be useful guidance.
This whole thread is quite interesting:
https://twitter.com/zooba/status/1415440484181417998. Given how much effort
we are spending on really niche wheel builds, I’m wondering if we should
just draw a line somewhere:
- we do what we do now for the main platforms: Windows, Linux (x86,
aarch64), macOS, *but*:
- no wheels for ppc64le
- no wheels for Alpine Linux
- no wheels for PyPy
- no wheels for Raspberry Pi, AIX or whatever other niche thing comes
- drop 32-bit Linux in case it is becoming an annoyance.
This is not an actual proposal (yet) and I should sleep on this some more,
but I've seen Chuck and Matti burn a lot of time on the numpy-wheels repo
again recently, and I've done the same for SciPy. The situation is not very
sustainable and needs a rethink.
The current recipe is "someone who cares about a platform writes a PEP,
then pip/wheel add a platform tag for it (very little work), and then the
maintainers of each Python package are now responsible for wheel builds (a
ton of work)". Most of these platforms have package managers, which are all
more capable than pip et al., and if they don't then wheels can be hosted
elsewhere (example: https://www.piwheels.org/). And then there's Conda,
Nix, Spack, etc. too of course.
Drawing a line somewhere distributes the workload, where packagers who care
about some platform and have better tools at hand can do the packaging, and
maintainers can go do something with more impact like write new code or
<end of brainwave>
I would like to understand how to go about extending the SIMD framework in
order to add support for POWER10. Specifically, I would like to add the
following instructions: `lxvp` and `stxvp` which loads/stores 256 bits
into/from two vectors. I believe that this will be able to give a decent
performance boost for those on POWER machines since it can halved the
amount of loads/stores issued.
Additionally, matrix engines (2-D SIMD instructions) are becoming quite
popular due to their performance improvements for deep learning and
scientific computing. Would it be beneficial to add these new advanced SIMD
instructions into the framework or should these instructions be left to
libraries such as OpenBLAS and MKL?
Our bi-weekly triage-focused NumPy development meeting is Wednesday,
July 28th at 9 am Pacific Time (16:00 UTC).
Everyone is invited to join in and edit the work-in-progress meeting
topics and notes:
I encourage everyone to notify us of issues or PRs that you feel should
be prioritized, discussed, or reviewed.
This week we have our planned Newcomer's meeting on July 29, at 8PM UTC.
This time, we are teaming up with Tony Fast and Isabela Presedo-Floyd to
propose a low-code mini-sprint focusing on accessibility. This is a great
opportunity to make your first contribution to NumPy!
We will be focusing on writing alt-text for images in our documentation.
Alt-text provides a textual alternative to non-text content in web pages,
and as cited in this WebAIM document :
"Alternative text serves several functions:
- It is read by screen readers in place of images allowing the content
and function of the image to be accessible to those with visual or certain
- It is displayed in place of the image in browsers if the image file is
not loaded or when the user has chosen not to view images.
- It provides a semantic meaning and description to images which can be
read by search engines or be used to later determine the content of the
image from page context alone."
You can find some more information on how to add alt-text in .
As usual, all are welcome - feel free to join even if you just want to
To join on Zoom, use this link: https://zoom.us/j/6345425936
Hope to see you around!
** You can click this link to get the correct time at your timezone:
*** You can add the NumPy community calendar to your Google calendar by
clicking this link: https://calendar.google.com/calendar
It would be nice to be able to use the Python syntax we already use to
format the precision of floating numbers in numpy:
>>> a = np.array([-np.pi, np.pi])
This is particularly useful when you have large arrangements. The problem
is that if you want to do it today, it is not implemented:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unsupported format string passed to numpy.ndarray.__format__
In this PR (https://github.com/numpy/numpy/pull/19550) I propose a very
basic formatting implementation for numeric numbers that uses
`array2string` just like it currently does `str`
At first, since we are only considering formatting the numeric type,
floating numbers specifically, we are only interested in being able to
change the precision, the sign, and possibly the rounding or truncation.
Since the `array2string` function already does everything we need, we only
need to implement the` __format__` function of the `ndarray` class which
parses a predefined format (similar to the one already used by Python for
built-in data types) to indicate the parameters before said.
I propose a mini format specification inspired in the [Format Specification
format_spec ::= [sign][.precision][type]
sign ::= "+" | "-" | " "
precision ::= [0-9]+
type ::= "f" | "e"
We are going to consider only 3 arguments of the `array2string` function:`
precision`, `suppress_small`,` sign`. In particular, the `type` token sets
the` suppress_small` argument to True when the type is `f` and False when
it is `e`. This is in order to mimic Python's behavior in truncating
decimals when using the fixed-point notation.
As @brandon-rhodes said in gh-5543, the behavior when you try to format an
array containing Python objects, the behavior should be the same as Python
has implemented by default in the `object` class: ` format (a, "") ` should
be equivalent to `str (a)` and `format(a, "not empty")` should raise an
What remains to be defined is the behavior when trying to format an array
with a non-numeric data type (`np.numeric`) other than `np.object_`. Should
we raise an exception? In my opinion yes, since in the future formatting is
extended -- for example, for dates -- people are aware that before that was
I'm open to suggestions.