Hjälp med Float pow(x,y)

[hyperion]

Jag undrar om någon kan hjälpa mig med ett "litet" problem jag har med Float-beräkningar i BoostC.

Om jag t.ex. försöker göra beräkningen: Float = pow(4.1,4.2) så blir det allt annat än rätt.
Verkar som att "y" i "Float = pow(x,y)" måste vara ett heltal? för om x=4 och y=4 så blir det korrekt (256)

Detta är till PIC18F

Från Float rutinen/include:

Kod: Markera allt

float pow(float x, float y)
{
	float retval, real;
	int iterations;
	char neg = 0;

	if (flt_eq(x, 1.0))
		return(1.0);

	if (flt_eq(y, 0.0))
		return(1.0);

	if (flt_eq(x, 0.0))
		return(0.0);

	iterations = flt_toi(y);
	y = flt_sub(y, flt_fromi(iterations));

	if (iterations < 0)
	{
		iterations = 0 - iterations;
		neg = 1;
	}

	retval = x;

	if (iterations > 0)
		iterations--;

	while (iterations)
	{
		retval = flt_mul(retval, x);
		iterations--;
	}

	if (flt_ne(y, 0.0))
	{
		real = flt_mul(x, y);
		retval = flt_add(retval, real);
	}

	if (neg)
		retval = flt_sub(0, retval);

	return (retval);

}

[kodar-holger]

Ja det där ser inte rätt ut. På rad 36 och framåt gör man något magiskt där man försöker addera x*decimaldelen av y till resultatet man fått fram genom iteration. Så kan man inte göra.

Funkar ln? I så fall kan du använda den för att skapa en egen ^ om jag minns rätt.

[hyperion]

Nej ln funkar inte heller har jag för mig. Eventuellt finns en workaround för det men om man med hjälp av den kan göra det du nämner tror jag tyvärr inte.

Du har inte något förslag på hur man kan ändra/rätta rutinen som jag postade som du hittade fel i?

[kodar-holger]

Tyvärr inte. För många år sen hittade jag ett fantastiskt dokument på stora stygga internet som beskrev metoder för approximering av en massa mattefunktioner. Det låg sen på mitt skrivbord i att-studera högen i kanske 10 år innan jag flyttade för några år sen. Då kastade jag det mesta i den högen utan åtgärd. Och nu har jag googlat en stund utan att bli så mycket klokare.

I ditt fall är ju 4.1^4.2 = 4.1^4 * 4.1^0.2 medan koden ger dig 4.1^4 + 4.1*0.2.

4.1^0.2 är samma sak som femte roten ur 4.1 vilket inte gör dig något lyckligare.

Om ln funkat hade säkert en e^ funnits också.

a = x^y
ln(a) = y*ln(x)
a = e^(y*ln(x))

Men funkar inte ln, och finns inte e^ så är du kokt där också.

Hur stora tal behöver du hantera? Större tänkare än jag kan säkert hitta på en serieutveckling du kan använda.

PIC 18F förresten. Hur mycket minne har du???

[hyperion]

Tack för hjälpen! jag och matte säger jag bara... huga

Jadu, minnet i min stackars 18F4550 uttnyttjas väl men just nu bara till cirka 60%.

Jag ska kolla vidare lite på detta nu när jag fått lite tips (hoppas ln/e^ funkar)


Återkommer.

[TomasL]

1k+1k RAM och 32k PGM +256B EEProm
Föreslår att du uppgraderar till 32orna.
18f och flyttal är ingen hejare.

[hyperion]

I know

Ska faktiskt ta mig i kragen och göra klart mitt labbkort för dsPIC33EP512MU814 LQFP-144 så jag kan labba på bäst jag vill utan att få slut på resurser any time soon

Mjukvaran jag använder mig av när jag programmerar har inte stöd för PIC32 tyvärr.

[bearing]

Vad ska du göra / Varför behöver du göra den här beräkningen?

[hyperion]

För att räkna ut höjd över vattnet med en BMP180 sensor.

[kodar-holger]

Jaja, men då måste ju tabelluppslagning och linjär interpolering vara fullt tillräckligt.

Gör beräkningen på så många punkter du har minne till utanför. Lagra dessa i koden (retlw typ) Slå upp värden i tabellen och räkna ut ett mellanliggande värde.

[hyperion]

Såhär ser formeln ut:

h= (((P0/P)^(1/5,257) - 1) * (T + 273,15)) / 0,0065

h = höjd över havet i meter
P0 = lufttryck vid havsnivå i hPa
P = uppmätt lufttryck i hPa
T = uppmätt temperatur i C

Som exempel:

P0 = 1017,00 hPa
P = 1013,25 hPa
T = 24,00 C

Ger:
h = 32,1358091 meter

(det är inte alltid hela tal för för P0 eller T. P är inte heller alltid ,25 / ,50 / ,75 osv. Vill bara klargöra det )

[bearing]

Föreslår att ha tabeller för vänstra och högre termen, och sedan multiplicera dem.

[kodar-holger]

Ger:
h = 32,1358091 meter

Nej. Databladet säger att absolute accuracy i höjd är typiskt +- 1m, så det bästa du kan vänta dig är h=32m oavsett vad matematiken ger dig.

För övrigt är matte viktigt och i detta fall inte så svårt.

h1 = ((P0/P)^(1/5,257) - 1) / 0,0065 får du tabellera som vi sagt. Bilda dig en uppfattning om mellan vilka värden P0 kan variera, och på vilken höjd du kan vara. Räkna ut vilket intervall P kan vara genom att invertera formeln och stoppa in min och max h. Dela upp P0/P i lämpliga intervall och räkna ut lutningskoefficienten. Det är den du skall tabellera för ett P0/P. Leta upp närmast lägre P0/P, subtrahera från ditt P0/P och multiplicera resultatet med lutningskoefficienten från tabellen. (Andra kommer att rätta mig om jag tänkt fel)

h2 = (T + 273,15) / 0,0065 kan du räkna ut. Helt linjär, inga konstigheter

h = h1 * h2


En annan tanke kan vara att rita upp mula in formeln i excel/oo-calc och rita kurva över P0/P inom rimliga intervall på P0/P. Avviker den mycket från en rät linje? Om inte, skit i det och gör det helt linjärt.

[hyperion]

Om vi ska vara petiga så skrev jag inte att databladet ger h = 32,1358091 meter utan vad formeln ger för resultat. Mycket väl medveten om att sensorn inte har så hög noggrannhet.

Och att matte är viktigt håller jag helt med om, jag är bara inte bra på det.

Vet inte hur jag ska göra hälften av dina instruktioner.

P0 varierar mellan 950 - 1050 enligt SMHI

P kommer aldrig vara högre än P0 då jag inte kommer vistas under havsnivå.
så 300<P<P0

T varierar mellan -30 - 60 grader C

Här tar det stopp för mig.

Vet inte hur jag ska ställa upp detta och få fram något vettigt alls.

Känns som mer besvär än nödvändigt, byter hellre till en PIC som klarar float-beräkningar. Tyckte det borde gå att ordna med en 8-bit PIC också men men.

[hyperion]

h2 bör väl för övrigt vara endast h2 = T + 273,15 eller?