I looked at the Obex fixed point library, but decided on F32 because it seemed easier to deal, better supported, and integrated better with IDE constants.
Can you point me to that library, I seem to be too blind to find it. I found one with fixed point in its name, but looking into it I found that it si simply an older IEEE float implementation not fixed point. I would be interested in it before I code one on my own.
martinh, this is the fixed point library: http://obex.parallax.com/objects/501/ I believe that it is written in Spin which is why it is slower than F32.
martinh, this is the fixed point library: http://obex.parallax.com/objects/501/ I believe that it is written in Spin which is why it is slower than F32.
Thx, that is what I found, but I really was blind and got confused by the source code of the FloatMath.spin which is not fixed point. Now I look through the spin_trigpack.spin and found the fixed point implementation. Yes it is written completely in spin - soooo sloooow.
Well - I have to code this in PASM if nobody else has one ready.
If there is someone interested, I will post it for review and improvement in another thread, but don't expect miracles or early results. The prop is only hobby of mine and has nothing to do with my daily job, so my progress will be awfully slow.
I have mostly use for the following fixed point types (only signed types, no unsigned for the moment):
32bit: s+23.8, s+15.16, s+7.24
and 16 bit: s+7.8 (maybe but only maybe also s+11.4)
so I will start with that formats.
Not sure until now which math functions make sense to be implemented for this types, I have to think about it.
I've read this quote from you several times on the forum:
As my old boss used to say "If you think you need floating point to solve the problem you don't understand the problem"
Sorry, yes, I'm getting old and repetitive:)
To this day I'm not sure it that boss was talking about maths on a computer in general or the particular problems we were dealing with at the time.
Or was it so that he was trying to make us feel better because the processors we were targeting were only 16 bit with no floating point hardware and the language we were using, CORAL 66, had only fixed point math support.
Do you have any suggestions on how we can better understand the problem.
In general no. Which problem? They are all different.
Can one do trig without floating point?
Of course. How do calculators do it:)
Worrying about overflowing 32 bits etc. is new to me.
And that is a general problem. Programmers throw everything into floats and assume they need not worry about anything any more. Guys brought up programming 8 bit micros and such soon learn what their number ranges are.
Fair enough. I've just assumed 64 bit float support is completely off the table for the Prop. It would be bigger and slower than F32. Notice that no one has felt the need too create an F64 yet. Besides Spin does not even have 64 bit integer data type.
I think you skipped that part on my MATH page at http://propeller.wikispaces.org/MATH. It is only for the 4 basic functions and no spin wrapper... as I do not care about spin ;-).
I have been thinking on revamping it a bit and add some more stuff like signed numbers, and finally adding the cordic part and the conversion routines... plenty to do
yes the idea is that you just call a cog when you need it, and fall back to floatmath if it's not available. There's also a bunch of navigation specific stuff that you can comment out if you want (this was for the autopilot)
Comments
I also found the dynamic math lib mentioned above: http://obex.parallax.com/objects/194/
Well - I have to code this in PASM if nobody else has one ready.
If there is someone interested, I will post it for review and improvement in another thread, but don't expect miracles or early results. The prop is only hobby of mine and has nothing to do with my daily job, so my progress will be awfully slow.
I have mostly use for the following fixed point types (only signed types, no unsigned for the moment):
32bit: s+23.8, s+15.16, s+7.24
and 16 bit: s+7.8 (maybe but only maybe also s+11.4)
so I will start with that formats.
Not sure until now which math functions make sense to be implemented for this types, I have to think about it.
Sorry, yes, I'm getting old and repetitive:)
To this day I'm not sure it that boss was talking about maths on a computer in general or the particular problems we were dealing with at the time.
Or was it so that he was trying to make us feel better because the processors we were targeting were only 16 bit with no floating point hardware and the language we were using, CORAL 66, had only fixed point math support.
In general no. Which problem? They are all different.
Of course. How do calculators do it:)
And that is a general problem. Programmers throw everything into floats and assume they need not worry about anything any more. Guys brought up programming 8 bit micros and such soon learn what their number ranges are.
I think you skipped that part on my MATH page at http://propeller.wikispaces.org/MATH
Oops, sorry, forgot about that. What an excellent page that is.
I have been thinking on revamping it a bit and add some more stuff like signed numbers, and finally adding the cordic part and the conversion routines... plenty to do