Regarding The Library And Variable Usage.

[davidthefat]

Okay, I was wondering if anyone has any idea why the WPILib uses doubles instead of floats. It makes more sense to me to use floats over doubles. I find it very "costly" to use 32 extra bits. Also, why are variables like PWM ints? Why not a short? Sure, if java had unsigned variables, I would have used uint_8 (unsigned byte) instead.

Now, keep in mind, this is an embedded system. It is not a good idea to spam usage of doubles IMHO. Even if we have like 64 mb of ram. I know, you can fill that up with over 6 million doubles, but it still bothers me.

[EricVanWyk]

Why not? Unless you get actual gains by going with smaller data types, it isn't worthwhile.

You'd be surprised at the relative costs of things in modern processors. I'm not a PPC expert, but I did do a lot of assembly level optimization of on the ARM (THUMB2) platform. Using U8s instead of U32s can often be slower, as memory access is word aligned.

Don't optimize unless you have to and will actually benefit.

[MikeE]

Originally Posted by davidthefat

Okay, I was wondering if anyone has any idea why the WPILib uses doubles instead of floats. It makes more sense to me to use floats over doubles. I find it very "costly" to use 32 extra bits. Also, why are variables like PWM ints? Why not a short? Sure, if java had unsigned variables, I would have used uint_8 (unsigned byte) instead.

Now, keep in mind, this is an embedded system. It is not a good idea to spam usage of doubles IMHO. Even if we have like 64 mb of ram. I know, you can fill that up with over 6 million doubles, but it still bothers me.

I spent several years cramming fairly sophisticated signal processing and pattern matching algorithms onto embedded systems, and one of the lessons I took from the experience is that the embedded world doesn't always work the way one would naively expect.
While integer arithmatic was always preferable for speed we encountered several situations where floating point calculation was faster using double precision than single precision floats due to implementation details in support libraries. And in almost all cases of consumer electronics memory access speed was a more significant practical constraint that raw number crunching.

IMHO the primary purpose of the library is clarity and utility for programmers of various abilities. Bit cramming efficiency should be at best a secondary consideration.

[davidthefat]

I get it, after reading the PPC Instruction Set Reference Manual, the PPC's Floating Point Registers are 64 bit registers. In other words, if I were to use single precision floating points, then the processor has to shove that to one 32 bit side of the register and fill the rest with 0's. I get it, that takes more effort than just shoving a double in there. The single precisions are always converted to doubles anyway.

Reading the technical manuals really do help...

So there was a method to their madness...

[MikeE]

Originally Posted by davidthefat

So there was a method to their madness...

In the most part the libraries are written by professional software engineers, so I start with the assumption that there is a good reason for design decisions. (Always allowing for the possibility of bugs occurring in complex systems of course.)

[Greg McKaskle]

Not to beat a dead horse, but if I recall, the singles are loaded into the registers as doubles. That doesn't mean adding 32 zeroes on the end, but it means changing a (23+1,8,1) format into a (52+1,12,1). This means that the base two exponent uses 12 bits rather than 8, and the mantissa is 52 with 1 implicit bit instead of 23 bits. Both formats are described by the IEEE 754 format -- a pretty fascinating read.

Greg McKaskle

[davidthefat]

Originally Posted by Greg McKaskle

Not to beat a dead horse, but if I recall, the singles are loaded into the registers as doubles. That doesn't mean adding 32 zeroes on the end, but it means changing a (23+1,8,1) format into a (52+1,12,1). This means that the base two exponent uses 12 bits rather than 8, and the mantissa is 52 with 1 implicit bit instead of 23 bits. Both formats are described by the IEEE 754 format -- a pretty fascinating read.

Greg McKaskle

Aha, thank you, I knew something sounded wrong about my statement. i read about that a couple days ago!

[MikeE]

Originally Posted by Greg McKaskle

Both formats are described by the IEEE 754 format -- a pretty fascinating read.

Spotlighted!
You've provided an outstanding working definition of an Engineer (EE/ECE sub-species).