Implement the Complex#** method in C. This method calculates complex
exponentiation using `exp(w * log(z))` for complex exponents and
`(abs(z)**n) * Complex.polar(1, n * arg(z))` for real exponents.
Optimize the performance of `Complex#div` by using a hybrid approach.
For common cases, a direct calculation is used. For extreme values,
it falls back to the `frexp`/`ldexp` based calculation for numerical
stability.
Co-authored-by: Gemini <gemini@google.com>
Refactor the C implementation of arithmetic operations (+, -, *)
to reduce code duplication. A new static helper function `complex_op`
is introduced to handle the common logic of the operations.
Co-authored-by: Gemini <gemini@google.com>
Added complete call-seq documentation for all Complex methods in
mrblib/complex.rb (18 methods):
## Complex Class Methods:
- polar: creates complex number from polar coordinates (magnitude, angle)
with trigonometric conversion using Math.cos and Math.sin
## Complex Instance Methods:
- inspect, to_s: string representation methods for debugging and display
with proper formatting of real and imaginary parts
- +@, -@: unary plus and minus operators for identity and negation
- <=>: spaceship operator for comparison with other numeric types,
enables Comparable module functionality with proper nil handling
- abs/magnitude: absolute value (magnitude) calculation using hypot
- abs2: square of absolute value for performance-critical calculations
- arg/angle/phase: argument (angle) calculation using atan2
- conjugate/conj: complex conjugate operation (negates imaginary part)
- fdiv: floating-point division ensuring float results
- polar: returns [magnitude, angle] array representation
- real?: always returns false for complex numbers
- rectangular/rect: returns [real, imaginary] array representation
- to_c: returns self (identity conversion)
- to_r: converts to rational when imaginary part is zero, raises RangeError otherwise
## Numeric Extension Methods:
- i: creates pure imaginary number (0+num*i) for convenient complex creation
- to_c: converts any numeric to complex with zero imaginary part
Co-authored-by: Atlassian Rovo Dev
The method introduced by #5979 causes a fault by swapping classes.
```console
% bin/mruby -e 'Method = Proc; p Object.method(:inspect)'
zsh: segmentation fault (core dumped) bin/mruby -e 'Method = Proc; p Object.method(:inspect)'
```
After applying this patch, a `TypeError` exception will be raised.
```console
% bin/mruby -e 'Method = Proc; p Object.method(:inspect)'
trace (most recent call last):
[1] -e:1
-e:1:in method: allocation failure of Proc (TypeError)
```
However, if the `mrb_vtype` is the same object, the same care must still be taken as before.
```console
% bin/mruby -e 'Method = Binding; p method(:puts).eval("12345")'
trace (most recent call last):
[1] -e:1
-e:1:in eval: wrong argument type nil (expected Proc) (TypeError)
```
Calling `Class#allocate` with `UnboundMethod#bind_call` usually succeeds without problems.
If this behavior does not make us happy, we can now prohibit it with `MRB_SET_INSTANCE_TT(klass, MRB_TT_UNDEF)`.
At the same time, it applies to the `Binding`, `Complex`, `Data`, `Float`, `Integer`, `Method`, `Rational` and `UnboundMethod` classes.
ref. commit 7f40b645d2
Currently, the build configurations `MRB_USE_COMPLEX` and `MRB_USE_RATIONAL` are not listed in the documentation.
In other words, they are hidden settings.
They are defined in `mrbgems/mruby-{complex,rational}/mrbgem.rake`.
So this patch assumes that it is safe to refer to these functions in core-gems directly from core functions.
However, applications that link with `libmruby_core.a` will have compatibility issues.
In fact, `mrbgems/mruby-bin-mrbc` links with `libmruby_core.a`, so I had to prepare a dummy function.
- `#include <math.h>` is done in `mruby.h`.
Eliminate the need to worry about the `MRB_NO_FLOAT` macro.
- Include mruby header files before standard header files.
If the standard header file is already placed before `mruby.h`, the standard header file added in the future tends to be placed before `mruby.h`.
This change should some reduce the chances of macros that must be defined becoming undefined in C++ or including problematic header files in a particular mruby build configuration.
Running pre-commit with GitHub Actions now gives us more tests and coverage
Remove duplicate GitHub Actions for merge conflicts and trailing whitespace
Remove duplicate checks for markdownlint and yamllint from the GitHub Super-Linter
Add new custom pre-commit hook running with a shell script to sort alphabetically and uniquify codespell.txt
Add new pre-commit hook to check spelling with codespell
https://github.com/codespell-project/codespell
Fix spelling
The GitHub Super Linter is a more robust and better supported
tool than the current GitHub Actions we are using.
Running these checks:
ERROR_ON_MISSING_EXEC_BIT: true
VALIDATE_BASH: true
VALIDATE_BASH_EXEC: true
VALIDATE_EDITORCONFIG: true
VALIDATE_MARKDOWN: true
VALIDATE_SHELL_SHFMT: true
VALIDATE_YAML: true
https://github.com/marketplace/actions/super-linterhttps://github.com/github/super-linter
Added the GitHub Super Linter badge to the README.
Also updated the pre-commit framework and added
more documentation on pre-commit.
Added one more pre-commit check: check-executables-have-shebangs
Added one extra check for merge conflicts to our
GitHub Actions.
EditorConfig and Markdown linting.
Minor grammar and spelling fixes.
Update linter.yml
- `mrb_num_div_int(mrb,x,y)` -> `mrb_div_int(mrb,x,y)`
- `mrb_num_div_flo(mrb,x,y)` -> `mrb_div_flo(x,y)`
They are internal function not supposed to be used outside of the core.
Tests for (`Float` or `Integer`) `op` `Complex`. Also added test
dependency to `mruby-rational` since `int_div` definition relies on
`Rational` when `MRB_USE_RATIONAL` is defined.
Yukihiro "Matz" Matsumoto