SELECT CASES ???

[Pete]

We have SELECT CASE and SELECT EVERYCASE, but does any language make use of SELECT CASES?

Example.

Let's say I have two coordinates y, and x

I can do...

Code: (Select All)

SELECT CASE y
    CASE IS > 0
        SELECT CASE x
            CASE IS > 0
            CASE IS = 0
            CASE IS < 0
        END SELECT

    CASE IS = 0

        SELECT CASE x
            CASE IS > 0
            CASE IS = 0
            CASE IS < 0
        END SELECT

    CASE IS < 0
        SELECT CASE x
            CASE IS > 0
            CASE IS = 0
            CASE IS < 0
        END SELECT
END SELECT

But wouldn't it be cool to just code it as:

Code: (Select All)

SELECT CASES y, X
CASE y IS > 0, x IS > 0
CASE y IS > 0, x = 0
CASE y IS > 0, x IS < 0

CASE y = 0, x IS > 0
CASE y = 0, x = 0
CASE y = 0, x IS < 0

CASE y IS < 0, x IS > 0
CASE y IS > 0, x = 0
CASE y IS < 0, x IS < 0
END SELECT

Pete

[SMcNeill]

Yucky yuck yuck!

Look close at your code samples.  Count the conditions you check against for point (-1, -1)...

The first does 3 checks for y, 3 checks for x.  The second does 9 checks for y, 9 checks for x. 

6 conditional checks vs 18..  How much slower is the multiple select cases going to be??

Yucky yuck yuck!

---

To highlight the difference, the first method you posted ADDs the number of possibilities together for how many conditions it may have to check against. The second method that you proposed, has to MULTIPLY the number of possibilities together.

With 10 choices for X and 10 choices for Y, the first method has to make a maximum of 20 condition checks -- while the second could be making up to 100...
With 10 choices for X, Y, and Z, the first method has to make a max of 30 condition checks -- while the second would be making up to 1000...

Do you *really* want to add that type of overhead to your program?

[James D Jarvis]

It would be cool if we had that.

[Pete]

I agree it is certainly not set up for speed, but outside of gaming there are uses that milliseconds don't matter. It's easier to code for variable relationships, but yes, you'd have some explaining to do as to when and when not to use it. What I was mostly curious about is if any other coding languages allow for case relationships. Obviously it C/C++ does not, this would be a pain to incorporate into QB64.

Pete

[SMcNeill]

It would be cool if we had that.

Why?  You're not saving typing, and you're not going to be as efficient or fast with your program by trying to use such syntax.  What possible benefit could it offer at all?

If someone wants to work up such a syntax, I'd at least suggest making it somewhat simpler such as:

Code: (Select All)

SELECT CASES y, x
CASE y IS > 0
    AND CASE x IS > 0
    AND CASE x = 0
    AND CASE x IS < 0
CASE y = 0
    AND CASE x IS > 0
    AND CASE x = 0
    AND CASE x IS < 0
CASE y IS < 0
    AND CASE x IS > 0
    AND CASE x = 0
    AND CASE x IS < 0
END SELECT

Of course, that's not a whole lot different than what we have currently, so I doubt it's worth the effort to implement in the long run.

Honestly, it seems to me that if one prefers that type of syntax, they'd be better off just writing IF statements.

IF y > 0 AND x < 0... 
IF y > 0 AND x = 0...
IF y > 0 and x > 0...

[Pete]

Two votes for cool, 1 vote yuck. Cool wins. When can we expect the roll out???

Pete

[SMcNeill]

Two votes for cool, 1 vote yuck. Cool wins. When can we expect the roll out???

Pete

I dunno.  How quick can you push a pull request with the changes you've implemented for this into the repo, so we can reject them? 

I imagine the roll out would probably be two days after never, after that!



Kidding aside, I honestly don't think any developer would waste their time ever typing to adopt such a syntax into the language.  All we do with SELECT CASE is translate the SELECT CASES into IF.. THEN.. code already.  For example here's a simple SELECT CASE and it's translated code:

Code: (Select All)

Select Case x
    Case Is < 0
    Case Is = 0
    Case Is > 0
End Select

Code: (Select All)

if (((*__SINGLE_X<((float)( 0 ))))||new_error){
sc_ec_1_end:;
goto sc_1_end;
}
if (((*__SINGLE_X==((float)( 0 ))))||new_error){
sc_ec_2_end:;
goto sc_1_end;
}
if (((*__SINGLE_X>((float)( 0 ))))||new_error){
sc_ec_3_end:;
goto sc_1_end;
}
sc_1_end:;

Our SELECT CASE basic code gets translated into IF-THEN c code, when all is said and done.  As I mentioned above, if one *really* likes such a syntax as you showcased, why not just use IF-THEN directly and skip that step of QB64 having to translate from SELECT CASE to IF for you. 

[Kernelpanic]

There are coincidences! I had a problem today with calling a function in "Select ... Case". There are no problems with a procedure, but it didn't work with the function. Maybe anyone know why?

Code: (Select All)

Declare Sub Eingabe()
Declare Sub Lesen()
Declare Function SatzLesen(0)

Dim As Integer auswahl

Nochmal:
Cls
auswahl = 0
Locate 3, 4
Print "Waehlen Sie das gewuenschte Programm."
Locate 6, 10
Print "In Datei schreiben    -> 1"
Locate 7, 10
Print "Datei lesen           -> 2"
Locate 8, 10
Print "Bestimmten Satz lesen -> 3"
Locate 9, 10
Print "Programm beenden      -> 4"

Locate 11, 4
Input "Ihre Wahl bitte: ", auswahl
Print

Select Case auswahl
  Case 1
    Call Eingabe
  Case 2
    Call Lesen
  Case 3
    SatzLesen
  Case 4
    End
  Case Else
    Beep: Locate 12, 4
    Print "Falsche Eingabe!"
    Sleep 1
    GoTo Nochmal
End Select

[SMcNeill]

If it's a FUNCTION, then doesn't it need a return variable associated with it?

x = SatzLesen (or such)

[Pete]

If it's a FUNCTION, then doesn't it need a return variable associated with it?

x = SatzLesen (or such)

That's the first thing you've been right about in the last 10 minutes. Either that or something like...

Code: (Select All)

PRINT SatzLesen

Pete