Documentation
Documentation for VectorTA and VectorGrid
The documentation is split the same way the work is split. VectorTA is about indicator computation, exposed interfaces, and execution backends. VectorGrid is about what happens after those indicators become a strategy search problem.
That distinction matters because the wrong reading order wastes time. If the question is formulas, signatures, package setup, or where a feature lives, stay in the docs. If the question becomes architecture, benchmark interpretation, or why a path was designed a certain way, switch to technical insights.
Indicators and execution paths
VectorTA
Start here when the question is still inside the library: what an indicator computes, which parameters matter, what the Rust or Python surface looks like, and whether scalar, SIMD, or CUDA is the right path.
Strategy validation and optimization
VectorGrid
Start here when the work has become a search problem: simulation rules, parameter sweeps, backtest interpretation, and the difference between a result that looks good and one you would actually trust.
Start From The Actual Problem
Organize this section by the problem you are trying to solve right now. The technology labels matter after that.
Understand what an indicator is actually doing
Read the theory page first. Move to the API reference or examples only after you know what the indicator is supposed to mean and just need the callable surface.
Integrate VectorTA into Python or Rust
Start with the integration guide if the immediate problem is packaging, data interchange, build shape, or environment setup before you get deeper into indicator design.
Decide whether CUDA is worth the extra complexity
Read the GPU setup page, then the performance guide, then the technical insights articles. That order matters because setup alone will not tell you whether the benchmark shape matches your workload.
Turn indicators into a strategy you can defend
Start with backtesting fundamentals before you touch optimization. A fast optimizer will happily search a broken simulation and return polished nonsense.
When the work is still inside VectorTA
This part of the docs moves from indicator semantics to executable surfaces. Start with theory if you need formulas and interpretation. Move to the API reference and examples once the job becomes signatures, parameter ranges, return shapes, and concrete outputs.
When the work has become a backtest
This part of the docs is about simulation discipline, execution assumptions, parameter sweeps, and out-of-sample validation. It is where you go once the question stops being indicator usage and starts becoming strategy evidence.
Integration Only Matters After The Product Boundary Is Clear
This is where the docs stop talking about indicator meaning and start talking about process boundaries: packaging, runtime shape, execution backends, and how much complexity the workload actually justifies.
When the problem is packaging and runtime shape
Most users either start from Python for research or from Rust for production integration. These pages are for that boundary: package installation, build mode, deployment target, and when to stop reading setup docs and move back into product docs.
When performance becomes concrete
These pages become useful once performance turns into a real bottleneck. The docs explain supported paths and setup. The technical insights articles cover what those paths cost, where they pay off, and where the benchmark numbers stop carrying over cleanly.
Some Questions Are Really Engineering Notes
Some questions stop being documentation questions. If you want to know why the CUDA path is organized around device residency, how the SIMD kernels are split, or what the benchmark results imply for a real workload, you are already in technical-insights territory. The pages below are the bridge between usage docs and implementation detail.
Architecture overview
Read this when the question is about system shape and execution boundaries at the system level.
Testing best practices
Read this when correctness, parity across CPU and GPU paths, and validation discipline matter more than feature discovery.
Technical insights
Read this when you want the engineering argument: why a path exists, how the benchmarks were shaped, and where the numbers carry over cleanly to real workloads.
Suggested Reading Orders
These are opinionated routes through the material. They are meant to get from question to answer with as few wrong turns as possible.
New to VectorTA
Use this order if you are still learning the shape of the library and want the fastest route from overview to callable surface.
Building a strategy
Read in this order if you are moving from indicators into something that has to survive a backtest and hold up under scrutiny.
Integrating from Python
Use this route when the immediate goal is running the released bindings, checking the package surface, and only then deciding whether you need lower-level performance work.
Evaluating CUDA
This route separates setup from evidence. First confirm the path, then read the benchmark and architecture material before assuming the GPU is the right answer for your workload.
Install The Library, Then Read The Right Page
Keep installation easy. Use the crate or the Python package as the entry point, then go straight to the quickstart or the product page that matches the work you are actually doing.
Rust crate
cargo add vector-ta Python package
python -m pip install vector-ta Three Pages That Prevent Most Wrong Turns
- Technical indicators theory : start here if you need to reason about what the library is computing.
- TA library API reference : open this when you are done with theory and need the callable surface.
- Backtesting fundamentals : read this before you trust any optimized strategy result.
Common Navigation Questions
1. Where do I go for formulas versus code-level usage?
Use the concept pages when you need formulas, interpretation, and indicator behavior. Use the API reference and examples when you need signatures, outputs, and direct execution detail.
2. When should I read the docs, and when should I read the technical insights articles?
Use the docs when the question is how to use a page, API, binding, or workflow. Use technical insights when the question is why the system is built a certain way, what the benchmark setup was, or where the implementation limits still are.
3. Where should I start if I care about strategy validation more than indicators?
Start with backtesting fundamentals, then move to the strategy and optimization tutorials, and only after that read the VectorGrid overview and technical insights pages. That order keeps the simulation contract clear before you optimize it.
4. Is Python a first-class entry point or just a thin wrapper?
Python is a legitimate entry point for research workflows. Start with the Python integration guide and quickstart, then move deeper only if you need a lower-level Rust or CUDA path for the workload you are running.