I keep getting "400 Bad Request"

This version works on (0,128) and averages less than 1250 t-states:
lognat:
;Input:  H.L needs to be on (0,128.0)
;Output: H.L if c flag set
; returns nc if input is negative (HL not modified)
;Error:
; The error on the outputs is as follows:
; 20592 inputs are exact
; 12075 inputs are off by 1/256
; 100 inputs are off by 2/256
; So all 32767 inputs are within 2/256, with average error being <1/683 which is smaller than 1/256.
;Size: 177 bytes
;Speed: average speed is less than 1250 t-states

ld a,h \ or l \ jr nz,$+5
ld h,80h \ ret
dec h
dec h
jr nz,$+9
inc l \ dec l
jr nz,normalizeln-1
ld l,177
ret
inc h
jr nz,normalizeln
ld b,h
ld c,l
ld e,l
ld d,8
add hl,hl
add hl,hl
add hl,de
ex de,hl
call HL_Div_DE
ld h,a \ ld l,b
sla h \ jr c,$+3 \ ld l,c
add hl,hl \ jr c,$+3 \ add hl,bc
add hl,hl \ jr c,$+3 \ add hl,bc
add hl,hl \ jr c,$+3 \ add hl,bc
add hl,hl \ jr c,$+3 \ add hl,bc
add hl,hl \ jr c,$+3 \ add hl,bc
add hl,hl \ jr c,$+3 \ add hl,bc
add hl,hl \ jr c,$+3 \ add hl,bc
rl l
ld a,h
adc a,b
ld h,b
ld l,a
scf
ret
HL_Div_DE:
add hl,hl \ sbc hl,de \ jr nc,$+3 \ add hl,de \ adc a,a
add hl,hl \ sbc hl,de \ jr nc,$+3 \ add hl,de \ adc a,a
add hl,hl \ sbc hl,de \ jr nc,$+3 \ add hl,de \ adc a,a
add hl,hl \ sbc hl,de \ jr nc,$+3 \ add hl,de \ adc a,a
add hl,hl \ sbc hl,de \ jr nc,$+3 \ add hl,de \ adc a,a
add hl,hl \ sbc hl,de \ jr nc,$+3 \ add hl,de \ adc a,a
add hl,hl \ sbc hl,de \ jr nc,$+3 \ add hl,de \ adc a,a
add hl,hl \ sbc hl,de \ adc a,a \ ret

inc h
normalizeln:
xor a
inc h \ ret m
ld d,a \ ld e,a
ld a,l
jr z,toosmall
inc e \ srl h \ rra \ jr nz,$-4
rla \ rl h
dec e
stepin:
ld l,a
push de
call lognat
pop de
;now multiply DE by 355, then divide by 2 (rounding)
ld b,d \ ld c,e \ ld a,d
ex de,hl
add hl,hl
add hl,hl ;4
add hl,bc ;5
add hl,hl ;10
add hl,bc ;11
add hl,hl ;22
add hl,hl
add hl,hl
add hl,hl
add hl,bc
add hl,hl
add hl,bc
sra h \ rr l
adc hl,de
scf
ret
toosmall:
dec d
dec e \ add a,a \ jr nc,$-2
inc h
jp stepin
The worst error is 2/256, which is much better than I thought it would be On [1,2] it is at worst 1/256 and the average case is <1/683 which is smaller than 1/256 (the smallest positive 8.8 number).

Quote from: Xeda112358 on November 11, 2013, 12:56:18 pm

I like labels in BASIC because they can often be an excellent solution and often the best solution
[...]

When's that They also have that memory bug

That memory 'bug' isn't a bug, actually, it is just misuse of Goto and Lbl inside While, Repeat, and For loops.

Examples are when you use the Menu() command, the options need to jump to labels, then if you want to jump back to the menu, you either need to use a non-optimal Repeat loop, or the more optimal Goto. For example:
Lbl 0
Menu("HEADER","ITEM 1",01,"ITEM 2",10,"EXIT",1
Lbl 01
Pause "HI!
Goto 0
Lbl 10
Pause "HAHAHAHAHA
Goto 0
Lbl 1

In reality, While loops and Repeat loops use memory (so large nestings of these can consume lots of RAM) whereas Lbl and Goto use no memory. In RPGs, using labels is usually the best option, and for games where you want to use subroutines without using subprograms, you can take advantage of mixing labels and while loops. I made heavy use of this in an RPG a while ago.

To be more technical, the OS needs to push information onto an operator stack whenever it executes a loop. When it reaches an End, it uses that information and it doesn't remove it until the loop is finished. If you had 9 nested while loops, then , it pushes the data for each loop onto this stack, and when it reaches an End, the information is popped off in reverse order. If you use a Goto to jump out of a loop, the data never gets popped off the stack unless you place an unused end somewhere (but then only one item is popped off).

Wow, these are fantastic o.o I definitely missed a lot of these.

For path finding, I have only successfully done it on a tiled maze. Essentially, I had the human player and the non human player 'chasing.' Chasing is done by moving in the optimal direction to be closer to the human player. The trick is when the chaser gets stuck, I would draw on some other buffer marking the position and the chaser would not be able to stay on that tile, so they would move backwards or left/right and each tile visited for the next 8 or 16 turns would be marked as well and they would remain marked for 8 or 16 turns (think of a snake from a snake game being placed on the other buffer growing for 8 or 16 turns, then shrinking).

This allows the chaser a little more intelligence to get unstuck, and when you have multiple chasers, the others can avoid getting stuck, too, while potentially taking other routes. I actually got the idea from a cellular automata experiment where I had a few hundred cells navigating a maze and the majority of them were able to find the exit. That, however, is too taxing on the CPU for use in a game on these calculators.

I wish I still had a working example

I do not have an 8XU to test it, it is just a bunch of code. I want to write a simple command line interface first, as an App that clears RAM and uses nothing from the OS. Then if I can successfully use it as a calculator and make a simple program, I will try to turn it into an 8xu.

Oh, I should clarify. To use the same kind of math abilities, this should be about as fast as BASIC. Graphics and such should still be faster, and if the programmer uses integers or even 24-bit floats instead of full 80-bit floats, the program should run much faster than TI-BASIC.