#Free42 android appszoom manual
#Free42 android appszoom code

I like to juggle the stack myself in programs instead of using register but the limited stack in particular forces you to make it understandable e.g. In RPL a new structured language was developed and the stack was replaced by a list with stack-functionality for calculations. The programming 'language' (Keystoke) resulted from it. In RPN calculation was the startpoint and the stack optimized for this kind of operation. In RPL it became consistent with a dynamic stack. Wouldn't a dynamic array be more consistent for this on a RPN Calculator?Īs I mentioned in an other thread, I don't see RPL as a successor to RPN but more as a fork. I think it was precisely this consideration that led to the development of RPL. the big stack offers an alternative for people who prefer that kind of coding style.

You have no idea how often my HP48 almost flew out of the window because of 'Error: To Few Arguments' which even appeared on the HP48 if you wanted to push it away with ]. It has been pretty reckless on the part of HP to ignore the habits of many RPN users in such a mean way. x=0 is not the same as an empty stack and you can't clear the stack with '0 enter enter enter' etc.

#Free42 android appszoom manual

(02-03-2021 11:21 PM)Thomas Okken Wrote: For manual calculations this may not be a very big deal. Thanks! (BTW, I think ANS is a pretty confusing name, too.) Confusingly there is an ARG (right-shift /) but that's the Arg of a complex number. On the 50g it's called ANS (left-shift ENTER). (How does that work on the 50g, actually? I'm referring to the command that retrieves all the parameters consumed by the last function, on the 48G, but I can never find anything on the 50g.) (02-03-2021 06:41 PM)John Keith Wrote: (02-03-2021 03:45 PM)Thomas Okken Wrote: UNDO would be difficult, but ARG would actually be pretty easy.

#Free42 android appszoom code

The current code will not handle this case correctly hopefully I'll have this fixed by tomorrow. The former is sort of OK as is, but doesn't deal with memory allocation failures well the latter, which is rather important because you'll need it if you want to use 4-level-based functions from a big stack context, is still a bit of a mess, and that is turning out to be rather complicated to get right.

By the way, before anyone gets too deep into this, I should mention that I'm still working on the code to clean up after FUNC+LNSTK and FUNC+L4STK.