Librería de Indicadores Bursátiles

Descripción

I built the Stock Indicators Library to create a transparent foundation for market research and backtesting in C#. Technical indicators are widely available, but using an external package without understanding its conventions can make research difficult to reproduce. Differences in warm-up periods, missing-value handling, numerical precision, or formula variants can change a result without producing an obvious error. By implementing a compact set of calculations directly, I could define those choices explicitly, test them, and understand how each transformation affected a signal. The project applies my experience in C#, quantitative systems, predictive analytics, and software architecture to the fundamentals beneath a trading experiment.

The core design treats market observations as ordered time-series data with clear field and timestamp semantics. Indicators consume an explicit sequence and return values aligned to that sequence, including a defined policy for periods where insufficient history exists. I avoided APIs that silently reorder data or hide initialization behavior. This contract-first approach reflects my distributed-systems and data-engineering experience: ordering, identity, and missing state are part of the data, not incidental details. When a research result depends on a moving window, the library makes the window and its readiness visible so downstream strategies can distinguish an unavailable value from a meaningful zero.

Each indicator is implemented as deterministic math with a narrow responsibility. Moving averages, momentum measures, volatility calculations, and related transformations can be composed without embedding portfolio decisions inside the calculation layer. That separation matters because an indicator is evidence, not a strategy. My AI Trading Strategies studies reinforced the need to distinguish feature construction, signal logic, position sizing, execution assumptions, and evaluation. Keeping these layers independent makes it possible to test whether a calculation is correct before debating whether the resulting signal has value in a particular market regime.

Numerical correctness receives more attention than visual plausibility. A chart can look reasonable even when a boundary condition or denominator is wrong. I use known input sequences, manually verifiable examples, comparisons across equivalent formulations, and tests for constant, rising, falling, sparse, and short series. Floating-point tolerances are explicit rather than chosen only after a test fails. This approach draws on my experience with unit testing and production diagnostics: validation should target the assumptions most likely to create a believable but incorrect result, especially when the output may influence a financial decision.

Backtesting introduces additional risks that the library is designed not to obscure. A calculation must not use future observations, and a strategy must account for the difference between the time a signal is known and the time a trade could occur. Warm-up data, market gaps, transaction costs, survivorship bias, and parameter selection remain responsibilities of the research system around the indicators. My work in deep learning, reinforcement learning, and predictive AI makes this boundary especially important. More sophisticated models do not repair contaminated data or unrealistic evaluation; they can amplify those problems while making them harder to notice.

Performance is addressed through straightforward algorithms, bounded allocations, and APIs that can be used repeatedly during simulation. I prefer clarity first, then measure before optimizing. Some rolling calculations can reuse prior state rather than recomputing an entire window, but that optimization must preserve the same result and reset behavior. C# provides a useful balance of strong typing, mature tooling, and runtime performance for this work. The library can participate in larger .NET research, simulation, and service applications without introducing a separate runtime solely for basic indicator computation.

Security and operational discipline still apply even though the library itself does not place trades. Data sources should be traceable, external inputs validated, and research configurations versioned. Results should record the indicator parameters and data interval that produced them. If the library is exposed through a service, callers need bounded requests so an arbitrary window or series size cannot consume unlimited resources. These considerations reflect my security-engineering and resilient-architecture background. A trustworthy financial tool is not defined only by correct formulas; it also makes assumptions, provenance, and resource limits visible to the systems and people using it.

The project gave me a controlled environment for connecting software craftsmanship with quantitative reasoning. It applies knowledge from C# and .NET, deterministic systems, time-series analysis, AI trading strategies, machine learning, backtesting, and test design without claiming that indicators can predict markets reliably on their own. Its value is a transparent research component whose behavior can be inspected, reproduced, and challenged. That foundation supports better experimentation because it reduces ambiguity: when a strategy behaves unexpectedly, I can examine the data, calculation, signal, and evaluation as separate layers instead of treating a third-party indicator as an unquestioned black box.