[C/C++] Hoe verhef je machten in deze taal?

[^Stalkie^]

Hallo,

Ik ben net begonnen met C/C++ progammeren. Ik kan wel VB, Fortran progammeren, dus de progammeer basics begrijp ik wel. Alleen nu heb ik even een vraagje. In Fortran kan je machtsverheffen met de operator **. Dit is in VB de operator ^. Nu las ik in een tutorial dat de exponentiation operator in C en C++ niet bestaat. Ze zeggen er alleen niet bij hoe het dan wel moet.. Dus bijv: 2^2 geeft 4. Wie helpt mij!!

[tus]

Dit is toch wel erg rtfm als je het mij vraagt.

Het is in ieder geval de functie pow in C.

[Anoniem: 39376]

shl

[D2k]

pow(a,b);

dit is btw errug basic

<edit>
sneller op send drukken na hettypen

[^Stalkie^]

Hehe.. Jaja.. Ik weet het.. Maar de f*****g manual is ff nie beschikbaar hier want ik doe het in notepad.. Compilen doe ik later wel... Vandaar even deze post.

[tus]

Dan moet je niet vergeten

de math.h te includen.

[^Stalkie^]

Hehe dank je wel... Dat zal ik er even bijzetten...
Ik ben namelijk een progamma aan het porten van Fortran naar C++. Is hetzelfde als je de IMSL libs in Fortran nodig hebt voor complexe wiskundige bewerkingen, maar dan de math functions in c...
Dank u. Ik weet genoeg..

[_Squatt_]

Op vrijdag 16 november 2001 15:32 schreef robh het volgende:
shl

Bedoel jij een shift naar links?
Ik dacht niet dat 'shl' C is. Je kunt wel 'a = b << 1' gebruiken. Maar dan nog, dit werkt alleen voor machtverheffen met machten van 2.

En het lijkt me niet dat dit op elke processor het zelfde resultaat geeft. (ivm big- of little-endian, dacht ik).

[Pooh]

code:

unsigned int power(unsigned int b, unsigned int e) 
{ 
  if (e==0) return 1; //by definition
  unsigned int tmp=b;
  for(int i=0;i<e;i++)
    tmp*=b;
  return tmp;
}

Kon 't niet laten...
Wie schrijft 'm voor floats?

[D2k]

maak er dan gewoon een template van

of een overloaded functie

[Pooh]

Op vrijdag 16 november 2001 22:26 schreef D2k het volgende:
maak er dan gewoon een template van

of een overloaded functie

Hoe wil je dan 3.4^1.2 berekenen?

[Anoniem: 33423]

a^(b+c) = a^b * a*c
a^(1.2) = a^1 * a^(0.2) = a^1 * a^(1/5) = a^1 * (5wortel a)

Nu moet je dus nog een wortel functie hebben... (maar niet alleen sqrt, maar ook voor andere machten).

[Pooh]

"Gewoon een wortelfunctie" ... Dat is wel heel flauw, worteltrekken is verheffen tot de macht 0.5. (Of, de x^e-machtswortel trekken is verheffen tot de macht 1/x)

[Apache]

enkel een 2de macht:

# define sqr(x) ((x) * (x))

[Onno]

Op vrijdag 16 november 2001 21:11 schreef _Squatt_ het volgende:
En het lijkt me niet dat dit op elke processor het zelfde resultaat geeft. (ivm big- of little-endian, dacht ik).

Big en little endian slaat alleen op hoe getallen in het geheugen opgeslagen worden, verder niet. shl is gewoon shl, ongeacht van de manier van opslag van de getallen.

[marcusk]

Op zaterdag 17 november 2001 19:43 schreef Onno het volgende:
Big en little endian slaat alleen op hoe getallen in het geheugen opgeslagen worden, verder niet. shl is gewoon shl, ongeacht van de manier van opslag van de getallen.

maar het resultaat van shl en shr verschilt toch bij big- en little endian? immers, bij het ene is a shl b gelijk aan a * 2^b, bij het andere a / 2^b, toch?

[Onno]

Nee.

[mbravenboer]

Het maakt denk toch wel uit of je het over een Shift Left Logical of een Shift Right Arithmetic hebt? Bij de logical variant zou er toch wel degelijk een verschil moeten zijn tussen Big en Little Endian?

[Anoniem: 38857]

Sinds wanneer wordt een shift uitgevoerd in het geheugen? Dat gebeurt in registers. Daar staat toch echt de binaire representatie van een bepaalt getal, ongeacht van de manier waarop het in het geheugen is opgeslagen. Het zou toch niet best zijn als 26 op een intel processor 0001 1010 is en op een motorola processor 1010 0001.

[marcusk]

Op zaterdag 17 november 2001 20:58 schreef Onno het volgende:

Nee.

nou... erm... bedankt voor de uitleg

[mbravenboer]

Daghdha: Daar staat toch echt de binaire representatie van een bepaalt getal, ongeacht van de manier waarop het in het geheugen is opgeslagen.

Ik kan me vergissen (ben een beetje newbie op dit gebied, maar wel druk bezig ), maar volgens mij kan de manier van opslaan in registers ook big of little endian zijn.

Het zou toch niet best zijn als 26 op een intel processor 0001 1010 is en op een motorola processor 1010 0001.

Waarom zou dat niet best zijn? 26 is dan trouwens geen 0001 1010 of 1010 0001, maar wordt opgeslagen als 0001 1010 of 1010 0001. Das wat anders .

[Onno]

Op zaterdag 17 november 2001 22:11 schreef mbravenboer het volgende:
Ik kan me vergissen (ben een beetje newbie op dit gebied, maar wel druk bezig ), maar volgens mij kan de manier van opslaan in registers ook big of little endian zijn.

Het hele big/little endian verhaal gaat over de opslag van getallen in *kleinere* eenheden (het probleem bestaat dus ook niet bij 8 bits getallen, omdat onze opslagmedia allemaal uit eenheden van 8 bits bestaan), laten we zeggen een 16 bits getal in bytes. Dan maakt een x86 cpu van het getal 0x1234 de bytes 0x34 en 0x12, terwijl er bij een Motorola 0x12 0x34 uitrolt.

Maar, een register is altijd even breed als het getal dat ie bevat, en dus bestaat een dergelijke mapping gewoon niet. Bit 0 is rechts (per definitie), en daarna komt de rest van de bits, op volgorde.

[mbravenboer]

Onno: Het hele big/little endian verhaal gaat over de opslag van een getal in *kleinere* eenheden (het probleem bestaat dus ook niet bij 8 bits getallen, omdat onze opslagmedia allemaal uit eenheden van 8 bits bestaan), laten we zeggen een 32 bits getal als bytes. Dan maakt een x86 cpu van het getal 0x1234 de bytes 0x34 en 0x12.

Ok, dus stel dat een getal (of een string) hebt wat 32 bits (= 4 bytes = 1 register) in beslag neemt, dan worden intern de groepjes van 8 bits (= 1 byte) toch (ook in een register) achterstevoren opslagen?

Maar, een register is altijd even breed als het getal dat ie bevat, en dus bestaat een dergelijke mapping gewoon niet.

Hoe bedoel je dat?

[Onno]

Op zaterdag 17 november 2001 22:33 schreef mbravenboer het volgende:
Ok, dus stel dat een getal (of een string) hebt wat 32 bits (= 4 bytes = 1 register) in beslag neemt, dan worden intern de groepjes van 8 bits (= 1 byte) toch (ook in een register) achterstevoren opslagen?

Nee, want een register bestaat niet uit groepjes van 8 bits. Zoals het gezegd: het gaat *alleen* om de opslag van getallen in eenheden die kleiner zijn dan zijzelf. En een getal past in z'n geheel in een register -> er wordt dus niks gegroepeerd, verdeeld, wat dan ook.

[mbravenboer]

Ah ok... tuurlijk... Ik zat teveel op de hex notatie te letten.

Ik had dit voorbeeld:

MIPS is little-endian. One result of this is that character data appear to be stored "backwards" within words. Here is a representation of part of memory, storing the characters "Help" (0x706c6548) and then the number 32766 (0x00007ffe).

0x10000000 0x48 ("H")
0x10000001 0x65 ("e")
0x10000002 0x6c ("l")
0x10000003 0x70 ("p")
0x10000004 0xfe
0x10000005 0x7f
0x10000006 0x00
0x10000007 0x00

Stel dat we dus zeggen dat het getal 32766 wordt genoteerd als 0x00007ffe (dus least significant bit last = Big Endian). Dan wordt dit bij little endian dus de andere kant op geschreven.... Maar uiteraard niet in groepjes zoals ik nu zelf zie (Sorry dat ik zo'n newbie ben ).

Maar hoe zit het dan met die shift? Maakt het uit of die logical of arithmetic is als je little en big endian vergelijkt?

[.oisyn]

Op zaterdag 17 november 2001 22:48 schreef mbravenboer het volgende:
Stel dat we dus zeggen dat het getal 32766 wordt genoteerd als 0x00007ffe

nee, we zeggen niet even dat dat zo genoteerd wordt, het is gewoon een feit dat het zo genoteerd wordt! Net als in het decimale stelsel (we schrijven 32677 toch ook niet als 77623)

Oftewel, minst belangrijke cijfer aan de rechterkant.

(dus least significant bit last = Big Endian)

je moet bij big en little endian niet aan bits denken, maar meer aan het kleinst mogelijke element wat kan worden opgeslagen. In dit geval dus de byte. Je kunt bits niet afzonderlijk adresseren, maar bytes wel. En dan zit je dus met een dilemma: ga ik eerst de least significant byte opslaan (little endian), of eerst de most significant byte (big endian)

Dan wordt dit bij little endian dus de andere kant op geschreven.... Maar uiteraard niet in groepjes zoals ik nu zelf zie (Sorry dat ik zo'n newbie ben ).

Dus niet de andere kant op, maar het getal wordt eerst opgesplitst in bytes:

code:

0x00007ffe => 0x00 0x00 0x7f 0xfe

bij little endian schrijf je die groepjes dus in de verkeerde volgorde weg (wat zo z'n voordelen heeft, maar dat even terzijde), en big endian is in de volgorde zoals ik het hierboven heb neergezet

Maar hoe zit het dan met die shift? Maakt het uit of die logical of arithmetic is als je little en big endian vergelijkt?

Zoals al eerder gezegd, bij shifts maakt het niet uit hoe een getal opgeslagen is in het geheugen.

Stel, je zit even in het decimale stelsel zoals wij dat kennen, en je hebt het getal 500. Een shift is in principe een verplaatsing van de komma, dus een shift naar links maakt het getal 5000 en een shift naar rechts maakt het 50. Hoe je ze in het geheugen opslaat maakt echt helemaal niets uit, want we hebben nou eenmaal gedefinieerd dat het minst belangrijke cijfer het meest rechts staat.

De logical shift en arithmetic shift zijn ook alleen verschillend bij de shift naar rechts. De logical shift naar rechts vult de lege plaats die aan de linkerkant ontstaat op met een 0, terwijl bij de arithmetic shift de linker bit hetzelfde blijft (dwz, als er een 0 stond staat er nog steeds een 0, en als er een 1 stond een 1).

De arithmetic shift is in het leven geroepen voor negatieve getallen. Stel je hebt 4 bits: 1110. Dit getal stelt -2 voor. Als je eentje naar rechts wil shiften wil je natuurlijk 1111, -1 dus, overhouden. Maar als je met de logical shift naar rechts shift, dan komt er 0111 uit, wat het getal 7 voorstelt. Dus een arithmetic shift zorgt ervoor dat het teken wordt behouden

[Olaf van der Spek]

Een rekenkundige shift naar rechts is wel afhankelijk van de processor. De andere shifts niet.

[mbravenboer]

OiSyN legt het ff uit

Wowie! Bedankt voor de goede uitleg . Nu is het me helemaal duidelijk .

[drZymo]

Op vrijdag 16 november 2001 15:34 schreef stalkie_ het volgende:
Hehe.. Jaja.. Ik weet het.. Maar de f*****g manual is ff nie beschikbaar hier want ik doe het in notepad.. Compilen doe ik later wel... Vandaar even deze post.

Manual is altijd beschikbaar . Ooit gehoord van MSDN? Je kan al proggelen in VB dus dan moet je weten dat het daar ook allemaal in staat. Beetje

[Olaf van der Spek]

Op zondag 18 november 2001 04:41 schreef OiSyN het volgende:

[..]

nee, we zeggen niet even dat dat zo genoteerd wordt, het is gewoon een feit dat het zo genoteerd wordt! Net als in het decimale stelsel (we schrijven 32677 toch ook niet als 77623)

Hoe bedoelt waarschijnlijk dat het genoteerd wordt als 00, 00, 7f, ff, en niet ff, 7f, 00, 00

[mbravenboer]

OlafvdSpek: Hoe bedoelt waarschijnlijk dat het genoteerd wordt als 00, 00, 7f, ff, en niet ff, 7f, 00, 00

Dat bedoelde ik inderdaad ja. Tenslotte is alles conventie en omdat we het topic al aardig in spraakverwarringen en verkeerde manier van uitdrukken aan het belanden was, heb ik het maar even aangegeven .

[Anoniem: 13700]

Op zondag 18 november 2001 04:41 schreef OiSyN het volgende:
nee, we zeggen niet even dat dat zo genoteerd wordt, het is gewoon een feit dat het zo genoteerd wordt! Net als in het decimale stelsel (we schrijven 32677 toch ook niet als 77623)

Oftewel, minst belangrijke cijfer aan de rechterkant.
[..]

je moet bij big en little endian niet aan bits denken, maar meer aan het kleinst mogelijke element wat kan worden opgeslagen.

Niet om vervelend te doen maar dit bestaat wel, het wordt "bit-endianness" genoemd. Er zijn mainframes waarbij de bits in een byte omgekeerd opgeslagen worden (ibm springs to mind). Netwerkfuncties zoals ntohl() hebben daarom zowel een gegarandeerde byte- als bit-endianness (en als je met de resultaten van die functies gaat bitshiften gebeuren er op sommige platforms rare dingen).

Voor de rest klopt je verhaal over byte-endianness natuurlijk.

[MSalters]

Op vrijdag 16 november 2001 15:37 schreef stalkie_ het volgende:
Hehe dank je wel... Dat zal ik er even bijzetten...
Ik ben namelijk een progamma aan het porten van Fortran naar C++. Is hetzelfde als je de IMSL libs in Fortran nodig hebt voor complexe wiskundige bewerkingen, maar dan de math functions in c...
Dank u. Ik weet genoeg..

't Is een beetje een zooitje, die post.

C != C++

C90 heeft geen complex, C99 heeft _Complex maar geen
compilers.
C++ heeft complex<>. complex<> machtsverheffen gaat
idd gewoon via pow(complex<>,complex<>) en andere
overloads.

C++ heeft net zoals FORTRAN een snelle math library;
blitz. Moet je wel downloaden.

----
complexe wiskundige bewerkingen is bv. 1+2i*3+4i = -5+10i,
is wat anders dan moeilijke wiskunde.

[Anoniem: 39486]

Op maandag 19 november 2001 13:45 schreef MSalters het volgende:

[..]

----
complexe wiskundige bewerkingen is bv. 1+2i*3+4i = -5+10i,
is wat anders dan moeilijke wiskunde.

Nie waar, 1+2i*3+41 = 1+10i.

Je moet wel je prioriteiten kennen hoor...

[Olaf van der Spek]

4i != 41

[Anoniem: 39486]

Op dinsdag 20 november 2001 12:06 schreef OlafvdSpek het volgende:
4i != 41

euh...ja, maar dat was een typefoutje....

[Olaf van der Spek]

Hij had het trouwens over complete getallen, waarin a + bi een getal voorsteld. Als je twee van deze complexe getallen vermenigvuldigd is dat niet hetzelfde als wat jij doet.

[XKB]

(1+2i)*(3+4i) = 8i^2 + 10i + 3

Maar aangezien i^2 = -1 per definitie wordt

8i^2 = -8

en geeft het totaal:

-5+10i

zie ook hier

[Anoniem: 39486]

Ik probeer altijd zo min mogelijk reacties te posten op dingen waar ik niks van weet, en dat heb ik nu dus ook niet gedaan. Ik weet heel goed wat complexe getallen zijn en hoe je daar mee rekent. Dus nu even voor de duidelijkheid:

1+2i*3+4i = 1+10i en NIET -5+10i

want, heel eenvoudig:

(1+2i)*(3+4i) != 1+2i*3+4i

Vandaar mijn opmerking:

"Je moet wel je prioriteiten kennen hoor... "

Goed lezen mannen...

[XKB]

Op woensdag 21 november 2001 11:35 schreef Xalista het volgende:

1+2i*3+4i = 1+10i en NIET -5+10i

want, heel eenvoudig:

(1+2i)*(3+4i) != 1+2i*3+4i

Vandaar mijn opmerking:

"Je moet wel je prioriteiten kennen hoor... "

Als je inderdaad precies naar de notatie kijkt is het 1+10i doordat meneer van dale het zo vindt. Maar de schrijver bedoelde de vermenigvuldiging van 2 complexe getallen. Neem ik aan..

[Anoniem: 39486]

Op woensdag 21 november 2001 11:59 schreef XKB het volgende:

[..]

Als je inderdaad precies naar de notatie kijkt is het 1+10i doordat meneer van dale het zo vindt. Maar de schrijver bedoelde de vermenigvuldiging van 2 complexe getallen. Neem ik aan..

Dit heeft helemaal niks met van Dale te maken. Wiskundige operaties hebben gewoon prioriteiten en je gebruikt haakjes om aan te geven wat je precies wilt. Dit is geen mierenneukerij, er staat gewoon wat er staat.

BTW, een complex getal hoeft er niet persee uit te zien als a + bi hoor, bi is zelf ook al een complex getal en in principe is a ook een element van de complexe getallen. Wat dat betreft is a * bi dus ook gewoon een vermenigvuldiging van complexe getallen.

Dit is geen kwestie van "iedereen begrijpt toch wat ik bedoel", want wat wordt bedoelt staat er gewoon niet.

[XKB]

Op woensdag 21 november 2001 12:13 schreef Xalista het volgende:

[..]

Dit heeft helemaal niks met van Dale te maken. Wiskundige operaties hebben gewoon prioriteiten en je gebruikt haakjes om aan te geven wat je precies wilt. Dit is geen mierenneukerij, er staat gewoon wat er staat.

BTW, een complex getal hoeft er niet persee uit te zien als a + bi hoor, bi is zelf ook al een complex getal en in principe is a ook een element van de complexe getallen. Wat dat betreft is a * bi dus ook gewoon een vermenigvuldiging van complexe getallen.

Dit is geen kwestie van "iedereen begrijpt toch wat ik bedoel", want wat wordt bedoelt staat er gewoon niet.

Je hebt volkomen gelijk. Behalve dan dat van Dale ook gewoon regels zijn voor de prioriteiten van operatoren.

Toch leuk hoe een topic over machts verheffen kan verzanden in dit soort nutteloze discussies over wiskundige notaties. Kan je maar weer zien dat "normale" taal niet geschikt is voor wiskunde.

zie over Meneer van Dale ed hier

[Anoniem: 39486]

Op woensdag 21 november 2001 12:23 schreef XKB het volgende:

[..]

Je hebt volkomen gelijk. Behalve dan dat van Dale ook gewoon regels zijn voor de prioriteiten van operatoren.

Toch leuk hoe een topic over machts verheffen kan verzanden in dit soort nutteloze discussies over wiskundige notaties. Kan je maar weer zien dat "normale" taal niet geschikt is voor wiskunde.

zie over Meneer van Dale ed hier

Aah, bedoel je dat zinnetje, dat heb ik ook wel een geleerd op de basisschool ofzo. Ik dacht dat je het woordenboek bedoelde, ik snapte niet wat dat ermee te maken had...

[XKB]

LOL!!!

[Anoniem: 31450]

Op vrijdag 16 november 2001 21:11 schreef _Squatt_ het volgende:

[..]

Bedoel jij een shift naar links?
Ik dacht niet dat 'shl' C is. Je kunt wel 'a = b << 1' gebruiken. Maar dan nog, dit werkt alleen voor machtverheffen met machten van 2.

En het lijkt me niet dat dit op elke processor het zelfde resultaat geeft. (ivm big- of little-endian, dacht ik).