Overleg:Poolcoördinaten

Ik heb dit artikel aangepast, omdat poolcoordinaten in meer dimensies op verschillende manieren gedefinieerd kunnen worden. Bovendien worden ook cilindercoordinaten als poolcoordinaten opgevat. Ook is er het probleem bij het omrekenen dat de hoek niet direct als arccos of arctan bepaald kan worden.Nijdam 3 jan 2005 17:59 (CET)

Het lijkt me dat de opmerking "een rechte in poolcoordinaten" bij het laatste plaatje wel wat meer uitleg kan gebruiken.Nijdam 8 jun 2006 22:17 (CEST)

Rechte en lineaire functie

Naast de figuur over een lineaire functie in poolcoördinaten staat "Rechte in poolcoördinaten" Men stelt hier klaarblijkelijk "lineaire functie" gelijk aan "rechte". In poolcoördinaten vorm een lineaire functie, als b.v. r = r₀ + b.θ , een uitdeinende spiraal. Men zou dus best die tekst "een rechte in poolcoördinaten" weglaten Huibc 19 jun 2006 18:01 (CEST)

Waarom heet het "poolcoördinaten"?

Bij cilinder- en bolcoördinaten is het voor mij wel logisch en begrijpelijk waarom dat zo wordt genoemd. Maar waarom spreek je van poolcoördinaten en niet van "cirkelcoördinaten"? Een verklaring in het lemma zou niet misstaan. Ik ben benieuwd! Maiella 28 okt 2008 02:01 (CET) PS. Van de middelbare school herinner ik me het begrip een "poollijn". Maar dat lemma ontbreekt vooralsnog, en die naamgeving is voor mij altijd een raadsel gebleven!. Maiella 28 okt 2008 02:01 (CET)

nieuwe definitie poolcoordinaten

De nieuwe definitie definieert poolcoordinaten op onafhankelijke wijze. Dus zonder te steunen op een andere soort coordinaten zoals carthesische coordinaten. Bovendien worden de coordinaten zodanig gedefinieerd dat onmiddellijk duidelijk wordt dat een punt vele gelijkwaardige stellen poolcoordinaten heeft. Dit is van groot belang bij vergelijkingen van krommen in poolcoordinaten en meer speciaal bij het berekenen van snijpunten van twee krommen steunend op hun poolvergelijkingen. Bovendien mag de eerste poolcoordinaat r niet gedefinieerd worden als een afstand maar als een reeel getal. Jhncls (overleg) 5 sep 2013 14:18 (CEST)

Ik weet niet of ik deze abstractie, die op zich wel juist is, als eerste kennismaking met poolcoordinaten wel acceptabel vind. Wat vinden anderen ervan? Madyno (overleg) 6 sep 2013 10:58 (CEST)

Als vanaf de eerste paragraaf van de inhoud reeds gesproken wordt over transformatieformules, omzetten van integralen en jacobiaanse determinanten, dan vind ik de definitie van poolcoordinaten helemaal niet zo abstract. Wellicht kan de abstractie toch nog verminderd worden door hier en daar een paar voorbeelden tussen te voegen zonder dat het iets tekort doet aan de correcte definitie van de begrippen. Jhncls (overleg) 6 sep 2013 14:27 (CEST)

Een negatieve r toestaan is volgens mij niet gebruikelijk. - Patrick (overleg) 6 sep 2013 12:38 (CEST)

Als variant kan dat eventueel in een aparte paragraaf achteraan behandeld worden, liefst met een voorbeeld waaruit blijkt dat dat handig kan zijn. - Patrick (overleg) 6 sep 2013 13:02 (CEST)

Een negatieve r is noodzakelijk omdat het voorkomt bij poolvergelijkingen. Neem bijvoorbeeld de hyperbool met vergelijking $r=5/(1+3\cos(\theta ))$. Voor θ= 2 is r gelijk aan -20.1 en het punt van de hyperbool is (-20.1 , 2). Zeker bij het berekenen van snijpunten van twee krommen kan dit belangrijk zijn. Neem bijvoorbeeld de snijpunten van die hyperbool met de rechte met poolvergelijking θ-2 = 0. Jhncls (overleg) 6 sep 2013 13:26 (CEST)

Ook het feit dat een punt oneindig veel stellen poolcoordinaten heeft is bij krommen van groot belang. Bij een snijpunt S van twee krommen kan het ene stel poolcoordnaten van S voldoen aan de vergelijking van de eerste kromme en een ander stel poolcoordinaten van het zelfde punt S voldoen aan de vergelijking van de tweede kromme en als men enkel positieve r toelaat kunnen snijpunten van de twee krommen ontsnappen aan de berekeningen.Jhncls (overleg) 6 sep 2013 13:34 (CEST)

Op de engelse versie "Polar coordinate system" wordt ook vanaf het begin van het artikel gewezen op de waarde van de oneindig veel stellen poolcoordinaten en de negatieve r waarden. Ook het veel gebruikte online grafische tool "http://graph.seriesmathstudy.com/graphictool.htm" gebruikt voor poolcoordinaten negatieve r waarden. Jhncls (overleg) 6 sep 2013 13:40 (CEST)

"Noodzakelijk" is een groot woord, je kan ook zeggen dat $r=5/(1+3\cos(\theta ))$ de vergelijking van de tak van de hyperbool aan de kant van de oorsprong is, en $r=5/(-1+3\cos(\theta ))$ de vergelijking van de andere tak. - Patrick (overleg) 6 sep 2013 15:02 (CEST)

Inderdaad. Het nadeel van deze werkwijze is dan, dat men bij die opslitsing van de vergelijking van die hyperbool in twee delen, bij elk deel moet toevoegen voor welke theta waarden ze geldig is. Dit kan bij veel krommen veel omslachtiger worden dan gewoon te aanvaarden dat er een negatieve r mogelijk is. Dan volstaat 1 voorschrift zondermeer. Stel je voor dat je snijpunten moet berekenen met vergelijkingen van twee krommen die op verschillende manier zijn opgesplitst in delen! Jhncls (overleg) 6 sep 2013 15:33 (CEST)

Met de conventie r≥0 is $r=5/(1+3\cos(\theta ))$ (zonder verdere aanvullingen) de vergelijking van een tak van de hyperbool, zonder die conventie is het de vergelijking van de hele hyperbool. Wat handiger is hangt er dus vanaf of het over die tak gaat of over beide takken. Ik stel voor dat standaard wordt uitgegaan van r≥0 (dat is zoals gezegd volgens mij gebruikelijker) en anders erbij te vermelden "waarbij r negatief kan zijn". - Patrick (overleg) 7 sep 2013 00:07 (CEST)

Het is ook onnodig ingewikkeld als voor een gegeven punt de waarde van r afhangt van de keuze van θ en omgekeerd. - Patrick (overleg) 7 sep 2013 00:21 (CEST)

OK. Van zodra ik een beetje tijd heb vandaag zal ik het aanpassen. Dus dat standaard wordt uitgegaan van r≥0 en dan iets verder dat men soms negatieve waarden van r toelaat. Ik zorg dan ook voor een aangepaste figuur. Jhncls (overleg) 7 sep 2013 11:16 (CEST)

Parse-fout

Parse-fout op deze pagina!
Bovenstaande niet middels vier tildes ondertekende oprisping is hier op 24 september 2013 om 11:00 uur geplaatst door 212.178.200.133.

Probeer je scherm te verversen en kijk dan of het probleem zich nog steeds voordoet. Bob.v.R (overleg) 24 sep 2013 12:19 (CEST)

Merkwaardig ik had dezelfde parserfout. Ik denk hem nu opgelost te hebben. Mvg JRB (overleg) 24 sep 2013 23:18 (CEST)