ndarray should offer __format__ that can adjust precision #5543
Comments
Without this tweak, the attempt to print was dying with an error,
because a NumPy array does not know what to do with a '.6' format
string:
Traceback (most recent call last):
File "tmp9.py", line 9, in <module>
print(mars(tt=2457061.5).position)
File "/home/brandon/skyfield/skyfield/units.py", line 50, in
__str__
return '{0:.6} AU'.format(self.AU)
TypeError: non-empty format string passed to object.__format__
In response I have opened: numpy/numpy#5543
|
That would be lovely, yes. Any interest in putting together a patch?
|
|
Yes, I will try my hand at it and let you know if it works! Thanks for letting me know that the feature will be welcomed, before I got started. |
|
What would the expected output be? Numpy seems to be doing what all Python sequences do, and I don't think that breaking that commonality is a good idea: |
|
Ah, I thought we were talking about array scalars (where we obviously It does seem like supporting .format() in a useful way would be an On Sun, Feb 8, 2015 at 10:31 AM, Jaime notifications@github.com wrote:
Nathaniel J. Smith -- http://vorpus.org |
|
@jaimefrio — my understanding is that the entire design of NumPy arrays is precisely to do things that all Python sequences do not. Normal lists cannot accept division; NumPy arrays can. Normal lists cannot be taken to a power; NumPy arrays can. The whole point was to break commonality very nearly everywhere, from what I can see of its design, so that lists would act like numbers. Accepting a format string is, in my view, symmetrical with division and being taken to a power. The behavior I am anticipating is roughly that of running str() on a NumPy array, but with the format adjusted as though numpy.set_printoptions had been called to set whatever precision is specified by the format string. |
|
I like the suggestion. The array scalar case would certainly just be to have expected behaviour, and it would seem the route of least surprise to apply the format to the individual elements (and otherwise behave as if no format string was given). |
|
It certainly seems convenient, but there may be a good reason why Python lists, or tuples, do not do the same. The change in behavior from Python 2.x to 3.x probably means that raising an error is a conscious decision. I don't follow any of the Python forums, perhaps someone will know if this has been brought up before somewhere else. Either way. it is probably a good idea to give this a run through the mailing list, where it will get looked at by more people than here. |
|
Python lists and tuples do not support A NumPy array—unless its members are of dtype The change in behavior was simply to avoid disappointing users who provide a format string: if the string is accepted by a type, and raises no error, then people reasonably expect to see some change in format, but were not doing so — under the old Python 2 behavior — and instead were having their format string accepted quietly but then just ignored. Here is the issue in which it was negotiated that an error was better for uses than an ignored formatting string: http://bugs.python.org/issue7994 I propose that NumPy arrays adhere quite strictly to this standard behavior: in situations where the array itself is formatting its contents, accepting and using the string will allow the user to decide how many decimal places are shown, in the standard way that users already set the precision of data they are printing. In situations where the NumPy array contains other objects, and is doing no numeric formatting of its own, then I see no problem with its ignoring the format string (unless someone wants to make the argument that a NumPy array ought to broadcast it to its members!) and raising the “you gave me a format string I can't use!” exception that is now standard in Python to warn users away from trying to format things in situations where the format will be ignored. |
|
You have me convinced... Thanks for the detailed explanation! |
|
Thank you for pushing for an improved proposal — the idea that a NumPy array should raise an exception when given a format string if the NumPy array's dtype is object_ had simply not occurred to me, and it's an edge case that users will be very happy that NumPy gets right! @njsmith (or whomever would like to), feel free to assign this to me so that it shows up on my GitHub to-do list when I sit down this weekend. Thanks for the chance to add this! |
|
I'm really interested in this feature (and willing to contribute) and wanted to check what progress has been made in the last two years. I can't seem to access numpy-discussion right now to see if the discussion has continued there. |
|
Apparently, no one assigned it to me. By that first weekend I had already forgotten about this issue given the press of other responsibilities — so, no progress from me yet. |
|
@gustavla see here for the numpy-discussion mailing list. But I don't think this has been discussed before. Our rule is that API changes need to reach consensus on the mailing list. This feature feels like a pretty clear win to me (especially with the arrival of f-strings), so I don't anticipate any objections. Still, it would be good to come up with a concrete proposal on how it should work and run that by the mailing list before starting work. |
This fixes numpygh-7978 The behavior for other sized arrays is left unchanged, pending discussion in numpygh-5543
This fixes numpygh-7978 The behavior for other sized arrays is left unchanged, pending discussion in numpygh-5543
In Python 3.7, the |
|
throwing another hat into the ring from #12491 import numpy as np
x, y = np.array([-969100.0]), np.array([-4457000.0])
# This works
"%.4g, %.4g" % (x, y)
# This errors
"{:.4g}, {:.4g}".format(x, y)happening because size-0 / size-1 arrays are treated as their scalar in many places except in |
If you run the [00_intro_to_thinc.ipynb](https://github.com/explosion/thinc/blob/master/examples/00_intro_to_thinc.ipynb) notebook on a GPU, you get the following error when you execute the cell where you create an optimizer and do several passes over the data. ``` TypeError Traceback (most recent call last) <ipython-input-27-c7aae9724b89> in <module>() 21 total += Yh.shape[0] 22 score = correct / total ---> 23 print(f" {i} {score:.3f}") TypeError: unsupported format string passed to cupy.core.core.ndarray.__format__ ``` Also see the related open NumPy issue: [ndarray should offer __format__ that can adjust precision #5543 ](numpy/numpy#5543). This pull request proposes a simple fix/workaround.
If you run the [00_intro_to_thinc.ipynb](https://github.com/explosion/thinc/blob/master/examples/00_intro_to_thinc.ipynb) notebook on a GPU, you get the following error when you execute the cell where you create an optimizer and do several passes over the data. ``` TypeError Traceback (most recent call last) <ipython-input-27-c7aae9724b89> in <module>() 21 total += Yh.shape[0] 22 score = correct / total ---> 23 print(f" {i} {score:.3f}") TypeError: unsupported format string passed to cupy.core.core.ndarray.__format__ ``` Also see the related open NumPy issue: [ndarray should offer __format__ that can adjust precision #5543 ](numpy/numpy#5543). This pull request proposes a simple fix/workaround.
|
Can you guys help me with this? I want to implement this but don't know where to start |
|
Hi @scratchmex You might want to
|
|
I suspect this issue needs an NEP explaining how formatting will be designed to behave for numpy datatypes, especially for |
|
been while since this was last discussed. what are the steps for adding this? is a NEP required first? |
|
@grisaitis please see PR #19550 |
In many wonderful cases an ndarray can be used in place of a Python float and Just Work.
But not in one case:
The output of the above code, at least under Python 3.4, is:
It would be a great convenience if the ndarray grew a
__format__()method that understood the tiny mini-language of float formatting, and used the number of digits of precision specified there to make its own call to the standard NumPy vector array formatting. Users could control array appearance on the screen using a Python standard that many programmers already understand.The text was updated successfully, but these errors were encountered: