0-127 is no more confusing than -32768-32767 or 0-65535.

Good point.  It's also no less confusing to someone who doesn't get the importance of those particular numbers (*ahem* the people this system was made for to make things less confusing, yet makes things more confusing)

Quote from: Ashbad on August 09, 2011, 06:25:02 pm

Quote from: calc84maniac on August 09, 2011, 06:20:09 pm

0-127 is no more confusing than -32768-32767 or 0-65535.

Good point.  It's also no less confusing to someone who doesn't get the importance of those particular numbers (*ahem* the people this system was made for to make things less confusing, yet makes things more confusing)

It wasn't to make it less confusing, it was for convenience. It can be really annoying to convert decimal to _EXXXX format manually.

Then don't use decimal!  There are usually a million and one ways around using decimal, since with this notation doesn't do anything like convert from hex back to decimal, just a notation for decimal to hex; hence, it really isn't highly useful anyways.

Since it seems as though the drawbacks to the fpart of the XXX.XXX system will be documented in the future, I'm fine with that; though, that ipart looks really, REALLY ugly even in comparison.  I promote a XX.XXX system where 99.000 == 0xFF00.

That will screw with all your math. That would make 0.500**1.000>>1.000 true, for instance. And don't suggest changing the ** operator, either, because then all it would make it almost twice as slow because of the necessary extra multiply.

I fail to see how changing how the top translates from decimal to true value, rather than just the top staying in true form, changes *anything* of that sort.  99.000 * .500 (proposed translation) ==  255.000 (current translation) would return true.  I fail to see any of your point whatsoever.  How things translate to the same form doesn't affect any math at all.  If 1.000 ** .500 returned true before, it will return true after the change as well.

Or, we go back to my original point of keeping things constant: why is it that it's not something like 255.255 then, or 99.99 (the slower speed is fine by me, floating points are expected to be slower anyways -- life isn't about a dozen or so cycles, it's about ease of use).  The different notations for the different parts is just stupid.  No FP notation should ever do this.  Ever.  Keep it consistent, at the very very very very very least.

There's only one notation: decimal notation. Is the part that's throwing you off the fact that the number is bounded between two powers of two and not two powers of ten?
Edit: It doesn't seem very hard to understand a statement such as "The number must meet the condition that -128<=#<128."

Why do you think I'm an idiot?  Any moron can understand those limits compared to the other ones.  It still doesn't mean they're a good idea.  Much like how expressing the S&P500 as a line graph, and then the DOW Jones as a donut graph wouldn't be a good idea.  Being consistent is key.

Why do you think I'm an idiot?  Any moron can understand those limits compared to the other ones.  It still doesn't mean they're a good idea.  Much like how expressing the S&P500 as a line graph, and then the DOW Jones as a donut graph wouldn't be a good idea.  Being consistent is key.

Ashbad, I do not think that you are an idiot. I'm sorry if I made it seem like that. I just do not see how the notation is inconsistent.

I've wanted this feature for a while: ability to insert constant values into Asm() code.

Example of possible syntax, if I wanted to generate ld bc,GDB1 \ ld de,(axv_A) I would do:
Asm(01(GDB1)^rED5B(°A)^r)

I like this idea.  However, what if { and } were used instead of ( and )?  This would lead to a more standard syntax, even if it breaks up the flow of the Asm code.

Feature request: A method of using #Realloc() that is local to the file being parsed.

Basically, if someone were to use #Realloc() in a source file currently, the #Realloc() would change the memory mapping for all other files to be parsed. It would be very convenient for utilities programmers to have a method of specifying a location for the variables buffer that didn't impact any other files. i.e. As soon as a file is done being parsed, the variable buffer is returned to the location of the previous buffer.

For example:

:.TEST
:#Realloc(<Pointer>)
:prgmUTIL
:<more code>
:Return

Inside prgmUTIL
:.UTILS
:#Realloc(<Different pointer>)ʳ
:<more code>
:Return

The #Realloc()ʳ in prgmUTIL shouldn't change the location of the buffer in prgmTEST