Optellen en vermenigvuldigen met equivalence classes

Moderators: dirkwb, Xilvo

Forumregels
(Middelbare) school-achtige vragen naar het forum "Huiswerk en Practica" a.u.b.
Zie eerst de Huiswerkbijsluiter
Reageer
Berichten: 86

Optellen en vermenigvuldigen met equivalence classes

Ik heb een vraag over equivalence relations. Met een equivalence relation partitioneer je een verzameling. Je 'hakt' een verzameling in stukjes die equivalence classes heten. Nou vraag ik me af of arithmetic met die equivalence classes well defined is voor alle equivalence relations. In mijn tekstboek wordt het voorbeeld van modular arithmetic gebruikt. Daar wordt bewezen dat optellen en vermenigvuldigen well defined is voor de equivalence relation modular arithmetic. If [x]= and [y]=[v], then *[v]=[x]*[y]. Geldt deze stelling voor alle equivalence relations of moet je dat voor iedere equivalence relation apart nagaan? En zo ja waarom? Een tegenvoorbeeld zou het voor mij duidelijker maken.

Berichten: 400

Re: Optellen en vermenigvuldigen met equivalence classes

Ik snap de vraag niet helemaal goed. Je moet erop letten dat je je bewerkingen goed definieert. Je kan ook fouten maken in wiskunde, maar ik snap niet goed wat je bedoelt. Waarom zou het onmogelijk zijn om fouten te kunnen maken? En stel nu dat jij een 'veralgemening' zoekt, kan je dan precies zeggen hoe die eruit zou moeten zien? Nu kan niemand er iets mee doen omdat er niets aan te tonen valt, want je zegt niet welke veralgemening je zou willen aantonen. Doe echt aan wiskunde en zit niet wat vaag te doen, want klaarblijkelijk begrijp je zelf ook niet wat je bedoelt, anders zou je misschien zelf kunnen aantonen wat je wil aantonen.

Wil je ook Nederlands gebruiken?

equivalentierelaties in plaats van equivalence relations

equivalentieklassen in plaats van equivalence classes

bewerkingen/rekenen in plaats van arithmetic

goed gedefinieerd in plaats van well defined

modulorekenen in plaats van modular arithmetic

als in plaats van if

en in plaats van and

dan in plaats van then

Edit: Zie je waarom nagegaan wordt of bewerkingen goed gedefinieerd zijn, waarom dat nodig is, wat dat inhoudt? Probeer dat goed te begrijpen en dan wordt het misschien vanzelf duidelijk.

Berichten: 400

Re: Optellen en vermenigvuldigen met equivalence classes

Ik heb verder nagedacht over wat je misschien bedoelt en ben tot het volgende gekomen als vertrektpunt van wat je waarschijnlijk bedoelt:

Vertrek van de verzameling van de gehele getallen. Op deze verzameling definiëren we equivalentierelaties. Een voorbeeld is voor elk natuurlijk getal n verschillend van 0 de equivalentierelatie
\(xR_n y\)
als en slechts als
\(x\equiv y\hbox{ mod }n\)
. Dit is een equivalentierelatie omdat (...) Op de quotiëntverzameling definiëren we de bewerking * als volgt (...) Deze bewerking is goed gedefinieerd omdat (...)

Nu zie je al dat er verschillende punten zijn waarom we andere equivalentierelaties kunnen maken (en waarom het te vaag is wat je schrijft):

1) We kunnen equivalentierelaties op een andere verzameling maken.

2) Zelfs als we dezelfde verzameling, in dit geval de gehele getallen, nemen, dan nog kunnen we andere equivalentierelaties op die verzameling definiëren.

3) Zelfs als we dezelfde equivalentierelatie, in dit geval "mod n" (voor een welbepaalde n) nemen, dan nog kunnen we andere bewerkingen dan deze * op de quotiëntverzameling definiëren.

Mijn vraag is nu aan jou (en zo zie je ook waarom je niet duidelijk bent): op welk punt wil je veralgemenen? Punt 1, punt 2 of punt 3? En op welke manier?

Voor punt 3 (de andere punten zijn te algemeen tenzij jij specifiek aangeeft welke relaties en bewerkingen je definieert): Als je een bewerking definieert op de quotiëntverzameling moet je die in de eerste plaats "goed definiëren". Je definieert dat normaal als volgt. Definieer de bewerking # (ik heb hier gewoon een symbool gekozen voor de bewerking) op de quotiëntverzameling. Als je die bewerking inwendig en overal gedefinieerd maakt wil dit zeggen dat je voor elke twee elementen x en y uit je quotiëntverzameling een x#y definieert als een element z uit de quotiëntverzameling.

Nu vraag je je waarschijnlijk af: hoe kan een bewerking nu fout definiëren?

Wel wat je doet bij de definitie bij modulorekenen en invoeren van de bewerking * op de quotiëntverzameling is x*y definiëren als z door gebruik te maken van de bestaande bewerking * op de gehele getallen. Je zegt dat je x*y definieert als volgt: neem een representant x_1 uit de equivalentieklasse horende bij het element x en neem een representant y_1 uit de equivalentieklasse horende bij y. Merk op dat x en y elementen zijn uit de quotiëntverzameling (lees: het zijn equivalentieklassen), terwijl x_1 en y_1 gewoon gehele getallen zijn (hiervoor moet je dus een beetje abstract denken). Op de gehele getallen hebben we * al vroeger gedefinieerd (daar ga ik niet verder op in). We maken gebruik van die bewerking en nemen z_1=x_1*y_1; z_1 is dus een geheel getal. Definieer nu x*y=z waarbij z het element uit de quotiëntverzameling is waar de equivalentieklasse van z_1 bij hoort.

En nu zie je waarom je moet nagaan of dit goed gedefinieerd is. x*y is namelijk op oneindig veel verschillende manier gedefinieerd, omdat je een representant kiest uit x en een uit y om z te definiëren, en daar heb je oneindig veel keuzes, en dat kan natuurlijk niet: je mag maar 1 iets definiëren voor x*y natuurlijk, dat moet een welbepaald element z uit de quotiëntverzameling geven, er is dus eigenlijk een probleem. Natuurlijk is er geen probleem indien al deze oneindig veel verschillende manieren waarop x*y gedefinieerd is allemaal precies dezelfde z als resultaat geven. Dat is precies wat je doet wanneer je nagaat of de bewerking goed gedefinieerd is: controleren of dat het geval is.

Dus: dit geldt bij dit speciale geval. Als jij ergens in een compleet andere situatie zit en een bewerking op één of andere manier rechtstreeks op de quotiëntverzameling definieert, op 1 manier voor elke mogelijke 2 elementen waarop je de bewerking wil definiëren, dan is er geen probleem. In dit geval was dit wel een probleem omdat je dat op verschillende manier deed doordat je van die bewerking op de gehele getallen gebruik wou maken.

Noot: ook hier zou jij kunnen zeggen, bijvoorbeeld modulo 5 om de bewerking rechtstreeks te definiëren door het gewenste resultaat te geven voor iedere mogelijke vermenigvuldiging van elementen uit de quotiëntverzameling (dat zijn 5 elementen). Dan is dat automatisch goed gedefinieerd, want dat is de manier waarop je een bewerking definieert. Dat wordt dan echter niet alleen een lange definitie waarbij je al die mogelijke vermenigvuldigingen opschrijft en definieert (je schrijft dan de 25 mogelijkheden op en het bijhorende resultaat), maar bovendien is het een ondoenbare en onwerkbare definitie om daar bijvoorbeeld eigenschappen op te gaan bewijzen, want dan moet je die eigenschap gewoon voor iedere vermenigvuldiging apart nagaan (tenzij je als eigenschap de link naar de bewerking * op de gehele getallen zou leggen, en dan verder deze eigenschap zou gebruiken in verdere bewijzen, maar dan kan je dat eenvoudiger meteen bij de definitie doen en aantonen dat de definitie goed gedefinieerd is). Vandaar dus waarom het op die andere manier gebeurd is. [Eigenlijk zou je iets meer schrijfwerk hebben als je die eerste definitie wat exacter wil doen (nu lijkt het wat vreemd om al over z te spreken voor je hebt aangetoond "dat de bewerking goed gedefinieerd is"), waarbij je dan eerst alle z_ij=x_i*y_j zou moeten nemen, aantonen dat deze alle representanten van dezelfde equivalentieklasse zijn (dit is wat verstaan wordt onder "goed gedefinieerd"), en dan overgaat dat de definitie (of toch zoiets in die aard als ik mij niet vergis), maar men vindt het denk ik vaak niet nodig om het zo op te schrijven. Er is ook nog zoiets als 'logica' die alles veel exacter aanpakt. Echter kan het wel verwarrend werken als je op die manier niet exact bent.]

Hopende op deze manier enige hulp te zijn geweest. Hopende duidelijk gemaakt te hebben dat je bij wiskunde je bewerkingen definieert en dat als je een andere verzameling hebt daar ook opnieuw die bewerkingen op moet definiëren. Die zijn natuurlijk niet zomaar gegeven. Je kan gelijk wat in een verzameling stoppen en ik kan bijvoorbeeld geen appel met een tafel vermenigvuldigen (hoewel ik dat wel zou kunnen definiëren als een ander element uit de verzameling, een lamp bijvoorbeeld ](*,) ). En ook hopende verduidelijkt te hebben dat het noodzakelijk is om bij wiskunde (als je de dingen wil definiëren en stellingen wil bewijzen) exact en niet vaag te zijn of dat dat anders alleen maar tot verwarring leidt. Omdat niet iedereen daar een boodschap aan heeft om zich daar mee bezig te houden werkt men voor deze mensen vaak met 'rekenregels' (en ook voor jezelf eens je rond bent met alles te definiëren en bewijzen, om er sneller en gemakkelijker mee te kunnen werken), maar als jij je op het terrein van de bewijzen en de opbouw van de wiskunde begeeft (voor je de rekenregels hebt, de wiskundige achtergrond van de rekenregels, waarom deze werken), dan moet je dus exact zijn anders gaat het niet.

Berichten: 86

Re: Optellen en vermenigvuldigen met equivalence classes

Als ik het goed begrijp moet je voor elke equivalentie relatie checken of de bewerkingen well defined zijn. Dus voor een equivalentie relatie is het dus mogelijk om x~z maar xy niet equivalent met zy. Heb je misschien een voorbeeld van zo een equivalentie relatie? Dat zou meer duidelijkheid scheppen voor me.

Gebruikersavatar
Berichten: 5.679

Re: Optellen en vermenigvuldigen met equivalence classes

Als ik het goed begrijp moet je voor elke equivalentie relatie checken of de bewerkingen well defined zijn. Dus voor een equivalentie relatie is het dus mogelijk om x~z maar xy niet equivalent met zy. Heb je misschien een voorbeeld van zo een equivalentie relatie? Dat zou meer duidelijkheid scheppen voor me.
Bijvoorbeeld de relatie ](*,) (mod 2), oftewel modulo 2 ongelijkheid, dat wil zeggen twee getallen voldoen aan de relatie als er één even en één oneven is.
In theory, there's no difference between theory and practice. In practice, there is.

Reageer