Hi Oliver, 2012/1/27 Oliver Seitz <[email protected]>: > Hi Joep! >> Long vars are a true advantage. However, use them as a substitute for float >> does require a lot more attention: > >> - you need to plan for the max used value and the min required accuracy. > > This is true. But in many cases this shouldn't be too hard. If you're dealing > with time, probably a femtosecond is precise enough. If it is length, it's > probably a micrometer. True, this is not hard when you are aware of the concept and have simple dimensions. It is still extra though. And there are catches: if femtosecond is the time base and micrometer is the length, speed will be in units of 250 times the circumference of the earth and as such of no practical use. So you might want to use nanoseconds and nanometers in this particular case (which brings it down to 1 m/sec) and scale this particular variable by 1000 to support mm/sec. A float would hide this kind of complexity for you. A tutorial that elaborates on this could help, but still it takes effort and you need to stay aware of the underlying effects of fixed scaling.
> If you really don't know beforehand, you can use a 83-byte variable > multiplied by 10^100, this is what a common pocket calculator can display. > maximum range 10^100, resolution 10^-100. (I might be wrong here, I'm not > sure the compiler can handle multiplications and divisions on this size.) That would be expensive - large program, memory and cpu load. A float would use 8 bytes... >> - assing and print properly is not as obvious as real floats. > > Very true ;-) Assigning a constant value which is not zero is nearly > impossible. But a function could be implemented to do this: > > pi=fixpoint_divide(fixpoint_int_to_fix(314159),fixpoint_int_to_fix(100000)) > > Printing has to be done through a library function, just like for integers. This should do the job (and you would need similar functions if you would go for floats). >> It might be possible to implement floats in a library and use a large >> variable ( or struct?) to store it and pass it to functions. Most of such a >> library would be straightforward. The main issue would be to maintain the >> optimal exponent. > > I had preferred fixed point, because at least add/subtract would be no > effort, and printing is really easy, too. Only if all fixed points are scaled similar (as you suggest, but at a footprint impact). > But it's worth to think in this direction, too, of course. My math skills are > a bit rusty in this field, though ;-) If they are rusty, they are there. As I said before, afaik the main issue is automatic selecting the right exponent (maximal precision without overflows). I looked into this briefly last summer. Maybe next summer, I'll have time to implement it in a library. >> Print_string(serial_hw_data, 'hello JAL world.') would be a start. It is a >> personal feature request from the moment strings were introduced but has not >> been implemented in all those years. > > This points in the direction where the cause might be lying why I prefer to > think about a fixed point lib and not asking for compiler support of float > vars ;-) Fixed point math is good. For an amateur developer, a float math library might be better. > And, switching to C is not an option for me right now... I dislike C so much > that I would take quite an effort to avoid using it... Interesting... I like C, especially with the more strict C++ rules on (amongst others) prototypes. Only downside is the availability (standardization) of libraries. E.g. for the launchboard are two compilers, each with their own set of libs. And for AVR there are probably even more libs. This was case with JAL before jallib: many libraries existed, but you had to combine them yourself and keep them up to date afterwards... Anyway, if there would have been an efficient non-crippled C-compiler for pic-16 at the time, I would not have used JAL... Regards, Joep -- You received this message because you are subscribed to the Google Groups "jallib" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jallib?hl=en.
