Axe Q&A

[Deep Thought]

It will almost definitely overflow the stack in a very short amount of time (and that's probably why the routine you linked to crashes).

A better alternative (that works) is a queue algorithm. It uses a queue (like an array) to hold the list of points to test, instead of recursively calling a function that can quickly fill up the hardware stack.

[MGOS]

That's what I did... first I gave the program the 714 bytes L1 which sucked, then a 5kB Buffer which kinda works, but not 100%.

(A,B) are the coordinates of the "Paint bucket"
(P,Q) are the coordinates the stack returns (given is a 5000B large Buffer, so 2500 coordinates should fit in)

Code: Select All | Copy To Clipboard

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34

0->S PUS(A,B) While S POP() Pxl-On(P,Q) If P-95 PUS(P+1,Q) End If P PUS(P-1,Q) End If Q-63 PUS(P,Q+1) End If Q PUS(P,Q+1) End End Return Lbl PUS ReturnIf pxl-Test(r1,r2) If S<2500 r1->{S*2+GBD1} r2->{S*2+GBD1+1} S++ End Return Lbl POP S-- {S*2+GBD1}->P {S*2+GBD1+1}->Q Return

File is attached

The number displayd at the end tells how often there was a stack overflow.

[Builderboy]

There was a floodfill routine posted earlier that used no extra memory and so can never cause a crash, but I can't find the link anymore

[MGOS]

There was a floodfill routine posted earlier that used no extra memory and so can never cause a crash, but I can't find the link anymore

That's a bummer.

[chattahippie]

Here's one jacobly made

http://www.omnimaga.org/index.php?topic=12583.15

[MGOS]

Here's one jacobly made

http://www.omnimaga.org/index.php?topic=12583.15

Wow... that one's cool. now I'm wondering if I should stick with the tough work of converting it to axe or think of another solution by myself.

Edit: I rewrote my algorithm that it needs only a second 768 B buffer like Xeda wrote, but it is d*mn slow (because of the search algorithm I used)

Screeny at 4x speed:

[Yeong]

Why won't this code work?

Code: Select All | Copy To Clipboard

1 2 3 4 5 6

"Pic0Pic1Pic2Pic3Pic4Pic5Pic6Pic7Pic8Pic9"→Z "Pic1"→I GetCalc("varP")→Q float{Q}→P {Z+P}→{I}

For some reason, it seems like string I doesn't change. Why is that?

[jacobly]

"Pic0" is actually 3 bytes long (not including the terminating 0).

Since the first two bytes are always the same, you could do:

Code: Select All | Copy To Clipboard

1 2 3 4 5 6

"Pic0Pic1Pic2Pic3Pic4Pic5Pic6Pic7Pic8Pic9"→Z "Pic1"→I GetCalc("varP")→Q float{Q}→P {P*3+Z+2}→{I+2}

But an even better method would be:

Code: Select All | Copy To Clipboard

1 2 3 4 5

"Pic1"→I GetCalc("varP")→Q float{Q}→P (P?-1,9)→{I+2} .Pic1-Pic9 is 0-8, and Pic0 is 9.

Edit: Not enough parentheses. Also, that's subtract 1, not negative 1.

[Yeong]

Ah. I never knew that Pic1 was 3 bytes O.o
Thanks a bunch.
EDIT: also, will I be able to use 0 as pic0? because that seems more reasonable to me.

[jacobly]

That's what the code does: it converts an input from 0-9 to the internal representation of that Pic. So if you type in a 0 it will give you the pointer to Pic0 (represented internally as a 9).

[Runer112]

I know you didn't ask for this, but I'm just going to provide a few tips about how to improve the code:

Code: Select All | Copy To Clipboard

1 2 3 4 5 6 7 8 9

"Pic1"→Str1                 .Use static instead of varaible data pointers                             . whenever possible, they are more optimized !If GetCalc("varP")         .Error handling is important!  .Handle error  .Return or Goto somewhere End (float{}??10)-1→{2+Str1}    .Omits storing and reloading the value returned by GetCalc()                             . and restructures the conditional to omit the else branch

[Yeong]

So, here's my code.

Code: Select All | Copy To Clipboard

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41

:.AATEST :"Pic1"→I :GetCalc("uP")→J :fPart(J}→K :K?-1,9→{I+2} :UnArchiveI :GetCalc(I)→Q :conj(Q,{L6},768 :DispGraph :ArchiveI :GetCalc("Str1")→V :GetCalc("uA")→M :GetCalc("uB")→N :GetCalc("uH")→O :GetCalc("uW")→P :fPart(M}→A :fPart(N}→B :fPart(O}→H :fPart(P}→W : :"0123456789ABCDEF"→T :0→θ :For(D,0,H/8-1 :For(C,0,W/8-1 :For(F,0,7 :8*pxl-Test(8*C+A→Z,8*D+B+F→Y) :+(4*pxl-Test(Z+1,Y)) :+(2*pxl-Test(Z+2,Y)) :+pxl-Test(Z+3,Y) :→U :{T+U}→{V+θ} :8*pxl-Test(Z+4,Y) :+(4*pxl-Test(Z+5,Y)) :+(2*pxl-Test(Z+6,Y)) :+pxl-Test(Z+7,Y) :→U :{T+U}→{V+θ+1} :θ+2→θ :End :End:End

Yeah, I know I takes a lot of var from OS
But that aside, the problem is that no matter the OSVar P is, it still shows Pic1. What did I do wrong? (problem probably comes from the first few lines of the code)

[Runer112]

The issue is the line with the inline conditional. It's not treated as TI-BASIC experience may suggest, like this:
(K?-1,9)→{I+2}

It's treated like this:
K?(-1),(9→{I+2})

So with your current code, P=0 will select Pic0, but no other values of P have any effect because the store statement is not executed. To fix this, add the parentheses as shown in the first line of code. Alternatively, use the code I suggested in my previous post since it's more optimized anyway.

[Yeong]

oh.
Thanks for the solution.
also, what's the difference of using Str1 and A? (Static and variable)

[Runer112]

Depending upon usage, there are quite a few differences between using static pointers (constants) and variables. Most can simply be summarized with the fact that constants are more optimized. To cite the two examples from your code:
"Pic1"→I = 3 bytes (not counting the size of the string data)
→{I+2} = 8 bytes

Whereas with a constant:
"Pic1"→Str1 = 0 bytes (not counting the size of the string data)
→{Str1+2} = 4 bytes

I also just realized that the second code statement can be further optimized by making the store a full 2-byte store. It may sound counter-intuitive that saving 2 bytes instead of 1 byte is actually smaller, but it works out this way because Axe works with 2-byte values and the conversion to a 1-byte value costs a byte when storing to a constant address.
Note: You shouldn't always convert 1-byte stores to a constant address into 2-byte stores to save size, as many times, overwriting the second byte at the store address is undesired. However, in this case you'll end up overwriting a 0 with another 0, so it doesn't matter