That's basically A<<0 which is a highly optimized command to return 1 if its negative and 0 if its positive or zero.  That separates out the negative case.  Then !If A can extract the zero from the remaining case.

But if you need the exact number output, I think this is fairly uncommon so I don't think that a command for it is needed.  But here it is in optimized Axe code: A>=>=0?A?1,,-1

EDIT: The white rectangle thing I guess I can see useful, but each rectangle routine is over 100 bytes, which is much larger than making your own subroutine to do the same thing with the existing commands.  The only time it would be useful from a optimization perspective is if you only use 2 out of the 3 rectangle routines in your entire program at any point, or you are super super pressed for speed because you're drawing hundreds of white rectangles every second.  I will consider adding it though, just be warned it can easily bloat your code more than using the existing commands.

If 32-bit *^ is added, then something like /^ that returns the quotient and remainder would be useful.

not possible oncalc Due to RAM limits

not possible oncalc Due to RAM limits

This has nothing to do with Ram limit since Apps are run from Archive.
This is more like rewriting all the "Compile for app" option, so I think it is at the bottom of the To Do list

Maybe it is possible if you pars first the first page and then the second page etc. ?

The memory that's needed isn't the only problem. Writing multi-page apps in any language requires extra code in the app to deal with page swapping, and the contents of the pages have to be separated by the programmer. The compiler can't do this alone - the programmer has to think about all of this. I believe that changes in how the language works are required, but I'm not sure since I don't have a lot of experience of things like this.

Quote from: aeTIos on December 23, 2011, 08:57:35 am

not possible oncalc Due to RAM limits

This has nothing to do with Ram limit since Apps are run from Archive.

Maybe the RAM limit would be a problem during compilation?

Writing a multiple page app is already a pain to organize so writing a multipage app (Axe) that creates multipage apps (your app) would be very tricky

Quote from: Hayleia on December 23, 2011, 08:59:16 am

Quote from: aeTIos on December 23, 2011, 08:57:35 am

not possible oncalc Due to RAM limits

This has nothing to do with Ram limit since Apps are run from Archive.

Maybe the RAM limit would be a problem during compilation?

Yeah, I didn't think about that one

Having code on multiple pages is pretty hard to orchestrate without writing the code manually in ASM. On the other hand, having only data, not code, on other pages might be possible if something similar to the archived file reading operations are used (and RAM wouldn't be an incredibly difficult issue there, since the extra-page data could be written directly to archive rather than being stored in RAM)

I think the most effective way to accomplish this would be to have a different static pointer syntax (with a prefix or something) for data on other app pages. That way, the user will be able to control what data is accessed more slowly and what data is accessed more quickly, and Axe will easily know whether to generate a normal memory access or an off-page memory access. If you use a 16-bit pointer for off-page accesses, that's a maximum of 4 pages of data available, and data will be able to cross page boundaries.

Edit: Also, I suppose that when compiling a RAM program, these special pointers could be treated like normal data, as much as RAM allows.

Edit2: Actually, come to think of it, this wouldn't work for specifying anonymous data on other pages. But I guess [HEX]^r and Data()^r aren't taken, right?

Edit3lol: In fact, if the syntax for archived data is Data()→prefixStr1, the syntax for anonymous data could be Data()→prefix