Author Topic: Bug Reports  (Read 447952 times)

0 Members and 2 Guests are viewing this topic.

Offline 133794m3r

  • LV2 Member (Next: 40)
  • **
  • Posts: 21
  • Rating: +1/-3
    • View Profile
Re: Bug Reports
« Reply #1785 on: December 19, 2012, 04:05:07 pm »
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.
« Last Edit: December 19, 2012, 04:13:30 pm by 133794m3r »

Offline Sorunome

  • Fox Fox Fox Fox Fox Fox Fox!
  • Support Staff
  • LV13 Extreme Addict (Next: 9001)
  • *************
  • Posts: 7920
  • Rating: +374/-13
  • Derpy Hooves
    • View Profile
    • My website! (You might lose the game)
Re: Bug Reports
« Reply #1786 on: December 19, 2012, 07:42:16 pm »
I noticed that running my axe program messes seriousley up with the plots and with the table settings, resulting in memory/syntax erros when wanting to use 'em.

THE GAME
Also, check out my website
If OmnomIRC is screwed up, blame me!
Click here to give me an internet!

Offline Runer112

  • Project Author
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2289
  • Rating: +639/-31
    • View Profile
Re: Bug Reports
« Reply #1787 on: December 19, 2012, 07:57:23 pm »
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 LnRegr to restore that. ;)

Offline Sorunome

  • Fox Fox Fox Fox Fox Fox Fox!
  • Support Staff
  • LV13 Extreme Addict (Next: 9001)
  • *************
  • Posts: 7920
  • Rating: +374/-13
  • Derpy Hooves
    • View Profile
    • My website! (You might lose the game)
Re: Bug Reports
« Reply #1788 on: December 19, 2012, 08:17:42 pm »
I just use the normal interrupts, compiled as an app
EDIT: That fixed it anyways ^^ thanks
« Last Edit: December 19, 2012, 08:19:43 pm by Sorunome »

THE GAME
Also, check out my website
If OmnomIRC is screwed up, blame me!
Click here to give me an internet!

Offline Freyaday

  • The One And Only Serial Time Killing Catboy-Capoeirista-Ballerino
  • LV10 31337 u53r (Next: 2000)
  • **********
  • Posts: 1970
  • Rating: +128/-15
  • I put on my robe and pixel hat...
    • View Profile
Re: Bug Reports
« Reply #1789 on: December 19, 2012, 08:25:15 pm »
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.
« Last Edit: December 19, 2012, 08:29:20 pm by Freyaday »
In other news, Frey continues kicking unprecedented levels of ass.
Proud member of LF#N--Lolis For #9678B6 Names


I'm a performer at heart; I stole it last week.
My Artwork!

Offline Matrefeytontias

  • Axe roxxor (kinda)
  • LV10 31337 u53r (Next: 2000)
  • **********
  • Posts: 1982
  • Rating: +310/-12
  • Axe roxxor
    • View Profile
    • RMV Pixel Engineers
Re: Bug Reports
« Reply #1790 on: December 22, 2012, 02:04:04 pm »
It seems that For(12)r doesn't work for me → INVALID TOKEN right on the r.

If it can be helpful for someone, here is what it throws after pressing [stats] :

009DB7009ED5110A
A0D7A0D79DAD4861
0A830323BAB30186
004168CB
« Last Edit: December 22, 2012, 02:04:33 pm by Matrefeytontias »

Offline calc84maniac

  • eZ80 Guru
  • Coder Of Tomorrow
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2912
  • Rating: +471/-17
    • View Profile
    • TI-Boy CE
Re: Bug Reports
« Reply #1791 on: December 22, 2012, 02:07:29 pm »
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.
"Most people ask, 'What does a thing do?' Hackers ask, 'What can I make it do?'" - Pablos Holman

Offline Runer112

  • Project Author
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2289
  • Rating: +639/-31
    • View Profile
Re: Bug Reports
« Reply #1792 on: December 22, 2012, 03:41:20 pm »
It seems that For(12)r doesn't work for me → INVALID TOKEN right on the r.

Fixed. :)

Offline 133794m3r

  • LV2 Member (Next: 40)
  • **
  • Posts: 21
  • Rating: +1/-3
    • View Profile
Re: Bug Reports
« Reply #1793 on: December 25, 2012, 12:42:35 am »
Floating point math _isn't_ working currently.

Here's an example program.

Code: [Select]
:.TEST
:2/10->Float{C}
:C*10->C
:Float{C}
:Disp C>Dec

Expected result.

Code: [Select]
1
Done
Actual result.
Code: [Select]
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).
« Last Edit: December 25, 2012, 01:02:42 am by 133794m3r »

Offline Runer112

  • Project Author
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2289
  • Rating: +639/-31
    • View Profile
Re: Bug Reports
« Reply #1794 on: December 25, 2012, 12:51:23 am »
Yeah, I'm not surprised floating point math isn't working, because Axe doesn't have floating point math. The float{} command is only for converting between OS floats and Axe's standard 16-bit integers.

However, if you want something slightly closer to floating point math than integer math, you can use fixed point math. Standard fixed point numbers in Axe give you a range of about -128 to 128, with a precision of 1/256 (they're essentially signed integers treated as being a fraction over 256). You can find more information about both float{} usage and all the fixed point operators in the Commands.html file included in the Axe download.
« Last Edit: December 25, 2012, 12:54:19 am by Runer112 »

Offline Hayleia

  • Programming Absol
  • Coder Of Tomorrow
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 3367
  • Rating: +393/-7
    • View Profile
Re: Bug Reports
« Reply #1795 on: December 25, 2012, 01:29:04 am »
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 :)
I own: 83+ ; 84+SE ; 76.fr ; CX CAS ; Prizm ; 84+CSE
Sorry if I answer with something that seems unrelated, English is not my primary language and I might not have understood well. Sorry if I make English mistakes too.

click here to know where you got your last +1s

Offline 133794m3r

  • LV2 Member (Next: 40)
  • **
  • Posts: 21
  • Rating: +1/-3
    • View Profile
Re: Bug Reports
« Reply #1796 on: December 25, 2012, 02:05:16 am »
Yeah, I'm not surprised floating point math isn't working, because Axe doesn't have floating point math. The float{} command is only for converting between OS floats and Axe's standard 16-bit integers.

However, if you want something slightly closer to floating point math than integer math, you can use fixed point math. Standard fixed point numbers in Axe give you a range of about -128 to 128, with a precision of 1/256 (they're essentially signed integers treated as being a fraction over 256). You can find more information about both float{} usage and all the fixed point operators in the Commands.html file included in the Axe download.

It "should" be OK but now it's not giving me _any_ results that are _remotely_ accurate.

Anyway I just tried it with the "fixed point way". And it doesn't work either.
Code: [Select]
:.TEST
:(1/*10)**10->B
:Disp B>Dec
Expected 1, got 0.

So even though it "should" work, it's still not.
« Last Edit: December 25, 2012, 02:12:31 am by 133794m3r »

Offline Builderboy

  • Physics Guru
  • CoT Emeritus
  • LV13 Extreme Addict (Next: 9001)
  • *
  • Posts: 5673
  • Rating: +613/-9
  • Would you kindly?
    • View Profile
Re: Bug Reports
« Reply #1797 on: December 25, 2012, 02:35:35 am »
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.

Offline Runer112

  • Project Author
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2289
  • Rating: +639/-31
    • View Profile
Re: Bug Reports
« Reply #1798 on: December 25, 2012, 02:42:52 am »
Fixed point math does work, but there are two reasons I can see why that code does not do what I think you may be expecting it to do.

First: As I mentioned in my previous post, fixed point numbers are really just 16-bit signed integers that we "pretend" are divided by 256. What this means is that, when you enter the number 1, this represents the integer value 1, but the fixed point value 1/256. Likewise, those 10s you use really represent the fixed point value 10/256.

Second: You may ask why this still doesn't work, because shouldn't (1/256)/(10/256)*(10/256) still be 1/256, which would be displayed by ►Dec as the integer value 1? Theoretically, yes. (1/256)/(10/256) is the first operation, which should give 1/10. But fixed point numbers in Axe represent fractions as 256ths, not tenths. 1/10 would be 25.6/256, but this gets truncated down to 25/256 which is the crucial reason why this calculation returns the unexpected result. Multiplying this by 10/256 then gives 250/65536, which in 256ths would be 0.9765625/256. And again this gets truncated, giving the final result of 0/256, or simply 0.


Anyways, let's get to actually solving these issues. Unfortunately the truncation errors aren't really avoidable entirely; the best solution is to try to make sure you're not working with too many really small fixed point numbers. But on the other hand, work with numbers that are too large and you'll get overflow errors. So it's a bit of a balancing act. As for the first issue, you could enter fixed point 1 as the integer 256, and fixed point 10 as the integer 2560. But a cleaner way of doing it in my opinion is to enter them as 1.0 and 10.0, as Axe can now convert numbers with up to 3 decimal places into their fixed point values automatically.

Offline 133794m3r

  • LV2 Member (Next: 40)
  • **
  • Posts: 21
  • Rating: +1/-3
    • View Profile
Re: Bug Reports
« Reply #1799 on: December 25, 2012, 08:34:53 pm »
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.)
« Last Edit: December 25, 2012, 08:49:06 pm by 133794m3r »