| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The finfo contains a cache for dtypes, but the np.complex128 dtype does not end up in the cache. The reason is that the np.complex128 is converted to np.float64 which is in the cache.
Performance improvement for finfo(np.complex128):
Main: 2.07 µs ± 75 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)
Pr: 324 ns ± 28.9 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)
Improve performance of finfo by making the cache check the first action in the __new__
Improve performance of _commonType by re-using the expression for a.dtype.type and eliminating variables
The finfo and _commonType was part of the computatation time in lstsq when using scikit-rf. Since these methods are used in various other methods performance can improve there slightly as well.
|
| | |
|
| |
|
|
|
| |
Deprecate np.finfo(None), it may be that we should more generally deprecate `np.dtype(None)` but this is a start and particularly weird maybe.
Closes gh-14684
|
| |\
| |
| | |
MAINT: Move set_module from numpy.core to numpy._utils
|
| | | |
|
| |/
|
|
|
|
| |
This removes the attributes on finfo and the "public" module. It also
deprecates `np.core.MachAr`. We should be able to get away with just
deleting it, but there seems little reason to not just deprecate it for now.
|
| |
|
|
|
|
|
| |
finfo() and iinfo() both have a dtype attribute, which was undocumented before this commit.
[skip azp] [skip actions]
Co-authored-by: Ralf Gommers <ralf.gommers@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There was some confusion about how finfo works with complex numbers,
leading to an issue being made requesting that numpy either adds a
cinfo function or changes the documentation of finfo. The submitter of
that issue also linked to an issue for a seperate repository, which also
included conversation about the proposed change. (github.com/data-apis/array-api/issues/433)
In both discussions, there was a general concensus that it would be better
to change the documentation to explain how finfo works instead of
creating a cinfo function.
Since this is just a small documentation change, there's no need
to run the normal checks.
[skip ci]
|
| |
|
|
|
|
|
|
|
|
| |
This fixes the missing attributes. I tested the warning and fix
on valgrind itself.
These attributes were added in gh-18536 but the fallback path was
not checked there.
Replaces gh-21813, although something more like it may make sense
if it allows us to just delete MachAr completely.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* ENH: Add smallest_normal and smallest_subnormal attributes to finfo class
* ENH: Add smallest_normal and smallest_subnormal attributes to MachAr
* BUG: Fix minor bug in the calc of smallest_subnormal attribute
* ENH: Use nextafter to calculate smallest subnormal in finfo
* ENH: Use nextafter for calculating all subnormal numbers
* ENH: Add warning in case the subnormal number is zero and hardcode double double value
* FIX: Fix docstring in new function
* FIX: Add stacklevel parameter to warning
* ENH: Move smallest_subnormal to a property and add a test
* FIX: Only hardcode the subnormal value for double double
* FIX: Fix subnormal warning test
* FIX: Fix the hardcoded value for double double type
* FIX: Fix failing test by supressing an overflow warning
* ENH: Fix the value for smallest_normal and tiny in double double
* BUG: Fix failing tests when tiny is NaN
* BUG: Fix failing test when tiny is NaN
* ENH: add review fixes
* ENH: Raise TypeError for smallest_subnormal/tiny value in longdouble
* FIX: Replace TypeError with warning
* BUG: Fix tests
* ENH: Add release note
* ENH: Add review changes
* BUG: Fix wrong value in smallest_subnormal
Co-authored-by: Sebastian Berg <sebastian@sipsolutions.net>
* BUG: Fix wrong value in subnormal number
* ENH: Bind the smallest_normal warning to the finfo class
* BUG: Revert warning supression in tests
* ENH: Add review changes
* BUG: Fix failing test
* BUG: Fix test identation
* BUG: Fix typo
* Update numpy/core/tests/test_getlimits.py
Co-authored-by: Sebastian Berg <sebastian@sipsolutions.net>
|
| |
|
|
|
|
|
|
| |
This very simple flip of ordering avoids accessing the last 6 uninitialized bytes of 80-bit floats.
Since none of our known `long double` patterns share the 10-byte prefix, this change does not effect behavior.
Accessing these bytes does not invoke any undefined behavior, but it does cause false positives in tools like `msan` and `valgrind`, which is reason enough to avoid doing so.
`msan` does not always report this error, likely due to the caching of memory allocation.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit adds a note to the documentation of finfo clarifying that
the attribute `tiny` does not represent the smallest positive usable
number. Instead it refers to the smallest positive number with there
being no leading 0's in the mantisse (normalized floating point number).
Alternatively, `tiny` represents the smallest positive floating point
number with full precision. The smallest positive subnormal floating
point number is typically orders of magnitudes smaller, but has reduced
precision since leading 0's in the mantisse are used to allow smaller
exponents than indicated by `minexp`.
The commit also adds a brief clarification to the docstring of machar.
Closes #16252
Co-authored-by: Anirudh Subramanian <anirudh2290@apache.org>
Co-authored-by: Ross Barnowski <rossbar@berkeley.edu>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* DOC: Improve docs for np.finfo.
Replace inaccurate statements about eps and epsneg attrs with
correct statements and examples.
Added np.spacing and np.nextafter to See Also.
Closes #6940.
* Removed LaTeX math from finfo docstring.
* MAINT: Add periods at end of some sentences.
Co-authored-by: Charles Harris <charlesr.harris@gmail.com>
|
| |
|
|
| |
Now that 2.7 is gone, there is no need to pop manually from kwarg dictionaries.
|
| |
|
|
|
|
|
| |
Inheriting from object was necessary for Python 2 compatibility to use
new-style classes. In Python 3, this is unnecessary as there are no
old-style classes.
Dropping the object is more idiomatic Python.
|
| |
|
|
|
| |
As numpy is Python 3 only, these import statements are now unnecessary
and don't alter runtime behavior.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes GH-12271
Tests verify that everything in ``dir(numpy)`` either has ``__module__`` set to
``'numpy'``, or appears in an explicit whitelist of undocumented functions and
exported bulitins. These should eventually be documented or removed.
I also identified a handful of functions for which I had accidentally not setup
dispatch for with ``__array_function__`` before, because they were listed under
"ndarray methods" in ``_add_newdocs.py``. I guess that should be a lesson in
trusting code comments :).
|
| | |
|
| |
|
|
|
|
|
| |
getlimits previously called numpy code before all of numpy was loaded,
which often causes circular import issues. This delays getlimits init.
Fixes #12063
|
| |
|
|
|
|
|
|
| |
Otherwise it is hard to impossible to figure out what is the actual
value which fails the test.
See e.g. failing on 3.4 (only) tests of nibabel:
https://ci.appveyor.com/project/nipy/nibabel/build/1.0.498/job/eechfm1kxroa0rju#L598
|
| |
|
|
| |
Does not work, and shouldn't be there.
|
| |
|
|
|
|
|
|
| |
Delay use of array repr until needed for string representations of the
float info parameters. This is to allow getlimits to be imported early
without pulling in too much of the repr machinery.
See: https://github.com/numpy/numpy/pull/8983#discussion_r115838683
|
| |
|
|
|
|
|
| |
Make sure that value shapes and dtypes are the same as the original
calculated values from the MachAr class.
Closes #8585
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* ENH: hard-code finfo parameters for known types
Hard-code the MachAr parameters for float64, float32, 80-bit extended
precision, to save time, and provide skeleton for more difficult types
such as the double double on PPC; see
https://github.com/numpy/numpy/issues/2669
* ENH: add PPC long double finfo
Add parameters for PPC long double, fixing long-standing bug for finfo
on PPC.
* BF: use Python floats for float64 finfo
For some reason (garrgh) np.exp2 with float64 gives a different answer on
Windows than it does on other platforms; use Python floating point
calculations instead, which do appear to be consistent.
* DOC: add release notes for finfo fixes
Add release note describing fixes for PPC long double ``finfo``.
* RF: try using byte string to identify floats
From suggestion by Chuck, and
https//perl5.git.perl.org/perl.git/blob/3118d7d684b56cbeb702af874f4326683c45f045:/Configure
* TST: add tests for reasonable finfo parameters
Check that finfo returns somewhat reasonable parameters for all floating
point types.
* RF: add warning for not-recognized float type
Warn if we don't have a signature for the float type.
* NF: add IEEE float128 type signature
Still needs test on platform with IEEE float128, to check MachAr-like
parameters are correct.
|
| |
|
|
|
|
|
| |
Add a bits attribute to np.finfo, document the existence of this
attribute for both np.iinfo and np.finfo, plus some extra spacing
around the __str__ labels to make the representation consistent
for both classes.
|
| | |
|
| |
|
|
|
| |
Fixed typos in docstrings were updated for functions where the parameter
names in the docstring didn't match the function signature.
|
| |
|
|
|
|
|
| |
Run the 2to3 ws_comma fixer on *.py files. Some lines are now too long
and will need to be broken at some point. OTOH, some lines were already
too long and need to be broken at some point. Now seems as good a time
as any to do this with open PRs at a minimum.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The numliterals fixer replaces the old style octal number like '01' by
'0o1' removes the 'L' suffix.
Octal values were previously mistakenly specified in some dates, those
uses have been corrected by removing the leading zeros.
Simply Removing the 'L' suffix should not be a problem, but in some
testing code it looks neccesary, so in those places the Python long
constructor is used instead.
The 'long' type is no longer defined in Python 3. Because we need to
have it defined for Python 2 it is added to numpy/compat/np3k.py where
it is defined as 'int' for Python 3 and 'long' for Python 2. The `long`
fixer then needs to be skipped so that it doesn't undo the good work.
Closes #3074, #3067.
|
| |
|
|
|
|
|
| |
Add `print_function` to all `from __future__ import ...` statements
and use the python3 print function syntax everywhere.
Closes #3078.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The new import `absolute_import` is added the `from __future__ import`
statement and The 2to3 `import` fixer is run to make the imports
compatible. There are several things that need to be dealt with to make
this work.
1) Files meant to be run as scripts run in a different environment than
files imported as part of a package, and so changes to those files need
to be skipped. The affected script files are:
* all setup.py files
* numpy/core/code_generators/generate_umath.py
* numpy/core/code_generators/generate_numpy_api.py
* numpy/core/code_generators/generate_ufunc_api.py
2) Some imported modules are not available as they are created during
the build process and consequently 2to3 is unable to handle them
correctly. Files that import those modules need a bit of extra work.
The affected files are:
* core/__init__.py,
* core/numeric.py,
* core/_internal.py,
* core/arrayprint.py,
* core/fromnumeric.py,
* numpy/__init__.py,
* lib/npyio.py,
* lib/function_base.py,
* fft/fftpack.py,
* random/__init__.py
Closes #3172
|
| |
|
|
|
|
|
|
| |
This should be harmless, as we already are division clean. However,
placement of this import takes some care. In the future a script
can be used to append new features without worry, at least until
such time as it exceeds a single line. Having that ability will
make it easier to deal with absolute imports and printing updates.
|
| | |
|
| |
|
|
| |
I think that is the end of it.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
