Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
@SukMikeHok first year, second semester 🙂
-
@SukMikeHok I think most of us are in the same boat sadly!
-
I'd recommend basics on numerics, conditioning of problems and shit, but that may come later. Usually, when you have such a float problem, it's because you have a problem with bad numeric condition. Something like a matrix that has eigen values with a big factor between them.
Or you are doing too many steps where rounding errors can add up.
Or you are doing loops with a float variable that you increase by something like 0.1. -
@Fast-Nop we had to implement line intersections formulas, detect whenever the balls trajectory intersects with the line, and according to the way that I've implemented it, and with testing many situations, it shouldn't have made any issues, until I learned about floating point numbers problem
-
@Revenger I'm curious about the actual root cause here. I can see how problems could arise with angles close to 0°, 90° and 180°, but that shouldn't happen in Arcanoid? Or can you influence the ball's angle according to how fast your racket is moving horizontally?
-
@Fast-Nop First of all yes we had to deal with vertical angles separately as special if cases (enough for the project as is), the issue was that the balls would escape the boundary walls because if you were to draw the point of the ball's next location point on each animation loop, for some reason the trajectory line right before it reaches the wall, everything looks fine, but on the very next loop, the ball would be WAY passed the boundary wall line, by a fracture of epsilon (teeny tiny distanced from the wall), because again when calculating the ball's moment steps and figuring out on each loop if it hit something or not, it wouldn't come out perfect as things were planned on paper thanks to floating points design in java.
-
-
That still occasionally bites you in the job.
The other day our Frontend dev came, clearly confused, asking why 1.3+0.1 is 1.400000000000001 in JS. He seemed rather frustrated.
Fun fact: JetBrains marks things like
`if (floatvar == 1.4)`
With a warning, suggesting an automated refactoring to
`if ((Math.Abs(floatvar) - 1.4) <= thresholdvar)` -
@Sefie fuckers never suggested that ever... EVER.
-
@Furyzer00 nope, somewhere else.
Related Rants
There are no bugs, only happy little accidents
Second semester
Java - OOP Course
We had to write a game, an arkanoid clone
Neat shit
And a fun course, mad respect to the Prof.
BUT
Most students, including me had this ONE bug where the ball would randomly go out of the wall boundaries for no clear reason.
A month passed, sleepless nights, no traces.
Two months later. Same shit. Grades going down (HW grades) because it became more and more common, yet impossible to track down.
3 months later, we had to submit the HW for the last time which included features like custom level sets, custom blocks and custom layouts.
So before we submit the game for review, they had pre-defined level sets that we had to include for testing sake.
I loaded that.
The bug is back.
But
REPRODUCIBLE.
OMG.
So I started setting up breakpoints.
And guess what the issue was.
FLOATING FUCKING POINT NUMBERS
(Basically the calculations were not as expected)
Changing to Ints did it's job and the bug was officially terminated.
Most satisfying night yet.
Always check your float number calculations as it's never always what you expect.
Lesson learned, use Ints whenever possible.
rant
wk117