A kind suggestion with Select...Case

[norbert doerre]

This is just a small sample for ortho mode in CAD:

Select Case dAngle
Case >= 0.00 * PI And < 0.25* PI
dpMove.y = mCirc.cp.y
Case >= 0.25 * PI And < 0.50 * PI
dpMove.x = mCirc.cp.x
Case >= 0.50 * PI And < 0.75 * PI
dpMove.x = mCirc.cp.x
Case >= 0.75 * PI And < 1.00 * PI
dpMove.y = mCirc.cp.y
Case >= 1.00 * PI And < 1.25 * PI
dpMove.y = mCirc.cp.y
Case >= 1.25 * PI And < 1.50 * PI
dpMove.x = mCirc.cp.x
Case >= 1.50 * PI And < 1.75 * PI
dpMove.x = mCirc.cp.x
Case >= 1.75 * PI And < 2.0 * PI
dpMove.y = mCirc.cp.y
End Select

Unfortunately the Select...Case function does not support boolean operations obviously. In many situations like this one, it would make things much more transparent in comparison to other code syntax.

[Chris Holbrook]

I think the nearest you can get is to use a range, like:

CASE a TO b

in which the second limit is inclusive, unlike your example.

[Mike Doty]

Or forget about CASE and go for performance

GLOBAL gPI!()  'multiply once in advance
FUNCTION PBMAIN () AS LONG
 
  DIM gPI!(0 TO 8) '9 pre-multiplied values to compare to
 
  pi! = 1          'change to pi
  FOR x& = 0 TO 8  '0, .25, .50, .75, 1, 1.25, 1.50, 1.75, 2 if pi = 1
    gPI!(x&) = pi! * variable!
    variable! = variable! + .25
  NEXT
  'test all 8 conditions  (0 to 7)
  FOR Angle! = -1 TO 12 STEP .25
    CALL DoIt(angle!)
  NEXT
END FUNCTION
SUB DoIt(Angle!)
  FOR x& = 0 TO 7    '8 possible conditions
    IF angle! >= gPI!(x&) AND angle! < gPI!(x&+1) THEN
      ? "Angel" + STR$(Angle!)+ " =>" + STR$(gPI!(x&)) + " and <" + STR$(gPI!(x&+1)) + "   condition" + STR$(x&)
      EXIT FOR
    END IF
  NEXT
END SUB

[Chris Boss]

Would the following work:

Select Case dAngle/PI
   Case >= 0.00 And < 0.25
      dpMove.y = mCirc.cp.y
   Case >= 0.25 And < 0.50
      dpMove.x = mCirc.cp.x
   Case >= 0.50 And < 0.75
      dpMove.x = mCirc.cp.x
   Case >= 0.75 And < 1.00
      dpMove.y = mCirc.cp.y
   Case >= 1.00 And < 1.25
      dpMove.y = mCirc.cp.y
   Case >= 1.25 And < 1.50
      dpMove.x = mCirc.cp.x
   Case >= 1.50 And < 1.75
      dpMove.x = mCirc.cp.x
   Case >= 1.75 And < 2.0
      dpMove.y = mCirc.cp.y
End Select

[Dave Biggs]

'Case >= 0.00 And < 0.25 =====> Syntax error (not String or Numeric Expression)

This perhaps?

Select Case dAngle/PI
   Case <0
     Exit Select
   Case < 0.25
      dpMove.y = mCirc.cp.y
   Case < 0.50
      dpMove.x = mCirc.cp.x
   Case < 0.75
      dpMove.x = mCirc.cp.x
   Case < 1.00
      dpMove.y = mCirc.cp.y
' etc
 End Select

[Michael Mattias]

??? (not tried)

  SELECT CASE -1& 
         CASE (X => 0.00 * PI ) AND ( x< 0.25* PI) 
...

Kind of a spinoff from COBOL...

   EVALUATE TRUE 
       WHEN  (condition ) [AND|or] [NOT] condition] 
            Do something
        WHEN .....
         ...
    END-EVALUATE

[John Gleason]

You can usually order the cases to avoid complex boolean expressions (as Dave Biggs showed). You'll get a big speed improvement by pre-calculating your pi ranges (like Mike Doty said too).

#COMPILE EXE
#DIM ALL

FUNCTION PBMAIN () AS LONG
   DIM piFactor(8) AS EXT
   LOCAL dAngle, pi, mult AS EXT
   LOCAL ii AS LONG
   '-------------------place below in PBMAIN where it will get executed only once-----------------
   pi = 4 * ATN(1)                  'make accurate pi value
   FOR ii = 1 TO 8                  'pre calculate your case ranges so SELECT CASE doesn't have to.
      mult = mult + .25
      piFactor(ii) = piFactor(ii) + mult * pi
   NEXT
   '-------------------place above in PBMAIN where it will get executed only once-----------------
   RANDOMIZE
     dAngle = piFactor(8) * RND
                       
  SELECT CASE dAngle
     CASE < piFactor(1)
        ? "dpMove.y = mCirc.cp.y"
     CASE < piFactor(2)
        ? "dpMove.x = mCirc.cp.x"
     CASE < piFactor(3)
        ? "dpMove.x = mCirc.cp.x"
     CASE < piFactor(4)
        ? "dpMove.y = mCirc.cp.y"
     CASE < piFactor(5)
        ? "dpMove.y = mCirc.cp.y"
     CASE < piFactor(6)
        ? "dpMove.x = mCirc.cp.x"
     CASE < piFactor(7)
        ? "dpMove.x = mCirc.cp.x"
     CASE < piFactor(8)
        ? "dpMove.y = mCirc.cp.y"
  END SELECT

[John Petty]

Select Case doesn't but IF THEN does, that is the difference between them ie
IF dAngle >= 0.00 AND dAngle < 0.25*PI THEN
...
ELSEIF dAngle >= 0.25*PI AND dAngle < 0.50*PI THEN
...
ELSEIF dAngle >= 0.50*PI AND dAngle < 0.75*PI THEN
...
etc
Just as readable and not much more typing using copy and paste.
I make no comments about the speed.

[Walt Thompson]

When working with SELECT CASE I've found it useful to insert EXIT SELECT after each case. This makes the code a little more "bullet proof" by eliminating a situation where more than one case satisifies a given condition. Also, the cases do not have to be in any particular order.

#COMPILE EXE
#DIM ALL

FUNCTION PBMAIN () AS LONG
   DIM piFactor(8) AS EXT
   LOCAL dAngle, pi, mult AS EXT
   LOCAL ii AS LONG
   '-------------------place below in PBMAIN where it will get executed only once-----------------
   pi = 4 * ATN(1)                  'make accurate pi value
   FOR ii = 1 TO 8                  'pre calculate your case ranges so SELECT CASE doesn't have to.
      mult = mult + .25
      piFactor(ii) = piFactor(ii) + mult * pi
   NEXT
   '-------------------place above in PBMAIN where it will get executed only once-----------------
   RANDOMIZE
     dAngle = piFactor(8) * RND
                       
  SELECT CASE dAngle
     CASE < piFactor(1)
        ? "dpMove.y = mCirc.cp.y"
        EXIT SELECT 

     CASE < piFactor(2)
        ? "dpMove.x = mCirc.cp.x"
        EXIT SELECT 

     CASE < piFactor(3)
        ? "dpMove.x = mCirc.cp.x"
        EXIT SELECT 

     CASE < piFactor(4)
        ? "dpMove.y = mCirc.cp.y"
        EXIT SELECT 

     CASE < piFactor(5)
        ? "dpMove.y = mCirc.cp.y"
        EXIT SELECT 

     CASE < piFactor(6)
        ? "dpMove.x = mCirc.cp.x"
        EXIT SELECT 

     CASE < piFactor(7)
        ? "dpMove.x = mCirc.cp.x"
        EXIT SELECT 

     CASE < piFactor(8)
        ? "dpMove.y = mCirc.cp.y"
  END SELECT

[Mike Doty]

Walter,
Once a CASE returns true the next CASE won't execute.
EXIT SELECT is only useful in early termination in the CASE that is true.
I see the logic in your statements, but 2 CASE's won't be executed.

[Mike Doty]

Also, the cases do not have to be in any particular order.

CASE's may need to be in a correct order.
This is an error:
x& = 2
SELECT CASE x&
...CASE > 0 'would catch all positive values
...CASE > 1 'never executes
END SELECT

[norbert doerre]

Sorry for my delay...

Sorry but I had no time to have an earlier look into this thread again. Boolean operation should be possible into SELECT...CASE. It would help a lot in many, many cases. I remember that this syntax was once added just to make life easier than with IF...ELSE...ENDIF. SELECT CASE should at least be able to do what IF ENDIF could do ever before. The sample I introduced in this thread is very simple and only shows the priciple of the syntax needed in order not to loose overview when code becomes much more complex.

[Rodney Hicks]

SELECT CASE dAngle
CASE 0.00 * PI TO  0.24* PI
dpMove.y = mCirc.cp.y
CASE 0.25 * PI TO  0.49 * PI
dpMove.x = mCirc.cp.x
CASE 0.50 * PI TO 0.74 * PI
dpMove.x = mCirc.cp.x
CASE 0.75 * PI TO .99 * PI
dpMove.y = mCirc.cp.y
CASE 1.00 * PI TO 1.24 * PI
dpMove.y = mCirc.cp.y
CASE 1.25 * PI TO 1.49 * PI
dpMove.x = mCirc.cp.x
CASE 1.50 * PI TO 1.74 * PI
dpMove.x = mCirc.cp.x
CASE 1.75 * PI TO 2.0 * PI
dpMove.y = mCirc.cp.y
END SELECT

Does this help?

[Michael Mattias]

SELECT CASE X 
   CASE 1
     do a 
   CASE 2, 3, 4 
     do b 
   CASE < Y 
     do c 
   CASE  J TO  K                 '    J to K , inclusive
     ... 

   CASE BETWEEN  J and K    '    J TO K , not inclusive 
      ....
...

???

[norbert doerre]

A fly on the moon

Rod, in case You are programming with the windows API, your code is certainly sufficient. But in the reality of real numbers, there exist limits down to 10^-14 or even less, for instance if You zoom into a real world. I made an example with my program: I drew the moon 1:1 and a fly on the moon 1:1. Then, when You zoom in so that the fly just fills the screen, You must still be able to use orthgonal mode.

[norbert doerre]

A substitution does not help much.

Michael, You are doing a substitution. When I tried it 14 days ago I found out that accuracy is diminished each time a quad number is transferred to another quad variable. I'm using PI as quad number. May be this is a result of "Heisenberg's unsharpness". Hope You understand!

[Michael Mattias]

I found out that accuracy is diminished each time a quad number is transferred to another quad variable

Huh? Not by simple assignment (LET quadvar= another quadvar) it isn't. Show failing code

[Gösta H. Lovgren-2]

Without evidence to the contrary, M is right here.

'

'PBWIN 9.00 - WinApi 05/2008 - XP Pro SP3
#Compile Exe                                
#Dim All 
#Include "WIN32API.INC"
#Include "COMDLG32.INC"
 
Function PBMain
  Local quad1, quad2,quad3,quad4 As Quad
  Local f, s As String, ctr, ctr2 As Long
  
  Quad1 = 22 / 7 * 10000000000000000000000000000000  'PI = lotsa places (32)
  ?Str$(quad1)
  f$ = "Quad # = #,     (Lotsa Places)" 
  Quad2 = quad1
  quad3 = quad2
  quad4 = quad3  
  
  s$ =      Using$(f$, 1, quad1) & $CrLf 
  s$ = s$ & Using$(f$, 2, quad2) & $CrLf 
  s$ = s$ & Using$(f$, 3, quad3) & $CrLf 
  s$ = s$ & Using$(f$, 4, quad4) & $CrLf 
  
  ctr2 = 1000000' Reassign lotsa times
  For ctr = 1 To 100000
   Quad1 = Quad4
   Quad2 = quad1
   quad3 = quad2
   quad4 = quad3  
  Next ctr
  
  ?s$,, Using$("Quad = Test after #, iterations", ctr2)
End Function 'Applikation beenden
'

=========================================
I conceive that the great part
of the miseries of mankind
are brought upon them by false estimates
they have made of the value of things.
Ben Franklin
=========================================

[Mike Doty]

Saw this in some source code from Fred Meier:
'Problem: C returns quads using the EDX:EAX registers, whereas
         'PB returns quad values in st(0) of the FPU. Following will
         'move value from EDX:EAX into a Quad
         lqpA = VARPTR(lqA)
         CALL DWORD lhRutAddr USING UsingLastInsertRowid(ghDab)
         ! mov ecx, lqpA
         ! mov [ecx], eax
         ! mov [ecx+4], edx

Also, there is an issue with QUAD's, but I can't find the post.
I think it has something to do with different processors. Maybe
it is in the current help file, but can't find it there either.

[Bob Zale]

Actually, this is what's found in the current help file:

"While most FUNCTION calling conventions are fairly well defined throughout the industry, there are a few exceptions. In the case of functions which return a Quad Integer value, some programming languages (including PowerBASIC) return the quad value in the FPU, while others return it in EDX:EAX. PowerBASIC automatically detects the method used by imported functions and adjusts accordingly for you, but that's not a feature found in other compilers. Therefore, we recommend that you do not EXPORT QUAD FUNCTIONS unless they will only be accessed by PowerBASIC programs. A simple equivalent functionality would be to return the quad-integer value to the caller in a BYREF QUAD parameter."

Best regards,

Bob Zale
PowerBASIC Inc.