summaryrefslogtreecommitdiff
path: root/numpy/core/src/scalarmathmodule.c.src
Commit message (Collapse)AuthorAgeFilesLines
* MAINT: merge scalarmathmodule into umath moduleJulian Taylor2014-10-091-1980/+0
| | | | | There is no good reason it needs to be its own module. Also removes the undocumented pymath alter/restore functions.
* ENH: add scalarmathmodule.h.src with integer overflow functionsJulian Taylor2013-10-151-126/+2
| | | | and use them in scalarmathmodule.c instead of the old (disabled) ones.
* Revert "Merge pull request #3567 from arinkverma/avoid_conversion"Charles Harris2013-09-031-214/+12
| | | | | | | | | | | | | | | This reverts commit de9f1c92d3ca0920bce915438f0406f587aa98db, reversing changes made to d958dec676beeac218a118fac084fa8b14bc9171. There is a change of behavior in conversion of signed to unsigned PyLong that shows up on my machine. For some reason this did not show up in the travisbot tests. This reverts the merge that led to this problem until it can be sorted out. Error shows up as numpy/core/arrayprint.py", line 653, in __call__ if _MININT < x < _MAXINT: OverflowError: can't convert negative int to unsigned
* Check for error value by PyLong_AsUnsignedLong as (unsigned long)-1Arink Verma2013-08-311-1/+1
|
* Replaced PyInt_As_Long with PyInt_AsLong and errorcheckingArink Verma2013-08-301-10/+27
|
* Added PyInt_CheckExact for python < 3 and error check for PyLong_AsLongArink Verma2013-08-301-21/+34
|
* Extracting longlong value without converting it to NyTypeArink Verma2013-08-301-4/+66
|
* ENH: Avoiding conversion of integer to NumPy Scalar.Arink Verma2013-08-301-13/+123
| | | | | | There is a bottleneck in scalar operations, when trying to extract the underlying C value from a Python integer/float. I have avoid conversion for know integer type but extracting its value.
* STY: Giant whitespace cleanup.Charles Harris2013-08-181-1/+1
| | | | Now is as good a time as any with open PR's at a low.
* Merge pull request #2941 from raulcota/avoid_create-kill_npscalarsCharles Harris2013-07-291-4/+61
|\ | | | | Avoid conversion to NumPy Scalar
| * Fix indentationRaul Cota2013-01-221-4/+4
| |
| * Avoid conversion to NumPy ScalarRaul Cota2013-01-221-4/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After profiling I noticed that a bottleneck for NumPy scalar operations occurs when trying to extract the underlying C value from a Python float because it first converts the Python scalar into its matching NumPy scalar (e.g. PyFloat -> float64) and then it extracts the C value from the NumPy scalar. For some types, it is a lot faster to just extract the value directly from the Python scalar. I only did for PyFloat in this modified code but the code is laid out such that it can be easily extended to other types such as Integers. I did not do them because I was unsure if there was a special scenario to handle across OS and/or between 32 and 64 bit platforms. The ratio of speed to do different operations are listed below (Old time / New time with modifications). In other words, the bigger the number, the bigger the speed up we get. Tested in Python 2.6 Windows RATIO TEST 1.1 Array * Array 1.1 PyFloat * Array 1.1 Float64 * Array 1.0 PyFloat + Array 1.3 Float64 + Array 1.1 PyFloat * PyFloat 1.0 Float64 * Float64 4.0 PyFloat * Float64 2.9 PyFloat * vector1[1] 3.9 PyFloat + Float64 9.8 PyFloat < Float64 9.9 PyFloat < Float64 1.0 Create array from list 1.0 Assign PyFloat to all 1.0 Assign Float64 to all 4.2 Float64 * pyFloat * pyFloat * pyFloat * pyFloat 1.0 pyFloat * pyFloat * pyFloat * pyFloat * pyFloat 1.0 Float64 * Float64 * Float64 * Float64 * Float64 1.0 Float64 ** 2 1.0 pyFloat ** 2
* | MAINT: Remove outdated version checks.Charles Harris2013-07-111-9/+0
| | | | | | | | | | | | | | | | | | | | Because Numpy 1.8.0 will no longer supports Python versions < 2.6 we no longer need to check for that and can also remove the code that is specific to those earlier versions. To make this a bit safer, the toplevel setup.py file now contains a check of the Python version number and raises an error when run by an unsupported version.
* | Merge pull request #3341 from juliantaylor/sse2-sqrtCharles Harris2013-05-251-2/+8
|\ \ | | | | | | vectorize sqrt ufunc with SSE2
| * | ENH: vectorize sqrt ufunc using SSE2Julian Taylor2013-05-251-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | specialize the sqrt ufunc for float and double and vectorize it using SSE2. improves performance by 4/2 for float/double if one is not memory bound due to non-cached data. performance is always better on all tested machines (amd phenom X2, intel xeon 5xxx/7xxx, core2duo, corei7) This version will not set errno on invalid input, but numpy only checks the fpu flags so the behavior is the same. In principle the compiler could autovectorize it when setting ffast-math (for no errno) and specializing the loop for the vectorizable strides and giving it some hints (restrict, __builtin_assume_aligned, etc.), but its simpler and more reliable to simply vectorize it by hand.
* | | MAINT: fix some compiler warningsJulian Taylor2013-05-251-1/+1
|/ / | | | | | | | | implicit declarations, wrong declarations, unused variables and fixes a comparison typo bug in multiarraymodule.c
* | Merge pull request #349 from ericfode/float16powCharles Harris2013-04-011-5/+12
|\ \ | |/ |/| First attempt at BF for 2165 and added better tests for scalarmath pow function
| * Update scalarmathmodule.c.srcEric Fode2013-04-011-1/+1
| | | | | | Got rid of some white space in scalarmathmodule.c.src
| * fixed some style problemsEric Fode2012-07-131-8/+8
| |
| * First attempt at BF for 2028 and added better tests for scalarmath pow functionEric Fode2012-07-121-6/+13
| |
* | BUG: Replace unprefixed SIZEOF_* macros with prefixed versions.Charles Harris2013-01-051-4/+4
| | | | | | | | | | | | The sources don't define NPY_NO_PREFIX and consequently none of the unprefixed macros are defined. Using them can lead to some unexpected results.
* | Use PyMODINIT_FUNC and update docs accordingly.cgohlke2012-09-021-1/+1
| | | | | | | | See https://github.com/scipy/scipy/pull/279
* | STY: core: move non-Py3 specific stuff out from npy_3kcompat.h to private ↵Pauli Virtanen2012-07-131-1/+1
|/ | | | | | npy_pycompat.h npy_3kcompat.h is semi-private, so this can be done.
* WRN: Fix unused variable compiler warnings in scalarmathmodule.c.src.Charles Harris2012-04-211-84/+227
| | | | | | | | Two templates were broken up and specialized. The corresponding substitution loops could also be specialized, but this wasn't done this time through. Breaking up the templates clarifies the code at the expense of extra text, but I think the improved clarity is a good tradeoff.
* DEP: Update all the '#define NPY_NO_DEPRECATED_API' instances to beMark Wiebe2012-04-061-1/+1
| | | | versioned
* UPD: Various fixes, Remove #define NPY_NO_PREFIX from files in core.Charles Harris2012-02-051-1/+1
|
* UPD: Use prefixed macros in numpy/core/src/scalarmathmodule.c.src.Charles Harris2012-02-041-269/+511
| | | | | Also a fair amount of stylistic cleanups. This module lives in a state of stylistic sin and needs an intervention.
* UPDATE: Replace macros in old_defines.h by new.Charles Harris2012-02-041-2/+2
| | | | | With the exception of the numarray fixups these were all instances that were results of code generation.
* STY: core/src - replace macros in old_defines.h with new versions.Charles Harris2012-02-041-6/+6
|
* ENH: core: Make scalar math module leave out the deprecated headerMark Wiebe2011-07-061-0/+2
|
* BUG: core: make complex division by zero to yield inf properly (#1776)Pauli Virtanen2011-04-021-4/+11
|
* WRN: core: Remove many warnings gcc produces with stricter flagsMark Wiebe2011-01-291-4/+4
|
* ENH: ufunc: Change object/reference handling code to treat NULL as Py_None ↵Mark Wiebe2011-01-211-4/+6
| | | | more consistently
* BUG: core: Some fixes and clean up of floating point exception codeMark Wiebe2010-12-031-10/+10
|
* ENH: core: Create half/float16 data typeMark Wiebe2010-12-011-87/+161
|
* BUG: core: Make scalar output volatile to prevent incorrect optimizer ↵Mark Wiebe2010-11-151-3/+9
| | | | reordering (#1671)
* BUG: core: adjust ComplexWarning location frame up by one, so that the ↵Pauli Virtanen2010-10-161-1/+1
| | | | warning comes from the correct location (#1639)
* BUG: core: fix uint64 -> Python int cast (fixes #1287)Pauli Virtanen2010-10-101-6/+2
|
* BUG: core: handle errors from PyErr_Warn for ComplexWarningPauli Virtanen2010-10-081-9/+18
|
* ENH: core: emit ComplexWarning also when array scalars are cast to real/intPauli Virtanen2010-09-211-4/+40
|
* ENH: core: make npy_3kcompat.h header public, for easier usage in ScipyPauli Virtanen2010-07-171-1/+1
|
* ENH: Remove some unused variable warnings.Charles Harris2010-04-251-3/+1
|
* ENH: get rid of #warning directives, either by fixing the issue or changing ↵Pauli Virtanen2010-04-041-10/+0
| | | | them to comments
* 3K: Some remaining Py_TYPE issuesPauli Virtanen2010-02-201-1/+1
|
* BUG: Fix bugs in complex pow (fixes #1313)Pauli Virtanen2009-12-071-1/+1
| | | | Thanks to Francesc Alted.
* 3K: module inits for all core modulesPauli Virtanen2009-12-061-3/+33
|
* 3K: core: handle removed tp_compare and PyObject_ComparePauli Virtanen2009-12-061-4/+54
| | | | Also, implement tp_richcompare for flagsobject.
* 3K: core: adapt to changes in PyNumberMethodsPauli Virtanen2009-12-061-2/+40
| | | | Some entries were removed in Py3K -- easy to adapt to.
* Cleanup scalarmathmodule.c.src.Charles Harris2009-10-201-3/+3
| | | | Remove hard tabs.
* Make the type cast clearer + comment.David Cournapeau2009-03-091-1/+5
|
View Lorry Controller Status