Betragsberechnung eines Vectors in C, am16

Doppelt

schon gesehen & gelöscht ;)

Schön :) gibts das auch in c oder muss ihc unbedingt den asm code 
einbinden?

schon klar :) naja eig. würde es mit ein paar tricks auch so gehen, 
danach den wert skalieren und gut. ich werte einen beschleunigungssensor 
aus, der betrag ist die resultierende kraft (im stand die erdanz.)

genau, und um zu wissen ob es stimmt müsste ich den befehlssatz von 
meinem kleinen lernen (zu faul...:)
aber ichg werde es mal bei gelegenheit einbinden und testen (wobei mir 
da schon mal beim durchschauen push & pop fehlen)

32-Bit Quadratwurzel für avr-gcc gibt's in AVR Arithmetik: Wurzel.

Sehr schön, danke. hab mir sowas ähnliches gestern bereits selber 
geschrieben:

1

ui16 int_sqrt(ui32 zahl)

2

{

3

   ui16 wurzel = UI16MAX ;

4

   ui16 temp   = wurzel-1;

5

   while ( temp < wurzel ) 

6

   {

7

      wurzel = temp;

8

      temp   = wurzel + zahl/wurzel >> 1;

9

   }

10

   return wurzel;

11

}

funktioniert sehr gut, aber wie man auf den ersten blick sieht werden 
die nachkommastellen nicht berücksichtigt, die funktion eignet sich 
somit mehr für größere zahlen. lt. der funktion ist:
wurzel 4 = wurzel aus 5...8, nämlich 2.

man könnte sie, wenn nötig natürlich noch mit dem modulo erweitern...

Ralf's Version dürfte grob geschätzt um mindstens den Faktor 20 bis 30 
schneller sein als deine Newton Iteration.

DirkB schrieb:
> Micha S. schrieb:
>> kann ich die sqrt() funktion irgendwie umgehen?
>
> Was machst du denn mit dem Betzrag.
> Wenn du die nur vergleichen willst, brauchst du die Wurzel nicht ziehen.

Ich würde auch lieber diese Variante nehmen.

Karl Heinz Buchegger schrieb:
> Ralf's Version dürfte grob geschätzt um mindstens den Faktor 20 bis 30
> schneller sein als deine Newton Iteration.

Guten morgen, na heute besser gelaunt? ;-)
Ja das ist klar, das ist abhängig von der zahl, je größer desto mehr 
durchläufe & somit langsamer. Mir ging es ja, wie gestern erwähnt, 
hauptsächlich darum die fliesskommaarithmetik zu umgehen, was mir auch 
erst mal gelungen ist. nächstes kriterium war dann der Speicherbedarf, 
deswegen die entscheidung zur Newtonschen Iteration.

Micha S. schrieb:

> erst mal gelungen ist. nächstes kriterium war dann der Speicherbedarf,
> deswegen die entscheidung zur Newtonschen Iteration.

Gut.
Das ist jetzt in Ralfs Code noch nicht optimal gelöst. sIdx muss keine 
32 Bit Variable sein und ob die anderen beiden 32 BIt sein müssen, 
müsste man analysieren. Auch der Return Datentyp muss kein 32 Bit Typ 
sein, 16 Bit reichen. Aber abgesehen von den paar Bytes auf dem Stack 
trägt sein Code auch höchst wahrscheinlich weniger auf, als die Division 
in deinem Code, die das eigentliche Übel darstellt. AVR können nur 
schlecht allgemein dividieren. Von daher ist so gut wie jeder Code, der 
keine derartige Division braucht immer besser. Und von der Länge des 
C-Codes in Source Form solltest du dich nicht blenden lassen

Ja da hast du recht, ich denke ich werde den ralfs code ncoh ein wenig 
für den avr optimieren und bei interesse posten!

Grüße & herzlichst Dankeschön