• (nodebb)

    You or I would likely try and answer this question using a simple distance calculation

    You might do that, but I wouldn't, or at least not with a strict application of "simple distance calculation". I would compare deltaX*deltaX + deltaY*deltaY to radius*radius to avoid calculating the square root that's required for a "simple distance calculation".

  • some guy (unregistered)

    Am I missing something? This is not looking for a box, it is looking for a specific point?

  • Zug (unregistered) in reply to Steve_The_Cynic

    Yeah, pretty much what I did, except for integer overflow, and floating point was too slow…

  • Rob (unregistered) in reply to some guy

    Yes, but the nested for loops are iterating over every point in a radius x radius box to see if the desired point is in there. You could get a false positive if the point is in the corner of the box, outside the radius circle.

  • Tinkle (unregistered)

    A 'simple' distance calculation is not WTFy enough... try this.

    double deltaX = PositionX - point.X; double deltaY = PositionY - point.Y; double angle = double.Atan2(deltaX, deltaY); double distance = deltaX * Math.Sin(angle) + deltaY * Math.Cos(angle);

  • Mike (unregistered)

    +1 for knowing the Taxicab metric

  • Sami (unregistered)

    From center point, send an infinite number of messengers to all possible directions. Give all of them food and water to survive 2 x radius travel. Tell them to turn back if they find the Point. If someone gets back, return true, otherwise return false.

  • (nodebb)

    If you need the box radius like this loop does, just use something like this

    abs(PositionX - point.X) <= radius && abs(PositionY - point.Y) <= radius

  • Anonymous Geometer (unregistered)

    Isn't this more of a Chebyshev distance check than a taxicab one? The taxicab or Manhattan "circle" would have diagonal sides, not axis-aligned ones.

  • 516052 (unregistered)

    Well, since we are sharing entries here is mine:

    {
    volatile int x, y;
	
    Point(int x, int y)
    {
        this->x = x;
        this->y = y;
    }

    bool operator==(const Point& other) const
    {
        return x == other.x && y == other.y;
    }
};

bool IsWithin(Point center, Point target, int radius)
{
    if (center == target)
    {
        return true;
    }
	
    if(radius <= 0)
    {
        return false;
    }

    Point points[] =
    {
        Point(center.x + 1, center.y ),
        Point(center.x + 1, center.y + 1 ),
        Point(center.x, center.y + 1 ),
        Point(center.x - 1, center.y + 1 ),
        Point(center.x - 1, center.y ),
        Point(center.x - 1, center.y - 1 ),
        Point(center.x, center.y - 1 ),
        Point(center.x + 1, center.y - 1 ),
    };

    for (const Point& p : points)
    {
        if (IsWithin(p, target, radius - 1))
            return true;
    }

    return false;
}```
  
Call it from the original code with IsWithin(Point(PositionX, PositionY), point, radius);  
  
This preserves the buggy square behavior as intended and adds several additional layers of wrongness. See how many you can detect.  
HINT: Complexity.
  • 516052 (unregistered)

    Also, for some reason the code tag cut off my first line. It's supposed to be: struct Point

  • Argle (unregistered)

    I'm not going to try to post any full code here, but I thought the following was bad:

    A rectangle of pixels about 1600x800; the bottom center was the origin. Data supplied as a line of radar weather data; angle + row of weather density pixels. Solution was to do polar to rectangular conversions on each angle and "pixel" on the line. Problems: The origin was recomputed for every single angle in the supplied data. There were gaps between angles far from the origin. It was all computed in double precision despite the general lack of precision of the original data and the integral nature of the pixels. Worse yet, it was real-time data and the compute slot of the display was constantly overrunning. (No surprise there.)

    I started over and pre-computed angle and distance of all pixels, including anti-aliased pixels between angle sweeps. Quick lookup and all the trig was gone. Got it under the time-slice time with time to spare.

  • Jonathan (unregistered) in reply to Anonymous Geometer

    Yes, you are right.

  • (nodebb)

    That's one heck of a Speedup Loop. ( https://thedailywtf.com/articles/The-Speedup-Loop )

  • (nodebb)

    I started over and pre-computed [...]. Got it under the time-slice time with time to spare.

    return 4; //Chosen by a fair die. Guaranteed to be random.
  • Hmmmm 🤨 (unregistered)

    When the coding and understanding of a solution is this bad, you have to point your finger at the hiring process and oversight instead of the coder himself.

  • (nodebb)

    One of the more interesting metrics since we're talking about calculations is how floating point math almost never uses the FPU anymore. It's almost always more efficient to do it using the SIMD instructions so the distance formula is best done using a single SIMD multiply. Especially if you have AVX available and thus can operate on 4 doubles at the same time. You can eliminate square root and do a 3D distance calculation with a single AVX multiply and then likely a masked addition and thus in two instructions do the calculation.

    Even the FPU would require many more instructions.

  • (nodebb)

    Ah yes, the radius of a square.

    When I tried out ChatGPT 2 something years ago, it actually produced similar code for a simple math problem. Turns out after googling that the code was heavily upvoted on LinkedIn (the platform of incompetence honestly) and after googling a bit more, I found out that 10% of the training material was LinkedIn crap (40% was reddit, I guess that offset the worst offenders mostly - dunno). So yeah, in the old days incompetent devs copied this stuff from stackoverflow, these days they copy it from token generators. Same same, nothing changes, incompetence just seems to have many pretty colors.

  • Tim (unregistered)

    Now THIS is what thedailywtf.com is for :-)

  • (nodebb) in reply to Steve_The_Cynic

    Using Pythagorus is a simple distance calculation.

  • (nodebb) in reply to Sami

    send an infinite number of messengers

    This is a countable infinity. The points on a plane are uncountable, so there is a chance you'll miss the point.

    The above argument does not apply if the x and y coordinates are both integers.

  • Drak (unregistered) in reply to jeremypnet

    Except it does not calculate the distance, it calculates the distance squared (which is why you have to square the radius).

  • Drak (unregistered) in reply to jeremypnet

    If x and y are both integers, you don't need to send out infinite messengers, just send one to each point with radius.

  • UniMatrix69 (unregistered)

    Unless I'm missing something obvious, the original question assumes: 1] That the input point is from the centre of 0,0 2] The radius extends from the same centre

    If those are correct, then the calculation is very simple: InRadius = (point.x ^2 + point.y^2) <= radius^2

  • 516052 (unregistered) in reply to UniMatrix69

    Yes, but like that's far too efficient and clean and actually has no side effects and gets the job done. Hell, it does not even cause the stack to overflow like mine would.

Leave a comment on “Quite a Distance from the Right Solution”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article