Adding more Logical Operators

[Dimster]

Would it be difficult to add more logical operators to the QB64 language?

I often come across math formulas which use some hieroglyics that I'm constantly looking us to decipher. When it comes to logical operators I see them so often I sometimes wonder if they may be useful in QB64. For example, a couple of them are:

V means the logical OR, so it would be "A V B" v's "A OR B". The inverted V means AND
 
A pyramid of dots    .    means "THEREFORE", so "HM = M  and S = M    .     S = HM"
                            . .                                                                       .  .

(sorry, my depiction of a pyramid of dots leaves a lot to be desired)

And the inverse of the pyramid of dots means "Because" or "Since"


There are more, like << which means "much less than" and >> meaning "much more than" but I find personally I don't need those very much. The V and inverted V (or rotated 180 degree V) are just a short form of OR and AND so perhaps not as revolutionary for QB64, but the pyramid of dots may help with using the logical operator of IMP. (IMP being my pet peeve)

Is it too difficult to add more Logical Operators to QB64 math arsenal?

[Dimster]

Here's another thought - increase the working scope of SLEEP.

So SLEEP will take a value in terms of Time but what if SLEEP AT could expand to include either a Line Number or a Loop Control, such as SLEEP AT CASE 3: SLEEP 1 ... SLEEP AT FOR I=6

In the instance of Line Number, you could have multiple Lines covered with the 1 SLEEP AT command. ie SLEEP AT LN100, LN500,LN25000

[Kernelpanic]

So SLEEP will take a value in terms of Time but what if SLEEP AT could expand to include either a Line Number or a Loop Control, . . .

There we go with "sleep". - The little program: You enter the kilowatts of an engine and the program shows how much PS (horsepower) it has.

Whenever "i MOD 3 = 0" it pauses for 5 seconds.

Code: (Select All)

'Beispiel fuer sleep - 3. Juni 2022

OPTION _EXPLICIT

DIM kw_eingabe AS DOUBLE, ps AS DOUBLE
DIM i AS INTEGER

CLS
PRINT
PRINT "Rechnet Kilowatt(KW) in PS um": PRINT
INPUT "Geben Sie die Motorleistung ein (KW): ", kw_eingabe

FOR i = 1 TO 10
  ps = kw_eingabe * 1.36
  PRINT USING "###.## KW sind ###.## PS"; kw_eingabe, ps
  IF i MOD 3 = 0 THEN
    SLEEP 5 '5 Sekunden warten
  END IF
  PRINT
  kw_eingabe = kw_eingabe + 5.0
NEXT

END

[Kernelpanic]

And here with a subprogram - Everything works.:

Code: (Select All)

'Beispiel fuer sleep - 3. Juni 2022

OPTION _EXPLICIT

DIM kw_eingabe AS DOUBLE, ps AS DOUBLE
DIM i AS INTEGER

SCREEN _NEWIMAGE(800, 600, 32)

CLS
PRINT
PRINT "Rechnet Kilowatt(KW) in PS um": PRINT
INPUT "Geben Sie die Motorleistung ein (KW): ", kw_eingabe
PRINT

FOR i = 1 TO 10
  ps = kw_eingabe * 1.36
  PRINT USING "###.## KW sind ###.## PS"; kw_eingabe, ps
  IF i MOD 3 = 0 THEN
    SLEEP 3 '3 Sekunden warten
  ELSEIF i MOD 4 = 0 THEN
    PRINT
    CALL Quadratvolumen(i)
  END IF
  PRINT
  kw_eingabe = kw_eingabe + 5.0
NEXT

END

SUB Quadratvolumen (i)
  DIM volumen AS DOUBLE

  volumen = (i * i) * i
  PRINT USING "Ein Wuerfel von ##.## cm Kantenlaenge hat ein Volumen von ###.## qcm"; i, volumen
END SUB

[Kernelpanic]

Instead of this - see screenshot:

. . . you can also write (but only with one square):

Code: (Select All)

volumen = i ^ 3

I like QuickBasic 

[Dimster]

Hello Kernelpanic - I love that handle. Seems you have SLEEP with time down pat. I gather SLEEP AT may not be that interesting.
 
Here's another idea for PRINT and LPRINT. You know how the question mark is a short form for PRINT, what if two question marks short formed LPRINT.

[vince]

interesting, FreeBASIC has added these operators in the form of:

https://www.freebasic.net/wiki/KeyPgOpAndAlso
https://www.freebasic.net/wiki/KeyPgOpOrElse

in my opinion, more operators should not be added to QB64 except bit shifting which I guess is already included in QB64 with the ugly and hacky _SHL and _SHR functions, why are operators suddenly functions?

I guess if these were really wanted, the stage is set:  function _AndAlso(x, y) along with _OrElse(x, y) -- that would retain the underscore QB45 compatibility requirement and the ugliness would not be all that out of place considering _SHL/_SHR

[Dimster]

Hi Vince ... not a fan of more logical operators...Some of the stuff I've floated here are more a short cut to the language then they are advancing the syntax with something new. Like the V and inverted V instead to typing OR or AND. Perhaps the double ?? for LPRINT is also  a corner cutting time saver, and really, are we getting that lazy ( I am  ).

But I'm not sure more logical operators wouldn't be helpful. When I write a statement with logical operators I see the words (OR, AND, XOR, NOT etc) and not the truth table which underlays the actionable part of the statement. It's typically the reason why I make so many mistakes especially with IMP.

Here's an example statement with logical operators which I see as correct but it's not

IF a = 5 AND b = 6 AND c = 5 THEN c = a
PRINT c

This prints zero, when it should print -1. Here is where I was thinking a THEREFORE function may help. Instead of THEN use THEREFORE to make the statement TRUE in verse as well as TRUE (-1) in the Logic process.

AndAlso & OrElse sound cool. I haven't heard of them before. Always something new under the sun.

[madscijr]

Would it be difficult to add more logical operators to the QB64 language?
I often come across math formulas which use some hieroglyics that I'm constantly looking us to decipher.
When it comes to logical operators I see them so often I sometimes wonder if they may be useful in QB64. For example, a couple of them are:
V means the logical OR, so it would be "A V B" v's "A OR B". The inverted V means AND
 
A pyramid of dots    .    means "THEREFORE", so "HM = M  and S = M    .     S = HM"
                            . .                                                                       .  .
...
Is it too difficult to add more Logical Operators to QB64 math arsenal?

Honestly, I think this would make a lot of people confused. 
Maybe if the IDE had some setting to allow that notation, 
and if the person turned it off in the settings, 
it would automatically convert those statements to the standard QuickBasic notation, 
e.g. "A V B" would be changed back to "A OR B", etc.? 
But that would still mean that there would be source code listings out there in forums and downloadables, 
that use this new notation, and old time QuickBasic users or people who don't want to get into that notation, might find it difficult. 

I guess it comes down to, what do we gain from typing "V" instead of "OR"? 
So we have to type one less character, not that big of a gain. 
And on the downside, it would confuse a lot of people possibly break compatibility. 
Just my 2 cents...

[madscijr]

Here's an example statement with logical operators which I see as correct but it's not
IF a = 5 AND b = 6 AND c = 5 THEN c = a
PRINT c
This prints zero, when it should print -1.
Here is where I was thinking a THEREFORE function may help.

When I try the following test, I'm not getting 0 or -1: 

Code: (Select All)

Print "Test #1:"
a = 5
b = 6
c = 5
Print "  Before:"
Print "    a=" + _Trim$(Str$(a))
Print "    b=" + _Trim$(Str$(b))
Print "    c=" + _Trim$(Str$(c))
Print "  If a = 5 And b = 6 And c = 5 Then c = a"
If a = 5 And b = 6 And c = 5 Then c = a
Print "  After:"
Print "    a=" + _Trim$(Str$(a))
Print "    b=" + _Trim$(Str$(b))
Print "    c=" + _Trim$(Str$(c))

Print

Print "Test #2:"
a = 1
b = 2
c = 3
Print "  Before:"
Print "    a=" + _Trim$(Str$(a))
Print "    b=" + _Trim$(Str$(b))
Print "    c=" + _Trim$(Str$(c))
Print "  If a = 5 And b = 6 And c = 5 Then c = a"
If a = 5 And b = 6 And c = 5 Then c = a
Print "  After:"
Print "    a=" + _Trim$(Str$(a))
Print "    b=" + _Trim$(Str$(b))
Print "    c=" + _Trim$(Str$(c))

Am I missing something? Do we really need a "therefore" keyword? 

AndAlso & OrElse sound cool. I haven't heard of them before.
Always something new under the sun.

My impression was the appraoch to QB64 has been to keep the new parts to a minimum, to accommdate newer features of PCs since the old days. 
They have been very conservative about changing the language, to keep it backwards compatible with QuickBasic. 
My concern is if we start adding fancy logical operators, it would cause compatibility issues and confuse people, and be more trouble than benefit. 

I would say that if we are going to add stuff to the language, keep it to important changes, like 

• the ability to store an array inside a user defined type
  
• better sound & graphics commands
  
• a built-in GUI and form editor (like in VBA)
  
• etc.
  

Just my opinion...