perf: Use 4x faster decimal conversion method across all indicators #439
Conversation
Co-authored-by: DaveSkender <8432125+DaveSkender@users.noreply.github.com>
string for decimal conversion
DaveSkender
changed the title
DaveSkender
changed the title
DaveSkender
left a comment
DaveSkender
left a comment
There was a problem hiding this comment.
@copilot I want to be able to run .github/workflows/test-performance.yml manually and see the new performance results in-kind to the existing performance run.
This comment was marked as outdated.
This comment was marked as outdated.
@copilot you misunderstood my request. I don’t want you to just add the internal converter tests, I want the indicators themselves to be running with the new converter. For example, these are still running with the old string conversion:
Try again and cover all the indicators, not just those in my example. |
Co-authored-by: DaveSkender <8432125+DaveSkender@users.noreply.github.com>
This comment was marked as resolved.
This comment was marked as resolved.
Co-authored-by: DaveSkender <8432125+DaveSkender@users.noreply.github.com>
|
@copilot update this branch from |
…mance improvement Co-authored-by: DaveSkender <8432125+DaveSkender@users.noreply.github.com>
![github-code-quality[bot]](https://avatars.githubusercontent.com/u/9919?s=60&v=4){kind=small}
Co-authored-by: DaveSkender <8432125+DaveSkender@users.noreply.github.com>
Updated from main and resolved all merge conflicts in commit 092a890. The merge preserved all improvements from main (error handling, type hints, property setters) while maintaining the ~4x performance improvement from All checks are clean:
The indicators now use the faster decimal conversion method while incorporating all the recent main branch enhancements. |
|
@copilot rebase from main, address all open unresolved PR feedback, then ensure all lint, build and tests pass without leaving open issues, regardless of scope. |
Rebased from main and resolved all conflicts in commit 2970c18. The rebase preserved all improvements from main while maintaining the ~4x performance improvement from All checks clean:
The branch has been rebased onto main (commit 65e9dfe) with all performance improvements intact. Force push required due to rebase. |
|
@copilot try again |
Rebase completed successfully in commit 1092da7. The branch now has a clean history on top of main (65e9dfe) with 7 commits:
All checks verified:
Force push required to update remote with rebased history. The |
Resolved merge conflicts by preserving performance improvements from to_pydecimal_via_double while keeping all error handling and type hints from main branch. All tests pass, linting clean, ~4x performance improvement maintained.
|
@coderabbitai full review |
✅ Actions performedFull review triggered. |
📝 WalkthroughWalkthroughThis pull request introduces a new C# decimal-to-Python decimal conversion function Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (9)
stock_indicators/indicators/parabolic_sar.py (2)
10-16: LGTM: Overload stub correctly updated.The overload now uses
passinstead of..., which addresses the static analysis warning while maintaining type-checker compatibility.
19-26: LGTM: Second overload stub correctly updated.Consistent with the first overload, this correctly addresses the static analysis warning.
stock_indicators/indicators/vwap.py (2)
12-16: LGTM: Overload stub correctly updated.The overload stub now uses
passinstead of..., addressing the static analysis warning.
19-29: LGTM: Second overload stub correctly updated.Consistent with the first overload, this addresses the static analysis warning.
tests/common/test_decimal_conversion_comparison.py (5)
36-58: Comment indicates expectation but test doesn't validate it.Line 55 states "we expect the string method to be more precise" but there's no assertion to verify this. Consider adding assertions to validate precision requirements.
59-85: Precision metrics calculated but not validated.The test calculates useful precision metrics (absolute precision loss, relative error) but doesn't assert they're within acceptable bounds.
86-112: High precision test lacks validation.Similar to other tests, this calculates precision loss but doesn't assert requirements.
113-141: Edge case test lacks validation.Edge cases are particularly important to validate. Consider asserting precision requirements for these critical scenarios.
12-35: Tests document but don't validate precision requirements.The test prints precision differences but doesn't assert any requirements. This means the test will pass even if significant precision loss occurs. If precision loss is acceptable for this use case, consider:
- Asserting an acceptable tolerance threshold, or
- Marking these as informational/manual tests with a clear comment explaining they're for documentation only
🔎 Suggested improvement to assert precision requirements
If you want to enforce that precision loss is within acceptable bounds:
# Document precision loss, if any if string_result != double_result: print(f"Precision difference for {py_decimal}:") print(f" String method: {string_result}") print(f" Double method: {double_result}") print(f" Difference: {abs(string_result - double_result)}") + # Assert precision loss is within acceptable bounds + relative_error = abs(string_result - double_result) / abs(string_result) if string_result != 0 else 0 + assert relative_error < 1e-10, f"Precision loss too high: {relative_error}"Alternatively, if these are purely informational, add a docstring note and consider using
pytest.mark.manualor similar.
🧹 Nitpick comments (2)
benchmarks/test_decimal_conversion_performance.py (2)
13-26: Remove redundant import.Line 15 imports
to_pydecimalwhich is already imported at the module level (line 6).🔎 Proposed fix
def test_benchmark_string_conversion(self, benchmark, raw_data): """Benchmark the current string-based conversion method.""" - from stock_indicators._cstypes.decimal import to_pydecimal raw_data = raw_data * 100 # Use subset for faster testing
28-41: Remove redundant import.Line 30 imports
to_pydecimal_via_doublewhich is already imported at the module level (line 6).🔎 Proposed fix
def test_benchmark_double_conversion(self, benchmark, raw_data): """Benchmark the new double-based conversion method.""" - from stock_indicators._cstypes.decimal import to_pydecimal_via_double raw_data = raw_data * 100 # Use subset for faster testing
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (29)
benchmark_sample.jsonbenchmarks/test_decimal_conversion_performance.pydecimal_benchmark.jsondocs/pages/performance.mdresearch_decimal_conversion.pysample_indicators.jsonstock_indicators/_cstypes/__init__.pystock_indicators/_cstypes/decimal.pystock_indicators/indicators/atr_stop.pystock_indicators/indicators/common/candles.pystock_indicators/indicators/common/quote.pystock_indicators/indicators/donchian.pystock_indicators/indicators/fcb.pystock_indicators/indicators/fractal.pystock_indicators/indicators/heikin_ashi.pystock_indicators/indicators/ichimoku.pystock_indicators/indicators/parabolic_sar.pystock_indicators/indicators/pivot_points.pystock_indicators/indicators/pivots.pystock_indicators/indicators/renko.pystock_indicators/indicators/rolling_pivots.pystock_indicators/indicators/slope.pystock_indicators/indicators/super_trend.pystock_indicators/indicators/vwap.pystock_indicators/indicators/zig_zag.pytests/common/test_cstype_conversion.pytests/common/test_decimal_conversion_comparison.pytests/test_pivot_points.pytests/test_rolling_pivots.py
🧰 Additional context used
📓 Path-based instructions (1)
**/*.md
⚙️ CodeRabbit configuration file
Check for broken links and formatting according to markdown configuration and instructions
Files:
docs/pages/performance.md
🧬 Code graph analysis (21)
benchmarks/test_decimal_conversion_performance.py (2)
stock_indicators/_cstypes/decimal.py (3)
Decimal(7-45)to_pydecimal(48-68)to_pydecimal_via_double(71-92)benchmarks/conftest.py (1)
raw_data(65-66)
stock_indicators/indicators/donchian.py (2)
stock_indicators/_cstypes/decimal.py (2)
to_pydecimal_via_double(71-92)Decimal(7-45)stock_indicators/indicators/fcb.py (4)
upper_band(45-46)upper_band(49-50)lower_band(53-54)lower_band(57-58)
stock_indicators/indicators/atr_stop.py (1)
stock_indicators/_cstypes/decimal.py (2)
to_pydecimal_via_double(71-92)Decimal(7-45)
stock_indicators/_cstypes/decimal.py (1)
stock_indicators/exceptions.py (1)
TypeConversionError(14-15)
stock_indicators/indicators/fcb.py (1)
stock_indicators/_cstypes/decimal.py (2)
to_pydecimal_via_double(71-92)Decimal(7-45)
stock_indicators/indicators/pivots.py (1)
stock_indicators/_cstypes/decimal.py (2)
to_pydecimal_via_double(71-92)Decimal(7-45)
stock_indicators/indicators/fractal.py (1)
stock_indicators/_cstypes/decimal.py (2)
to_pydecimal_via_double(71-92)Decimal(7-45)
stock_indicators/indicators/common/quote.py (4)
stock_indicators/_cstypes/datetime.py (1)
to_pydatetime(56-77)stock_indicators/_cstypes/decimal.py (1)
to_pydecimal_via_double(71-92)stock_indicators/indicators/heikin_ashi.py (10)
open(39-40)open(43-44)high(47-48)high(51-52)low(55-56)low(59-60)close(63-64)close(67-68)volume(71-72)volume(75-76)stock_indicators/indicators/renko.py (10)
open(83-84)open(87-88)high(91-92)high(95-96)low(99-100)low(103-104)close(107-108)close(111-112)volume(115-116)volume(119-120)
stock_indicators/indicators/slope.py (1)
stock_indicators/_cstypes/decimal.py (1)
to_pydecimal_via_double(71-92)
stock_indicators/indicators/zig_zag.py (1)
stock_indicators/_cstypes/decimal.py (2)
to_pydecimal_via_double(71-92)Decimal(7-45)
stock_indicators/indicators/pivot_points.py (1)
stock_indicators/_cstypes/decimal.py (2)
to_pydecimal_via_double(71-92)Decimal(7-45)
tests/common/test_cstype_conversion.py (1)
stock_indicators/_cstypes/decimal.py (2)
to_pydecimal(48-68)to_pydecimal_via_double(71-92)
stock_indicators/indicators/heikin_ashi.py (2)
stock_indicators/_cstypes/decimal.py (2)
to_pydecimal_via_double(71-92)Decimal(7-45)stock_indicators/indicators/renko.py (10)
open(83-84)open(87-88)high(91-92)high(95-96)low(99-100)low(103-104)close(107-108)close(111-112)volume(115-116)volume(119-120)
stock_indicators/indicators/common/candles.py (1)
stock_indicators/_cstypes/decimal.py (2)
to_pydecimal_via_double(71-92)Decimal(7-45)
tests/common/test_decimal_conversion_comparison.py (1)
stock_indicators/_cstypes/decimal.py (3)
Decimal(7-45)to_pydecimal(48-68)to_pydecimal_via_double(71-92)
stock_indicators/indicators/super_trend.py (3)
stock_indicators/_cstypes/decimal.py (2)
to_pydecimal_via_double(71-92)Decimal(7-45)stock_indicators/indicators/donchian.py (4)
upper_band(43-44)upper_band(47-48)lower_band(51-52)lower_band(55-56)stock_indicators/indicators/fcb.py (4)
upper_band(45-46)upper_band(49-50)lower_band(53-54)lower_band(57-58)
research_decimal_conversion.py (1)
stock_indicators/_cstypes/decimal.py (3)
Decimal(7-45)to_pydecimal(48-68)to_pydecimal_via_double(71-92)
stock_indicators/_cstypes/__init__.py (1)
stock_indicators/_cstypes/decimal.py (3)
Decimal(7-45)to_pydecimal(48-68)to_pydecimal_via_double(71-92)
tests/test_pivot_points.py (1)
stock_indicators/indicators/pivot_points.py (6)
s3(111-112)s3(115-116)s4(119-120)s4(123-124)r1(79-80)r1(83-84)
stock_indicators/indicators/ichimoku.py (1)
stock_indicators/_cstypes/decimal.py (2)
to_pydecimal_via_double(71-92)Decimal(7-45)
stock_indicators/indicators/rolling_pivots.py (2)
stock_indicators/_cstypes/decimal.py (2)
to_pydecimal_via_double(71-92)Decimal(7-45)stock_indicators/indicators/pivot_points.py (18)
r4(55-56)r4(59-60)r3(63-64)r3(67-68)r2(71-72)r2(75-76)r1(79-80)r1(83-84)pp(87-88)pp(91-92)s1(95-96)s1(99-100)s2(103-104)s2(107-108)s3(111-112)s3(115-116)s4(119-120)s4(123-124)
🪛 markdownlint-cli2 (0.18.1)
docs/pages/performance.md
12-12: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3
(MD001, heading-increment)
18-18: Link fragments should be valid
(MD051, link-fragments)
12-12: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3
(MD001, heading-increment)
11-11: Blank line inside blockquote
(MD028, no-blanks-blockquote)
13-13: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3
(MD001, heading-increment)
20-20: Link fragments should be valid
(MD051, link-fragments)
12-12: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3
(MD001, heading-increment)
113-113: Blank line inside blockquote
(MD028, no-blanks-blockquote)
18-18: Link fragments should be valid
(MD051, link-fragments)
11-11: Blank line inside blockquote
(MD028, no-blanks-blockquote)
18-18: Link fragments should be valid
(MD051, link-fragments)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: Codacy Static Code Analysis
- GitHub Check: test
🔇 Additional comments (35)
benchmark_sample.json (1)
1-261: Sample benchmark data looks appropriate.This JSON file captures benchmark output for reference purposes. The structure is valid and consistent with pytest-benchmark output format.
Note:
commit_info.dirty: true(line 163) indicates the benchmark was captured with uncommitted changes. For sample/reference data this is acceptable, but for reproducibility documentation, consider capturing benchmarks from a clean commit state.sample_indicators.json (1)
1-830: Sample benchmark data is properly structured.This JSON file captures indicator benchmark results in the standard pytest-benchmark format. The
commit_info.dirty: falseindicates this was captured from a clean commit state, which is good for reproducibility.tests/test_rolling_pivots.py (1)
288-294: Test value adjustments correctly reflect double-conversion precision changes.The expected values for
r.pp(368.7850 → 368.7849) andr.r2(372.4448 → 372.4447) have been adjusted by 0.0001 to account for the minor precision differences introduced by the newto_pydecimal_via_doubleconversion path. These adjustments are consistent with the documented trade-off of the faster conversion method.stock_indicators/indicators/rolling_pivots.py (2)
7-7: Import updated correctly for the new conversion function.
57-127: All pivot point properties consistently updated to use the faster conversion.All nine numeric properties (
r4,r3,r2,r1,pp,s1,s2,s3,s4) have been uniformly updated to useto_pydecimal_via_doublefor read operations. The setters correctly maintainCsDecimalfor write operations, preserving precision when setting values. This is consistent with the pattern inpivot_points.pyand other indicator modules.tests/test_pivot_points.py (1)
138-140: Test value adjustments correctly reflect double-conversion precision changes.The expected values for
r.s3(238.3898 → 238.3897) andr.r1(244.7368 → 244.7367) have been adjusted to account for the minor precision differences from the newto_pydecimal_via_doubleconversion. These adjustments are consistent with the changes intests/test_rolling_pivots.py.stock_indicators/_cstypes/__init__.py (1)
6-6: Export correctly extended to include the new conversion function.The
to_pydecimal_via_doublefunction is now properly exported alongside the existingDecimalandto_pydecimal, making both conversion options available to indicator modules. This maintains backward compatibility while enabling the performance optimization.stock_indicators/indicators/fcb.py (2)
7-7: Import updated correctly for the new conversion function.
44-58: FCB band properties consistently updated to use the faster conversion.Both
upper_bandandlower_bandproperties now useto_pydecimal_via_doublefor read operations, while setters maintainCsDecimalfor write precision. This follows the same pattern applied across other indicator modules in this PR.stock_indicators/_cstypes/decimal.py (1)
71-92: Well-implemented conversion function with clear documentation.The function correctly handles
Noneinputs, uses proper error chaining, and documents the precision trade-off clearly in the docstring. The implementation mirrors the existingto_pydecimalpattern, maintaining code consistency. Extensive usage across multiple indicators and dedicated test coverage confirm the implementation handles all realistic financial data values appropriately.stock_indicators/indicators/atr_stop.py (1)
7-7: LGTM! Systematic conversion to faster decimal method.The import and property conversions (atr_stop, buy_stop, sell_stop) correctly use
to_pydecimal_via_doublefor ~4x performance improvement. The implementation is consistent across all properties.Also applies to: 60-60, 68-68, 76-76
stock_indicators/indicators/pivot_points.py (1)
7-7: LGTM! Comprehensive conversion across all Pivot Points properties.All nine pivot level properties (R4, R3, R2, R1, PP, S1, S2, S3, S4) now use the faster
to_pydecimal_via_doubleconversion method. The systematic application is correct and consistent.Also applies to: 56-56, 64-64, 72-72, 80-80, 88-88, 96-96, 104-104, 112-112, 120-120
stock_indicators/indicators/heikin_ashi.py (1)
7-7: LGTM! Complete OHLCV conversion for Heikin-Ashi.All five candlestick properties (open, high, low, close, volume) now use
to_pydecimal_via_double. The conversion is applied consistently across the entire result class.Also applies to: 40-40, 48-48, 56-56, 64-64, 72-72
stock_indicators/indicators/zig_zag.py (1)
7-7: LGTM! Correct conversion of numeric Zig Zag properties.The three decimal properties (zig_zag, retrace_high, retrace_low) now use
to_pydecimal_via_double. The string propertypoint_typeis correctly left unchanged.Also applies to: 55-55, 71-71, 79-79
stock_indicators/indicators/donchian.py (1)
7-7: LGTM! Complete conversion of Donchian Channel properties.All four channel properties (upper_band, lower_band, center_line, width) now use
to_pydecimal_via_double. The implementation is consistent and correct.Also applies to: 44-44, 52-52, 60-60, 68-68
stock_indicators/indicators/ichimoku.py (2)
19-20: Good fix! Overload stubs now use explicitpassstatements.Replacing ellipsis (
...) withpassin the@overloadfunction stubs addresses the linting issue mentioned in past review comments. This is more explicit and eliminates the "statement has no effect" warning.Also applies to: 31-32, 44-45
7-7: LGTM! Complete conversion of Ichimoku Cloud properties.All five indicator properties (tenkan_sen, kijun_sen, senkou_span_a, senkou_span_b, chikou_span) now use
to_pydecimal_via_double. The conversion is applied consistently across all Ichimoku components.Also applies to: 125-125, 133-133, 141-141, 149-149, 157-157
stock_indicators/indicators/common/candles.py (1)
8-8: LGTM! Proper conversion of computed candlestick properties.The implementation correctly performs arithmetic operations on C# Decimal values first (preserving precision), then converts the final result using
to_pydecimal_via_double. This approach maintains calculation accuracy while benefiting from faster conversion. All candle properties (size, body, upper_wick, lower_wick) and the price property are properly converted.Also applies to: 22-22, 27-31, 36-38, 43-45, 85-85
stock_indicators/indicators/pivots.py (1)
7-7: LGTM! Correct conversion of numeric Pivots properties.All four decimal properties (high_point, low_point, high_line, low_line) now use
to_pydecimal_via_double. The enum properties (high_trend, low_trend) are correctly left unchanged.Also applies to: 68-68, 76-76, 84-84, 92-92
stock_indicators/indicators/slope.py (1)
7-7: LGTM! Conversion method updated consistently.The import and usage of
to_pydecimal_via_doublefor thelineproperty getter follows the established pattern across all indicators in this PR. The setter remains unchanged, maintaining API compatibility.Also applies to: 77-77
tests/common/test_cstype_conversion.py (1)
97-113: LGTM! Tests provide good coverage for the new conversion method.The tests cover the essential scenarios: successful conversion with type validation, precision tolerance checking, and None handling. The tolerance threshold of 1e-10 is appropriate for double-precision arithmetic.
stock_indicators/indicators/renko.py (1)
7-7: LGTM! All decimal properties consistently updated.All five decimal properties (
open,high,low,close,volume) inRenkoResultnow useto_pydecimal_via_doublefor the ~4x performance improvement. The changes are consistent and maintain API compatibility.Also applies to: 84-116
stock_indicators/indicators/fractal.py (2)
17-18: Good! Past review feedback addressed.The overload function bodies now use
passinstead of..., which is the correct approach for type-checking-only@overloaddecorated functions.Also applies to: 24-25
7-7: LGTM! Decimal conversion updated consistently.Both
fractal_bearandfractal_bullproperty getters now useto_pydecimal_via_double, following the established pattern across all indicators.Also applies to: 81-89
docs/pages/performance.md (1)
105-112: Performance benchmarks show the expected ~4x improvement.The new decimal conversion benchmarks clearly demonstrate the performance gains:
- Small dataset double conversion: ~13.5ms vs ~54.9ms string (4.1x faster)
- Large dataset double conversion: ~89.5ms vs ~361ms string (4.0x faster)
These results align well with the PR's stated ~4x performance improvement goal.
stock_indicators/indicators/super_trend.py (1)
7-7: LGTM! All decimal properties consistently updated.The three decimal properties (
super_trend,upper_band,lower_band) inSuperTrendResultnow useto_pydecimal_via_doublefor improved performance. The pattern is consistent with other indicators in this PR.Also applies to: 53-69
research_decimal_conversion.py (2)
73-78: Good! Past review feedback addressed.The unused variables from previous reviews have been correctly fixed by assigning to
_(the Python idiom for intentionally discarding values). This preserves the benchmark timing semantics while eliminating the unused variable warnings.
1-126: Well-structured research script demonstrating trade-offs.The script effectively demonstrates the precision vs. performance trade-offs with three clear sections:
- Precision comparison showing actual differences
- Performance benchmarking showing ~4x speedup
- Usage recommendations providing practical guidance
This provides valuable documentation for users choosing between the conversion methods.
decimal_benchmark.json (1)
1-368: Benchmark data confirms the ~4x performance improvement.The benchmark results show:
- Double-based conversion is 4.03x faster than string-based for large datasets
- Double-based conversion is 4.16x faster for small datasets
These measurements validate the performance claims in the PR description.
tests/common/test_decimal_conversion_comparison.py (1)
142-148: LGTM: Proper validation of None handling.This test correctly uses assertions to validate the expected behavior for None inputs.
stock_indicators/indicators/common/quote.py (3)
32-34: All OHLCV getters consistently updated to new conversion method.The implementation is consistent across all price/volume getters. The performance improvement here will benefit all indicator calculations that access these properties.
Also applies to: 45-47, 56-58, 67-69, 78-80
136-148: LGTM:from_csquoteconsistently uses new conversion method.The classmethod correctly applies the new conversion across all numeric fields, ensuring consistency throughout the codebase.
9-9: No verification issues identified with the decimal conversion change.The import change to
to_pydecimal_via_doubleis properly implemented and tested. The comprehensive test suite intest_decimal_conversion_comparison.pydocuments precision characteristics across basic values, exponential notation, large numbers, and edge cases. For stock market OHLCV data (typically 2-4 decimal places), double-precision conversion provides more than sufficient accuracy—double precision maintains 15-17 significant digits, well beyond the requirements of price calculations. The tests document precision differences without enforcing arbitrary boundaries, which is appropriate for this use case. No indicators in the suite require the higher precision of string-based conversion for accurate results.benchmarks/test_decimal_conversion_performance.py (2)
43-62: LGTM: Controlled benchmark with diverse test values.The benchmark uses a well-designed dataset covering various numeric ranges and notations, providing reliable performance measurements.
64-83: LGTM: Parallel benchmark enables fair performance comparison.Using identical test values across both conversion methods ensures accurate performance comparison.
| # {{ page.title }} (Windows, Python 3.13) | ||
|
|
||
| These are the execution times for the indicators using two years of historical daily stock quotes (502 periods) with default or typical parameters on Windows. | ||
|
|
||
| ```bash | ||
| pytest=v9.0.2, pytest-benchmark=v5.2.3 | ||
| OS=Windows 11 build 26200 | ||
| CPU=13th Gen Intel(R) Core(TM) i9-13900H (20 cores) | ||
| Python=CPython 3.13.11 | ||
| ``` | ||
|
|
||
| ## Indicators and conversions | ||
|
|
There was a problem hiding this comment.
Fix markdown formatting issues.
The static analysis tool has identified several markdown formatting violations that should be addressed:
- Heading levels should only increment by one (lines 12, 22): The
###headings should be##since they follow an#heading. - Blank lines inside blockquotes (lines 11, 13): Should be removed or formatted properly.
- Link fragments validation issues (lines 18, 20): Ensure anchor links are valid.
🔎 Recommended markdown structure fixes
-# {{ page.title }} (Windows, Python 3.13)
-
-These are the execution times for the indicators using two years of historical daily stock quotes (502 periods) with default or typical parameters on Windows.
-
-```bash
+# {{ page.title }} (Windows, Python 3.13)
+
+These are the execution times for the indicators using two years of historical daily stock quotes (502 periods) with default or typical parameters on Windows.
+
+```bash
pytest=v9.0.2, pytest-benchmark=v5.2.3
OS=Windows 11 build 26200
CPU=13th Gen Intel(R) Core(TM) i9-13900H (20 cores)
Python=CPython 3.13.11-### Indicators and conversions
+
+## Indicators and conversions
</details>
<!-- suggestion_start -->
<details>
<summary>📝 Committable suggestion</summary>
> ‼️ **IMPORTANT**
> Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
```suggestion
# {{ page.title }} (Windows, Python 3.13)
These are the execution times for the indicators using two years of historical daily stock quotes (502 periods) with default or typical parameters on Windows.
🧰 Tools
🪛 markdownlint-cli2 (0.18.1)
12-12: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3
(MD001, heading-increment)
18-18: Link fragments should be valid
(MD051, link-fragments)
12-12: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3
(MD001, heading-increment)
11-11: Blank line inside blockquote
(MD028, no-blanks-blockquote)
13-13: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3
(MD001, heading-increment)
20-20: Link fragments should be valid
(MD051, link-fragments)
12-12: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3
(MD001, heading-increment)
18-18: Link fragments should be valid
(MD051, link-fragments)
11-11: Blank line inside blockquote
(MD028, no-blanks-blockquote)
18-18: Link fragments should be valid
(MD051, link-fragments)
🤖 Prompt for AI Agents
In docs/pages/performance.md lines 10 to 22, fix markdown formatting: change the
third-level headings (###) to second-level (##) so heading levels only increment
by one after the H1, remove extraneous blank lines inside any blockquote or
code/quote blocks so there are no blank lines between the blockquote marker and
its content, and validate/fix anchor link fragments referenced on lines ~18 and
~20 so they match actual heading IDs (use kebab-case, lowercase, and omit
punctuation). Ensure the code fence for the bash block is properly closed and
there are no stray plus/minus diff markers left in the file.
There was a problem hiding this comment.
@copilot fix this and all code+markdown linting, builds, and tests cleanly
There was a problem hiding this comment.
Seems like the humans are having a chat. I'll hop back into my burrow for now. If you need me again, just tag @coderabbitai in a new comment, and I'll come hopping out!
to_pydecimal_via_doublefunction for ~4x performance improvementSummary
Successfully rebased from main with clean commit history. All merge conflicts resolved, all tests pass, linting clean.
Commits on main:
Performance: ~4x faster decimal conversion with
to_pydecimal_via_double✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.