Trigonometry and Exp/Log functions

ManAtWork

Is there a Spin2 object that supports trigonometry and exp/log functions? I've found Eric's BinFloat.spin2 in OBEX but as this also includes add/sub/mul/div I think it was created before floats were officially supported by the compiler. I haven't found anything in the library included in the Propeller tool distribution.

Duane Degn

I don't know about log functions but I can get most of my trig needs satisfied with rotxy() , polxy(), xypol(), qsin() and qcos().
These functions all use integers.
These are listed starting at the bottom of page 10 in the Spin2 doc.

Mickster

@ManAtWork said:
Is there a Spin2 object that supports trigonometry and exp/log functions? I've found Eric's BinFloat.spin2 in OBEX but as this also includes add/sub/mul/div I think it was created before floats were officially supported by the compiler. I haven't found anything in the library included in the Propeller tool distribution.

You working on s-curve acceleration by any chance?

I don't need it but I will want it at some point. Wondering about the most efficient approach with the P2.

Craig

ManAtWork

@Mickster said:
You working on s-curve acceleration by any chance?

Acceleration profiles for CNC and motion control can easily done all with integers. You usually have a fixed upper limit to all numbers so overflows are not an issue. And the sale numbers are high enough to justify lots of work for coding and optimization.

For projects that are more in the "research" and single unit area I'd prefer floating point numbers. I don't want to worry about overflows and I don't want to spend much time on finding the optimum range and scaling factors.

The barometric altitude formula, for example, is nonlinear and requires a pow() function. In the Elev-8 flight controller firmware this is avoided by linear interpolation with a large table. It's possible but it makes it hard to apply corrections. An explicit formula is much easier to handle.

BinFloat.spin2 works very well. And if I use FlexSpin I have dead code removal. I only call that pow() function 25 times a second so performance is not an issue.

Mickster

@ManAtWork
You have handled s-curve with integers?

I'm sure it's possible and in fact, I'm not convinced that the 'S' is even that critical due to motor response, etc.

Craig

pik33

Exp and log are cordic operations, so if they are not present, a few asm lines will do the trick. They are 5:27<>32:0 so I needed several experiments to fully understand how they works (and I used them for synth's ADSR)

Mickster

@pik33 said:
Exp and log are cordic operations, so if they are not present, a few asm lines will do the trick. They are 5:27<>32:0 so I needed several experiments to fully understand how they works (and I used them for synth's ADSR)

Man, I should have thought about the synth stuff. Wow my needs are obviously trivial

Craig

pik33

I didn't manage to do 16 voices and 6-op FM in one cog So the next iteration will be 4-op thing. With a nice control panel for which I already did a 32 bpp video driver

ersmith

@ManAtWork said:
Is there a Spin2 object that supports trigonometry and exp/log functions? I've found Eric's BinFloat.spin2 in OBEX but as this also includes add/sub/mul/div I think it was created before floats were officially supported by the compiler. I haven't found anything in the library included in the Propeller tool distribution.

BinFloat still works with the modern PNut compiler (I updated it to change the names of a few functions to avoid conflict). The add/sub/mul/div it provides are IEEE compliant, whereas the PNut ones aren't. I forget which tests fail, I think some NaN ones and a few rounding tests. If you want to use the compiler built-ins the easy thing to do would be to change the definitions of add/sub etc. to use +. -. and so on. I don't know what effect this would have on the accuracy of the trig functions; there might be a few more rounding errors.

ManAtWork

@Mickster said:
@ManAtWork
You have handled s-curve with integers?

S-curves are in fact rather trivial when you have a pre-computed trajectory. You simply output the velocity profile without any ramps at all (infinite acceleration, rectangular brick walls). Then you run a moving average filter over it and you get a triangular profile with linear ramps. Run another moving average filter and you get S-curves. Voilà.

@ersmith said:
BinFloat still works with the modern PNut compiler (I updated it to change the names of a few functions to avoid conflict). The add/sub/mul/div it provides are IEEE compliant, whereas the PNut ones aren't. I forget which tests fail, I think some NaN ones and a few rounding tests. If you want to use the compiler built-ins the easy thing to do would be to change the definitions of add/sub etc. to use +. -. and so on. I don't know what effect this would have on the accuracy of the trig functions; there might be a few more rounding errors.

Yes I might do that and create a trimmed version of BinFloat. I don't care about bit-for-bit IEEE compliancy as long as I get ~20 bits or better accuracy or something like that. Some day, Parallax has to provide their own math library, I think. But for me it's perfectly OK to use both, built in add/mul and Trig/Exp of BinFloat.

NaN is pretty handy to handle errors. If one of the sensor values is invalid (GPS signal is too weak or receiver needs more time to start up and scan for satellites, for example) I could put NaN there and all results that use that input are automatically flagged NaN, too.

mwroberts

@ManAtWork said:

S-curves are in fact rather trivial when you have a pre-computed trajectory. You simply output the velocity profile without any ramps at all (infinite acceleration, rectangular brick walls). Then you run a moving average filter over it and you get a triangular profile with linear ramps. Run another moving average filter and you get S-curves. Voilà.

I get what you are saying! Very interesting... in the past I've always treated two adjacent moves as separate adding the decel velocity of the prior to the accel of the current to get the composite velocity durring the overlap....

Circuitsoft

@ManAtWork said:

S-curves are in fact rather trivial when you have a pre-computed trajectory. You simply output the velocity profile without any ramps at all (infinite acceleration, rectangular brick walls). Then you run a moving average filter over it and you get a triangular profile with linear ramps. Run another moving average filter and you get S-curves. Voilà.

Reminds me of Bezier Curves.