6 ms·
I had a discussion on one of the Nim boards because Nim does the same, i.e. Writing -2^2=4 but 0-2^2=-4 because Nim treats the first as the unary - which takes
by cycomanic 2y ago
I had a discussion on one of the Nim boards because Nim does the same, i.e. Writing -2^2=4 but 0-2^2=-4 because Nim treats the first as the unary - which takes precedence over exponentiation. I realise that you can argue how it is technically correct (and interestingly several of the people I was talking with couldn't even get my point), but I still argue it's incredibly unintuitive for anyone coming from an regular engineering/science background who wants to do regular work. I would almost argue will exclude it to be used by many due to this.
- bikenaga 2y agoYou're right that violating established mathematical convention can be a deal-killer for some kinds of adoption. A few years ago I was reading the docs for a new programming language, thinking it might be useful in teaching. The docs were well-written and in a beautifully produced book. I got to the chapter on trig functions and discovered that they'd decided to make angles increase clockwise. And there was a graph of the sine function, with the graph below the x-axis from 0 to 180 degrees. And I sadly put the well-written beautifully-produced book on the shelf and haven't looked at it since. I can see why people would think "angles increase clockwise" is more natural than the existing convention ("angles increase counterclockwise") - it's the way clocks do it, right? Yeah, it's just convention, but when the established convention has been around for at least a century or two and there are libraries full of books and papers which use it, "more natural" still isn't good enough reason to break with it. And it really wasn't necessary to do that for their project. I'm sure people who do software can think of lots of conventions which may even suck but will never be replaced.
- thaumasiotes 2y ago> I got to the chapter on trig functions and discovered that they'd decided to make angles increase clockwise. That is an established mathematical convention, called "bearing". https://en.wikipedia.org/wiki/Bearing_(navigation) https://en.wikipedia.org/wiki/Bearing_(navigation) > And there was a graph of the sine function, with the graph below the x-axis from 0 to 180 degrees. But that definitely isn't a convention anywhere; bearing 0 has sine 1. There isn't really one mathematical convention on "angles". There's a fairly strong one on angles that are named theta, but in a math class it's normal to orient phi in whatever way makes sense to you. As you trace a sphere, do you want phi to represent the angle between (1) the radius ending in your point and (2) the xy plane, as that angle varies from negative pi/2 to pi/2? Do you want it to represent the angle between (1) the radius ending in your point and (2) the positive z axis, as that angle varies from 0 to pi? That's your call. An increase in the angle just means it's getting wider; what direction that requires the angle to grow in depends on how you defined the angle and which of its sides is moving.
- LegionMammal978 2y agoRegardless of relative directions around circles, the sine and cosine between 0° and 90° can be described unambiguously in terms of ratios between side lengths of right triangles. You could decide to define the functions differently, but then they'd no longer be the sine and cosine, they'd be something else. The whole point of having these two named functions is that they're a common ground, independent of whatever idiosyncratic angle measurements are useful for a given problem.
- thaumasiotes 2y ago> Regardless of relative directions around circles, the sine and cosine between 0° and 90° can be described unambiguously in terms of ratios between side lengths of right triangles. That's true, if there are no angles greater than 90° or less than 0°, as is the case in a non-pathological right triangle. In this case, as ratios of nonnegative lengths, all trig functions are always nonnegative. If you want to include angles outside those bounds, then you care about what exactly occurs where, and while you can unambiguously define angles between 0 and 90 to have all positive trig functions, you can also unambiguously define them to have negative sines and tangents. Fundamentally what's happening is that you're defining certain line segments to have negative length instead of positive length. Which line segments should have negative length isn't a question about angles. > You can decide to define the functions differently, but then they'd no longer be the sine and cosine, they'd be something else. Only in a sense much stricter than what people generally use. Sine and cosine themselves are hard to distinguish - you can also call them sine (x) and sine (x - 270). Some people might argue that the sine of (x - 270) is still a sine. > In general, the two functions can be described by their differential equations If you do that, you'll completely lose the information about where sine is positive and where it's negative. You can apply any phase shift you want (as long as you apply it to both functions) and their differential equations will look exactly the same.
- LegionMammal978 2y ago> If you want to include angles outside those bounds, then you care about what exactly occurs where, and while you can unambiguously define angles between 0 and 90 to have all positive trig functions, you can also unambiguously define them to have negative sines and tangents. You could define trig functions differently, but then you'd need a separate pair of unnamed functions to express "the ratios of unsigned side lengths of a right triangle in terms of its unsigned interior angles". It's the same reason we don't count "-1 apple, -2 apples, -3 apples, ...". Or why horizonal and vertical lines usually fall on the x-axis and y-axis instead of the (1/√2,1/√2)-axis and (-1/√2,1/√2)-axis. We optimize for the common case. > If you do that, you'll completely lose the information about where sine is positive and where it's negative. You can apply any phase shift you want (as long as you apply it to both functions) and their differential equations will look exactly the same. What do you mean? "sin(0) = 0, cos(0) = 1, and for all x, sin'(x) = cos(x), cos'(x) = -sin(x)" is perfectly unambiguous. If you changed the initial conditions, you'd get another pair of functions, but then they'd no longer be the sine and cosine, they'd be some other linear combination. And for that, refer to what I said about the x-axis and y-axis: better to take the stupid simple (0,1) solution and build more complex ones from there.
- aezart 2y agoThe Godot game engine has its 2d graphics origin at the top-left of the screen, with the positive Y axis pointed down. Having clockwise trig functions is a natural consequence of that. I think it's a fairly common setup for all 2D graphics software.
- Dalewyn 2y agoI don't think I've ever seen a graphical system of any kind that didn't have 0,0 at the top-left corner of the monitor or viewport either, with positive x going right and positive y going down. I actually didn't even think about it until now. Now it's going to bug me. God damnit. :V
- moefh 2y agoSomewhat related, bitmap files (.bmp) store the image lines in bottom-to-top order, effectively putting (0,0) at the bottom-left. It's the only image format I've ever seen that does that -- everyone else stores lines in top-to-bottom order, consistent with putting (0,0) at the top-left.
- dayjaby 2y agoWhat do bitmap and excel have in common? :D
- jampekka 2y agoE.g. OpenGL normalized device coordinates have x=0,y=0 at screen center, with top left being x=-1,y=1. It's easier to reason with in many cases.
- bikenaga 2y ago> I don't think I've ever seen a graphical system of any kind that didn't have 0,0 at the top-left corner of the monitor or viewport either, with positive x going right and positive y going down. Is that because the electron beam in cathode ray tubes scanned from top left to bottom right?
- 2y ago
- eviks 2y ago"more natural" is a good reason any time since otherwise you get to perpetuate these bad conventions for all the future generations to suffer.
- bikenaga 2y agoWhat is "more natural" is a matter of opinion, and opinion will differ. But even if there's a lot of agreement that an existing convention could stand improvement, that doesn't by itself make it "a good reason any time" for throwing out the existing convention. What is a "convention"? It's something followed by a large "installed base". So changing a convention means a large cost will be incurred in changing up. Who should decide whether the benefits of changing outweigh the costs? Someone has to pay for it, and simple fairness suggests that the people who will bear the costs of changing up should have the largest say. The point is that just because someone thinks something new is better doesn't mean that old should be thrown out. And if you ignore that installed base, the change just doesn't happen. We tried in the U.S. to switch over to metric years ago. Many of us think it would have made sense, but many more people didn't agree and it didn't happen. It would be easier computationally if there were 100 degrees in a circle rather than 360. But the 360-installed-base is too large and the costs of changing are judged to be too great, so we're stuck with 360. You're absolutely right, though, that suggestions for change should always get a fair hearing, and people who believe in them should go ahead and see if enough other people will sign on.
- Validark 2y agoIt's insane to me that you'd throw away a whole language, toolchain, ecosystem, and community, just because you disagree with the caret operator not taking precedence over a unary minus. Do they not have parentheses on the keyboards where you're from?
- tsimionescu 2y agoThere's no regular engineering convention about the ^ exponentiation operator, because there is no exponentiation operator in regular or engineering math notation. The superscript used for exponentiation doesn't need a precedence level, it has a natural grouping behvaior. This is most visible in the fact that you never need parentheses around an exponent expression in math notation, but you need them a lot in programming notation. They are just different notations. Consider in math notation: 2+2 3 + 5 Programming notation: 3^(2+2)+5 Completely different notations in a much more fundamental way than how they treat unary minus.