"IF" with multiple possible values for the same var

[Nuno]

Hello all,

wondering if there's a simpler way of making such code a lot simpler and shorter:

if x=2 or x=4 or x=7 or x=34 or .....(and so on many, many times) then

   something here

end if

Happens that I have a lot of possible values for the same var and same code to be executed.

As it is, my "IF" line already takes 5 text editor lines, with the _ connector.

The numbers have no mathematical relation between them.

And there's several such "IF"'s. Gets pretty messy and confusing.

Is there such a thing as (my pseudo code hipotesis below)

"if x contains array(...) then"

"if x=array(...) then"

"f x=2,4,7,34,... then"

and so on. you get the idea.

Or another elegant way/idea on how to approach this.

Was thinking about a lookup table. Extremely easy to do in assembly code (my area). Not so in L.B.

Guess I could have a really big array with all possible values. The var would be the indexing.

Then the resulting value from that big array used in a SELECT CASE command to choose the correct bit of code.

Any ideas greatly appreciated. Thanks

[tsh73]

Select case x
Case 3,14,1,5,9,26
Do_someting
Case 2,18,71,187
Do_something_else
...
Case else
Print "you even have case else"
End select

[tsh73]


If instr(",2,4,7,34,",  ",";x;",") then


[Nuno]

Apr 13, 2023 13:19:23 GMT -5 tsh73 said:

Select case x
Case 3,14,1,5,9,26
Do_someting
Case 2,18,71,187
Do_something_else
...
Case else
Print "you even have case else"
End select

That certainly reduces the size of it all. A lot simpler than my idea too.

Thanks. will give it a try

[Nuno]

Apr 13, 2023 13:22:36 GMT -5 tsh73 said:


If instr(",2,4,7,34,",  ",";x;",") then


Got a bit lost with this one...

Please forgive my lack of expertise in L.B. (and all BASIC versions) first time using it.

although a long time assembly code programmer, in several uP's, last time I used a high level language was is PASCAL times... (yep, 35+ years ago...), so please have a bit of patience with me

Looked here www.libertybasicuniversity.com/lb4help/ for how that instruction works, and I think if the number on the left sequence, indexed by the "x" var,

exists, then the "IF" proceeds to the "THEN" part. If there's a " or space, it proceeds to the "ELSE" part?

Thank you

[tsh73]

this one actually uses 2 shortcuts.
so, instr("long string", "a thing") searches for "a thing" in a "long string"
It returns position (from 1) if found and 0 of not found
This "zero/notzero" generally used as false/True.
(so if instr(...) then
actually means
if instr(...)<>0 then that is, "if found then"
)

Second is LB semicolon ; operator (?) which takes number and converts it to string
(actually it concatenates strings, but then it founds number, it converts it to string along the way)

so if x is 3 then
",";x;"," converts it to ",3,"

And I added (,) so instr did not found (3) in (34) - but only (,3,) in, you guess, (,3,)
(this expalins leading and trailing (,) in ",2,4,7,34," as well - so (,2,) would register in spite of being first number in a list)

[Nuno]

Apr 13, 2023 14:45:35 GMT -5 tsh73 said:

this one actually uses 2 shortcuts.
so, instr("long string", "a thing") searches for "a thing" in a "long string"
It returns position (from 1) if found and 0 of not found
This "zero/notzero" generally used as false/True.
(so if instr(...) then
actually means
if instr(...)<>0 then
)

Second is LB semicolon ; operator (?) which takes number and converts it to string
(actually it concatenates trings, but then it founds number, it counverts it to string along the way)

so if x is 3 then
",";x;"," converts it to ",3,"

And I added (,) so instr did not found (3) in (34) - but only (,3,) in you guess (,3,)
(this expalins laedfing and trailing (,) in "",2,4,7,34,"" as well - so (,2,) would register in spite of being first number in a list)

Clear now!

Acctually migth work better than the SELECT CASE command. Will give both a deeper tought to see what works best.

For the SELECT CASE implementation, if the number I want is in the first CASE n, then the next CASE n will not be tested.

A  IF instr(...) THEN line will not prevent the next IF instr(...) THEN line from being checked.

But there's only one number to check at a given time... Will sleep on it...

Thank you very much for your help.

[Walt Decker]

Will your variable always be one of your assigned values?  If so you can wrap it in a function.  That way you can also use it to check the value of an array element.

For example:

'
IF FN.Foo(X) THEN
  SELECT
    CASE (X > 1) AND (X < 14)
      Do Something
   CASE ELSE
 END SELECT: END IF

IF FN.Foo(VAL(MyAry$(6)) THEN
  SELECT
    CASE VAL(MyAry$(6)) >= 1
      Do Something
    CASE ELSE
  END SELECT
END IF

FUNCTION FN.Foo(Value)

Ok = 0
IF Value TTHEN Ok = 1

FN.Foo = Ok
END FUNCTION
'
You could also leverage the function to make the call to do something.

[Nuno]

Hi Walt,

Thank you for your suggestion. I was thinking about that same line of tought, of a huge array to be used as a lookup table.

Unfortunatly was clearly not practical, reason why I started this thread.

There's about 64k possible values (16 bit number read from MODBUS devices). Of these, only less than 128 are of interest.

It gets even worst because there's no relation between them that I can see.

I'm convinced that a SELECT CASE is my best option. At least I've started to change my code that way.

[Walt Decker]

There is always a relation between numbers, odd numbers, even numbers, numbers <= some value, numbers >= some value, number <> some value.

I have no idea what the purpose is but a select case is probably best and easiest with which to work. INSTR is probably the worst with which to work because it can give you false positives.

[Nuno]

Agreed on that false positive. Was the reason I went SELECT CASE.

[tsh73]

INSTR is probably the worst with which to work because it can give you false positives.

LOL

If you don't like cats that just mean you can't cook 'em properly (C) Alf


INSTR could give you thing SELECT CASE couldn't: ability to change condition on the fly. Because it's just a long string.
Of course you might or might not need it.