Double Integer Maths

[lanternfish]

Having searched hig and low in the forums, I am unable to find a good description for how to tackle double integer maths with the PICAXE.

The problem I have is converting radians to degrees. Now, the usual formula is: degrees = radians * 180 / pi. That part is easy.

In my application the radians component is a double integer (32 bits) with the following specs with a range of +-0 to pi/2 ( -1.5707963 to +1.5707963) and a resolution of 10-e8.

As the required resolution is only 10-e3, to convert radians to degrees:

(pi/2 x 10e3) * (180 x 10e3) / (pi x 10e3)

= 15708 * 1800000 / 31416

= 900000

= 900000 * 10-e3

= 90.0000

but 180 x 10e3 is greater than 16 bit resolution so how can I achieve the desired resolution?

Your help greatly appreciated.

 

[inglewoodpete]

Have a look at PICAXE 32-Bit Maths by the PICAXE Maths genius Jeremy Leach.

Alternately, there is uM-FPU, a 32-bit floating point coprocessor in an 8-pin DIP using i2c. The uM-FPU can also handle long integers and conversions.

 

[hippy]

Or scale the calculations so no overflow occurs. For example, instead of multiply by 10E3, multiply by 10E2, the adjust later in the calculation. The accuracy of the result may suffer as a result.

Also you can take common factors out. In this case -

(pi/2 x 10e3) * (180 x 10e3) / (pi x 10e3)

is

(1/2) * (180 x 10e3)

 

[lanternfish]

Have a look at PICAXE 32-Bit Maths by the PICAXE Maths genius Jeremy Leach.

Alternately, there is uM-FPU, a 32-bit floating point coprocessor in an 8-pin DIP using i2c. The uM-FPU can also handle long integers and conversions.

Didn't use 32-bit as a search team. Drat!

Have downloaded the above pdf. Looks promising. Will read, re-read ..... and try. Thanks for that.

Had thought of the uM-FPU (board space isn't an issue -yet) but at NZ$40 for uM-FPU V3, hoped I could avoid this if possible.

Cheers

 

[lanternfish]

Or scale the calculations so no overflow occurs. For example, instead of multiply by 10E3, multiply by 10E2, the adjust later in the calculation. The accuracy of the result may suffer as a result.

Also you can take common factors out. In this case -

(pi/2 x 10e3) * (180 x 10e3) / (pi x 10e3)

is

(1/2) * (180 x 10e3)

Yes, from reading otherposts, scaling the calculations is the way to go. However, I need the 10e3 resolution.

As for my example,tThe problem is that pi/2 is the maximum value and I have no way of knowing what the x in pi/x will be.

My maths knowledge is starting to show its age and under use.

As always, thanks for the help.

 

[MartinM57]

I'm a tad confused.

In my application the radians component is a double integer (32 bits) with the following specs with a range of +-0 to pi/2 ( -1.5707963 to +1.5707963) and a resolution of 10-e8.

Integers aren't normally classed as 16 bit so do you just mean it's a 32 bit number?

(as an aside, where are you getting a 32 bit number from that represents an angle to such incredible resolution in radians and why do you still want it in a stonkingly high resolution in degrees?)

Also I think you are showing you are showing that this number is representing positive and negative values - when you say "+-0 to pi/2" you really mean -pi/2 to +pi/2?

How does 32 bits equate to a resolution of 10e-8? (and we won't get onto accuracy vs. resolution just yet)

So what value indicates 0 (radians)?

As the required resolution is only 10-e3, to convert radians to degrees:
(pi/2 x 10e3) * (180 x 10e3) / (pi x 10e3)
= 15708 * 1800000 / 31416
= 900000
= 900000 * 10-e3
= 90.0000

I don't follow this at all.

Is the problem statement:
- I'm getting a 32-bit scaled number that represents a positive or negative angle in radians
- The scaling is such that -pi/2 is represented by x and +pi/2 and pi/2 is represented by y (for you to fill in x and y for us)
- I want to convert this to degrees, to an accuracy of 3 decimal places, i.e. -90.000 to +90.000
- I want my number to be represented in the following way:
- another scaled number using some other scaling (so I can do some more maths on it) where the scaling is ...err, what?
...a PICAXE integer representing the whole number of degrees (using 2's complement representation to cope with negative angles) and a PICAXE word representing the number after the decimal point (so I've got a chance of displaying this somewhere)?
...a PICAXE integer representing the sign (positive or negative), a PICAXE integer representing the whole number of degrees and a PICAXE word representing the number after the decimal point (so I've got a chance of displaying this somewhere)
...something else?

 

[BeanieBots]

Before you consider the uFPU, read the datasheet very carefully.
It only has a resolution of 23 bit.

 

[hippy]

It may also be worthwhile describing not just the abstract problem ( "How do I convert A to B" ? ) but what you are actually attempting to achieve overall.

Sometimes that may be the same, or very much so, but sometimes there may be other approaches which can be adopted which can simplify the processing. For example, readings based on pulses from sensors a foot apart don't have to be converted into a mph speed then converted to kph, then to metres-per-second and so on, but may be done in one step.

 

[lanternfish]

#6: Okay, clarifying my original post.

The value is from the Rockwell GPS unit I am using. This is the Rockwell Binary format output for latitude (longitude ranges +-pi radians). It consists of 2 words (4 bytes). And apparently has a resolution of 10-e8. I don't need that high a resolution.

I wish to convert this value to degrees, minutes,seconds. I'm not worried about the decimal seconds).

The Rockwell manual describes this as a Double Integer value. Just to confuse matters, I recently stumbled across another reference that states that this is "Extended Floating Point".

If we go back to the original Rockwell statement and given that the value is signed +/- then it must be, in 2's complement(?):

MSB LSB
-------------------------------------------------------------------
| S|............... (MSH)..................|..................(LSH)..................|
-------------------------------------------------------------------
0--1---------------------------15--16---------------------------31

Does this help?

#8: Absolutely. I just can't get my head around converting the Rockwell Binary DI to degrees, minutes, seconds.

Cheers

 

[lanternfish]

Of course, if the field is in fact a floating point number then it should have the 2's complement format:

MSB LSB MSB LSB
------------------------------------------------------------------
| S|..............Mantissa...............|.............Exponent...................|
------------------------------------------------------------------
0 . 1....................................23 24.........................................31

 

[hippy]

This is the Rockwell Binary format output for latitude (longitude ranges +-pi radians). It consists of 2 words (4 bytes). And apparently has a resolution of 10-e8. I don't need that high a resolution.

I wish to convert this value to degrees, minutes,seconds. I'm not worried about the decimal seconds).

There are 1,296,000 seconds in a full circle so you're going to need a high resolution. Do you really need that level of accuracy of reading ?

 

[MartinM57]

If I'm understanding you correctly (I'm not convinced) I think this might be in the "too hard" box for an 8-bit microcontroller without considerable effort.

Is it one of these? http://www.scribd.com/doc/8982545/Jupiter-Gps-Board

...which suggests that you can configure it to output NMEA or Rockwell Binary. One seems a lot easier to understand and use than the other....

 

[lanternfish]

If I'm understanding you correctly (I'm not convinced) I think this might be in the "too hard" box for an 8-bit microcontroller without considerable effort.

Is it one of these? http://www.scribd.com/doc/8982545/Jupiter-Gps-Board

...which suggests that you can configure it to output NMEA or Rockwell Binary. One seems a lot easier to understand and use than the other....

It is. Have no problem with the NMEA data. Can parse and output this no trouble at all.

I was whether it is possible to decode Binary output with a 28X2. he binary output would certainly make it easier to 'trap' the latitude, longitude, altitude frames as they are of fixed length. It is the 32-bit maths that causes the problem.

Cheers

 

[hippy]

It can be done - the umFPU is an 8-bit processor - but it will be an effort to do. It's more complicated than '32-bit math' because it's '32-bit floating point math'. Routines have to be provided to perform all the fundamental maths operations which are used and to convert between floating point and integer and handle signs.

Three possibilities -

* Work it all out from first principles

* umFPU I believe have some algorithms placed in the public domain or GPL'd

* Write the code in C/Basic/Other and run it through a compiler for an 8-bit micro then convert the generated code to PICAXE basic.

 

[lanternfish]

There are 1,296,000 seconds in a full circle so you're going to need a high resolution. Do you really need that level of accuracy of reading ?

#11

May not need that precision, for sure.

As longitude is given as an angular measurement ranging from 0° at the prime meridian to +180° (pi radians) eastward and −180° (-pi radians) westward, the binary string must be signed (bit 31). And this does not provide enough 'digits'. I am now assuming that the 2 word (4 byte) Rockwell binary is single precision binary floating-point.

Is this a wrong assumption?

This could mean that of the 32 bits, bit 31 is the sign, bits 30 - 23 are the exponent and bits 22 - 0, the fraction.

Will look at some binary output over the next few days and hunt down some algorithms to assess the output data.

And as I never got into floating point "back in the day" it will be a bit of a steep learning curve. But, what the hell!

Cheers

 

[lanternfish]

Just found a Wiki article that may help. And this explains it all:

n = (1 - 2s) x (1 + m2^-23) x 2^(x-127)) where s is the sign bit, x is the exponent and m is the fraction (significand).

All seems perfectly clear now (yeah right!)

Cheers

 

[hippy]

Is this a wrong assumption?

I don't know. You'd have to have a precise specification of how the data is represented. I wouldn't assume anything; there could be any number of bits used in the exponent, single precision and otherwise are just arbitrary labels or applicable to certain standards and there's no necessity for any internal representation to match a particular standard.

I don't follow the "this does not provide enough 'digits'" analysis, but it's not clear what 'this' is.

Mantissas and exponents can be of any bit length. As the maximim radian value is 2*PI it's possible that the exponent isn't a traditional +127/-127 style value, it could be +3/-252. While the bearing represents -/+ it could be offset by PI so mantissa not signed at all. Speculation doesn't really get you anywhere. You can also represent your floating point numbers in any form you want within the PICAXE; 64-bit mantissa, 16-bit exponent if you feell like it. Offsetting by PI yourself to get rid of negative bearings will make life easier, putting the sign back when you come to display.

 

[lanternfish]

Is this a wrong assumption?

I don't know. You'd have to have a precise specification of how the data is represented. ....

And therein lies one of the problems, as I haven't been able to find any info on the exact format of the data. And what I have found conflicts.

I don't follow the "this does not provide enough 'digits'" analysis, but it's not clear what 'this' is.

Sorry. 'digits' should have been 'bits'. And my muck-up because there are more than enough bits in 4 bytes to do 1,296,000 seconds in a full circle.

Mantissas and exponents can be of any bit length. As the maximim radian value is 2*PI it's possible that the exponent isn't a traditional +127/-127 style value, it could be +3/-252. While the bearing represents -/+ it could be offset by PI so mantissa not signed at all.

The Rockwell info has it that latitude is max. pi/2 and longitude max. pi. So I get a little confused from there.

Speculation doesn't really get you anywhere.

Though by speculating it may provide a start point for analysing the data fields.

.... Offsetting by PI yourself to get rid of negative bearings will make life easier, putting the sign back when you come to display.

Hmmm!

Thanks for that.