Repository navigation
Conversation
…thon and added rayon parralelization to local_krige
| let mut tree: KdTree<f64, usize, Vec<f64>> = KdTree::new(dim); | ||
| for i in 0..cond_no { | ||
| tree.add(cond_pos.column(i).to_vec(), i) | ||
| .expect("cond_pos columns are finite and match `dim`"); | ||
| } |
There was a problem hiding this comment.
The kdtree crate is a somewhat involved implementation of the basic idea. You do not seem to actually require anything from the "bucket point-region implementation" or even mutability at all and hence could use a much simpler and likely more efficient implementation. For example, both kd-tree and sif-kdtree would seem to fit that bill.
Of course, the dimension is not strictly fixed by this interface and the simpler crates usually require a compile-time dimension. IIRC, GSTools do not really support arbitrary dimensions here anyway? Hence specialising the implementation for 2 and 3 dimensions (using const generics) and just dynamically dispatching into those entry points might generally be preferable as it avoids the overhead of many short Vec<f64>.
| .num_threads(num_threads.unwrap_or(rayon::current_num_threads())) | ||
| .build() | ||
| .unwrap() | ||
| .install(|| { |
There was a problem hiding this comment.
Why build a dedicated thread pool using the defaults here instead of relying on the ambient and/or global pool to parallelise as appropriate?
| fn euclidean_dist(a: ArrayView1<'_, f64>, b: ArrayView1<'_, f64>) -> f64 { | ||
| a.iter() | ||
| .zip(b.iter()) // (&f64, &f64) | ||
| .map(|(x, y)| (x - y) * (x - y)) // |(x, y)| is type for closure |
There was a problem hiding this comment.
It is usually preferable to zip array views directly instead of immediately falling down to standard iterators as this will mean ndarray's own iteration and loop unrolling idioms can be brought to bear which more closely target numeric code.
No description provided.