Thank you! I read somewhere on the forum that Axe doesn't handle decimals numbers and it will be rounded automatically down and up. Is that right? Is there a routine or a way to store numbers such as 0.53?

There is also the new decimal feature in Axe... If you type: 0.53, it will automatically convert the number to fixed point notation, which in hex would be: 0x0087.  Some common operations with fixed point numbers are FP-inverse and FP-multiplication.  Converting from fixed point to decimal is easy: Divide by 256 to get the integer part.  Mod by 256 to get the fractional part (a fraction out of 256).

Quote from: Aichi on August 03, 2011, 04:39:12 am

You could store the values 0.00 to 655.35 in two bytes if you multiplicate your values by 100.
Displaying them correctly would be possible with an own displaying routine.
Furthermore Axe supports access to the floating-point variables of the OS afaik. Just take a look at the commands list.

Perhaps you mean 0.0 to 255.255?  655.35 wouldnt work so well as a FP high limit, considering the decimal part and integer part are both 8 bits.

Nah, I think he meant what he said.  I'm pretty sure he was giving an example with 100 as an arbitrary number.

I found a way around using decimals numbers . thanks. I'm having a problem with calling sub functions. I'm using Ashbad's guide for Axe v0.5.3 because I've had problems of getting my RAM and Archive cleared when I used Axe v1.0.1. The problem I'm having with my program is that it display the value of C 6 times, even though I only ask for it thrice, and the value of C is even different from each other in every Disp call. the code is below:

.PAST

sub(PAS,5)

Lbl PAS
1->C
1->K
r1-K->B
sub(EXC,r1)
A->C
Disp C>Dec,i
sub(EXC,K)
C/A->C
Disp C>Dec,i
sub(EXC,B)
C/A->C
Disp C>Dec,i
Return

Lbl EXC
1->A
For(I,1,r1
A*I->A
End
Return

Display are as follow: 120, 120, 5, 24, 24, 4

EXC is used for factorials ! and PAS is to generate a binomial coefficient.

The value for C I expected is 5

I don't think so because if I use
sub(EXC,3)
Disp A>Dec,i

I only get 1 display.

Advice: Don't use axe 1.0.0 or 1.0.1 as of now, they have a pretty good bug that killed my calculator (still trying to fix it).

You can use 1.0.2

Your problem is that you don't quit the program after calling sub(PAS). Then the programm will pass this function twice -> you get it displayed 6 times.
put a return after
sub(PAS,5)

Very, very correct.  PAS will be executed twice; the return for the definition label will eventually be used as the program-quitting return statement.  Put a return there where he said too; everything else seems fine from my quick skimming through it.

Your mixing your bases with 255.255, as that number is beyond Axe's precision in decimal and out of bounds in hex. What you're looking for is 0xFF.FF, 255+(255/256) in decimal.

Meh, 255.255 isn't out of the range at all.  It's the same as 0xFF.FF, but in decimal form, since 0xFF == 255.  It's a correct representation.

but, to keep it clean since you can't represent every single one of those 255,999 numbers, 255.255 is a better representation because it keeps you thinking in binary terms.  255.999 works, but it's rather misleading because you can't access all of the numbers such as 255.999, 255.998, 255.997, etc.  you can only access 25.5% of them.  255.255 is a better representation because while it doesn't conform perfectly to decimal standards (it makes it seem like the max limit on the fpart is just over 1/4) it represents the range better, as it's just a decimal representation of each separate ipart and fpart, instead of the value as a whole.  I still stand correct, as it's still a correct representation, just a different one.

It's not the representation Axe uses though. So whether or not it can be correct in other situations, I don't want people using it in Axe and then being helplessly confused when their program acts strange.

You use what you want, I'll use what I want; the correct way for axe if you are going to do it that way should be 999.999, since it's confusing for some if you mix a pure-decimal part with a "this is how many numbers a byte can portray" part.  Since it's entirely an incarnation of a u_int8.u_int8 format, either way is correct based on how you want to think of it.  Using 1000 units to fill a space where each of those units fills a space of .255 natural units (so, only 25.5% of them can actually represented by the fpart) is more confusing since the 1000 unit standard is rather arbitrary and made up while the 256 unit standard is extremely natural and conforming to how things actually work.  Just as long as people realize that .0x01 = .00390625, or 1/256 unnatural units, they'll be even better off.  Kinda like how radians are better to work with in many cases than degrees since 360 is a somewhat arbitrarily made up standard for units, whereas 2pi radians are more natural.

Of course, it all matter on how they are supposed to be thought of, but for the most part 255.255 is a more natural description.