Bugs in string functions: "split at" and "compare"

blocks (44) blocks (45)

1."compare" should result in "true" but gives "false" instead. What is wrong?
2. "split at" 'empty' results in a list ("empty-string", 1...[list]...); doesn't make sense. The result should be "(1)" to avoid always to remove the first item for a clean list.

gives the right result ("true"); so, "not equals" doesn't work correctly.
gives "false"; should be "true"

or do I think wrong?


You use text blocks for comparison. The text "0" does not equal "0.". Likewise, "a" does not equal "A". Likewise, "0" does not equal "00". If you use a math comparison block then "0" is the same as "0." and like "00".

1 Like

That is exactly what I want to do: comparing text blocks, not numbers. Don't you see the conflict between the statements?

1 Like

Yes you are right.
In fact, this block does not work like a text comparison. It works like a math block.
It's an error.


There are more text blocks that cause problems. It would have to be put together to make it easier to fix.

1 Like

According to
the 0. not equal 0 comparison should come up true, but it comes up false.

I agree this looks like a bug.

The extra empty list item at slot 1 after a split at empty text has hardened into a feature by now, and code is out there to work around it.

1 Like

Thank you for having delt with!

Yes, these are really strange results: → @ewpatton

These tests of '>' and '<' can be reduced to three basic rules:

  • The ASCII table matches the observed order for single characters ".", "0", " "
  • Given two strings, where one string is a leading substring of the other, the leading substring is smaller than the other.
  • Given two strings, their order is determined by the characters in the first position where they differ.

None of this, however, explains the <> operator action reported above by the OP.

1 Like

I am assigning to @ewpatton the original complaint:

Why does text compare of "0." (not equal) "0" return false?

I don't recall this ever being mentioned as a bug, and the text compare (not equal) option is recent, so likely to be buggy.

Technically, one could consider a string terminating before another as terminating with the NUL ascii character (0), which is less than whatever the next character in the other string would be.

This is a bug. After reviewing the code, the not equals comparison produces the following YAIL (simplified):

(yail-not-equal? "0." "0")

But the problem is that yail-not-equal? actually does a bit more than simply comparing two values, because it also includes the type coercion logic. If the two values fail to compare, App Inventor will try to parse them into their numeric forms and compare again (which is wrong in this scenario). It would be more appropriate for the block to generate something similar to:

(not (string=? "0." "0"))

which is equivalent to the blocks not compare text "0." = "0".

1 Like

Thank you!

One other thing to mention is that it's not quite an ASCII based sorting as far as I know. I believe that internally the string comparison functions ultimately are underpinned by Java's string comparison logic which can be locale dependent and uses the Unicode character code points, but the logic is effectively the same as @ABG outlined.


What is the same cannot be different. This is against logic. :grin:

Fix for the string != check is now pending review.