If you look carefully at that line, you use a right parenthesis instead of a right curly brace, hence your problem.

Interestingly enough, I could figure out this exact problem just from looking at the hex error dump. Boy am I glad I added that.

---

EDIT: Also, Builderboy is absolutely correct about what he mentioned in the post below. Adding the store there will actually introduce issues because of how the increment operator works.

It's also worthy to note that the ++ operation already stores the incremented value back to where it was read from, so the →{C+D}r part is completely unnecessary (and may not even work 100% of the time, since ++ doesn't always return the incremented value)

Going to reply to both of you here. I realized what I had done immediately after going to bed... I was just dicking around in Axe right before sleep trying to get a working range encoder working... seems I've learned a lesson, never post a bug report until I've had a good night of sleep. I realized how bad the thing was after I had stepped away from it. Anyway yeah... sorry about that everyone. I'm the stupid apparently... I'll post the range encoder to the routine thread once it's completed.

P.S. Once more, sorry for wasting everyone's time, I should've slept on it/not done something right before bed...

Edit: I also seem to need to get used to it being the bastard child of C and BASIC. I'm used to C, and wrote some BASIC, but it seems like I'm intermingling the syntax in areas it shouldn't be. Anyway I'll avoid posting to this thread unless it's something that I've been stuck with for at least 24hrs and looks to be OK.

Edit 2: Thanks for the awesome utility, once I get used to it, it should be better for me to write up some quick routines in.

Are you using a custom interrupt? If you look at the changelog you'll notice that custom interrupts now use the area that contains table data, resulting in your issues. You'll also notice that I added LnReg^r to restore that.

I still got a spurious Illegal Token error. And when I pressed [PRGM], the screen was full of random tokens. The program was in archive, and when I pressed [ON]+[DEL] with zStart to exit w/o saving, my calc crashed.
The same process kept happening until I put in RAM--the spurious error persisted through RAM clears.

Also, earlier, I watched as, after compiling an app, but before defragging and writing, Axe just hung, giving me a "Writing..." screen with an empty progress bar.
Nothing I did could exit out of it.
This again persisted through RAM clears, but a deletion and reinstallation of Axe fixed it.
Also, the first time it happened, it deleted two of my source files. I put them back on the calc from backups I had on the computer. They were fine the second time, though.

If you use a constant value in For() which is 256 or less, it's already optimized to loop over a single byte. I guess there's no For(const)^r for that reason.

Floating point math _isn't_ working currently.

Here's an example program.

:.TEST
:2/10->Float{C}
:C*10->C
:Float{C}
:Disp C>Dec
Expected result.

1
Done
Actual result.
0
Done
I've tried this multiple times and apparently floating point math doesn't work at all right now. I can't understand it but it's just not, at all. This is exactly accordingn to the commands documenation, it should result in the value being 1. It doesn't though, which makes me not understand why it's even there right now then. I've tried it on my ti-84plus se calculator running 2.43 with Axe 1.2.1, and I've also tried it with tilem2 running a 2.43 rom with the same specs(rom built by wabbitemu), and also a literal dump of my calculator. I've also tried it on an emulated ti-83plus se. None of them give the expected result(according to the syntax as setup in the commands list/documentation).

There is also Jacobly's Axiom for floating math stuff. I am not sure it works with latest versions of Axe (since it uses Select as token) but if it doesn't, you can necropost in the topic and ask for an update

The /* operation divides two 8.8 fixed point numbers, but the numbers you are giving it are not in fixed point format.  To put the numbers in fixed point format, use 1.0 and 10.0 instead of 1 and 10.  Furthermore, when you display a fixed point number, it will be x256, so if you expect the result 1, you will see the result 256.  In this case, you will see the result 250 because of rounding error when you do the divide.

OK, it _has_ to be a bug then. I'm using Axe 1.2.1 and changing the values to "1.0, and 10.0" makes the number the _same_ 250, which means that, according to you, there's a rounding error(for some reason). Also the thing that got me into this whole crazy thing in the first place was some "big"(at least I think it is) numbers not working right in Axe.

It was (2/10)*65535. I was expecting a whole number 13,107.  But, it never turns into that value... ever. I doubt Axe would be able to do it right now since you're saying it's all 256ths and 65535 256ths wouldn't be the 65535 value(a maximum for the total range in the range encoder I was working), just isn't working at all. I tried the fixed point math, it doesn't work either, nothing seems to work.

So since Axe can't do floating point math, and since fixed point(isn't working either), I don't know what to do right now. Since it's just not working(at all), and also since fixed point only works with values -128 to 128. The value I get is 65485(which is almost 1.0*65535), and it well should've been 0.2(51/256ths clearly close enough), but somehow that gets converted into nearly 1.0 which makes no sense to me(at the moment) but I imagine it's something with the parser. I'm beginning to think that I should just give up on Axe, as it's promises were too great. Even the math isn't working as one would think.

Edit: Basically, I wanted to do a simple rouguelike with psuedo-procedural generated content. But I wanted a way to compress the premade "rooms" and other data, in range encoding(seemed like a perfect first program... at least has always worked just fine for all of my other language excursions). Well to be honest, I normally do LZW, as the first one, but axe it looked to be requiring way too much work. But now I don't even know if range encoding will even work, because that's the _only_ spot I have to use non integers, and of course the one spot where I need some sort of non-whole number math, it doesn't work... Basically even if I don't do "real numers" it says it's 0. Even though (2/10)*65535 should be that 13,107. This is _only_ spot I needed non integer math, and of course it's not going to work.

Well... I guess there's two spots, the part where I calculate the share of the range, and then once again when I'm running over the data... but either way I had always used 65535(or some similar "big") number as I don't need super-duper precision. I just needed a way to do fixed point during that part. Then a single operation during the second part too. I was planning on just storing the counts(x bits) one after another and then recalculating the whole range later on. But anyway yeah, 3 decimal points _should_ be way more than enough.(with the whole range I'm using I just need for the values at the end to add up to the whole thing), and then of course make sure that the ranges work right(for the final two byte range value).

That's all I wanted to say here about it, I may go to the subroutine thread and asking for a fixed point math routine that actually does fixed point math as one would expect(even with the rounding errors.)