A native, multi-language scientific computing stack built from scratch around performance, reliability and numerical control.
DracoLIX is an open-source scientific computing project developed by Draconis Engineering.
The goal is to build a high-performance numerical computing stack spanning linear algebra, numerical methods, scientific simulation and HPC, with a particular focus on giving the developer direct control over data types, memory layout and computation.
DracoLIX is designed to be independent of NumPy and similar numerical runtimes. Instead of wrapping an existing numerical backend, DracoLIX aims to provide its own array types, dtype system, memory model and computational kernels.
The project is currently in an early stage. At present, the implementation is focused primarily on matrix operations, but the architecture is being developed with a much larger scientific computing ecosystem in mind.
Scientific computing is built on numerical primitives.
Matrices, vectors, tensors, numerical solvers and differential equations form the foundation of everything from engineering simulations to data analysis and computational physics.
DracoLIX aims to provide that foundation for the Draconis Engineering ecosystem.
The long-term vision is a platform capable of powering:
- Linear algebra
- Numerical analysis
- Scientific simulation
- Optimization
- Differential equations
- CFD
- Engineering computation
- High-performance data analysis
- HPC workloads
The core principle is simple:
Build the numerical infrastructure instead of depending on it.
DracoLIX is designed as a multi-language system where each language has a specific role.
DracoLIX
│
┌──────────┴──────────┐
▼ ▼
Public APIs Core Runtime
│ │
┌────────┼────────┐ │
│ │ │ │
Python Julia (C++) │
│ │ │ │
└────────┴────────┴─┬──────────┘
▼
DracoLIX C++ Core
│
┌─────────────┼─────────────┐
│ │ │
Arrays DTypes Memory
│ │ │
└─────────────┼─────────────┘
▼
Compute Runtime
│
┌─────────────┴─────────────┐
│ │
C++ Kernels Fortran Kernels (optional)
│ │
└─────────────┬─────────────┘
▼
CPU / SIMD
C++ forms the foundation of DracoLIX.
It is responsible for:
- Core data structures
- Memory management
- Array implementations
- DType system
- Runtime and dispatch
- Parallel execution
- SIMD-oriented computation
- Language bindings
- Performance-critical kernels
C++ provides the systems-level control required to make DracoLIX independent of external numerical runtimes.
Fortran is an optional HPC backend. Enabled via -DDRACOLIX_USE_FORTRAN=ON at build time; off by default.
It is intended for:
- Numerical kernels
- Scientific algorithms
- Linear algebra
- Numerical solvers
- Future HPC functionality
Where appropriate, Fortran and C++ communicate through well-defined native interfaces (iso_c_binding).
Python is one of the primary high-level interfaces to DracoLIX.
The Python API is intended to make high-performance numerical computation accessible without requiring users to write Rust or Fortran.
Python bindings are implemented directly against the DracoLIX core rather than relying on NumPy as an underlying execution engine.
import dracolix as dlx
A = dlx.matrix(
[[1.0, 2.0],
[3.0, 4.0]],
dtype=dlx.f64
)
B = dlx.matrix(
[[5.0, 6.0],
[7.0, 8.0]],
dtype=dlx.f64
)
C = A @ BJulia is planned as a first-class scientific computing interface.
Julia's strengths in numerical programming make it particularly suitable for:
- Scientific research
- Mathematical experimentation
- Numerical methods
- Differential equations
- Optimization
- Simulation
The Julia interface should communicate directly with the DracoLIX core rather than passing through Python.
One of the core goals of DracoLIX is to provide its own numerical type system.
DracoLIX should not require NumPy's dtype system to represent numerical data.
Instead:
dlx.f32
dlx.f64
dlx.i32
dlx.i64
dlx.c64
dlx.c128would represent native DracoLIX types.
Conceptually:
DType
│
┌───────────┼───────────┐
▼ ▼ ▼
Integer Float Complex
│ │ │
i8/i16/... f32/f64 c64/c128
The DType system is intended to become part of the DracoLIX runtime itself.
This allows the runtime to make decisions based on:
- Element size
- Alignment
- Numerical representation
- SIMD compatibility
- Kernel availability
- Memory requirements
- Future accelerator support
The goal is to build a numerical type system designed around DracoLIX's own execution model, not just copy NumPy.
DracoLIX will provide its own numerical data structures.
dlx.Array
dlx.Vector
dlx.Matrix
dlx.TensorThese structures will own and manage their underlying memory through the DracoLIX runtime.
A conceptual array representation might contain:
Array<T>
├── data
├── shape
├── strides
├── dtype
└── layout
This gives DracoLIX control over important performance characteristics such as:
- Contiguous memory
- Strided views
- Row-major and column-major layouts
- Memory alignment
- Cache efficiency
- SIMD compatibility
- Zero-copy views
- Slicing
- Parallel access
This is a deliberate design choice.
DracoLIX should not simply become:
Python
↓
NumPy
↓
C
↓
Rust
Instead:
Python
↓
nanobind
↓
DracoLIX Core
↓
Native Kernels
↓
CPU / SIMD / HPC
The long-term architecture separates what is being calculated from how it is calculated.
For example, a high-level operation might request:
C = A @ BThe runtime can then determine the appropriate implementation based on:
- DType
- Matrix dimensions
- Memory layout
- Hardware capabilities
- Available kernels
- Parallel execution options
Conceptually:
Matrix Multiplication
│
▼
Kernel Dispatch
│
┌───────────┼───────────┐
▼ ▼ ▼
Scalar SIMD Parallel
│ │ │
└───────────┼───────────┘
▼
Native Code
This dispatch architecture is intended to become increasingly important as DracoLIX grows beyond basic linear algebra.
DracoLIX is intended to grow incrementally.
- Native DTypes
- Arrays
- Vectors
- Matrices
- Tensors
- Memory management
- Views and slicing
- Basic arithmetic
- Matrix multiplication
- Vector operations
- Decompositions
- Linear system solvers
- Eigenvalue problems
- Sparse matrices
- Advanced matrix algorithms
- Numerical integration
- Interpolation
- Optimization
- Root finding
- ODE solvers
- PDE solvers
- Numerical differentiation
- Scientific simulation
- Computational physics
- Engineering workloads
- CFD
- Large-scale numerical analysis
Future research areas may include:
- Advanced SIMD
- Multithreading
- GPU acceleration
- Distributed computation
- MPI
- Domain decomposition
- Large-scale simulation
These features are long-term goals, not current capabilities.
DracoLIX is intended to become the numerical computation backbone of Draconis Engineering.
Draconis
│
┌──────────┼──────────┐
│ │ │
Olympus DuraPy ICARUS
│ │ │
└──────────┼──────────┘
│
DracoLIX
│
Numerical Computation
Olympus Analytics Engine will be one of the first major consumers of DracoLIX.
As Olympus processes increasingly large quantities of training and physiological data, DracoLIX can provide the numerical foundation for:
- Time-series analysis
- Statistical calculations
- Signal processing
- Rolling computations
- Training-load calculations
- Numerical models
- Large-scale historical analysis
Olympus understands the domain.
DracoLIX handles the mathematics.
DuraPy can use DracoLIX as its numerical backend for high-performance scientific and endurance-sports computation.
ICARUS can use DracoLIX when numerical computation becomes part of an agent workflow, allowing the agent to delegate computationally intensive operations to a native numerical engine.
DracoLIX should own its core numerical representation rather than simply wrapping another numerical library.
Performance matters.
Memory layout, cache behavior, SIMD, parallelism and algorithmic complexity should be considered fundamental parts of the architecture.
Numerical software must be predictable.
Correctness, testing, numerical stability and deterministic behavior are core concerns.
Different languages are good at different things.
DracoLIX embraces Python, Julia, Rust and Fortran instead of forcing everything into one language.
DracoLIX is fully open source.
The goal is to build a transparent numerical computing stack that can be studied, modified and extended by others.
DracoLIX should consist of smaller components rather than becoming one enormous monolithic library.
dracolix-core
dracolix-array
dracolix-linalg
dracolix-solver
dracolix-runtime
dracolix-python
dracolix-julia
...
The exact crate/package structure may evolve as the project develops.
DracoLIX is experimental and heavily under development.
Current functionality is limited compared to the long-term vision.
At the moment, the project primarily contains early implementations of numerical operations such as matrix multiplication.
The architecture and roadmap described above represent the direction of the project, not a claim that all of these capabilities currently exist.
- Project foundation
- C++ numerical core
- Initial Python interface (nanobind binding)
- Matrix multiplication prototype
- Native DType system
- Native Array / Matrix types
- Memory layout system
- Better benchmarking infrastructure
- SIMD kernels
- Parallel execution
- Expanded linear algebra (matmul, matvec, dot, norms, diag, batched)
- Sparse matrices
- Numerical solvers
- Julia interface
- ODE/PDE tooling
- Optimization
- Scientific simulation
- CFD
- GPU acceleration
- Distributed HPC
The roadmap is intentionally ambitious.
Not every feature is guaranteed to be implemented, and priorities may change as the project evolves.
DracoLIX started as a simple linear algebra library.
The long-term goal is considerably larger.
Instead of building another abstraction layer around existing numerical software, DracoLIX aims to explore what a modern, native, multi-language scientific computing stack could look like when the numerical runtime itself is designed from the ground up.
Own the data. Own the types. Own the computation.
DracoLIX is open source and intended to remain freely available to the community.
See the repository license for details.