Describe the bug
Describe the bug
In HRF-Engine/generalized_hrf_v2.py, the physics-informed kernels (wave_resonance_kernel, fourier_resonance_kernel, and morlet_wavelet_kernel) are implemented as custom kernel functions for the Support Vector Classifiers (Units 16, 17, and 18).
Currently, these functions compute the Euclidean distance mathematically as follows:
python
from sklearn.metrics.pairwise import euclidean_distances
dist = euclidean_distances(X, Y)
return np.cos(omega * dist) * np.exp(-(dist ** 2) / 2)
The Core Problem: During training or inference, euclidean_distances(X, Y) attempts to compute and allocate the full $N \times M$ dense distance matrix in RAM/VRAM at once. If a user passes a dataset of just 50,000 samples, euclidean_distances attempts to allocate a $50,000 \times 50,000$ float64 array in a single operation. This requires exactly 20 Gigabytes of contiguous Memory.
On any standard GPU or consumer CPU, this immediately triggers a CUDA Out Of Memory (OOM) error or system swap-crash, completely breaking the BEAST_18D pipeline on datasets that are even moderately sized.
Steps to reproduce
1.Switch to the gssoc-2026 branch.
2.Initialize the HarmonicResonanceClassifier_BEAST_18D (which loads the custom kernel units).
3.Create a mock dataset with 50,000 rows (X = np.random.rand(50000, 20)).
4.Attempt to run .fit(X, y) or .predict(X).
5.Observe the system crash with a MemoryError or cudaErrorMemoryAllocation when the custom kernel evaluates euclidean_distances(X, Y).
Expected behavior
Instead of loading the entire dense distance matrix into memory at once, the kernel evaluations must be memory-safe and scalable.
The algorithm should either:
Use sklearn.metrics.pairwise_distances_chunked to compute the cosine/exponential transformations iteratively.
Manually slice X and Y into generator chunks (e.g., 2048 rows at a time), compute the operations on that small chunk, and yield the result.
Describe the bug
Describe the bug
In HRF-Engine/generalized_hrf_v2.py, the physics-informed kernels (wave_resonance_kernel, fourier_resonance_kernel, and morlet_wavelet_kernel) are implemented as custom kernel functions for the Support Vector Classifiers (Units 16, 17, and 18).
Currently, these functions compute the Euclidean distance mathematically as follows:
python$N \times M$ dense distance matrix in RAM/VRAM at once. If a user passes a dataset of just 50,000 samples, euclidean_distances attempts to allocate a $50,000 \times 50,000$ float64 array in a single operation. This requires exactly 20 Gigabytes of contiguous Memory.
from sklearn.metrics.pairwise import euclidean_distances
dist = euclidean_distances(X, Y)
return np.cos(omega * dist) * np.exp(-(dist ** 2) / 2)
The Core Problem: During training or inference, euclidean_distances(X, Y) attempts to compute and allocate the full
On any standard GPU or consumer CPU, this immediately triggers a CUDA Out Of Memory (OOM) error or system swap-crash, completely breaking the BEAST_18D pipeline on datasets that are even moderately sized.
Steps to reproduce
1.Switch to the gssoc-2026 branch.
2.Initialize the HarmonicResonanceClassifier_BEAST_18D (which loads the custom kernel units).
3.Create a mock dataset with 50,000 rows (X = np.random.rand(50000, 20)).
4.Attempt to run .fit(X, y) or .predict(X).
5.Observe the system crash with a MemoryError or cudaErrorMemoryAllocation when the custom kernel evaluates euclidean_distances(X, Y).
Expected behavior
Instead of loading the entire dense distance matrix into memory at once, the kernel evaluations must be memory-safe and scalable.
The algorithm should either:
Use sklearn.metrics.pairwise_distances_chunked to compute the cosine/exponential transformations iteratively.
Manually slice X and Y into generator chunks (e.g., 2048 rows at a time), compute the operations on that small chunk, and yield the result.