8000 Floating point repr · Issue #6136 · numpy/numpy · GitHub
[go: up one dir, main page]
Skip to content

Floating point repr #6136

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
anntzer opened this issue Jul 31, 2015 · 5 comments
Closed

Floating point repr #6136

anntzer opened this issue Jul 31, 2015 · 5 comments

Comments

@anntzer
Copy link
Contributor
anntzer commented Jul 31, 2015 
In [1]: np.array(.1)[()] == np.array(.1).item()
Out[1]: True

In [2]: np.array(.1)[()] # a np.float64
Out[2]: 0.10000000000000001

In [3]: np.array(.1).item() # a python (64-bit) float
Out[3]: 0.1

Python floats use the shortest repr that give the same value when eval'd since https://bugs.python.org/issue1580 was accepted. It would be nice if numpy did the same.

I realize it would require a nontrivial patch :)
@anntzer anntzer mentioned this issue Jul 31, 2015
Closed
@njsmith
Copy link
Member
njsmith commented Aug 1, 2015

Yeah, this bugs me a bit too :-). The complication though is that when
printing arrays, it's pretty important that the different elements take up
the same number of columns of screen space, so any solution to this would
need some way to address that. Maybe print the shortest equivalent
representation and then pad to spaces if it's shorter than the allotted
space, or only do this for scalars, or something like that.
On Jul 31, 2015 10:51, "Antony Lee" notifications@github.com wrote:

In [1]: np.array(.1)[()] == np.array(.1).item()
Out[1]: True

In [2]: np.array(.1)[()] # a np.float64
Out[2]: 0.10000000000000001

In [3]: np.array(.1).item() # a python (64-bit) float
Out[3]: 0.1

Python floats use the shortest repr that give the same value when eval'd
since https://bugs.python.org/issue1580 was accepted. It would be nice if
numpy did the same.

I realize it would require a nontrivial patch :)

—
Reply to this email directly or view it on GitHub
#6136.

@anntzer
Copy link
Contributor Author
anntzer commented Aug 1, 2015

It's already space-padded:

In [1]: np.array([1, 1.1])
Out[1]: array([ 1. ,  1.1])

@aarchiba
Copy link
Contributor

Array printing passes through separate code from scalar repr. In fact, repr on arrays intentionally does not produce an invertible representation of the array (it prints according to printoptions). But this could be fixed for np.float64 without too much difficulty. np.float32 could be converted to double, which will sometimes produce more digits than necessary for inversion. np.longdouble can't go through python floats, so it would require implementing the algorithm to get a tidy representation; probably not worth it. The code would go in numpy/core/src/multiarray/scalartypes.c.src in the templated function @name@type_@kind@; the repr version would just convert to a python float and use repr.

@anntzer anntzer mentioned this issue Dec 30, 2015
Closed
@anntzer anntzer mentioned this issue May 11, 2016
Closed
@NeilGirdhar
Copy link
Contributor
NeilGirdhar commented May 18, 2016 •
edited
Loading

I think it would be better to write the same kind of type-precision respecting print that Python has rather than trying to go through Python's float-printing code. It would be nice for float32 to print shorter numbers automatically.

@anntzer anntzer mentioned this issue Feb 15, 2017
Open
@mdickinson mdickinson mentioned this issue Oct 30, 2017
Merged
ahaldane added a commit to ahaldane/numpy that referenced this issue Nov 4, 2017
@ahaldane
TST: New tests for scalar/array reprs with dragon4
9ab9e8b 
Fixes numpy#9360 numpy#2643 numpy#6136 numpy#9699 numpy#6908
Closes numpy#9919 numpy#9932
@ahaldane
Copy link
Member
ahaldane commented Nov 5, 2017

Closed by #9941

@ahaldane ahaldane closed this as completed Nov 5, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@aarchiba @njsmith @NeilGirdhar @anntzer @ahaldane
0