Casio fx-6300g Comparison Bug

The Casio fx-6300g graphing calculator has a subtle bug that affects using certain comparison operators against array memories, which will effectively cause the two sides of the comparison operator to be swapped. Here's how to trigger the bug, and what you can do to avoid it.

The Bug

The Casio fx-6300g, like many other old Casios, supports array-style memory indexing, in the form of variable[offset]. So A[0] refers to A, A[1] refers to B, A[2], refers to C, D[-3] refers to A, and so on. This indirect addressing capability allows for some very powerful programming capabilities on these otherwise very limited calculators. But I've uncovered a bug (which appears to be specific to the fx-6300g) that can manifest when making comparisons against array-indexed memories:

If a comparison expression has an array-indexed memory on the right hand side of the inequality, and that array memory is based on an odd-numbered letter (counting from A=0, B=1, D=3, F=5, etc.), then the comparison operator ≤ will instead be evaluated as ≥, and the operator < as >.

Example

Here's a very short program that demonstrates the problem:

5→B:8<B[0]⇒"BUG!"◢

This program stores 5 into variable B, then checks if 8 is less than B[0] (which is B, which is 5). If 8 is less than 5, it displays the message "BUG!". Or at least, that's what it's supposed to do. Because of the comparison bug, < gets interpreted as >, and because 8 is obviously greater than 5, the "BUG!" message is displayed.

Workarounds

There are a couple of ways to get around this issue. The first and most obvious is don't use "odd-numbered" letters for array memories. This program works fine (i.e. it doesn't display "BUG!"):

5→A:8<A[0]⇒"BUG!"◢

Or you can practice more defensive coding, and write all your comparisons (or at least the ones with array memories) in terms of > or ≥:

5→B:B[0]>8⇒"BUG!"◢

This works too, because the comparison is already >, and thus isn't misinterpreted (also, the array memory reference is on the left side now, which doesn't trigger the bug).

Cause

No idea! I'm assuming it's some weird parser error, but without a ROM dump and more knowledge of the CPU architecture than I have, I can only speculate.