[DISC] C of C++ :?

[Verwijderd]

Alarmnummer schreef op 06 augustus 2002 @ 16:18:
Als je gaat rekenen met normale integers, dan zal dit.

integer.MAX_VALUE+integer.MAX_VALUE

echt een fout opleveren, want je raakt buiten het domein van de integer. Dit geld ook voor die 1+1 met bits, want een 2 valt buiten het domein van de bit. Bij een boolse operator zal dit wel goed gaan. Ik hoop dat ik je nu (eindelijk) kan laten inzien dat de werking van een boolse + niet hetzelfde is als een integer +.

/me zucht.

Ik heb het over algebra's, niet over de beperkingen van computerimplementaties van getallen. Een bool operatie kan per definitie geen overflow hebben omdat de cardinaliteit van de boolse verzameling 2 is, en een operator een bewerking is die een domeinverzameling afbeeldt op een gelijke bereikverzameling. Als je dus de verzameling { 0, 1 } afbeeldt op { 0, 1 } dan kun je nooit een overflow krijgen (in de vorm van 2 ofzo).

Op een zelfde manier kan er binnen de verzameling van integers algebraisch nooit een overflow optreden. Die overflows zijn er het resultaat van dat je met de beperkte opslagcapaciteit van computers geen oneindige verzameling kunt afbeelden.

Je kunt overflows dus nooit gebruiken om te bewijzen dat algebra's verschillen, want in de algebra bestaan er geen overflows.!

Verder is ieder natuurlijk getal een reeel getal. Daarom is in principe ook iedere int een float en derhalve kan die conversie ook gemaakt worden.

En net zo is elke boolean een integer, de verzameling van booleans is een deelverzameling van de verzameling van integers, net zo als de verzameling van integers een deelverzameling is van de reals.

[Alarmnummer]

Het is erg belangrijk om je te realiseren dat niet alleen een computer behoefte heeft aan beperkingen van waardes voor bepaalde types, maar dat dit ook een erg machtig middel is voor het modeleren en ook gewoon onderdeel is van allerlei vormen van algebra`s. Als je de verzameling gehele getallen:Z neemt, dan is het 8 bits integer type A daar een subtype van, omdat iedere waarde van A ook in Z voorkomt. Maar ook is Leefijd:[0..150] daar een subtype van, omdat wederom ieder element van Leefijd voorkomt in Z. Er zijn dus in de informatica meer integer types dan Z en dit heeft verder niets te maken met de beperkingen van computers.

Als je nog een keer kijkt naar die + operator dan zou je hem kunnen definieren voor Z, maar je zou hem net zo goed kunnen definieren voor A. Als je hem defnieerd voor Z en het return type kan ook Z zijn, dan weet je dat je nooit een overflow krijgt. Maar als je wilt dat het resultaat van het type A is, dan kan het wel voorkomen dat overflow foutmelding krijgt omdat de som van 2 waardes niet altijd element is van A.

Dit is geen fout van de computer, maar dit is gewoon de definitie van die plus operator. Ik kan A ook als [10..25] definieren. Je weet nu zeker dat het resultaat van in een 8 bits integer past, en alle plus operatories door de computer uitgevoerd kunnen worden, maar in sommige gevallen is het type van de som niet gelijk aan A en moet je een foutmelding krijgen.

Ok. Dit is een heel verhaal waarmee ik duidelijk wil maken dat je heel goed met types en operatoren kan werken waarmee je soms wel overflows kan en wil krijgen en dat ermeer integer types zijn dan alleen de alles omvattende integer type:Z en dat er ook een menselijke behoefte is aan die andere integer types. En het belangrijkste punt is dat deze overflows niet ontstaan door een tekortkoming aan de pc, maar alleen ontstaan door de definitie van een operator. Ik hoop dat je het tot zover met me eens bent.

Nu ga ik nog een keer de stap ondernemen om terug te gaan naar type Bit:[0,1] (dit is een integer type). Ik ga nu nog een keer de + operator definieren waarvoor moet gelden dat het resultaat ook van het type Bit is.

0+0=0
0+1=1
1+0=1
1+1=overflow.

Ik zal nog nog een keer duidelijk uitleggen waarom hier dus wel een overflow optreed. Het resultaat van 1+1 is dus 2, maar aangezien 2 geen element van Bit, moet je dus een foutmelding opwerpen. Het is dus onjuist om te zeggen dat je 1+1 dan 1 moet maken omdat dit in strijd is met de definitie van een plus operator in het algemeen.

Nu hoop ik echt dat je het met mee eens bent, want anders loop ik dit allemaal voor niets te typen.

Nu ga ik nog een keer de + operator definieren voor de bool.
0+0=0
0+1=1
1+0=1
1+1=1

Zoals je ziet krijg je dus bij de boolean versie geen overflow omdat dit nergens op zou slaan.

code:

1+1
true or true    //vertaling
true        //tautologie
1       //terug vertalen

je ziet nu dus dat er een verschil in definitie is voor de bit + en de boolse +

Verder vind ik ook nog steeds dat een bool een volledig ander concept is dan een integer, en dit verschil dwing ik ook op in api`s. Ik denk ook niet dat we elkaar kunnen overtuigen, maar persoonlijk vind ik het typesysteem van C te zwak en dit maakt de taal onnodig gecompliceerd en foutgevoeliger. Ik denk ook niet dat ik je verder kan overtuigen en ik heb er eigelijk ook geen zin meer in om tijd eraan te verspillen.

[Verwijderd]

Alarmnummer schreef op 06 augustus 2002 @ 18:40:
Als je nog een keer kijkt naar die + operator dan zou je hem kunnen definieren voor Z, maar je zou hem net zo goed kunnen definieren voor A. Als je hem defnieerd voor Z en het return type kan ook Z zijn, dan weet je dat je nooit een overflow krijgt. Maar als je wilt dat het resultaat van het type A is, dan kan het wel voorkomen dat overflow foutmelding krijgt omdat de som van 2 waardes niet altijd element is van A.

Nee, dat is niet de reden voor overflows. Als je gewoon afbeeldt van A => A, dan is er technisch gesproken geen overflow! Het probleem ontstaat doordat je stelt dat A = Z, terwijl dat niet zo is. De overflow vindt dus plaats omdat je met verzameling A werkt, terwijl je een element uit verzameling Z verwacht. Dát is een overflow!

Ik zal nog nog een keer duidelijk uitleggen waarom hier dus wel een overflow optreed. Het resultaat van 1+1 is dus 2, maar aangezien 2 geen element van Bit, moet je dus een foutmelding opwerpen. Het is dus onjuist om te zeggen dat je 1+1 dan 1 moet maken omdat dit in strijd is met de definitie van een plus operator in het algemeen.

Het is niet strijdig met de + operator. Ik heb je al uitgelegd dat een operator een domein afbeeldt naar een gelijk bereik, en aangezien "overflow" geen element is van het domein, kan het ook niet in het bereik terecht komen. Het is dus onjuist om te stellen dat 1 + 1 = 2, dat ligt aan de algebra waarin je rekent! Snap dat nu toch!

Nu hoop ik echt dat je het met mee eens bent, want anders loop ik dit allemaal voor niets te typen.

Ik bedoel dit serieus en niet om je te beledigen, maar ik zou er nog eens wat wiskunde op naslaan als ik jou was. Het klopt namelijk gewoon niet wat je stelt, de eigenschappen van zowel de + als de * operator zijn exact gelijk in de boolse en de integer algebra. Exact gelijk!

[Alarmnummer]

laatste.

Ik heb je al uitgelegd dat een operator een domein afbeeldt naar een gelijk bereik

onzin:

Er gaat bij jouw iets fout om te stellen dat het return type van een operator altijd gelijk is aan het type van zijn argumenten. Stel ik heb het volgende type [m..n] dan weet ik dat het type van de inc functie : [m..n] -> [m+1..n+1].

Als je gaat stellen dat het type van inc [m..n]->[m..n] is, dan kan je voor n geen waarde terug sturen, omdat het resultaat (n+1) geen element is van [m..n] In dit geval geef je dus een foutmelding omdat de waarde niet gedefinieerd is binnen het result type. Dit doe je ook omdat 2 niet is gedefinieerd binnen het return type Bit.

+ als de * operator zijn exact gelijk in de boolse en de integer algebra

Schijnbaar het je problemen met overflows en type fouten. Ik denk dat je daar echt even in moet verdiepen. Ik raad je de volende literatuur aan:
On understanding types, data abstraction, and polymorphism

[Verwijderd]

Alarmnummer schreef op 06 augustus 2002 @ 19:32:
onzin:

Moehaha Het is geen onzin, maar de algebraische definitie van een operator. Ik raadt je nogmaals aan, je wiskunde erbij te nemen, want de zaken die je beweert kloppen gewoon niet.

Er gaat bij jouw iets fout om te stellen dat het return type van een operator altijd gelijk is aan het type van zijn argumenten. Stel ik heb het volgende type [m..n] dan weet ik dat het type van de inc functie : [m..n] -> [m+1..n+1].

NEEEEEEEEEEEE. Ten eerste is "inc" algebraisch geen operator maar een functie, namelijk "f(x) = x + 1". Dan hebben we het dus over de operator + en die beeldt wel degelijk { 0, 1, 2, ... } => { 0, 1, 2, ... } af, kijk maar:
0 + 0 = 0
1 + 0 = 1
2 + 0 = 2
enz.

Als je gaat stellen dat het type van inc [m..n]->[m..n] is, dan kan je voor n geen waarde terug sturen, omdat het resultaat (n+1) geen element is van [m..n] In dit geval geef je dus een foutmelding omdat de waarde niet gedefinieerd is binnen het result type. Dit doe je ook omdat 2 niet is gedefinieerd binnen het return type Bit.

Je maakt hier de fout door te stellen dat inc algebraisch een operator is, maar dat is niet zo; inc is een operatie of functie, geen operator. Zie boven.

[Creepy]

ik ga hier volgens mij totaal de mist in omdat ik iets mis.. maaruh...

+ en * exact gelijk in de booleaanse en integer algebra?
1+1 = 1 (want true or true = true) en 1+1=2
1+1+1+1+1+1+0+1 = 1 en 1+1+1+1+1+1+0+1 = 7

1*1 = 1 (want true and true = true) en 3*3=9 (ik pak een 3 ja.. "willekeurig" element uit de integer algebra)

Ik zie niet in wat hier hetzelfde aan is. Tenzij je afspreekt dat als je buiten het bereik komt, je het laatste element gebruikt (net als in C want 0= false =0 , 1 = true = 1 en 4235 = true = 1). maar die afspraak is in de booleaanse algebra toch niet gemaakt, aangezien in de booleaanse algebra alleen maar gebruik gemaakt wordt van 0 en 1.

[Alarmnummer]

na laatste
functie is prefix geschreven operator. It`s all the same. Ik zal het nog gekker stellen. In principe hoef je helemaal geen operatoren en operanden te hebben, maar alleen nog maar functies.

En verder beeld een inc functie [m..n] niet af op [m..n] maar op [m+1..n+1]
lees nou dat stuk nou eerst maar eens door.

[Alarmnummer]

Creepy schreef op 06 augustus 2002 @ 21:02:
ik ga hier volgens mij totaal de mist in omdat ik iets mis.. maaruh...

+ en * exact gelijk in de booleaanse en integer algebra?
1+1 = 1 (want true or true = true) en 1+1=2
1+1+1+1+1+1+0+1 = 1 en 1+1+1+1+1+1+0+1 = 7

1*1 = 1 (want true and true = true) en 3*3=9 (ik pak een 3 ja.. "willekeurig" element uit de integer algebra)

Ik zie niet in wat hier hetzelfde aan is. Tenzij je afspreekt dat als je buiten het bereik komt, je het laatste element gebruikt (net als in C want 0= false =0 , 1 = true = 1 en 4235 = true = 1). maar die afspraak is in de booleaanse algebra toch niet gemaakt, aangezien in de booleaanse algebra alleen maar gebruik gemaakt wordt van 0 en 1.

Je snapt het uistekend

[Verwijderd]

Creepy schreef op 06 augustus 2002 @ 21:02:
ik ga hier volgens mij totaal de mist in omdat ik iets mis.. maaruh...

+ en * exact gelijk in de booleaanse en integer algebra?
1+1 = 1 (want true or true = true) en 1+1=2
1+1+1+1+1+1+0+1 = 1 en 1+1+1+1+1+1+0+1 = 7

Ok, ik probeer het nog simpeler uit te leggen.

In de boolse algebra zijn er maar twee numerieke waardes, het eenheidselement en het nulelement. Maw. in de boolse algebra reken je maar met twee waardes: "iets" (1) en "niets" (0); alle operaties kunnen alleen "iets" of "niets" als resultaat hebben.

Zo is dus "iets" + "iets" + "iets" + ... = "iets"; want het is meer dan "niets", en er kan alleen "iets" of "niets" uitkomen.

Op precies de zelfde manier kun je bv. nooit een gebroken getal krijgen als je twee natuurlijke getallen met elkaar optelt of vermenigvuldigt; als je twee natuurlijke gatallen optelt of vermenigvuldigt komt daar altijd een natuurlijk getal uit. Het enige verschil is dat er maar twee boolse getallen zijn { 0, 1 } terwijl er oneindig veel natuurlijke getallen zijn { 0, 1, 2, ... }

Als je nu eens in "iets" en "niets" denkt ipv. "true" en "false"; dan zul je zien dat de operatoren exact het zelfde werken en hoeveelheden beschrijven, zowel in de integer als in de boolse algebra.

[Alarmnummer]

in jouw geval zijn in de normale (dus niet boolse) algebra 1+1 ook 1 zijn omdat iets + iets is iets. Trouwens je hebt jezelf wel een beetje verraden. Je zegt nu zelf dat je het moet zien als termen van iets en niets, en niet als getalsmatige waarden omdat je er dan niet zo handig mee kan rekenen. Ik vind dit dus een vrij goed argument (dat je nu zelf hebt gegeven) dat een bool type dus geen subtype is van een int type omdat het gedrag op sommige punten afwijkt.

ps.
ik denk dat jij je je wiskunde er nog even goed bij moet pakken. Want een operator hoeft echt niet op hetzelfde type af te beelden als het type van zijn argument. bv:

10 realdiv 20 = 0.5

Je gaat hier heel duidelijk van (2) integers naar een float.

Ga je maar eens verdiepen in functionele programmeertalen ed en dan praten we wel weer.

[MSalters]

Alarmnummer schreef op 06 augustus 2002 @ 21:16:
in jouw geval zijn in de normale (dus niet boolse) algebra 1+1 ook 1 zijn omdat iets + iets is iets.

Tsja, het wil niet echt lukken hè.
In de niet-booleaanse algebra is 0 het (enige) identiteits-element van de + functie. Als 1+1 =1 dan is dus 1 gelijk aan 0, wat in tegenspraak is met het axioma van de unieke 0.
In boolean algebra is er geen uniek identiteits element van +

In C en C++ heeft + zo'n indenteits element dan en slechts dan als het niet voor booleaanse algebra wordt gebruikt.

[Verwijderd]

Alarmnummer schreef op 06 augustus 2002 @ 21:16:
in jouw geval zijn in de normale (dus niet boolse) algebra 1+1 ook 1 zijn omdat iets + iets is iets.

Nope, want in het normale geval heb je als domein en bereik { 0, 1, 2, ... } en niet { 0, 1}

Geloof me alsjeblieft, ik verkoop hier geen lulkoek. De term "algebra" houdt intrensiek in dat er met waardes, hoeveelheden wordt gerekend. Met welke waardes er gerekend wordt, hangt af van de verzameling waarop men die algebra loslaat. Daarom krijg je verschillende resultaten als je gelijk gedefinieerde operatoren in de verzamelingen B, N, Z, Q, R of C gebruikt.

[Alarmnummer]

Ik denk dat we ons probleem hebben gevonden. Jij geloof dus niet in subtypes van een bepaald type. Jij erkent [1...10] niet als een subtype van N. Is dat het?

[Creepy]

Verwijderd schreef op 06 augustus 2002 @ 21:14:
[...]

Ok, ik probeer het nog simpeler uit te leggen.

In de boolse algebra zijn er maar twee numerieke waardes, het eenheidselement en het nulelement. Maw. in de boolse algebra reken je maar met twee waardes: "iets" (1) en "niets" (0); alle operaties kunnen alleen "iets" of "niets" als resultaat hebben.

Zo is dus "iets" + "iets" + "iets" + ... = "iets"; want het is meer dan "niets", en er kan alleen "iets" of "niets" uitkomen.

Op precies de zelfde manier kun je bv. nooit een gebroken getal krijgen als je twee natuurlijke getallen met elkaar optelt of vermenigvuldigt; als je twee natuurlijke gatallen optelt of vermenigvuldigt komt daar altijd een natuurlijk getal uit. Het enige verschil is dat er maar twee boolse getallen zijn { 0, 1 } terwijl er oneindig veel natuurlijke getallen zijn { 0, 1, 2, ... }

Als je nu eens in "iets" en "niets" denkt ipv. "true" en "false"; dan zul je zien dat de operatoren exact het zelfde werken en hoeveelheden beschrijven, zowel in de integer als in de boolse algebra.

Maar dan benoem je dus de 0 uit de normale algebra "niets", en al het andere uit de normale algebra "iets".
In C is dit geldig: true-false. Bestaan in booleaanse algebra de -?
Goed...dat bestaan over de - laten we achterwege, en we rekenen met de booleans net zo als met integers (want zoals jij het stelt werken de + en * operatoren exact hetzelfde in de normale en de booleaanse algebra.. Als dat zo is mogen we de - en / toch ook gebruiken??)

true - false = true (want 1 - 0 = 1)
1 - false = true (want alweer 1 - 0 =1)
true - true = false (want 1 - 1 = 0)
Wat is nu 99 - true? Is dat true (want 99-1 = 98) of is dat toch false want true - true = false?

[Verwijderd]

Nee, ons probleem is dat ik algebraisch argumenteer, terwijl jij informatie-technisch argumenteert. Als je algebraisch kijkt dan zal bv. 10 / 20 een andere uitkomst hebben nagelang de verzameling waarin je werkt. Als je in N of Z werkt is de uitkomst 0 en als je in R, Q of C werkt is de uitkomst 0.5. Zo functioneert de deeloperator trouwens ook in de overgrote meerderheid van de programmeertalen: deel je een int door een int, dan is het resultaat een int en geen real.

[Alarmnummer]

Als ik eerlijk ben vind ik het overgangsgebied tussen algabraisch en informatisch technisch vrij vaag maarja. We gaan nu eindelijk wel een kant op, hehe

Ik ben het met je eens dat je als je in N of Z werkt 10/20 een 0 eruit krijgt. Maar stel nu dat ik niet in N of Z werk, maar in [10..20]. 10/20 levert een 0 op, en dat element komt niet voor in [10..20], dus je kan geen waarde terug sturen, dus dan een foutmelding.

Als [10..20] een type was zoals N het ook is, zou je het dan met me eens zijn?

[Verwijderd]

Als ik verder algebraisch argumenteer dan wordt het heel ingewikkeld met deelverzamelingen als [10..20], omdat er geen 0-element en geen 1-element in die verzameling zit. Je kunt dan alleen partiele algebra's zoals splines of rings definieren. Maw. is het puur wiskundig vrij onzinnig om op dit soort verzamelingen rekenoperaties door te voeren, je zou een compleet "wazige" partiele algebra moeten definieren om dat mogelijk te maken.

Informatietechnisch heb je natuurlijk volledig gelijk, je kijkt dan tegen enorme algebraische gaten aan, en het is nogal practisch te signaleren dat je in zo'n gat gevallen bent.

[Alarmnummer]

Ok, we komen dichter bij het eindstation

Maar wat vind jij dan van deze uitspraak? bool a = 2;

heeft dit een betekenis in boolean algebra?

[ Voor 0% gewijzigd door Alarmnummer op 06-08-2002 21:58 . Reden: kromme zin ;) ]

[Verwijderd]

Alarmnummer schreef op 06 augustus 2002 @ 21:57:
Ok, we komen dichter bij het eindstation

Maar wat vind jij dan van deze uitspraak? bool a = 2;

heeft dit een betekenis in boolean algebra?

Nee, het heeft net zo weinig betekenis als int i = 2.0; in integer algebra

Waar we dan langs omwegen door de wondere wereld der verzamelingenleer op terug komen, is het impliciete cast-gedrag van een programmeertaal

Jij bent van het strenge soort en vervloekt alle downcasts, omdat er bij een downcast gegevensverlies kan optreden. Ik ben van de soepele soort, die zegt dat mensen in de praktijk constant met verschillende numerieke types door elkaar rekenen en daarbij impliciet downcasten, en dat het daarom niet gek is als een programmeertaal dat ook kan, ipv. het als een fout af te doen.

[Verwijderd]

Als je C++ kent, ken je C.

Begin met C en ga verder naar C++ zou ik zeggen.


Maar ja... opinions are like assholes, everybody's got one. En als het op programmeren aankomt geldt dat extra sterk.

My 2 cts dus.

[Alarmnummer]

Ik ben inderdaad tegen downcast omdat ze namelijk ook per ongeluk kunnen gebeuren. In java bv moet je altijd expliciet converteren naar een boolean als die gevraagd wordt. Hierdoor zul je zelf goed na moeten denken over allerlei coersions ipv dit per ongeluk gebeurt.

Ik heb zelf ook een tijd in c geprogrammeerd en mij is het wel opgevallen dat je veel langer bezig bent om fouten op te sporen tov java. Je leest heel makkelijk over een semantisch fout, syntactisch correct stukje code heen.

Daarnaast ben ik geinteresseerd in functionele programmeertalen en ben nu bezig met een type systeem te schrijven. En dan zie je allerlei tekortkomingen in allerlei talen. Zelf het typesysteem van java vind ik nu onnodig beperkt Maarja.. zullen ze toendertijd ook wel een reden voor hebben gehad.

Ik wil zelf gewoon zoveel mogelijk compile time uitdrukkingskracht tot mijn beschikking hebben. En soms moet je daarvoor wel eens 'omslachtig en streng zijn', maar ik denk dat je dit dubbel en dwars terug krijgt

[Alarmnummer]

Schrijf anders maar eens een functie in c, die de getallen [10.20] 1 kan verhogen, en bij de rest kan hij dat niet. Zo zou je het aan kunnen pakken:

code:

public int inc(int i){
   if(i<10||i>20)foutmelding
  return i++;
}

Maar op deze manier krijg je geen compile time foutmelding als je inc(40) aanroept. Als je een krachtiger type systeem had dan zou je dit als volgt bv kunnen verhelpen:

code:

public void int([10..20] i){
    return i++;
}

Als je nu de volgende aanroept hebt: int(40) dan krijg je een foutmelding. Zoals je ziet kan je met een krachtiger typesysteem beter modeleren wat je bedoelt en daardoor hoef je minder checks uit te voeren, en daardoor wordt oa je code nog duidelijker.

[Fish]

mmm is dit offtopic ?

[Alarmnummer]

dit begint redelijk offtopic te gaan ja

[RickN]

GVD!!! Waarom wordt zo'n interessante discussie uitgevochten in het tien miljoenste C vs C++ topic??? Als ik in D2k's noodkreet topic niet had gelezen dat er ergens een interessante discussie rondzwierf, anders had ik dit nooit gelezen.

Anyway, ik ben het volkomen met Alarmnummer eens.
Logica neemt een aparte plaats in in de wiskunde en staat los van de klassieke algebra. De boolse algebra die mietje aanhaalt is een electrotechnisch begrip, niet wiskundig. Wiskundigen hebben geen behoefte aan een dergelijk concept omdat de klassieke logica uitstekend voldoet.
Ik zal morgen eens kijken of ik het een en ander ook wiskundig hard kan maken, want dat lijkt het enige te zijn wat mietje kan overtuigen.
De logische operatoren als AND, OR, NOT zijn gewoon gedefineerd op de twee booleaanse waarden TRUE en FALSE. Dat er vervolgens allerlei interessante interpretaties worden gehangen aan logische operatoren op integers of integer operatoren op booleans is een bekend concept, dat heet operator overloading, erg geliefd bij electrotechnici en informatici, maar het heeft geen enkele wiskundige basis.

[Verwijderd]

Alarmnummer schreef op 06 augustus 2002 @ 22:30:
Ik ben inderdaad tegen downcast omdat ze namelijk ook per ongeluk kunnen gebeuren. In java bv moet je altijd expliciet converteren naar een boolean als die gevraagd wordt. Hierdoor zul je zelf goed na moeten denken over allerlei coersions ipv dit per ongeluk gebeurt.

Klopt, het kan per ongeluk misgaan, maar is dat een fout van de programmeur of van de taal? C is een taal die zeker niet bedoeld is voor beginnende programmeurs (dit bedoel ik niet persoonlijk), en iemand die "per ongeluk" met booleans rekent is voor mij niet bepaald ervaren. In C krijg je overigens voor dit soort impliciete downcasts optioneel een warning, die je ook nog eens per optie kunt veranderen in een error.

Daarnaast ben ik geinteresseerd in functionele programmeertalen en ben nu bezig met een type systeem te schrijven. En dan zie je allerlei tekortkomingen in allerlei talen. Zelf het typesysteem van java vind ik nu onnodig beperkt Maarja.. zullen ze toendertijd ook wel een reden voor hebben gehad.

Ik heb me een tijd lang bezig gehouden met FP, maar ik vind het (nog?) niet echt geschikt voor practische toepassingen, tenminste in runtime. FP in compile-time bewijst zijn nut in talen als C++ (dmv. templates).

Ik wil zelf gewoon zoveel mogelijk compile time uitdrukkingskracht tot mijn beschikking hebben. En soms moet je daarvoor wel eens 'omslachtig en streng zijn', maar ik denk dat je dit dubbel en dwars terug krijgt

Mja, ik ontken niet dat een streng typesysteem voordelen heeft, maar het heeft ook nadelen. Wat jij als uitdrukkingskracht typeert, kan ook sterk tegen je werken. Als je bv. alle impliciete downcasts verbiedt, dan is dat "programmeurtje martelen" van het ergere soort: in een OO-taal moet een programmeur dan alle gesubclasste types expliciet downcasten naar het baseclass-type...

Er bestaan overigens al verschillende talen die pre- en postcondities toelaten, en dat is wat jij in principe wilt met je type-systeem: precondities vastleggen. Het is de vraag of je voor elke mogelijke preconditie een apart type moet specificeren, of dat je een andere mogelijkheid bedenkt ze toe te laten zonder dat dat een programmeur kilometers code extra kost.

[Verwijderd]

RickN schreef op 06 augustus 2002 @ 23:22:
Logica neemt een aparte plaats in in de wiskunde en staat los van de klassieke algebra. De boolse algebra die mietje aanhaalt is een electrotechnisch begrip, niet wiskundig. Wiskundigen hebben geen behoefte aan een dergelijk concept omdat de klassieke logica uitstekend voldoet.

Sorry Rick, maar de boolse algebra is werkelijk een volledige algebra in de verzamelingenleer. En in de verzamelingenleer zijn er massa's algebra's, de "klassieke" algebra is er daar maar een van. En voor al die algebra's bestaan er operatoren, dat heeft niets met "overloading" te maken.

Ik zal morgen eens kijken of ik het een en ander ook wiskundig hard kan maken, want dat lijkt het enige te zijn wat mietje kan overtuigen.

Doe dat, ik heb de papers uit mijn studietijd nl. al voor me

[Alarmnummer]

Die types zijn niet zozeer pre condities. Maar dit zijn dingen die je compile time al kan regelen. Als jij weet dat jij een char wilt afdrukken met een bepaalde routine, dan geef je een char mee als argument en niet een int. Hetzelfde doet je in mijn voorbeeld. Je gaat daar een type declaren waarvan jij 100% zeker weet dat jij voor iedere orgineel een beeld kan bepalen en dat kan erg handig zijn. Ik heb halverwege dit topic ook een gemaakt met een null check, en ik ken niet anders zeggen dan dat ik daar een hele natte plasser van krijg

Verder werk ik zelf altijd met precondities, zodat ik weet dat iedere methode goeie argumenten krijgen. Maar je krijgt dan altijd zo`n kliederzooi in je methodes, en dat kan je hier voor veel van de gevallen goed oplossen.

En functioneel programmeren is trouwens iets anders dan templates. Wat jij bedoelt is geparametriseerde polymorphisme, en dat is veel krachtiger dan wat je kan met templates in c++.

En een beetje programmeurtje pesten is leuk om te doen Het komt bij mij niet zo heel vaak meer voor dat ik een bepaald object moet upcasten. Ik maak meestal gebruik van een double dispatch aanroep om bepaalde code uit te voeren op een class waarvan ik een bepaald basis type kan garanderen (meestal door generics ) als die class die methode niet bezit, of ik maak gebruik van polymorphisme. Ik heb al heel wat code geschreven, maar ik heb daar nog nooit problemen door ondervonden.

[Verwijderd]

Ik wil niet weer gaan kibbelen, maar precondities zijn niet prece asserts of iets dergelijks. Je zou een taal kunnen bedenken waarin je precondities kunt declareren, waarna ze door de compiler of runtime gechecked worden. Als je zo'n preconditie vaker nodig hebt, zou je hem aan een type kunnen hangen, waardoor je ongeveer krijgt wat jij wilt (en compile-time checking mogelijk wordt).

Ik bedoel dus zoiets:

void doe_iets(char letter <[ 'a' .. 'z' ]>, int dag <[ 1 .. 7 ]>);

typedef int <[1 .. 12]> maand;

[Alarmnummer]

En het voordeel aan deze aanpak is dus dat je veel problemen compile time op kan lossen, terwijl dit op dit moment runtime nog gedaan moet worden. Anders moet je deze maar eens doorkijken: Nice Safety in Nice Dit is een hele leuke taal die gewoon naar java byte code compileerd, zodat je het kan gebruiken op een normale vm.

Hier staan hele leuke dingen in die je toch een heel ander perspectief op de huidige aanpak van types geven. Zo gauw nice echt bruikbaar gaat worden, ga ik er zeker mee spelen.

ps: wat heb je trouwens gestudeerd?

[Verwijderd]

Alarmnummer schreef op 06 augustus 2002 @ 23:55:
En het voordeel aan deze aanpak is dus dat je veel problemen compile time op kan lossen, terwijl dit op dit moment runtime nog gedaan moet worden. Anders moet je deze maar eens doorkijken: Nice Safety in Nice Dit is een hele leuke taal die gewoon naar java byte code compileerd, zodat je het kan gebruiken op een normale vm.

Hehehe, nice, leuk Nice is dus in principe Java + templating, en op die safety-page wordt exact beweerd wat ik ook beweer: templating is een vorm van FP, alleen in een andere "stijl" dan de meeste functionele talen.

C++ implementeert dit op een vergelijkbare wijze:

• collections:
  std::stack<int, std::list<int> > my_stack;
  definieert een typesafe stack van integers, die intern opgebouwd is uit een double-linked list.
• multiple dispatch:
  template <class T> bool equal(const T& a, const T& b) { return a == b; }
  definieert een multiple dispatch equal functie met default implementatie.
• null pointers:
  Het gebruik van references, een reference is een impliciete pointer die nooit null kan zijn (tenzij je hem daar keihard toe forceert). Men garandeert dit door te eisen dat er geen ongeinitialiseerde references mogen voorkomen (en die initialisatie dus af te dwingen). Zie bv. die equal functie boven, a en b zijn twee references die gegarandeerd nooit null worden.

Het enige dat wezenlijk verschilt met C++ is het checken van null-references.

ps: wat heb je trouwens gestudeerd?

Eerst een jaartje astrofysica, maar ik ben helaas gestrand op QM. Daarna heb ik (theoretische) informatica gestudeerd.

[MSalters]

Alarmnummer schreef op 06 augustus 2002 @ 22:47:
...

code:

public int inc(int i){
   if(i<10||i>20)foutmelding
  return i++;
}

Maar op deze manier krijg je geen compile time foutmelding als je inc(40) aanroept. Als je een krachtiger type systeem had dan zou je dit als volgt bv kunnen verhelpen:

code:

public void int([10..20] i){
    return i++;
}

Als je nu de volgende aanroept hebt: int(40) dan krijg je een foutmelding.

En als je nu inc(20) aanroept dan krijg je dus geen foutmelding terwijl het resultaat niet representeerbaar is in het domein [10..20] ?!
Die inc die jij beschrijft is een operatie met type int[10..20]->int[11..21]. Nu kan de compiler dit nog wel checken, maar iha loop je het risico van halting probleem op statische pre/post conditie checks.

[mbravenboer]

Alhoewel de overeenkomsten tussen templates en geparameterizeerde typen groot lijken, zijn er qua compilatie methode en mogelijkheden grote verschillen. De meeste generic Java proposals compileren namelijk niet door code-generatie voor elke instantie van een 'template' of geparameterizeerd type, maar via type erasure. Ook het officiele voorstel voor geparameterizeerde typen in Java (JSR-14) doet dit. Hoe Nice het doet weet ik eerlijk gezegd niet omdat ik er alleen nog maar naar gekeken hebt. In .NET/C# gaan ze een stapje verder door generics door te voeren in de IL (vergelijkbaar met de Java Bytecode).

Als je meer wilt weten over de geparameterizeerde typen in .NET en Java zijn deze twee linkjes misschien handig. Ik probeer hier de beste bronnen op dit gebied te verzamelen:

http://www.mbravenboer.org/dotnet_resources.xhtml
http://www.mbravenboer.org/java_resources.xhtml

[Verwijderd]

mbravenboer schreef op 07 augustus 2002 @ 11:31:
Alhoewel de overeenkomsten tussen templates en geparameterizeerde typen groot lijken, zijn er qua compilatie methode en mogelijkheden grote verschillen. De meeste generic Java proposals compileren namelijk niet door code-generatie voor elke instantie van een 'template' of geparameterizeerd type, maar via type erasure.

Klopt, "templating" is een ruimer begrip dan "geparametriseerde types" (evil grin) Zowel code-generatie als type-erasure heeft zijn pro's en cons: het grote nadeel van type-erasure is natuurlijk dat je geen primitive types kunt parametriseren.

Een interessante ontwikkeling vind ik het beschouwen van geparametriseerde types (collections) als frist-class types. (Dit maakt het voor de programmeur eenvoudig om bv. een linked list naar een tree te casten.) Ik vind dit een tweesnijdend zwaard: het verhoogt de orthogonaliteit van de taal, maar ik vrees dat het tot zeer inefficiente code in de praktijk gaat leiden: zulke casts zijn veel duurder in rekentijd dan een gewone cast, terwijl dat op deze manier voor de programmeur niet duidelijk is.

[D2k]

RickN schreef op 06 augustus 2002 @ 23:22:
Als ik in D2k's noodkreet topic niet had gelezen dat er ergens een interessante discussie rondzwierf, anders had ik dit nooit gelezen.

offtopic:
kijk weer een tevreden klant
let maar niet op mij, dit is dus een van de topics met een beetje niveau erin

[Alarmnummer]

MSalters schreef op 07 augustus 2002 @ 07:51:
[...]
En als je nu inc(20) aanroept dan krijg je dus geen foutmelding terwijl het resultaat niet representeerbaar is in het domein [10..20] ?!
Die inc die jij beschrijft is een operatie met type int[10..20]->int[11..21]. Nu kan de compiler dit nog wel checken, maar iha loop je het risico van halting probleem op statische pre/post conditie checks.

Ik ben inderdaad vergeten het return type op te geven. Als het return type [11..21] is, dan zijn er geen problemen. Als het returntype [10..20] is, zul je bij invoer van 20 een foutmelding op moeten werpen. En verder loop je niet het risico op een een oneindige lus omdat je of een antwoord terug geeft in het juiste antwoord domein, of een foutmelding. Het is dus altijd beslisbaar.

Trouwen die [10..20] zijn niet zozeer precondities, maar het is een nieuwe type zoals byte, int en long dat ook zijn. Als je een formeel byte argument aan gaat roepen met een int argument dan zou je een foutmelding moeten krijgen. Hetzelfde geld voor:
[0..200] a = ...
int(a)
Dit geeft compile time al een foutmelding omdat het type van a geen subtype is van [10..20] (het is een supertype).

[Alarmnummer]

Verwijderd schreef op 07 augustus 2002 @ 12:23:
[...]
zulke casts zijn veel duurder in rekentijd dan een gewone cast, terwijl dat op deze manier voor de programmeur niet duidelijk is.

Generics in java worden compile time al opgelost en heb je runtime dus geen overhead van.

En kan je in c++ wel een restrictie aanbrengen op typevariablen?

vb:

code:

public class PersoonList<P extends Persoon>{
   ...
}

Je kunt nu alleen maar gaan parametriseren over subclasses van Persoon.

[Verwijderd]

Alarmnummer schreef op 07 augustus 2002 @ 13:49:
[...]
Generics in java worden compile time al opgelost en heb je runtime dus geen overhead van.

Euhhh? kun je mij vertellen hoe je in compile-time een linked list naar een tree cast? Er zal toch echt een runtime component moeten zijn die die de elementen van de list naar de tree copieert (en hoeveel elementen er in zo'n collection zitten is meestal niet bekend in compile-time).

En kan je in c++ wel een restrictie aanbrengen op typevariablen?

In C++ heb je verschillende opties zoals bv. traits, die de eigenschappen van een type beschrijven. Jouw voorbeeld:

class BasePersoon { ... };

typedef std::list<BasePersoon*> PersoonList;

Dit is trouwens behoorlijk XXX, het zou eleganter zijn die BasePersoon* te wrappen in een reference class.

[Alarmnummer]

Verwijderd schreef op 07 augustus 2002 @ 14:13:
Euhhh? kun je mij vertellen hoe je in compile-time een linked list naar een tree cast? Er zal toch echt een runtime component moeten zijn die die de elementen van de list naar de tree copieert (en hoeveel elementen er in zo'n collection zitten is meestal niet bekend in compile-time).

Mijn fout. Ik had even te snel gelezen en bedoelde op runtime overhead door aanwezigheid van generics in java.

[Verwijderd]

Schrijf anders maar eens een functie in c, die de getallen [10.20] 1 kan verhogen, en bij de rest kan hij dat niet. Zo zou je het aan kunnen pakken:
code:
--------------------------------------------------------------------------------
public int inc(int i){
if(i<10||i>20)foutmelding
return i++;
}

public void int([10..20] i){
return i++;
}

Deze twee functies zijn verschillend van aard. Zo heeft de eerste een identiek domein en bereik, de tweede niet (nog afgezien van het feit dat jij onterecht een void een int[11..21] laat returnen )

Of je moet natuurlijk de operator ++ overloaden voor het type int[10..20], zodat deze altijd een resultaat oplevert in int[10..20]... (mogelijk natuurlijk, maar niet wenselijk om dat steeds te moeten doen voor al die verschillende subdomeinen van int die je wilt gebruiken)

Verder ben ik het NIET met mietje eens dat de + operator voor integers en booleans gelijk is (zeker niet wiskundig)

Een van de axioma's van de booleaanse algebra is

Axiom #6: Distributive

* is distributive over + and + is distributive over *
a * (b + c) = (a * b) + (a * c), and
a + (b * c) = (a + b) * (a + c)

Dit is dus PERTINENT NIET WAAR voor integer-algebra!!! (maar een specifieke eigenschap van booleaanse algebra). Dat verschil zit 'em niet in het domein (een integer subdomein [0..1] geld deze regel namelijk ook niet voor) maar in de algebra zelf (in dit geval de defenitie van de + operator)

[Verwijderd]

Alarmnummer schreef op 07 augustus 2002 @ 13:49:
En kan je in c++ wel een restrictie aanbrengen op typevariablen?

Ja, maar niet op die (constraints through derivation) manier, en niet met behulp van een speciaal daarvoor bedoelde language feature.

Bezwaren tegen 'constraints through derivation' staan beschreven in 15.4.1 van The Design and Evolution of C++.

De [url="http://boost.org/libs/concept_check/concept_check.htm"]Boost Concept Check Library[/url] biedt een framework voor het gebruik van concept checking classes. Door een template een concept checking class te laten gebruiken worden duidelijkere error messages gegenereerd wanneer een gegeven type het gewenste concept niet implementeerd, en worden constraints die anders extern gedocumenteerd zouden moeten worden overzichtelijk vastgelegd in de code (overigens is documentatie alsnog wenselijk ).

[Alarmnummer]

Verwijderd schreef op 07 augustus 2002 @ 15:59:
Deze twee functies zijn verschillend van aard. Zo heeft de eerste een identiek domein en bereik, de tweede niet (nog afgezien van het feit dat jij onterecht een void een int[11..21] laat returnen )

Ik zal ook al dat het return type miste . Je zou kunnen kiezen voor 2 return types. je zou kunnen kiezen voor int, zodat je het type [10..20] puur gebruikt wordt voor compile time safety van deze functie. Maar je zou ook [11..21] als return type terug kunnen sturen waardoor er geen informatie verloren gaat. En verder kan je nu gerust dit zeggen:
int p = inc(20);
Ik zou persoonlijk kiezen voor de 2e aanpak omdat daar dus geen informatie verloren gaat en je kan het zonder problemen in een ruimer type plaatsen.
[0..100] p = inc(20); //dit kan je niet zeggen met de 1e aanpak.

Ik weet verder niet hoe handig dit is in de praktijk en het ligt er ook heel erg aan welk domein je zit. Maar ik merk wel dat ik wel enorm veel checks zou kunnen verwijderen als ik een krachtiger typesysteem tot mijn beschikking heb. Verder kan je er gewoon beter in kenbaar maken wat je wilt:

code:

public String toDag([0..6] dagIndex){
    ...
}

Dit is erg duidelijk.

[MSalters]

Alarmnummer schreef op 07 augustus 2002 @ 13:39:
[...]
Ik ben inderdaad vergeten het return type op te geven. Als het return type [11..21] is, dan zijn er geen problemen. Als het returntype [10..20] is, zul je bij invoer van 20 een foutmelding op moeten werpen. En verder loop je niet het risico op een een oneindige lus omdat je of een antwoord terug geeft in het juiste antwoord domein, of een foutmelding. Het is dus altijd beslisbaar.

Nee, het return type kan geen [10..20] zijn. Wat jij beschrijft is (naast [11..21]) [11..20, foutmelding]. Dat is een andere set uitkomsten. Wat voor wiskundige resultaten wil je daar op loslaten?
(Ik denk dat we nu op lattices uitkomen - en dan laat ik het aan mbravenboer over denk ik)

Trouwen die [10..20] zijn niet zozeer precondities, maar het is een nieuwe type zoals byte, int en long dat ook zijn. Als je een formeel byte argument aan gaat roepen met een int argument dan zou je een foutmelding moeten krijgen. Hetzelfde geld voor:
[0..200] a = ...
int(a)
Dit geeft compile time al een foutmelding omdat het type van a geen subtype is van [10..20] (het is een supertype).

Je mist het grote probleem van algebras op deze nieuwe types. Zoals al eerder opgemerkt heb je gewoon geen normale + op deze types, omdat het identiteitselement ontbreekt. ( Booleaanse algebra op [0..1] heeft die dus wel )

[Alarmnummer]

MSalters schreef op 07 augustus 2002 @ 17:08:
[...]
Nee, het return type kan geen [10..20] zijn. Wat jij beschrijft is (naast [11..21])
[11..20, foutmelding]. Dat is een andere set uitkomsten. Wat voor wiskundige resultaten wil je daar op loslaten?

Het return type is wel [10..20] (tenminste als je dat zo opgeeft) want een foutmelding is dus geen return waarde en dus geen element van een type. De functie wordt volledig afgebroken en zul je op hoger nivo weer moeten afvangen. Trouwens dit heeft niet meer zoveel te maken met wiskunde, maar dit is meer bedoelt voor in programmeertalen.

ps:
je kan dat afbreken dus vergelijken met het opgooien van een exception. Een exception is ook geen element van het return type, maar een andere manier om de methode te verlaten.

pps:
en je kan voor de subtypes exact dezelfde wiskundige regels erop loslaten als op int. Maar alleen in het geval dat de berekende waarde niet in dat type past, krijg je een foutmelding.

[MSalters]

Alarmnummer schreef op 07 augustus 2002 @ 17:13:
[...]
Het return type is wel [10..20] (tenminste als je dat zo opgeeft) want een foutmelding is dus geen return waarde en dus geen element van een type. De functie wordt volledig afgebroken en zul je op hoger nivo weer moeten afvangen. Trouwens dit heeft niet meer zoveel te maken met wiskunde, maar dit is meer bedoelt voor in programmeertalen.

ps:
je kan dat afbreken dus vergelijken met het opgooien van een exception. Een exception is ook geen element van het return type, maar een andere manier om de methode te verlaten.

pps:
en je kan voor de subtypes exact dezelfde wiskundige regels erop loslaten als op int. Maar alleen in het geval dat de berekende waarde niet in dat type past, krijg je een foutmelding.

Mietje schreef al eerder

Nee, ons probleem is dat ik algebraisch argumenteer, terwijl jij informatie-technisch argumenteert.

En dat geldt dus nog steeds. We waren bezig om algebra's te vergelijken, in het bijzonder die modulo MAX_INT, die modulo 2 en Booleaanse algebra. Die [10..20] is een moeilijk geval omdat je geen normale algebraische operator+ kunt definieren met een identiteits element. Sowieso worden identiteits elementen een probleem als je resultaat verzameling niet dezelfde is als je bron verzameling.

Een algebra heeft ook geen exceptions, anders dan als "bijzondere" resultaten. Zelfs als we dat negeren zit 10 nog niet in de resultaat set.

Wat pps betreft, je geeft daar een beschrijving van de 'functie' in termen van een mapping naar int gevolgd door een normale operatie in N en vervolgens een mapping van int naar de set [11..20, exception]. Dat hadden we wel zo'n beetje begrepen. Volgens mij mis je de essentie van de verschillen tussen + in algebra's met en zonder identiteits element. Daarmee samenhangend mis je dan ook (nog steeds volgens mij) de verschillen tussen een + waarvan de argumenten en het resultaat uit dezelfde verzamling komen, en jouw voorbeelden waar dat niet het geval is.

[Alarmnummer]

Dat hadden we wel zo'n beetje begrepen. Volgens mij mis je de essentie van de verschillen tussen + in algebra's met en zonder identiteits element.

Ik zou eerlijk gezegd niet weten wat daaraan informatie technisch verschillend aan is . Ik hoop dat je me dat even kan uitleggen zodat ik begrijp wat ik schijnbaar niet zie.

Daarmee samenhangend mis je dan ook (nog steeds volgens mij) de verschillen tussen een + waarvan de argumenten en het resultaat uit dezelfde verzamling komen, en jouw voorbeelden waar dat niet het geval is.

Informatie technisch zie ik geen enkel probleem. Maar als dit wel zo is, zou je me dan kunnen uitleggen wat ik dan over het hoofd zie?

[Verwijderd]

Alarmnummer schreef op 07 augustus 2002 @ 23:52:
Ik zou eerlijk gezegd niet weten wat daaraan informatie technisch verschillend aan is . Ik hoop dat je me dat even kan uitleggen zodat ik begrijp wat ik schijnbaar niet zie.

Ik neem het weer over

Je kunt informatietechnisch heel goed stellen dat je "twee integers optelt waarvan het resultaat in het interval 10 .. 20 moet liggen", maar dan is dat algebraisch geen + operator, mede omdat je een verzameling getallen definieert door het herhaald optellen van het eenheidselement, en dat eenheidselement zich niet in het bereik van die optel-operator bevindt...

Informatie technisch zie ik geen enkel probleem. Maar als dit wel zo is, zou je me dan kunnen uitleggen wat ik dan over het hoofd zie?

Het is gewoon een definitiekwestie, algebraisch mag je niet zomaar elke functie een operator noemen. Een algebraische operator is als volgt gedefinieerd:

Een n-aire operatie over een verzameling A is een functie
f: Aⁿ -> A;
n is het aantal argumenten van f (n >= 0)
n n-air
0 nullair
1 unair
2 binair
3 ternair

Een nullaire operatie f: A⁰ -> A wordt geheel bepaald door het element f = f( ) = f( < > ) van A;
een nullaire operatie heet ook een constante.

Voor ons is nu alleen f: Aⁿ -> A; belangrijk, want daarin zie je duidelijk dat het een afbeelding is van een aantal argumenten uit verzameling A naar opnieuw verzameling A.

[ Voor 0% gewijzigd door Verwijderd op 08-08-2002 02:58 . Reden: typo in quote (papier is primitief, cut&paste werkt niet) ]

[Verwijderd]

Met die definitie zou je dus de '+' wel degelijk als algebraische operator kunnen zien. In jouw definitie is geen definitie gegeven voor de verzamelingen Aⁿ en A, waardoor je daarmee niet de inc functie over {10,20} elimineert.

[Verwijderd]

Je kunt informatietechnisch heel goed stellen dat je "twee integers optelt waarvan het resultaat in het interval 10 .. 20 moet liggen", maar dan is dat algebraisch geen + operator, mede omdat je een verzameling getallen definieert door het herhaald optellen van het eenheidselement, en dat eenheidselement zich niet in het bereik van die optel-operator bevindt...

Ben ik niet met je eens. Een optelling waarvan het resultaat in [10..20] moet liggen is wel degelijk algebraisch gezien een optelling, er worden hier alleen restricties aan het bereik gesteld (en dus impliciet restricties dat het domein van de functie). De 'gewone' + operator definieren voor de ruimte [10..20] is denk ik wel een probleem, aangezien de afbeeldingsverzameling niet gelijk is aan de bronverzameling (en het dus volgens jouw defenitie uberhaupt geen operator genoemd kan worden)

Dat je een verzameling getallen definieert door het herhaald optellen van het eenheidselement is natuurlijk onzin : {2,5,14} is ook een verzameling getallen, heet wat jij hier bedoelt niet een volledige verzameling?

[Verwijderd]

Met die definitie zou je dus de '+' wel degelijk als algebraische operator kunnen zien. In jouw definitie is geen definitie gegeven voor de verzamelingen An en A, waardoor je daarmee niet de inc functie over {10,20} elimineert.

inc is dus in ieder geval geen operator, want deze beeld de verzameling [10..20] af naar [11..21]. Ook is de 'gewone algebra' plus hier geen operator, want
x in [10..20]
y in [10..20]
x + y niet in [20..40]
Je zou hiervoor dus een equivalent van de 'booleaanse algebra' moeten verzinnen waardoor je toch de + operator houdt, maar ik weet niet of dat mogelijk is...

[Verwijderd]

Mja ok. (waarom [20,40] overigens?) Als je het zo stelt is het dus niet mogelijk een operator te verzinnen die voldoet aan de algebraische operator-definitie waarvoor je een zekere optelling, danwel substractie danwel multiplicatie of deling definieert over een begrenst interval. Immers, het projectie-interval ligt altijd buiten de grenzen van het input-interval

[Alarmnummer]

Ik denk dat we nu op een verschil uitkomen in de algabraische wereld en de informatie technische wereld. Een ander voorbeeld dat er in de informatie technische wereld niet zo zwaar getild wordt aan die definitie van de operator zijn functionele programeertalen. Daarin heb je bv geen onderscheid tussen operatoren en functies. Operatoren zijn gewoon infix geschreven functies (zonder haakjes, maar veel functionele talen maken daar ook geen gebruik van). En het maakt verder absoluut niet uit naar wel domein je afbeeld en wat het orgineel is.

[Verwijderd]

Alarmnummer: Precies. Zolang maar is gedefinieerd wat het input-interval is en naar welk interval de functie/operator afbeeldt.