This brings up a good point about what's wrong with most languages' operator overloading designs. Order matters, even when operations are commutative. What we need is a way to define operators where order doesn't matter because the operation itself is commutative anyway. I'm not sure what syntax that would take on, but hopefully the collective unconscious will bring some sort of proposal to the forefront. It sounds loony, but trust me, it's a thing, I've seen it work far too often to believe otherwise.
Worth mentioning that the use of operators is kinda discouraged in Rust. Because they are not fallible. I.e. things like integer division by zero panic in runtime. Other arithmetic operators panic on overflowing/underflowing in debug mode. Index access panics on non-existing index. That's why it's encouraged to do 'n.checked_div(m)' instead of 'n / m', 'vec.get(n)' instead of 'vec[n]' etc.
Yea, if I think about it now, I could have mentioned that explicitly. :) That is why we have the system in place we have no, to prevent this uncontrolled spawn of operators and overloads that are, as you said, in no way fallible. Thanks for mentioning it here!
I can argue that the product of two 3D vectors should be neither a scalar, nor another 3D vector, but rather a _quaternion,_ but that's a whole can of worms. Technically, the ==, !=, , = operators are also overloadable, but their traits are stored in a completely different module, and their output type is _always_ bool, rather than being overloadable. There are 2 operators in Rust that I'm away of that are _not_ overloadable at all: && and ||. This is because they aren't actually equivalent to passing the two sides into a function call, since they only evaluate the right-hand side if necessary, which can have observable side-effects. Theoretically, it should be possible to make the override methods take functions for the right-hand side rather than values, but that means for more generic parameters and automatically boxing the expression in a closure... and it's just not really worth it when | and & are perfectly fine for most cases.
Regarding your first point: Yep, I specifically chose one way to do it to make my point. 😁 Regarding the other operators: I don't even consider them real operators, or at least not overloadable ones because their usage is baked into the language. Eq, PartialEq, Ord, and PartialOrd, etc. are all used by sorting algorithms and co. They are those operators you cannot change any meaning for. They will always have something to do with equality, or comparison, while for all the ones I have mentioned in the video, that's not the case. ☺️
going further with this, many libraries for geometric algebra (which contains quaternions as a subset of some algebras) have convention for when to use the inner (dot) product as | and exterior (cross) product as ^. there conventions exist across programming languages so I would argue in that sort of situation using those operators make sense.
@@ikhu6042 absolutely! If you can get a consensus on what to use when, that is absolutely fine. Code style is always a subjective thing bound to a specific context. If in a certain context, the rules are clear, you should ofc make use of what a language offers you! Thanks for adding this. ☺️
@@ikhu6042 I actually dislike this particular convention, since outside of GA, the same symbols have different but related meanings. The exterior product is ∧. In order theory, ∧ is instead the meet. The GA version of the meet is related to the intersection, which is ∩ and often defined in terms of AND, which uses the symbol ∧. Many programming languages when representing a set type already overload their operators to use the same symbols for both AND and set intersection. The result? The GA exterior product, _especially_ when using PGA / mirror-space, should use the & operator; same as AND. Similarly, the symbol for the regressive product ∨, which in mirror-space is also the join, is also used for the... join, as well as the OR operator, and visually resembles the set union operator. As a result, the regressive product should be implemented as | rather than &. As a cherry on top, the OR operator, the join, the union, and the regressive product are all dual to the AND operator, the meet, the intersection, and the exterior product respectively. This means that !x & !y = !(x | y), regardless of which system you're in. This one, GA libraries thankfully get right. Inner product honestly just gets the last option remaining, which is XOR / ^, which does make some sense, but it's less compelling than the other three. TLDR: choose operators based on their meaning, not based on the fact that ^ kinda looks like ∧.
I love the example code at 3:54! Is that actual real code, or something you have summarised, or something you've made up yourself just as an illustration???
It's demonstrational code, but how I would probably implement a naive version of an integer addition with inline assembly. ☺️ Or in other words: with all my examples, I try to spend a lot of time trying to come with something realistic, which doesn't feel too constructed. Admittedly, I don't always to succeed, but it makes me happy to read that you like this particular example. ☺️
If I want use trait functionality on a external data type I wrap it in a function pointer and in the trait I have a function to get the data type so that I can use it in the functions of the trait.
I often find after implementing these operators for my type T, on either side, then if T is not Copy then have to implement them for &T on both sides as well, for T and &T, and it just balloons out of control.
I've encountered this too, however some solutions I found in some popular crates (such as num) is to reduce such repetitions is to just macro-ize them instead and implement them for all of the derivatives.
Hey, thanks a lot. Yes I did. Was my own stupidity as I still had the original recording under the audio-edited one. 😫 easy fix, but cost me the algorithm. Still great to see some people get to watch the video as it was intended to. ☺️
Just because one can easily have sound effects as things appear and disappear does not mean that one has to or that it is a good idea. I find all these superfluous noises really annoying. As are the random images that flash up for no particular reason.
@@Heater-v1.0.0 the critique itself is right. I wanted to release it without any overly hefty sound, but someone convinced me not to. Watching other tech creators' content shows that most don't use effects because it probably distracts too much. I’m think I am better off without the sound effects, and I will tone down the animations. I won't go without them, but I will tune the ADHD level down a bit. 😉
@@oliverjumpertzme I feel that one of the most important things in a vid is the creator, their character, personality, style. That has to shine through. Almost as important as the actual informational content. The extra fluff of sound effects, animations etc is unnecessary. That's not to say some sprinkling of animations/sounds cannot be entertaining and useful. But I feel they have to be appropriate, imaginative, preferably unique, and reflect the creators personality. A difficult thing to pull off I'm sure. Anyway wishing you the best for your work.
I like that you go straight to the point. No long introductions or intro animations.
My last intros were too long. Don't want to make people fall asleep before I get to the good stuff anymore. 😁
Very well done, walked me down the rose path and then shows me why all roses have thorns. Very well done.
This brings up a good point about what's wrong with most languages' operator overloading designs. Order matters, even when operations are commutative. What we need is a way to define operators where order doesn't matter because the operation itself is commutative anyway. I'm not sure what syntax that would take on, but hopefully the collective unconscious will bring some sort of proposal to the forefront. It sounds loony, but trust me, it's a thing, I've seen it work far too often to believe otherwise.
Awesome video! All the graphics and illustrations are so well done 👌
Best Rust channel on TH-cam, by far!
Thank you, Simon. It means a lot! 💛🙏🏻
Worth mentioning that the use of operators is kinda discouraged in Rust. Because they are not fallible.
I.e. things like integer division by zero panic in runtime. Other arithmetic operators panic on overflowing/underflowing in debug mode. Index access panics on non-existing index.
That's why it's encouraged to do 'n.checked_div(m)' instead of 'n / m', 'vec.get(n)' instead of 'vec[n]' etc.
Yea, if I think about it now, I could have mentioned that explicitly. :)
That is why we have the system in place we have no, to prevent this uncontrolled spawn of operators and overloads that are, as you said, in no way fallible.
Thanks for mentioning it here!
I can argue that the product of two 3D vectors should be neither a scalar, nor another 3D vector, but rather a _quaternion,_ but that's a whole can of worms.
Technically, the ==, !=, , = operators are also overloadable, but their traits are stored in a completely different module, and their output type is _always_ bool, rather than being overloadable.
There are 2 operators in Rust that I'm away of that are _not_ overloadable at all: && and ||. This is because they aren't actually equivalent to passing the two sides into a function call, since they only evaluate the right-hand side if necessary, which can have observable side-effects. Theoretically, it should be possible to make the override methods take functions for the right-hand side rather than values, but that means for more generic parameters and automatically boxing the expression in a closure... and it's just not really worth it when | and & are perfectly fine for most cases.
Regarding your first point:
Yep, I specifically chose one way to do it to make my point. 😁
Regarding the other operators:
I don't even consider them real operators, or at least not overloadable ones because their usage is baked into the language. Eq, PartialEq, Ord, and PartialOrd, etc. are all used by sorting algorithms and co.
They are those operators you cannot change any meaning for. They will always have something to do with equality, or comparison, while for all the ones I have mentioned in the video, that's not the case. ☺️
going further with this, many libraries for geometric algebra (which contains quaternions as a subset of some algebras) have convention for when to use the inner (dot) product as | and exterior (cross) product as ^. there conventions exist across programming languages so I would argue in that sort of situation using those operators make sense.
@@ikhu6042 absolutely! If you can get a consensus on what to use when, that is absolutely fine.
Code style is always a subjective thing bound to a specific context. If in a certain context, the rules are clear, you should ofc make use of what a language offers you!
Thanks for adding this. ☺️
@@ikhu6042 I actually dislike this particular convention, since outside of GA, the same symbols have different but related meanings.
The exterior product is ∧. In order theory, ∧ is instead the meet. The GA version of the meet is related to the intersection, which is ∩ and often defined in terms of AND, which uses the symbol ∧. Many programming languages when representing a set type already overload their operators to use the same symbols for both AND and set intersection. The result? The GA exterior product, _especially_ when using PGA / mirror-space, should use the & operator; same as AND.
Similarly, the symbol for the regressive product ∨, which in mirror-space is also the join, is also used for the... join, as well as the OR operator, and visually resembles the set union operator. As a result, the regressive product should be implemented as | rather than &. As a cherry on top, the OR operator, the join, the union, and the regressive product are all dual to the AND operator, the meet, the intersection, and the exterior product respectively. This means that !x & !y = !(x | y), regardless of which system you're in. This one, GA libraries thankfully get right.
Inner product honestly just gets the last option remaining, which is XOR / ^, which does make some sense, but it's less compelling than the other three.
TLDR: choose operators based on their meaning, not based on the fact that ^ kinda looks like ∧.
I love the example code at 3:54! Is that actual real code, or something you have summarised, or something you've made up yourself just as an illustration???
It's demonstrational code, but how I would probably implement a naive version of an integer addition with inline assembly. ☺️
Or in other words: with all my examples, I try to spend a lot of time trying to come with something realistic, which doesn't feel too constructed. Admittedly, I don't always to succeed, but it makes me happy to read that you like this particular example. ☺️
@@oliverjumpertzme Yes... a "nice" piece of example code is an art-form. :)
What do you use to do your animations?
Davinci Resolve
Wonderful content! Thank you so much :)
Super happy to read that. Thank you! 💛
If I want use trait functionality on a external data type I wrap it in a function pointer and in the trait I have a function to get the data type so that I can use it in the functions of the trait.
Yep, basically also a form of the new-type idiom to work around orphan rules. 😁
I often find after implementing these operators for my type T, on either side, then if T is not Copy then have to implement them for &T on both sides as well, for T and &T, and it just balloons out of control.
That's indeed a problem with Rust's type system. 😅
Just implement Deref trait for your type.
@@mk72v2oq Yep, that also works. ;)
I've encountered this too, however some solutions I found in some popular crates (such as num) is to reduce such repetitions is to just macro-ize them instead and implement them for all of the derivatives.
in fact you can do this in rust, which makes perfect sense
cin >> &mut string;
True! 😁
Awesome Oli! THX
💛💛🙏🏻
OMG I need that garlic operator!!!
Available in a grocery store near you 😜
You joke, but any language accepting unicode symbols might have the garlic character available for definition?
@@aaronkaw4857 yea, you then only need a way to give it meaning…like in Scala, where everything can be made a function identifier 😂
@@oliverjumpertzme Make it throw an error whenever it's passed to the vampire operator.
@@aaronkaw4857 you mean panic? 😂
Great video! :)
You removed the slight echo effect, right? I thought I was going insane when I watched the video yesterday xD
Hey, thanks a lot. Yes I did. Was my own stupidity as I still had the original recording under the audio-edited one. 😫 easy fix, but cost me the algorithm. Still great to see some people get to watch the video as it was intended to. ☺️
@@oliverjumpertzme this shows that you care more about the quality of your videos than the clicks. Thanks!
@@OfficialViper Quality always > engagement. 💛
ayy, the duplicate voice is now gone!!
nice job
Yes. Reuploaded. Quality > algorithm. ☺️
Just because one can easily have sound effects as things appear and disappear does not mean that one has to or that it is a good idea. I find all these superfluous noises really annoying. As are the random images that flash up for no particular reason.
K
@@oliverjumpertzme Sorry, I was a bit harsh there. I liked your vid, perhaps I'm oversensitive to these details.
@@Heater-v1.0.0 the critique itself is right. I wanted to release it without any overly hefty sound, but someone convinced me not to. Watching other tech creators' content shows that most don't use effects because it probably distracts too much.
I’m think I am better off without the sound effects, and I will tone down the animations. I won't go without them, but I will tune the ADHD level down a bit. 😉
@@oliverjumpertzme I feel that one of the most important things in a vid is the creator, their character, personality, style. That has to shine through. Almost as important as the actual informational content. The extra fluff of sound effects, animations etc is unnecessary. That's not to say some sprinkling of animations/sounds cannot be entertaining and useful. But I feel they have to be appropriate, imaginative, preferably unique, and reflect the creators personality. A difficult thing to pull off I'm sure. Anyway wishing you the best for your work.
@@Heater-v1.0.0 thank you. Happy we could sort this out. ☺️