Also Vector2f instead of Vector3f for the cross product example. I’ll give them the benefit of the doubt that that’s a typo instead of them not knowing what a cross product is.
I disagree with the author on operator overloading. They claim that this function in C
float foo(float a, float b) {
return a+b;
}
is perfectly clear because you know it’s doing floating point addition, while this function in Python isn’t
def foo(a, b):
return a + b
because you don’t know if it’s floating point addition, integer addition, or string concatenation, and what happens if the inputs are different types?
I think that’s fundamentally mistaken. You could also ask of the C version if it’s doing normalized floating point addition, denormalized floating point addition, infinity addition, or NaN propagation. What happens if you mix different types of floats? And the answer is that it doesn’t matter. These are all just aspects of floating point addition. It returns the most sensible result in whatever format is best to hold that value, and you don’t need to worry yourself about how floats are stored under the hood.
The same is true of the Python version. It doesn’t matter if it’s integer addition or floating point addition or string concatenation. Those are just different aspects of the addition operator and it returns the most sensible result in whatever type is best to hold that value.
Agreed. I think operator overloading is a necessary feature in any math-oriented or general-purpose language. Being able to write formulae the same way as they’re written in the source paper is a huge boon to readability.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programming@programming.dev
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person’s post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
Follow the programming.dev instance rules
Keep content related to programming in some way
If you’re posting long videos try to add in some form of tldr for those who don’t want to watch videos
Honestly, I did not find that particularly convincing. Lot of typos and leaps in logic. The point is probably kind of true?!?
*This post overlaps
I am not sure I want to read the rest.
There are a ton of typos in this post, missing semicolons, “you” instead of “your”, “then” instead of “than”… that’s just the first sentence
Also Vector2f instead of Vector3f for the cross product example. I’ll give them the benefit of the doubt that that’s a typo instead of them not knowing what a cross product is.
I disagree with the author on operator overloading. They claim that this function in C
is perfectly clear because you know it’s doing floating point addition, while this function in Python isn’t
because you don’t know if it’s floating point addition, integer addition, or string concatenation, and what happens if the inputs are different types?
I think that’s fundamentally mistaken. You could also ask of the C version if it’s doing normalized floating point addition, denormalized floating point addition, infinity addition, or NaN propagation. What happens if you mix different types of floats? And the answer is that it doesn’t matter. These are all just aspects of floating point addition. It returns the most sensible result in whatever format is best to hold that value, and you don’t need to worry yourself about how floats are stored under the hood.
The same is true of the Python version. It doesn’t matter if it’s integer addition or floating point addition or string concatenation. Those are just different aspects of the addition operator and it returns the most sensible result in whatever type is best to hold that value.
Agreed. I think operator overloading is a necessary feature in any math-oriented or general-purpose language. Being able to write formulae the same way as they’re written in the source paper is a huge boon to readability.
Totally agree, trying to use BigInt in Java sucks because there’s no operator overloading