Visual Designers and SELECT CASE AS LONG

[Eros Olmi]

I suppose any extreme concept is not worth unless you are in an experimenting field.
For many projects speed in not a matter. In other yes.
It depends on the project or, better, it depends on the specific task to be performed because even if in a project the whole speed is not a matter, some tasks inside are speed dependant. I think that in any case optimization must be taken into account since the beginning of the project (oops: maybe I'm too extreme here ) .

For the projects I'm working on Speed is 50% of the whole importance. Of course stability is obviously at number 1.

[Charles Pegge]

I agree that it can make a program less obvious when scanning through but I favour a uniform structure which caters for all  conditions, cases and loops. It makes program logic much more extensible, and apart from jump tables, should be just as efficient. If you need to add, modify or remove any of the clauses, there is far less editing to do than if other constructs are used.

I find that optimising code makes it more 'brittle' for future alterations. So this needs to be avoided till the final stages of development.

In the spirit of extreme minimalism, This is the whole uniform structure I use , no other control structures are needed ( apart from the occasional goto ). It is also very easy to 'assemblerise'

Code Select Expand


do
    if ..
      exit
    end if
    ..
    continue
loop


[Theo Gottwald]

Minimalism ...

They tried to make RISC CPUs sometime ago. Then they dropped the concept and started over with CISC.
Because they realized that to much minimalism is not the worlds destination.
In fact, I think what they did was: They took the good things out of it.

Datastructures are technical representations of real-life decisions.
Of course you can break it more and more down, but then at the end you land on ASM level or below.

The structure of a algo should be possibly translated into written code.

For example, if you have a real-life situation to decide between 50 different choices, but you know that you will only ned one at the end,
you should be able to formulate it like this.

Using pure IF.. ELSE .. ENDIF as we know it, this may not work.
Using IF .. THEN .. ELSEIF ... ENDIF it may be an alternative, thats why PB has it.

But in some cases, when the decision is just dependent on a single amount,
the SELECT CASE AS LONG is the best choice in terms of speed and readability.

Otherwise I could we wouöld soon be back to RISC but it did not stand in history.
Therefore I believe that Minimalism just for its own reason is a failed concept.
Its only good to remove unneeded redundancy.

[Charles Pegge]

I found that by using this simplified structure, logic bugs were practically eliminated. In particular the absence of ELSE clauses makes it far easier to check the correctness of the code.

So the minimalism in this case pays off very well. But I agree the minimalism if inappropriately applied makes coding more difficult by having to create workarounds for absent constructs.

BTW, in terms of compactness this compares favourably with a SELECT structure. The only extra is the 'EXIT' command at the end of each case. In C, cases have to have an explicit 'break' anyway.

Code Select Expand


do
    if a=.. then ..: exit
    if a=.. then..: exit
    ' case else here
    exit
loop


[Theo Gottwald]

I found that by using this simplified structure, logic bugs were practically eliminated. In particular the absence of ELSE clauses makes it far easier to check the correctness of the code.

This sentence proofs, that you've never studied on a university.
Otherwise you should have heared the sentence (free tranlated from german)
"A two side-choice where only one side is given, is most often a program-mistake."

This is somehow a basic statement in information technology science (excuse my not so perfect english :-).

[Charles Pegge]

But in practise, choices are usually more than 2 sided - in fact you can never be sure how many choices will be necessary. Hence the need to deploy an extensible logic that is easy to check.

The extensibility is achieved by adding to the list or by nesting to any level. When you start nesting inside ELSE clauses, the logic can become extremely tangled with multiple negatives. modifications to the code then become hazardous. In this instance, It is often easier to dump the whole structure and rewrite it from scratch rather than attempt to extend it.

Beware false dichotomies, especially from computer science theory (and politicians).

[Theo Gottwald]

Beware false dichotomies, especially from computer science theory (and politicians).

hehehe

For me, I used some of these scientific ideas in my programm and i believe its good for their stability.
Anyway it doesn't mean there is no other way to write good programm.

About politicians ... this is actually not a science but near to religion. Therefore we should not directly compare it to technological questions.
While ... if we go into OOP we also get into religion somehow. :-)

[Charles Pegge]

I ran some tests to see which performs the best. SELECT CASE AS LONG or SELECT CASE AS CONST performs as fast as an Assembler compare list. Plain SELECT was 8 times slower. (taking empty loops into consideration)

The IF THEN result was most interesting as it appears to outperform the assembler test.
It seems that the compiler omits empty IF clauses or those which are never used. Can't tell which.

Code Select Expand


#COMPILE EXE
#DIM ALL

FUNCTION PBMAIN () AS LONG

DIM c AS LONG
DIM i AS LONG
DIM t AS SINGLE
t=TIMER
DO
    INCR i:IF i>1e8 THEN EXIT LOOP
    c=3
    #IF 0
    SELECT CASE AS CONST c
        CASE 0
        CASE 1
        CASE 2
        CASE 3
        CASE 4
        CASE 5
        CASE 6
        CASE 7
        CASE 8
        CASE 9
    END SELECT
    #ENDIF
   
    #IF 0
    ON c GOTO 0,1,2,3,4,5,6,7,8,9
    GOTO nx
    0: GOTO nx
    1: GOTO nx
    2: GOTO nx
    3: GOTO nx
    4: GOTO nx
    5: GOTO nx
    6: GOTO nx
    7: GOTO nx
    8: GOTO nx
    9: GOTO nx
    nx:
    #ENDIF
   
    #IF 0
    ! mov c,3
    a0:
    ! cmp c,0
    ! jnz a1
    ! jmp nx
    a1:
    ! cmp c,1
    ! jnz a2
    ! jmp nx
    a2:
    ! cmp c,2
    ! jnz a3
    ! jmp nx
    a3:
    ! cmp c,3
    ! jnz a4
    ! jmp nx
    a4:
    ! cmp c,4
    ! jnz a5
    ! jmp nx
    a5:
    ! cmp c,5
    ! jnz a6
    ! jmp nx
    a6:
    ! cmp c,6
    ! jnz a7
    ! jmp nx
    a7:
    ! cmp c,7
    ! jnz a8
    ! jmp nx
    a8:
    ! cmp c,8
    ! jnz a9
    ! jmp nx
    a9:
    ! cmp c,9
    ! jnz nx
    ! jmp nx
    nx:
    #ENDIF
   
    '#if 0
    IF c=0 THEN GOTO nx
    IF c=1 THEN GOTO nx
    IF c=2 THEN GOTO nx
    IF c=3 THEN GOTO nx
    IF c=4 THEN GOTO nx
    IF c=5 THEN GOTO nx
    IF c=6 THEN GOTO nx
    IF c=7 THEN GOTO nx
    IF c=8 THEN GOTO nx
    IF c=9 THEN GOTO nx
    nx:
    '#endif
   
LOOP
MSGBOX STR$(TIMER-t)
' results in seconds:
'   SELECT CASE c:           4.4
'   assembler cmp...         1.03
'   SELECT CASE AS LONG  c   1.06
'   SELECT CASE AS CONST c   0.905
'   ON C GOTO 01 02 ...      0.87
'   IF THEN ..               0.609
'   (empty loop)             0.505
'
END FUNCTION



[Eros Olmi]

Charles,
SELECT CASE AS CONST is valid only if you compare against a sequence of low numbers like 1,2,3,4,5 ...
If compare values are high value, PB will generate big comparison tables and execution time will increase a lot.

Eros

[Charles Pegge]

Ah yes, PB uses a jump table for SELECT AS CONST. You can see the EXE file jump in size as it creates a table to cover the highest number. But the speed remains the same no matter what the number of cases might be. For this test with 20 cases:

SELECT CASE AS c  10 secs
SELECT CASE AS LONG c   3 secs
SELECT CASE AS CONST 1 sec.

PS: it seems to be 6 bytes*max case number for the table.

Code Select Expand


#COMPILE EXE
#DIM ALL

FUNCTION PBMAIN () AS LONG

DIM c AS LONG
DIM d AS LONG
DIM i AS LONG
DIM t AS SINGLE
t=TIMER
d=RND
DO
    INCR i:IF i>1e8 THEN EXIT LOOP
    c=3
    SELECT CASE AS CONST c
        CASE 090
        CASE 190
        CASE 290
        CASE 390
        CASE 409
        CASE 590
        CASE 690
        CASE 790
        CASE 890
        CASE 990
        CASE 000
        CASE 100
        CASE 200
        CASE 300
        CASE 400
        CASE 500
        CASE 600
        CASE 700
        CASE 800
        CASE 900
    END SELECT

LOOP
MSGBOX STR$(TIMER-t)
' results in seconds:
'   SELECT CASE c:           10
'   SELECT CASE AS LONG  c   3
'   SELECT CASE AS CONST c   1
'   (empty loop)             0.505
'
END FUNCTION



[Bob Zale]

SELECT CASE AS CONST is valid only if you compare against a sequence of low numbers like 1,2,3,4,5 ...
If compare values are high value, PB will generate big comparison tables...
Eros

I'm surprised you'd say that, Eros, as it is simply not true.

It might be a good idea to head over to the PowerBASIC web site and learn how it works so you won't have to speculate as fact.  Just GOTO www.powerbasic.com -- Choose "Help Desk"  -- Then choose the complete documentation for either PB/CC or PB/WIN and follow the link to SELECT CASE.  You'll find a complete description there of the methodology of SELECT CASE CONST.  You might be surprised!

Or, you could write a small sample program and try it.

Best regards,

Bob Zale
PowerBASIC Inc.

[Bob Zale]

PS: it seems to be 6 bytes*max case number for the table.

Actually it's 4 bytes per CASE, plus a very small fixed overhead.

Best regards,

Bob Zale
PowerBASIC Inc.

[Eros Olmi]

Hey Mr Zale, welcome here!

I think I've completely read PB help file at least twice. I know what's there better than what you can expect.

From PB803 help in case of "SELECT CASE AS CONST":

While this form of the structure offers the utmost performance possible, the execution speed must be carefully weighed against the increased program size, particularly when using sparse case values.  For example, with just two CASE values of 2 and 1000, the generated jump table would need 999 table entries (3996 bytes in size).

Did I say something different?
Yes, maybe my sentence would have been: "Pay attention that if your possible CASEs are too sparse, there can be some performace issues."

ADDED:
here we are on a free not censored forum and we are allowed to make some little "semantic" error.
Why don't you jump also into the many posts where others and I make big compliments to PB products? Maybe just to say: thanks guy.

[Bob Zale]

You said:

"SELECT CASE AS CONST is valid only if you compare against a sequence of low numbers like 1,2,3,4,5 ... If compare values are high value, PB will generate big comparison tables..."

The PowerBASIC DOC says:

"Performance is enhanced by the internal creation of a vector jump table, one entry for each number from the smallest to the largest case value."


That's very different and very misleading to those not closely familiar with the product.  Not exactly a small "semantic" error.

Best regards,
Bob Zale

[Bob Zale]

"Pay attention that if your possible CASEs are too sparse, there can be some performace issues."

Unfortunately, that too is a very misleading statement.  There are no performance issues.  SELECT CASE CONST in PowerBASIC executes at the identical speed regardless of the number of CASE's.  A structure with 20,000 CASE's executes in the same elapsed time as one with 2 CASE's.  That's precisely why we designed this feature in the way we did.

Best regards,

Bob Zale
PowerBASIC Inc.