Logic question (handling inequalities in a BASIC compiler)

[elusiveshame]

Hey everyone, I have a logic question, though I'm not sure if this might belong in the math forum (probably not :P)

Anyway, I'm writing a BASIC compiler for the Motorola 68k processor by reverse engineering a dead project/compiler (with permission from the author as he's abandoned it years ago). Anyway, I've into an interesting conundrum. I've gotten to the logic operators, and was wondering what the proper output should be when it comes to inequalities.

The example I'm working with is: a <> 5 <> b

Assume both a and b are both equal to 0. Since both variables don't equal 5, it should return true, right?

The code I was testing with is:
if a <> 5 <> c then print "True"

In the abandoned compiler, this returns false and doesn't print "true" to the screen (actually, even if both variables are different values and not equal to 5, it returns false). I'm going to assume that's not the correct output, and should return true unless both variables don't equal the middle term, right?

Thanks! :)

 

[Mark44]

Hey everyone, I have a logic question, though I'm not sure if this might belong in the math forum (probably not :P)

Anyway, I'm writing a BASIC compiler for the Motorola 68k processor by reverse engineering a dead project/compiler (with permission from the author as he's abandoned it years ago). Anyway, I've into an interesting conundrum. I've gotten to the logic operators, and was wondering what the proper output should be when it comes to inequalities.

The example I'm working with is: a <> 5 <> b

Assume both a and b are both equal to 0. Since both variables don't equal 5, it should return true, right?

The code I was testing with is:
if a <> 5 <> c then print "True"

In the abandoned compiler, this returns false and doesn't print "true" to the screen (actually, even if both variables are different values and not equal to 5, it returns false). I'm going to assume that's not the correct output, and should return true unless both variables don't equal the middle term, right?

I don't think this is as simple as you seem to think. The expression a <> 5 <> b should probably return false, as you say the abandoned compiler does. If the associativity is left to right, this expression would be the same as (a <> 5) <> b. Since a is set to 0, the expression in parentheses is false, so continuing, we're comparing false with 0, and it's been so long since I've done any Basic that I don't know how those two values compare.

 

[elusiveshame]

I don't think this is as simple as you seem to think. The expression a <> 5 <> b should probably return false, as you say the abandoned compiler does. If the associativity is left to right, this expression would be the same as (a <> 5) <> b. Since a is set to 0, the expression in parentheses is false, so continuing, we're comparing false with 0, and it's been so long since I've done any Basic that I don't know how those two values compare.

I didn't think it was easy, but was hoping it was easy enough for someone here :P

One issue with the abandoned compiler is that it doesn't follow orders of operation unless you use parenthesis, but instead computes left to right, for example (assume b = 2): a = 5 / b + 2 * 3 would result in 9 (5/3 = 1 + 2 * 3 = 3 * 3), instead of it being 7.

I did test some of this in Visual Basic 6:
c = 4
If a <> 4 <> c Then
MsgBox "True"
End If

This will pop a message box when a <> 4, but will when c = 4, or when both a and c are the same value that isn't 4. The abandoned compiler never returns true with anything with the statement above.

I think I figured out what I needed to, though. The issue seems to be when I was using long integer variables, as the compiler is using SCC (set on clear carry) on long variables instead of SNE (set not equal), otherwise it operates the same as Visual Basic (for that expression) when using integers (SNE is used).

The way I was interpreting the expression to return was (a <> 5) AND (5 <> b), but with the VB testing, that's definitely not the case, so I was curious as to which the proper result would be outside of any programming language. The reason why I thought it was that is because if you were to do something like: 0 < x < 5, that expression is only true when x is both greater than 0 and less than 5. Unless I'm forgetting pre-calculus, which is entirely possible :)

 

[newjerseyrunner]

The logic for

a <> 4 <> c

is

(a <> 4) <> c

(a <> 4) is of type boolean, which when compared to c will either be 0 or 1.

So your true solutions are:
a <> 4 AND c == 1
a == 4 AND c == 0
All other solutions are false.

 

[Mark44]

The way I was interpreting the expression to return was (a <> 5) AND (5 <> b), but with the VB testing, that's definitely not the case, so I was curious as to which the proper result would be outside of any programming language. The reason why I thought it was that is because if you were to do something like: 0 < x < 5, that expression is only true when x is both greater than 0 and less than 5. Unless I'm forgetting pre-calculus, which is entirely possible :)

In C and languages derived from it, the expression 0 < x < 5 would always evaluate to true, regardless of the value of x. In these languages, the associativity of the < operator is left to right, so this expression is equivalent to (0 < x) < 5. The expression in parentheses will evaluate to either false (0) or true (1), both of which are less than 5, making the compound expression true.

 

[elusiveshame]

The logic for

a <> 4 <> c

is

(a <> 4) <> c

(a <> 4) is of type boolean, which when compared to c will either be 0 or 1.

So your true solutions are:
a <> 4 AND c == 1
a == 4 AND c == 0
All other solutions are false.

And this is exactly what I was looking for. I asked another forum as well, as it didn't even dawn on me that the result of the first operator will return 0 or 1. I mean, I knew it did, but completely spaced that that was the result being compared.

In VB6, a <> 4 <> true returns false, while a <> 4 <> false returns true.

Thank you to both you, and @Mark44 for your help!

 

[FactChecker]

I would advise you to rewrite the expression in simpler form till it is less ambiguous and gives the same predictable result for both compilers. Try (a<> 4) And ( 4 <> c). If that would require a great deal of code modification, I think you should bite the bullet and make all the changes.

 

[elusiveshame]

I would advise you to rewrite the expression in simpler form till it is less ambiguous and gives the same predictable result for both compilers. Try (a<> 4) And ( 4 <> c). If that would require a great deal of code modification, I think you should bite the bullet and make all the changes.

I honestly wouldn't write any expression in that manner, just because of the ambiguity of it. I would rather it be a little more code with explicitly defined parameters like your example above.

As for your last sentence... lol the reason I'm asking this question is because of a rewrite of the logic handling. I had added a few things to test for functions and completely broke it, and because it was a "hmm, I'll add that later" thing, it was ill planned. Lesson learned (sort of :P)

 

[harborsparrow]

I don't think that Basic enforces any kind of type. So if a and/or c contain a non-integer value, results may be erratic. This is one of the issues in using a language which does not require you to explicitly declare the type of variable.

 

[Mark44]

I would advise you to rewrite the expression in simpler form till it is less ambiguous and gives the same predictable result for both compilers. Try (a<> 4) And ( 4 <> c). If that would require a great deal of code modification, I think you should bite the bullet and make all the changes.

I honestly wouldn't write any expression in that manner, just because of the ambiguity of it. I would rather it be a little more code with explicitly defined parameters like your example above.

If by "that manner" you're referring to the expression that FactChecker wrote, it's not at all ambiguous. The one that would be ambiguous would be the one in your first post: a <> 5 <> b, for reasons already stated.

 

[elusiveshame]

If by "that manner" you're referring to the expression that FactChecker wrote, it's not at all ambiguous. The one that would be ambiguous would be the one in your first post: a <> 5 <> b, for reasons already stated.

The expression that I wrote in my first post :) The way FactChecker wrote it is how I write my expressions.

The reason why I asked about this expression and not something more clear is because while I'm building a new compiler, I'm also trying to make it as compatible to the compiler I'm reverse engineering, so that way when people adapt to it, their existing code still works. If it were up to me, I'd throw an exception error stating that the expression was too ambiguous :P

 

[NascentOxygen]

I seem to recall that the TRUE logic value was endowed with an integer value of -1 (and FALSE was integer 0) and this way logic statements could be embedded within arithmetic, in the microcomputer implementations I toyed with. [emoji45]

In a logic expression, a variable of value 0 was treated as FALSE and non-zero treated as TRUE.