Like this it will return false if input not number
Doing this is pointless, I think. Just replace initialize local result to (empty string)
from the solution with initialize local result to false
. Few blocks less, the same result.
...just one less 'else', but yes, that would be optimum.
If the source of a number is a TextBox, setting it to NumbersOnly helps, providing a decimal point is used for floats, not a comma.
IsIntegerTest.aia (2.5 KB)
Or:
That's vastly superior Tim!
Begs the question though as to why we do not have a maths block for this....
I don't know if there was ever a discussion for/against such a block. I think the argument for would be that it simplifies some things, but the argument against would mainly be to try and keep the blocks language somewhat constrained. I could imagine a good compromise would be modifying the is number? to have a dropdown where you could choose different constraints to check.
FYI, the more appropriate implementation of isInteger would be:
Modifying the block would be a good idea. One could also add a check to see if the number is a HEX number.
(Beating a dead horse)
No one used a test with a negative number to rule out the floor-based attempts.
There's no such thing as a hex number in App Inventor. It could be a text block that contains hexadecimal, but technically all number blocks are binary numbers rendered as decimal numbers.
Yes, but we have blocks to convert to hex and back. Unfortunately, there is no hex-only keyboard. there is an alphanumeric keyboard and you can enter letters from outside of hex. When we substitute invalid data for the hex to dec conversion, the block will return an error. If we already have hex in math blocks, it would be useful to have a block checking if the text is in the range 0-9 and A-F. Yes I know, we can do it in blocks, and you can also check with blocks if a number is an integer or a decimal number. .
It's a very great solution. Works the same as the previous one with much less code.
Actually, upon reviewing the code the is number block does have a hexadecimal variant and it has been in the system since 2015.
It really is . I don't think I ever checked this block by opening its functions .
Is there a situation when x is not a number yet still equals 0 in the formula ?
( I agree that your blocks are more concise....)
Sure, if I pass foobar as an input
I concede, either input textbox to numbers only or use isNumber block, but:
remainder of "foobar" / 1 does not equal 0
Also, a comma used as a period (full stop) is not catered for - yet most of Europe and some industries world-wide use the comma (aircraft industry being one, which is where the use of a comma started) .
Another negative to that approach is that once your values are large/small enough, App Inventor will switch to using scientific notation, so even though there's a period present in the printed representation that doesn't imply that "integer-ness" of the value. For example, 1.234567E10 is an integer but 1.234567E5 is not.
Sounds like a rock-solid case for updating is number?