To Nest or Not to Nest Else

[Pete]

Hey @TerryRitchie Have you seen the Baker and the Candlestick Maker? We have a tee time in an hour!

Pete

[TerryRitchie]

Hey @TerryRitchie Have you seen the Baker and the Candlestick Maker? We have a tee time in an hour!

Pete

Last I saw them they were with Tom the piper's son ... something about having pork for dinner.

[SMcNeill]

That second method caused my brain to get stuck in an infinite loop ... or it possibly divided by 0, I can't tell which, LOL

That's almost exactly what my brain did!   After thinking about it a bit, it makes sense though.  It's just not intuitive to me.

If x < 300 Then 'it's left of the box
ElseIf x > 400 Then 'it's right of the box 
Elseif y < 100 Then 'it's above the box
ElseIf y > 200 Then 'it's below the box
Else 'it's not left nor right, nor above nor below the box... it has to be IN the box!


It works, and I might use it for some code obfuscation challenge, but it hurts my brain to think backwards like that.

[TerryRitchie]

That second method caused my brain to get stuck in an infinite loop ... or it possibly divided by 0, I can't tell which, LOL

That's almost exactly what my brain did!   After thinking about it a bit, it makes sense though.  It's just not intuitive to me.

If x < 300 Then 'it's left of the box
ElseIf x > 400 Then 'it's right of the box 
Elseif y < 100 Then 'it's above the box
ElseIf y > 200 Then 'it's below the box
Else 'it's not left nor right, nor above nor below the box... it has to be IN the box!


It works, and I might use it for some code obfuscation challenge, but it hurts my brain to think backwards like that.

The only issue I have with the code is that the IF and all ELSEIF statements must be processed. The method I've always used allows for dropping out of the statements when any of them go FALSE.

Imagine feeding this kind of backwards code thinking to LLMs. Let what appears to be hallucinations along with real hallucinations begin!

[SMcNeill]

Actually, this exclusionary thinking may be quite useful to consider.   Think of this scenario:

A 20 pointed star spaceship is battling aliens in a space invaders style game.  Pew! Pew!  Bullets and aliens everywhere!

Checking every possible point of impact with those 20 star points is going to be processing heavy...

So why not create an EXCLUSION check first?  If the object isn't within this simple circle distance of the center of my Starship, then skip it.

Now, you're not checking everything against every point of the ship.  You're only checking things that are outside that exclusion zone.

That should run and process a TON smoother!

---

That second method caused my brain to get stuck in an infinite loop ... or it possibly divided by 0, I can't tell which, LOL

That's almost exactly what my brain did!   After thinking about it a bit, it makes sense though.  It's just not intuitive to me.

If x < 300 Then 'it's left of the box
ElseIf x > 400 Then 'it's right of the box 
Elseif y < 100 Then 'it's above the box
ElseIf y > 200 Then 'it's below the box
Else 'it's not left nor right, nor above nor below the box... it has to be IN the box!


It works, and I might use it for some code obfuscation challenge, but it hurts my brain to think backwards like that.

The only issue I have with the code is that the IF and all ELSEIF statements must be processed. The method I've always used allows for dropping out of the statements when any of them go FALSE.

Imagine feeding this kind of backwards code thinking to LLMs. Let what appears to be hallucinations along with real hallucinations begin!

Nope.  Think about it a little deeper.

IF x < 300 THEN
   'Do nothing, but we could if we wanted too...
ELSEIF x > 400 THEN  <-- we'll skip this and all other ELSEIF and ELSE statements, if the first condition was true.

[TerryRitchie]

Nope.  Think about it a little deeper.

IF x < 300 THEN
   'Do nothing, but we could if we wanted too...
ELSEIF x > 400 THEN  <-- we'll skip this and all other ELSEIF and ELSE statements, if the first condition was true.

Doh! ... brain .. hurts ... ow

[Pete]

I've actually made an exclusion routine I liked better because it was easier to code. Of course maybe it was just because the inclusion code was pissing me off at the the time. Sorry, this was several years ago, and I can't recall the project off hand. Anyway just another thing I love about BASIC and coding in general, a lot of different recipes that end up baking the same cake. Hmmm, now if I can fit a candlestick maker into the next discussion, I'll have hit the trifecta!

Pete

[SMcNeill]

Nope.  Think about it a little deeper.

IF x < 300 THEN
   'Do nothing, but we could if we wanted too...
ELSEIF x > 400 THEN  <-- we'll skip this and all other ELSEIF and ELSE statements, if the first condition was true.

Doh! ... brain .. hurts ... ow

See if this little snippet doesn't help clear up any confusion of how it actually works.

Code: (Select All)

Screen _NewImage(640, 480, 32)

$Color:32

Do

    Cls

    Line (100, 100)-(500, 400), Red, BF

    While _MouseInput: Wend

    x = _MouseX: y = _MouseY



    If x < 100 Then

        Print "LEFT OF THE BOX!"

    ElseIf x > 500 Then

        Print "RIGHT OF THE BOX!"

    ElseIf y < 100 Then

        Print "ABOVE THE BOX!"

    ElseIf y > 400 Then

        Print "BELOW THE BOX!"

    Else

        _PrintString (250, 250), "IN THE BOX!"

    End If



    _Limit 30

    _Display

Loop Until _MouseButton(1)

As you can see, running this, it only prints one single condition -- the first one it comes to. Doesn't matter if you're both above and left of the box. It'll print the first exclusion and then skip the rest. It's still a routine which only processes until it finds a condition which isn't true any more. It's just... backwards from how most folks would normally do it.

[luke]

Y'all are overcooking it, you don't need any conditionals:

Code: (Select All)

RectCollide% = R1.right  >= R2.left  _andalso _
               R1.left   <= R2.right _andalso _
               R1.bottom >= R2.top   _andalso _
               R1.top    <= R2.bottom

Plus you get to nicely align everything without the auto-formatter ruining it.

[OldMoses]

I was not aware of _ANDALSO, so there's a new toy to play with. Thanks for that heads up Luke.

I'll just leave this out here as the way I typically check for a value falling in a rectangular range.

Code: (Select All)

SCREEN _NEWIMAGE(640, 480, 32)
$COLOR:32
DO
    CLS
    LINE (100, 100)-(200, 200), Red, BF
    LINE (300, 100)-(400, 200), Blue, BF
    LINE (500, 100)-(600, 200), Green, BF
    WHILE _MOUSEINPUT: WEND
    x = _MOUSEX: y = _MOUSEY

    SELECT CASE x
        CASE 100 TO 200
            SELECT CASE y
                CASE 100 TO 200
                    _PRINTSTRING (130, 140), "Pete!"
            END SELECT
    END SELECT

    IF x < 300 THEN
    ELSEIF x > 400 THEN
    ELSEIF y < 100 THEN
    ELSEIF y > 200 THEN
    ELSE
        _PRINTSTRING (330, 140), "Steve"
    END IF

    IF InRange%(x, 500, 600) THEN
        IF InRange%(y, 200, 100) THEN '                         Note: range order can be swapped
            _PRINTSTRING (530, 140), "OldMoses"
        END IF
    END IF

    _LIMIT 30
    _DISPLAY
LOOP UNTIL _MOUSEBUTTON(1)



'Checks if a value (var&) is between (ll&) & (ul&) (order insensitive). Returns -1 if true 0 if false
FUNCTION InRange% (var&, ll&, ul&)
    a& = -ll& * (ll& <= ul&) - ul& * (ll& > ul&) '              Boolean swap & ByVal protection
    b& = -ul& * (ll& <= ul&) - ll& * (ll& > ul&)
    InRange% = -((var& >= a&) * (var& <= b&)) '                 in range? T/F
END FUNCTION 'InRange%

In fact, I also combine two InRange% calls into a second function called InRegion% then only call that with all parameters in a single call. I find it highly readable that way. Only both InRange% results of TRUE will result in a TRUE InRegion% result.

FUNCTION InRegion% (xpos%, ypos%, xl%, xh%, yl%, yh%)
    InRegion% = -(InRange%(xpos%, xl%, xh%) * InRange%(ypos%, yl%, yh%))
END FUNCTION

To reduce parameter count, I frequently set up click fields with a UDT array that contains upper left and lower right x/y data for all screen click points, then just ship off the UDT in an array loop to InRegion%, which then passes the appropriate data to the two InRange% calls. Once set up, click field recognition is a snap.