You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Does it make sense to add a zip function to array-like types? Doing so will make it less error-prone to do custom element wise operations:
/// Compute the element wise minimum. If any of the elements are incomparable,/// the element from v2 is returned.fnvec3_ew_min<T:PartialOrd>(v1:Vector3<T>,v2:Vector3<T>) -> Vector3<T>{Vector3::zip(v1, v2, |a, b| if a < b { a }else{ b })}
Motivation
I tried to write a simple axis aligned bounding box data structure today which requires keeping track of the min_x, max_x, min_y, etc. I figured I'd use a Point3 for the min and max values but couldn't find a nice way to compute the element wise minimum and maximum. We could consider adding those to the ElementWise trait but since floating-point values aren't Ord we would have to make choices that are best left for the library consumers to make. Having zip would be fairly natural seeing that map is already there.
It is possible to have v2 be a different type but I have a feeling there aren't many use cases for that.
Additionally I'd like to see a three-way-merge (zipzip?) and fold1 (fold/reduce without initial value) implemented. Writing other operations like the element sum, element product, the dot product becomes quite easy. However, since these methods are generated from macros it would probably introduce unnecessary compiler work.
impl<S>Vector3<S>{fnzipzip<U,F>(self,v2:Self,v3:Self,f:F) -> Vector3<U>whereF:Fn(S,S,S) -> U,{Vector3{x:f(self.x, v2.x, v3.x),y:f(self.y, v2.y, v3.y),z:f(self.z, v2.z, v3.z),}}}fnvec3_ew_clamp<T:PartialOrd>(v:Vector3<T>,min:Vector3<T>,max:Vector3<T>) -> Vector3<T>{Vector3::zipzip(v, min, max, |s, min, max| {if s < min {
min
}elseif s > max {
max
}else{
s
}})}
It is also possible to generalize these functions into traits which I've experimented here, but perhaps that is going too far.
The text was updated successfully, but these errors were encountered:
486: Implement zip for VectorN and PointN r=kvark a=mickvangelderen
Implements #485.
It is possible but messy to put `map` and `zip` in the Array trait. Rust doesn't support higher kinded types which would help because we want to abstract over any container, holding a fixed number of some item type. The implementation would basically need to reproduce the work in the generic-array crate which is silly.
Co-authored-by: Mick van Gelderen <mickvangelderen@gmail.com>
Does it make sense to add a
zip
function to array-like types? Doing so will make it less error-prone to do custom element wise operations:Motivation
I tried to write a simple axis aligned bounding box data structure today which requires keeping track of the min_x, max_x, min_y, etc. I figured I'd use a
Point3
for the min and max values but couldn't find a nice way to compute the element wise minimum and maximum. We could consider adding those to the ElementWise trait but since floating-point values aren'tOrd
we would have to make choices that are best left for the library consumers to make. Havingzip
would be fairly natural seeing thatmap
is already there.Implementation
In its simplest form we would add:
It is possible to have v2 be a different type but I have a feeling there aren't many use cases for that.
Additionally I'd like to see a three-way-merge (zipzip?) and fold1 (fold/reduce without initial value) implemented. Writing other operations like the element sum, element product, the dot product becomes quite easy. However, since these methods are generated from macros it would probably introduce unnecessary compiler work.
It is also possible to generalize these functions into traits which I've experimented here, but perhaps that is going too far.
The text was updated successfully, but these errors were encountered: