This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Runer112
Pages: 1 ... 46 47 [48] 49 50 ... 153
706
« on: December 27, 2012, 03:32:43 pm »
I'm not sure it's hung... try holding down CLEAR for a good second or so. The program only checks keys between frames, and frames can take a long time (almost a second) to render. And the blank screen may just be a fully white image (like a portion of the graph screen) displayed in mode 7.
707
« on: December 27, 2012, 03:24:31 pm »
No, the issue is sort of the other way around. 'Sx' is a statistics token that apparently the computer tokenizer he used recognized, so it converted his references to the custom variable he named "Sx" into a token that Axe doesn't recognize.
708
« on: December 27, 2012, 02:59:17 pm »
I think Matrefeytontias used a computer tokenizer to create the 8xp, which turned the letters "Sx" into the statistics token 'Sx'. You can fix these fairly easily by hand, I think there were only two issues.
709
« on: December 26, 2012, 06:34:32 pm »
Select(EXPR1,EXPR2) is an optimized way (only 2 bytes!) of saving the value of EXPR1, then evaluating EXPR2, then restoring the value of EXPR1. The first Select(-1,blah) decrements one from the loop counter, which goes from 3 to 0, and then saves it while we do the actual work. The next Select({+S},blah) adds the loop counter to S, reads the value at that memory location, and saves it; this is so we can use it for the ^5 later, while we can also use it for *2/10 now. Each call to the Store() command stores the 2-byte value before it to the previous letter variable (starting with S/R), and because of how we ordered our calls to it, we store the value divided by 5 first to the later letter variable, and then the value modulo 5 second to the letter variable right before it.
710
« on: December 26, 2012, 02:03:55 pm »
Hold onto your pants.
°S→A
8
While 1
End!If Select(-1,Select({+S},*2/10Store())^5Store())
Lbl Store
→{A-2→A}ʳ
Return
If speed is important and you want to avoid the /10 B_CALL and doing both a divide and a modulus operation:
°S→A
8
While 1
End!If Select(-1,{+S}-(Select(/5,Store())*5)Store())
Lbl Store
→{A-2→A}ʳ
Return
EDIT: I do hope these actually work; I didn't test them.
EDIT 2: Now I did test them, fixed a small issue with the second one and now they both work.
711
« on: December 25, 2012, 10:56:33 pm »
Okay, let's tackle this one bit at a time, and hopefully we can fully settle everything:
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).
I can assure you that fixed point math worksas intended. Any "bugs" you experience with fixed point math, like this rounding error, are simply due to the nature of doing math with numbers squashed into only 16 bits. Stepping through the calculation, 1.0/*10.0 would ideally give 0.1, but because fixed point numbers in Axe hold fractional information as 256ths, this (25.6/256) actually results in 25/256. Multiplying this by 10.0 then gives 250/256, giving you the result you see of 250.
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.
This is related to the issue above. Doing math with 16-bit numbers can have some fairly tight range limitations, unfortunately: 0 to 65535 for unsigned integers, -32768 to 32767 for signed integers, and -128 to 127.996 for (signed) fixed point numbers.
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.
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.
The calculation (2/10)*65535 can't really work in Axe, once again due to 16-bit number limitations. In the notation you gave, treating the numbers as integers, we have a precision problem: 2/10 will give 0, which multiplied by 65535 is still 0. Change the notation to fixed point like (2.0/*10.0)**65535.0, and now we have a range problem: 65535.0 is well beyond the range of Axe's fixed points. Try to mix the two like (2.0/*10.0)*65535, which I believe is what you did, and we have a sort of number identity problem: 2.0/*10.0 would result in 51/256, as you said. But then multiplying by 65535 gives 3342285/256, which does not fit into 16 bits. So all the data that overflowed past 16 bits is lost, and we're left with the 16-bit result 65485/256, giving you your result.
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).
I might suggest first making the engine without any data compression. It might be good to get a bit of a feel for the language doing some lighter tasks first, anyways. But when you do get around to compression, I do agree that length encoding may not be an effective approach due to the strengths of weaknesses of Axe. Your alternate idea of LZW may be more reasonable, or a simpler algorithm like LZ77 would be even more so.
As for the few pieces of your post which you may have noticed I did not feel like specifically quoting and responding to: I am currently the sole developer and maintainer of the Axe project, and I feel that in this role I have a responsibility to assist others with its use on an individual level, which I hope this post has been able to do. Being the one solely responsible for its proper functioning, I have to say that your insistence on features of it simply not working and lack of consideration for the possibilities of language limitations or misunderstandings doesn't really help either of us. So for remedying any future issues, rather than simply telling me that it doesn't work, I would appreciate your asking why things seem problematic and how I/we can help you come to a solution. 
712
« 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.
713
« 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.
714
« on: December 22, 2012, 11:21:34 pm »
I would personally add as a suggestion port Axe to allow to compile it for TI-83 calculators: as more and more projects are using it, it would be great to be able to use them on a TI-83 calculator!
This is a fairly large undertaking, so it's not exactly at the top of my priority list. It is on it, though.
A Axe PC application would also be appreciated
Writing a program on a PC is faster than on a calculator (and less fear of loss of data).
Just write programs in a program/web application that allows editing/saving 8xp files; for example, TI Program Editor, TokenIDE, SourceCoder, or IES. Then you can either send them to an emulator or a physical calculator to compile and test them.
Maybe you could add to the list as feature request multi-pages app and as optimization suggestion lazy if-conditions
I haven't updated this list in forever, I have a personal list that I keep track of all of this stuff on now. The best place to suggest features will always be the Features Wishlist, which I regularly check and add any good ideas to my to-do list. And short-circuit logic operators already exist as ? and ??. *edit AOC* This post and a few other were in another topic. That's why Runer refers to the feature Wishlist topic in this post. He isn't crazy or anything (as far as I know  )
715
« 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.
716
« on: December 20, 2012, 01:12:14 am »
I'm new here and I've got 3 feature requests:
1) a compile mode (some sort of debug mode) in which axe adds before every possible function that can result in a loop, like goto, while, repeat, for, sub, ... a code that terminates the program if a specific button is pressed. I know this is something I can build in my program myself very easily, but it is annoying to remove it afterwards in my finished version.
2) someway to test multiplayer games with 1 grm and optional a computer. I've got no idea how this could be realised, mayby by making a small program on the pc that sends a byte predefined byte when you press a key on the keyboard? The thing is, my friends don't want to play my games until I've tested them and so I can never play multiplayer games.
3) making the function-name-changing thing that axe does optional, it is a great feature, but I've noticed that it slows down scrolling through a program a lot, so I clear my ram always after compiling a game to spead it up again.
Hello, new person! I hope Axe has been useful for you, but let's see if we can't make it better: 1) I have plans to eventually add some sort of safety mode in which pressing ON during execution of an Axe program will immediately exit it. I think this should cover what you wanted. 2) Performing arbitrary linking between a computer and a calculator is extremely difficult. Also Axe uses the serial port for linking, and I'm not even sure it's possible to reprogram a silverlink cable to work with that. So unfortunately I don't think this feature will ever be added. If you want to test linking, I suggest loading up more than one virtual calculator in an emulator that supports virtual linking. 3) I agree that it should be optional, although I would disagree that it slows down scrolling by *a lot*. I'll add both an on/off toggle and speed improvement to my to-do list.
717
« 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. 
718
« on: December 19, 2012, 03:08:19 am »
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.
719
« on: December 19, 2012, 12:33:43 am »
The error message for a too-large app is "ERR:MEMORY". It really should be something more descriptive, like say, "ERR:TOO BIG FOR ONE PAGE" or something.
And that is too big for one error message. Anyways this isn't really a bug, and you still knew what it meant so it seems like it's descriptive enough. Maybe you won't even see that error eventually.
Does this mean we might be able to have two-page Axe apps in the future?
Eventually I hope so, yes. But as I've mentioned in previous posts, it's a logistical nightmare so don't expect it any time soon.
720
« on: December 19, 2012, 12:20:54 am »
Hey,
I met a big bug for new 1.2.1 commands
I didn't have enough time to try all combinations, but [W/I/ ][H/V]Line(arg,arg,arg) never worked, and IHLine(X,58000,1500) clears RAM when program stops.
For [W/I/ ][H/V]Line(arg) I had no matter
Fixed! Thanks for the report, I made a silly mistake that was easy to fix given this information.
And ICircle(X,Y,R) bugs : the circle is cut into 4 or 8 pieces of circle when inverted, either on white or black : there are always 4 or 8 pixels missing.
Fixed! I thought inverted circles looked a little funny when I briefly tested them, but somehow couldn't put my finger on it... Those few missing pixels turned out to be quite the challenge to fix (in an optimal manner), but after an hour or two I figured it out.
Trying to make a program with a name that contains invalid characters (like lowercase letters) will sometimes flat-out not create a program instead of cutting off the name.
I can't really say I'm too concerned with input validation right now, because it's an annoying issue that takes large amounts of code to get perfectly right (which Axe frankly doesn't have the space for). But I'll consider it down the road.
The error message for a too-large app is "ERR:MEMORY". It really should be something more descriptive, like say, "ERR:TOO BIG FOR ONE PAGE" or something.
And that is too big for one error message. Anyways this isn't really a bug, and you still knew what it meant so it seems like it's descriptive enough. Maybe you won't even see that error eventually.
Pages: 1 ... 46 47 [48] 49 50 ... 153
|
Show Posts