5 ms·
+1 (don't want general operator overloading, but a more powerful @Vector builtin type, basically Clang's ext_vector_type: https://clang.llvm.org/docs/LanguageEx
by flohofwoe 3y ago
+1 (don't want general operator overloading, but a more powerful @Vector builtin type, basically Clang's ext_vector_type: https://clang.llvm.org/docs/LanguageExtensions.html#vectors-and-extended-vectors https://clang.llvm.org/docs/LanguageExtensions.html#vectors-...), plus maybe a similar @Matrix builtin up to 4x4.
- xgkickt 3y agoAre Clang’s builtin types interoperable with __m128 intrinsics?
- Gibbon1 3y agoMaybe I'm small brained but built in vector types align with heavily platform optimized libraries. Meaning you don't want this stuff implemented in the compilers front end. You want it handled in the compilers back end.
- pixelpoet 3y agoPerformance is equivalent in both representations, but the important thing is being able to write vec4 c = a * 4 + b; instead of vec4 c = vec4_add(vec4_mul(a, 4), b); i.e. infix vs postfix order, with simple * and +/- operators etc. I would very much like to appeal to the Zig authors to see the beauty in the former expression compared to the latter, for a huge class of real-world mathematical applications.
- eska 3y agoIf this wasn’t math code we’d refactor such code into helper functions, but somehow when it’s math we refuse to. vec4 c = a * 4 + b; vec4 c = vec4_add(vec4_mul(a, 4), b); vec4 c = vec4_fma(4, a, b);
- naasking 3y agoI think operator overloading should be fine even for puritans, as long the language requires the type to be numerical in a strict sense, and so they have a well defined semantics. So integers, floating point, complex numbers, vectors, matrices, etc.
- justinpombrio 3y agoHow would the language require it to be numerical? For example, if you're defining complex numbers in a library, what would the compiler be checking about your ComplexNumber type before allowing you to define `+` for it?
- naasking 3y agoA few ways. The compiler could enforce commutativity, associativity and other properties of those operators. Another possible route is to require that all types contained within the exported types are also numerical, or have some specific set of operators defined.
- SkiFire13 3y agoDo you mean at the type level or also for the operational semantics? In the latter case it's undecidable. Also, you mentioned matrices in the previous comment, but multiplication between matrices is not commutative.
- naasking 3y agoIt's undecidable if the language used to define operators is sufficiently expressive. Even simple syntactic constraints would work well enough for most scenarios, like "operators may only be defined by an expression containing other operators". New types also don't have to inherit the properties of the operators they use. In any case, my point was that there are multiple avenues to explore in providing operators in a way that don't compromise the compiler's ability to optimize numerical code.
- throwawaymaths 3y agoThe problem with operator overloading is not really numericity, IMO. The problems are: - hidden control flow (function calls should look like function calls, an operation should never mask a function call) - global weirdness. If a library changes the language, how does that affect some other code you're pulling in? Where do you effect those changes?