wifi radio library does not support signed integers.

[Wenjie Wu]

wifi radio library uses 4 bytes to store unsigned integers. When users input negative numbers, it results in strange outcomes, as I learned from user feedback today. this issue is puzzling to him.

I have thought of two possible solutions:

1. Validate user inputs and provide an error message if a negative number is entered.

2. Support signed integers. The 4-byte space is quite ample, and using one bit to handle the sign seems quite feasible. I'm not sure if it's necessary, as sensors in the hardware field rarely require negative numbers. However, a typical scenario I thought of is that many MicroBlocks users are also Scratch users, who might prefer an intuitive expression form. Moreover, the data being transferred might not be sensor data but other meaningful negative numbers. Considering this, I lean towards supporting negative numbers.

‌

[John Maloney]

Good catch! I'm surprised nobody (including me) ever noticed this! Yes, it should support signed integers. Will fix.

[Wenjie Wu]

Another potentially confusing aspect is that when a very large number is entered, the IDE automatically converts these numbers instead of giving an error message. For instance, when I use wifi send number with 4294967295 (which is equal to 2^32-1), the IDE automatically converts it to -1.

I've found that users really like this library, which means it will be used very frequently. Making it as less confusing as possible could be very valuable.

[John Maloney]

As you probably know, that number (2^32 - 1) would also be converted to -1 in Arduino C. :-)

The reason is that most computers represent signed integers in "two's complement". Binary integers with the most significant bit set are interpreted as negative numbers. (In C/C++, one can use the "unsigned int" type to interpret 32-bit binary values as positive integers, but unsigned ints cannot represent negative numbers.)

MicroBlocks numbers are signed 31-bit integers with the range -1073741824 to 1073741823 (see the covert block entry in the Wiki.

It's rare to actually need numbers outside of +/- one billion in MicroBlocks programs. I've seen students type in crazy big numbers to see what will happen, but that can become a "teaching moment" for a discussion about number representations.

[Wenjie Wu]

As you probably know, that number (2^32 - 1) would also be converted to -1 in Arduino C. :-)

Thank you for informing me of this fact!

MicroBlocks numbers are signed 31-bit integers with the range -1073741824 to 1073741823 (see the covert block entry in the Wiki.

Although I often browse the MicroBlocks wiki, I missed the covert block entry. The MicroBlocks wiki is definitely a treasure!

but that can become a "teaching moment" for a discussion about number representations.

I completely agree that this is an great 'teaching moment' !

[caibing liang]

‌

[John Maloney]

Thank you for the fix! Will be fixed in the next pilot release.

[John Maloney]

I'm investigating this issue. I can't find a case where a number sent by MicroBlocks gets decoded incorrectly. I'm guessing this problem arose when sending negative integers to MicroBlocks over UDP from a laptop -- is that right?

So I think the only problem occurs when sending integers outside of MicroBlock's integer range (-1073741824 to 1073741823) to MicroBlocks from a non-MicroBlocks computer. In such cases, we should probably give an error.

Am I missing something? If so, could you provide examples of numbers in the MicroBlocks integer range that are not decoded correctly?

[Wenjie Wu]

Sorry, I think the issue was caused by me. I tested between two esp32, as you said, there were no issues. The problem only occurs when the computer receives wifi radio messages from the esp32. The issue is due to the Python library not parsing negative numbers correctly. I will fix it.

[Wenjie Wu]

The issue lies in my Python library: there are problems with sending and receiving negative numbers (positive numbers work fine). I compared the Python code with the MicroBlocks code but couldn't pinpoint the problem. Could @John Maloney help me take a look?

[John Maloney]

Try adding this line: the_number = the_number if the_number < 2147483648 else the_number - 4294967296

Python numbers are not 32-bit two's complement numbers so the bitwise operations you did resulted in a positive integer with a range of 0 to 4294967296. You need to re-interpret that as if it were a signed 32-bit integer in a language like C.

Note that you would have had the same problem when sending a 32-bit signed integer to Python as four bytes from any other language, not just MicroBlocks. I'm guessing Python has a library that does this sort of conversion, since it must come up often, but no need to use a library when one line will do what you need. :-)

[Wenjie Wu]

Thanks John and sorry to disturb you during your holiday. I'll try it.

[Wenjie Wu]

It works perfectly!

[John Maloney]

Great!

[caibing liang]

bug in line:msg.extend(struct.pack("<I", n)),change to msg.extend(struct.pack("<i", n))

[Wenjie Wu]

@caibing liang Thank you for the reminder. The issue should have been fixed in the last commit. Currently, there should be no problem with sending negative numbers. What issue did you encounter?