• Axe Q&A 5 5
Currently:  

Author Topic: Axe Q&A  (Read 528231 times)

0 Members and 2 Guests are viewing this topic.

Offline selectcoaxial

  • LV2 Member (Next: 40)
  • **
  • Posts: 29
  • Rating: +0/-0
    • View Profile
Re: Axe Q&A
« Reply #555 on: August 03, 2011, 04:03:37 am »
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?

Offline Aichi

  • LV5 Advanced (Next: 300)
  • *****
  • Posts: 290
  • Rating: +76/-3
    • View Profile
    • Devrays
Re: Axe Q&A
« Reply #556 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. :)

Offline Quigibo

  • The Executioner
  • CoT Emeritus
  • LV11 Super Veteran (Next: 3000)
  • *
  • Posts: 2031
  • Rating: +1075/-24
  • I wish real life had a "Save" and "Load" button...
    • View Profile
Re: Axe Q&A
« Reply #557 on: August 03, 2011, 05:06:28 am »
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).
___Axe_Parser___
Today the calculator, tomorrow the world!

Ashbad

  • Guest
Re: Axe Q&A
« Reply #558 on: August 03, 2011, 07:33:37 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.

Offline ztrumpet

  • The Rarely Active One
  • CoT Emeritus
  • LV13 Extreme Addict (Next: 9001)
  • *
  • Posts: 5712
  • Rating: +364/-4
  • If you see this, send me a PM. Just for fun.
    • View Profile
Re: Axe Q&A
« Reply #559 on: August 03, 2011, 09:23:42 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.

Offline Freyaday

  • The One And Only Serial Time Killing Catboy-Capoeirista-Ballerino
  • LV10 31337 u53r (Next: 2000)
  • **********
  • Posts: 1970
  • Rating: +128/-15
  • I put on my robe and pixel hat...
    • View Profile
Re: Axe Q&A
« Reply #560 on: August 03, 2011, 10:46:22 am »
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.
In other news, Frey continues kicking unprecedented levels of ass.
Proud member of LF#N--Lolis For #9678B6 Names


I'm a performer at heart; I stole it last week.
My Artwork!

Offline selectcoaxial

  • LV2 Member (Next: 40)
  • **
  • Posts: 29
  • Rating: +0/-0
    • View Profile
Re: Axe Q&A
« Reply #561 on: August 04, 2011, 05:53:54 am »
I found a way around using decimals numbers :D. 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:

Code: [Select]
.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
« Last Edit: August 04, 2011, 06:21:54 am by selectcoaxial »

Offline MGOS

  • LV6 Super Member (Next: 500)
  • ******
  • Posts: 336
  • Rating: +95/-0
    • View Profile
Re: Axe Q&A
« Reply #562 on: August 04, 2011, 07:27:09 am »
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)
« Last Edit: August 04, 2011, 07:27:35 am by MGOS »

Offline selectcoaxial

  • LV2 Member (Next: 40)
  • **
  • Posts: 29
  • Rating: +0/-0
    • View Profile
Re: Axe Q&A
« Reply #563 on: August 05, 2011, 10:06:55 am »
I don't think so because if I use
Code: [Select]
sub(EXC,3)
Disp A>Dec,i

I only get 1 display.

Offline zeldaking

  • LV4 Regular (Next: 200)
  • ****
  • Posts: 197
  • Rating: +15/-0
    • View Profile
Re: Axe Q&A
« Reply #564 on: August 05, 2011, 10:10:30 am »
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).
« Last Edit: August 05, 2011, 10:11:19 am by zeldaking »

Ashbad

  • Guest
Re: Axe Q&A
« Reply #565 on: August 05, 2011, 02:33:45 pm »
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.
« Last Edit: August 05, 2011, 02:37:30 pm by Ashbad »

Offline Runer112

  • Project Author
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2289
  • Rating: +639/-31
    • View Profile
Re: Axe Q&A
« Reply #566 on: August 05, 2011, 04:28:11 pm »
Just for clarification because people seem to be confused: fixed point numbers in Axe are represented in decimal just like you would represent them normally. 255.255 is not 255+(255/256) or 0xFFFF. It's a decimal representation, so 255.255 is 255+(255/1000) or 0xFF41. If you wanted to represent the maximum fixed point number, you would use 255.999 which is 0xFFFF.
« Last Edit: August 05, 2011, 04:31:26 pm by Runer112 »

Ashbad

  • Guest
Re: Axe Q&A
« Reply #567 on: August 05, 2011, 08:17:53 pm »
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. :)

« Last Edit: August 05, 2011, 08:25:37 pm by Ashbad »

Offline Runer112

  • Project Author
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2289
  • Rating: +639/-31
    • View Profile
Re: Axe Q&A
« Reply #568 on: August 05, 2011, 08:33:22 pm »
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 just a little strange because of a slightly off constant.
« Last Edit: August 05, 2011, 08:38:00 pm by Runer112 »

Ashbad

  • Guest
Re: Axe Q&A
« Reply #569 on: August 05, 2011, 08:46:50 pm »
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.