Efficiency of heatindex calculation method about bme280

[finitespace]

@coelner can you fix this.

[coelner]

Yes, I take care of this.
@jirkaptr
How did you do the measurement of speed and code size?

1. yes, it seems reasonable.
2. yes, but not by writing it directly to the formula. the values should be const including the use of PROGMEM. Why should it save RAM if we write it directly to the formula?
3. No, because below this temperature the heatindex is not relevant. use windchill instead. I will add a textual reminder and return the original temperature.
4. Yes. I fixed that. Thanks.

[jirkaptr]

@coelner:
To point 2.
My idea regarding code efficiency improvement is this (substitution of lines 75 – 83):
heatindex = -8.784695; //coeff. 0
heatindex += 1.61139411 * temperature; //1
heatindex += 2.338549 * humidity; //2
heatindex += - 0.14611605 * temperature * humidity; //3
float TempQ = temperature * temperature;
heatindex += (-1.2308094 / 100) * TempQ; //4
float HumQ = humidity * humidity;
heatindex += (-1.6424828 / 100) * HumQ; //5
heatindex += (2.211732 / 1000) * TempQ * humidity; //6
heatindex += (7.2546 / 10000) * temperature * HumQ; //7
heatindex += (-3.582 / 1000000) * TempQ * HumQ; //8

The gist is in fact that constants written directly into code (also defined by #define) are (usually) treated as part of code, i.e. as constants taken directly into ALU from program code, and they do not occupy RAM. Another advantage is that there are not calculated and used pointers to array. This is most effective solution (but not ideally aesthetic).

To point 3.
Most of resources provides information about limit 26.7/80. However I have found NOAA document http://www.wpc.ncep.noaa.gov/html/heatindex_equation.shtml . This document gives a good impression.

Merry Christmass!

P.S.:
Additional info:
The article "Methods to Calculate the Heat Index as an Exposure Metric in Environmental Health Research" (https://ehp.niehs.nih.gov/1206273/) compares 21 calculation methods of HeatIndex. The essential info is contained in these pictures:

Above mentioned NWS algorithm:

[coelner]

@jirkaptr
Point 2: Understood, but I think it is up to @finitespace to decide which way he wants
Point 3: https://github.com/adafruit/DHT-sensor-library/blob/09344416d2f3e8da0526494eb008c98d95fc0d79/DHT.cpp

[finitespace]

Yeah, I would like to remove all these magic numbers from EnvironmentCalculations.cpp. I think the only way to do that without increasing memory usage is to to throw a bunch of defines at the top. That was an interesting solution to use PROGMEM, I am not sure of it's downfalls as I have not used it before.

[coelner]

pull request contains NWS algorithm and coeffs as #define

[finitespace]

@coelner @jirkaptr I have merged @coelner's branch into the heatIndex branch and made modifications to minimize the logic. Please check the logic again to ensure I didn't make any mistakes. If this looks good, I will merge it into trunk.

[finitespace]

#65