Hi there,

I'm working on STM32F103 MCU and i need to compute the power of a value.

I use the math.h library but I'm looking for a more optimised library, if it's exists.

Is there a better way to compute the power?

Best Regards,

F.

Hi there,

I'm working on STM32F103 MCU and i need to compute the power of a value.

I use the math.h library but I'm looking for a more optimised library, if it's exists.

Is there a better way to compute the power?

Best Regards,

F.

In C, pow(x, y) does things in double-precision.

As usual, there is a single-precision variant in C lib too, here called powf().

Or, you are searching for some integer based algorithm. This function is not architecture-dependent, so you can try to port any algorithm.

Or, depending on your requirements, even a table-based approach might do, possibly with interpolation.

A lot depends on your ideas of performance, precision, and parameter range.

Hi Danish,

thanks for the reply.

Yes, you are right, I want to compute x^y.

Furthermore, my variables x and y are float. So I think that I can obtain the result in a short amount of time.

So, Can I use math library without problem?

Thanks

powf() is faster than pow() - sticking with the math library.

One point: that sensor claims its output is inversely proportional to distance.

So does this mean y is always -1.0f?

In which case you really want to calculate <scale_factor>/x ?

Another point: We're dealing with mechanical distances here. How many measurements per second is useful here?

And how many milliseconds does the pow() calculation take?

There's little point optimising something that will make very little difference to the overall system performance.

- Danish

The sensor generate a new measure every 25 milliseconds. Also I need to compute an average of these values. So I think that I'll compute the distance every 200 - 500 ms.

this is the first time that I use this distance sensor ( with exponential output ) and I don't now the best way to compute the distance.

For a (supposedly) hobby project, using powf() or even pow() would be fine, there seems plenty of time for the calculation.

But I sense the author of the Arduino lib did not spend much thoughts about resources or performance - which does not come as a surprise...

So does this mean y is always -1.0f?

In which case you really want to calculate <scale_factor>/x ?

I would consider Danish's comment.

A division is cheaper than a (usually) Taylor series based function, in terms of runtime.

I'm not working on a hobby project.

Fine, the initial posts just sounded like that.

Then I would think harder before pulling in floating point functions and libraries at all. You will see the impact on code space usage.

Having a look at the datasheet, I can't immediately identify an x^y relation (power function).

Rather, it seems partially ambiguous (voltage for 2.0cm distance = voltage for 5.5cm distance).

I would make my own measurement, and perhaps try a table-based approach.

Am I right in thinking that you are trying to compute x^y but you find it takes too long on stm32f103?

If it is taking too long then that often means you want to do it many times in quick succession, perhaps with either x or y not changing between calculations.

In C, pow(x, y) does things in double-precision. If x and y are not double-precision (e.g. float - ) then it first has to convert them to double-precision, and if you only need the result to be float then it has to convert back to float. All 3 steps waste time. powf(x, y) is faster if you only need float.

And if x or y are integers (e.g you only want to calculate x^2) then it is

muchfaster to explicitly do x*xHow else might things be speeded up?

pow calculates exp(y*log(x))

So if x doesn't change from call to call, then you can pre-calculate the log.

I'm sure there are other things to do to improve the speed of calculation, but only because you know something about the calculation or series-of-calculations that the compiler didn't guess.

I'd expect the math library to be pretty-well optimised and fast for double-precision numbers in general.

Hope this helps,

Danish