| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
This adds a version of `almostEqual` (which was already available for
floats) thata works with `Complex[SomeFloat]`.
Proof that this is needed is that the first thing that the complex.nim
runnable examples block did before this commit was define (an
incomplete) `almostEqual` function that worked with complex values.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This PR speeds up complex.pow when both base and exponent are real; when
only the exponent is real; and when the base is Euler's number. These
are some pretty common cases which appear in many formulas. The speed
ups are pretty significant. According to my measurements (using the
timeit library) when both base and exponent are real the speedup is ~2x;
when only the exponent is real it is ~1.5x and when the base is Euler's
number it is ~2x.
There is no measurable difference when using other exponents which makes
sense since I refactored the code a little to reduce the total number of
branches that are needed to get to the final "fallback" branch, and
those branches have less comparisons. Anecdotally the fallback case
feels slightly faster, but the improvement is so small that I cannot
claim an improvement. If it is there it is perhaps in the order of 3 or
4%.
---------
Co-authored-by: Andreas Rumpf <rumpf_a@web.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This PR speeds up the calculation of the power of a complex number when
the exponent is 2.0 or 0.5 (i.e the square and the square root of a
complex number). These are probably two of (if not) the most common
exponents. The speed up that is achieved according to my measurements
(using the timeit library) when the exponent is set to 2.0 or 0.5 is >
x7, while there is no measurable difference when using other exponents.
For the record, this is the function I used to mesure the performance:
```nim
import std/complex
import timeit
proc calculcatePows(v: seq[Complex], factor: Complex): seq[Complex] {.noinit, discardable.} =
result = newSeq[Complex](v.len)
for n in 0 ..< v.len:
result[n] = pow(v[n], factor)
let v: seq[Complex64] = collect:
for n in 0 ..< 1000:
complex(float(n))
echo timeGo(calculcatePows(v, complex(1.5)))
echo timeGo(calculcatePows(v, complex(0.5)))
echo timeGo(calculcatePows(v, complex(2.0)))
```
Which with the original code got:
> [177μs 857.03ns] ± [1μs 234.85ns] per loop (mean ± std. dev. of 7
runs, 1000 loops each)
> [128μs 217.92ns] ± [1μs 630.93ns] per loop (mean ± std. dev. of 7
runs, 1000 loops each)
> [136μs 220.16ns] ± [3μs 475.56ns] per loop (mean ± std. dev. of 7
runs, 1000 loops each)
While with the improved code got:
> [176μs 884.30ns] ± [1μs 307.30ns] per loop (mean ± std. dev. of 7
runs, 1000 loops each)
> [23μs 160.79ns] ± [340.18ns] per loop (mean ± std. dev. of 7 runs,
10000 loops each)
> [19μs 93.29ns] ± [1μs 128.92ns] per loop (mean ± std. dev. of 7 runs,
10000 loops each)
That is, the new optimized path is 5.6 (23 vs 128 us per loop) to 7.16
times faster (19 vs 136 us per loop), while the non-optimized path takes
the same time as the original code.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This is a small improvement on top of PR #22924, which documents the new
'j' format specifier for Complex numbers. In addition to that it moves
the handling of the j specifier into the function that actually
implements it (formatValueAsComplexNumber), which seems a little
cleaner.
---------
Co-authored-by: Angel Ezquerra <angel_ezquerra@keysight.com>
Co-authored-by: Clay Sweetser <Varriount@users.noreply.github.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this change strformat used the generic formatValue function for
Complex numbers. This meant that it was not possible to control the
format of the real and imaginary components of the complex numbers.
With this change this now works:
```nim
import std/[complex, strformat]
let c = complex(1.05000001, -2.000003)
echo &"{c:g}"
# You now get: (1.05, -2)
# while before you'd get a ValueError exception (invalid type in format string for string, expected 's', but got g)
```
The only small drawback of this change is that I had to import complex
from strformat. I hope that is not a problem.
---------
Co-authored-by: Angel Ezquerra <angel_ezquerra@keysight.com>
|
| |
|
|
| |
follow up https://github.com/nim-lang/Nim/pull/22851
follow up https://github.com/nim-lang/Nim/pull/22873
|
| | |
|
| |
|
| |
Co-authored-by: Clay Sweetser <Varriount@users.noreply.github.com>
|
| |
|
|
|
|
|
|
| |
* CIs: attempt to use csources_v1
* also updated the BSDs
* also updated azure pipelines
* std modules should not itself use the 'std/' import dir...
* compiler has to be careful with std/ for v1 booting
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
* Improve documentation for complex
Add missing doc comments
* Add runnableExample
Add links for principal values
Optimize `-`
Change var to let
* Use std prefix for imports
|
| | |
|
| | |
|
| |
|
|
|
|
| |
default values (#12538)
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
* remove `**`
* const `im` can now be used with Complex64
* converters from float|int to Complex are replaced by procs
* converters between various Complex types must stay to allow usage
of `im` with Complex64
* limit types for `+`, `-`, `/`, and `*` between Complex and float
* add `pow` for Complex and a number
* complex type changes
* unpublish approximation function
|
| | |
|
| | |
|
| |
|
|
| |
via OSX: find . -name '*.nim' -exec sed -i '' -E 's/[[:space:]]+$//' {} +
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|