Talk:Petit Computer 3/@comment-14600979-20140709193418/@comment-15296152-20140709214230

With this additional variable type, it'll be like this...

String variable - N$

Real variable - N

Integer variable  - N%

While it will require an addition character to parse, this could speed up the process of identifying the correct variable in the list in memory because now it won't have to search through any variables that are of the real-type. With PTC, you had just strings and real variables. Now, I don't know how PTC or PC will store these in RAM, but I have 2 theories which will explain my potential that this extra type would speed up the search process.

If all types are in the same stack, they'd have to be marked for their type, and that type is examined first. If looking for a real number, it skips all strings and won't even examine their names. Same if looking for a string, it'll skip all reals along the way. With an additional numeric type, that's more to skip when mixing real and integer.

If they each have their own separate stacks, then tthat just makes it that much faster, as it won't have to touch any of the stacks not relevant to the type being looked at. For instance, if you had 100 numeric variables in PTC, that's up to 100 variables it has check before either finding what it's looking for, or before it can add one to the list. This could be a mix of variables meant to act as either real or integer. In PTC3, with them separated, that'll be less examining altogether.

Then there's also the fact that internally, integers and floats are separate types. In PTC (on the DSi which has no FPU), everything was a fixed-type (likely 1.19.12 in a 32-bit form), and it had to convert each time anyways into a single format, no matter if you were dealing with values meant as integer or float. With separating integers and floats in PC3 (not to mention the 3DS has an FPU), this internal conversion is not required anymore.