wiskundige "scriptingtaal"

[Verwijderd]

zoals reeds in een vorige post ter sprake gekomen is ben ik bezig een wiskundige scripting taal te maken,

nu vraag ik mj af, kan ik best met types werken of volledig OO, zodoende dat er geen primitieve datatypes meer zijn

als ik met types zou werken, dan best met dynamische types zoals in perl, of eerder vaste types, waarbij integer en floats apart moeten worden gedefinieerd

[Alarmnummer]

Volgens mij grijp je een beetje te hoog. In oo heb je ook gewoon types en dat heeft verder niet zoveel uit te staan met het paradigma waar je mee bezig bent. Het heeft daarom niet zoveel nut om een keuze te maken die er niet bestaat. De enigste keuze die je kan nemen is of je wel of niet primitieve waardes (ipv objecten) in je systeem toelaat, maar dit heeft verder niets te maken met het typesysteem.

Ik zou zelf gaan voor de 'klassieke' aanpak: expliciet alle types declareren. Je krijgt nog meer dan genoeg andere lastige zaken voor de kiezen en ik zou het daarom zo 'eenvoudig' mogelijk houden. Ik ben op dit moment zelf ook bezig met een 2e orde type systeem, en daar maak ik ook gebruik van type declaraties en ik maak verder ook geen gebruik van type inference (types terug redenen).

Ik weet niet in welke taal je het wilt schrijven, maar anders moet je de sourcecode van Nice (is geschreven in Java en Nice) even ophalen, daarin zit een typesysteem zoals ML (1e taal waarin een zeer krachtig typesysteem zit en waar veel talen nog iets van mogen leren, zoals bv java,c#).

[Rataplan]

Post eens een omschrijving van het soort probleem dat je wilt oplossen? "Wiskundige scripting taal" is nogal vaag. Statistiek? Modellen doorrekenen? Functies oplossen? Integreren?

Verder kan je met een OO model waarin je een beetje fatsoenlijk kan overerven natuurlijk primitieve types altijd nog aanpassen, itt tot een systeem waarbij je primitieve types als programmeur nog eens moet aanmaken -> hoop extra werk voor die programmeur.

De keus tussen dynamische en statische types is al helemaal afhankelijk van het soort problemen dat je op wilt lossen.

Kortom: more info!

_{"een vorige post" vinnik trouwens ook nogal vaag}

[Alarmnummer]

En deze moet je maar eens doorlezen om een 1e indruk te krijgen van hoe gecompliceerd een typesysteem is.

Luca Cardelli and Peter Wegner. On understanding types, data abstraction, and polymorphism Ik vond het zelf erg verhelderend en heb nog een paar stukken van hem doorgelezen waarin genoeg informatie staat om degelijk typesysteem te begrijpen/ontwerpen.

[Verwijderd]

Het is geen wet van Meden en Perzen, maar "scriptingtaal" impliceert voor de meeste mensen "dynamische types". Maw. er zijn maar zeer weinig talen met een statisch typesysteem die "scriptingtaal" genoemd worden.

[Alarmnummer]

Als ik eerlijk ben moet ik eerst weer even opzoeken wat dynamische types precies inhouden. Ik ben even in de war met type inference maar dit is een statisch proces ipv een dynamisch proces.

Verder denk ik dat de topic starter eerst duidelijk moet uitleggen wat hij wil.

[Verwijderd]

Een taal waarin er wel types bestaan maar waarin variabelen geen statisch type hebben.

Neem bv. Javascript:

code:

var a= 10        // integer
a= 2 / a         // float
a= "Hallo " + a  // string

[Alarmnummer]

Type inference redeneert ook het type terug, dus waarin verschilt dit van dynamische types?

[Verwijderd]

Alarmnummer schreef op 19 augustus 2002 @ 01:21:
Type inference redeneert ook het type terug, dus waarin verschilt dit van dynamische types?

Emz, ik wilde behulpzaam zijn. Ik dacht je de moeite dynamische types op te zoeken te besparen door een voorbeeld te geven

[Alarmnummer]

afgezien van het feit dat typeinference statisch is, en dynamische types waarschijnlijk runtime worden gechecked. Het zal wel komen door het 'dynamische' gedrag van script talen.

[Alarmnummer]

Verwijderd schreef op 19 augustus 2002 @ 01:23:
[...]

Emz, ik wilde behulpzaam zijn. Ik dacht je de moeite dynamische types op te zoeken te besparen door een voorbeeld te geven

Het probleem is dus dat ik het verschil niet zie tussen 'dynamische types' en type inference. Het enigste verschil dat ik zie is dus statisch(type inference) dynamisch (dyn. types)

[Verwijderd]

"Dynamische types" is eigenlijk niet helemaal correct, het gaat in principe om "zwakke types", een "weakly typed language", wat dus iets verder gaat dan "dynamicly typed". Een variabele heeft hier geen expliciet type, en wijzigt impliciet dynamisch (runtime) zijn type al nagelang de operaties die erop uitgevoerd worden.

[Soultaker]

Alarmnummer schreef op 19 augustus 2002 @ 01:25:
Het probleem is dus dat ik het verschil niet zie tussen 'dynamische types' en type inference. Het enigste verschil dat ik zie is dus statisch(type inference) dynamisch (dyn. types)

Bij een dynamisch typesysteem vind (naar mijn idee) automatische conversie tussen (sub)typen plaats. Dat uit zich in PHP, Javascript en Perl bijvoorbeeld erin dat een getal in een string-functie gebruikt kan worden als string, en een string al getal.

Bij type inference wordt vastgesteld wat het type zou moeten zijn op basis van de operaties die er op uitgevoerd worden (bv. a = 4 betekent a is een integer) maar of een expressie als a = "4" / 2 opgelost wordt (en wat het type van a dan is) hangt af van de eigenschappen van het typesysteem.

In een taal als C/C++ zijn basic types als ints en reals redelijk dynamisch maar is er geen type inference (alle typen moeten gedeclareerd worden). Je kunt bijvoorbeeld wel 2/3.0 schrijven (wordt een double, als ik 't goed heb), maar niet "4"/2 (ok; kan technisch gezien in C stiekum wel, maar het gaat helemaal fout en je krijgt er warnings voor).

Maar als jullie met andere termen voor de hierboven beschreven eigenschappen komen vind ik 't ook best hoor.

edit:
Zoals mietje al zegt, is weakly typed een wat gebruikelijkere term.

[Verwijderd]

het is de bedoeling om eenvoudig te kunnen rekenen, dus floats en ints zullen zonder twijfel worden gebruikt,

maar ook met breuken zou ik eenvoudig willen werken, het zou zeer leuk zijn moest er zon abstractie zou kunnen worden bereikt dat alle mogelijke tyypes zelf kunnen worden aangemaakt
hierbij kan zuivere OO handig zijn , maar persoonlijk vind ik dat een paar primitieve datatypes wel handig zijn, indien andere ideeën hierrond, laat maar horen

je kan nog een paar types gebruiken zoals in java, dan zijn er wel enkele bedenkingen
bijv hoeveel (en vooral welke) types moet je dan primitief maken, moet je de mogelijkheid laten om zelgedefinieerde types ook primitief temaken enzovoort

[Verwijderd]

Noble_Paladin:

Je bent nog steeds niet duidelijk over je doelstellingen. Wat wil je met deze 'wiskundige taal'? Heb je al gekeken naar andere talen/libs die vaak voor wiskundige problemen worden gebruikt? En zo ja, wat was daar mee mis en hoe ga jij dat verbeteren?

Je hebt het over typesystemen en OOP, maar zonder context en meer informatie over jouw visie (heb je die?) kan niemand hier denk ik zinnig concreet advies geven.

[Soultaker]

Het lijkt me niet echt zinnig om (naar de programmeur toe) een object-georienteerde interface aan te bieden voor de 'getallen' alleen; dat wil zeggen als er verder niet van een OO programmeerwijze gebruik gemaakt wordt. Intern kun je natuurlijk doen wat je wil, maar ook hier geldt eigenlijk hetzelfde.

Ook als je nergens object-georienteerd werkt, kun je nog wel aan elke script-variabele intern een type (integer, floating point type, big numeral, breuk, etcetera) koppelen en impliciete conversie toepassen wanneer dat gewenst is.

Het lijkt me, zeker in een wiskundige taal, belangrijk dat je ofwel kiest voor een niet-OO opzet, ofwel het ontbreken van primitieve typen. Het bestaan van een primitief type (dat dus geen Object is) slaat binnen een OO omgeving nergens op.

[Verwijderd]

De bedoeling is om een interface te bieden, die het mogelijk maakt om wiskundige zaken in te voeren en zodoende ook te verwerken
het is de bedoeling dat al enkele veel voorkomende zaken opgenomen zijn, maar er moet de mogelijkheid zijn om de bibiotheek uit te breiden, hierbij lijkt me een OO aanpak best geschikt, maar OO met of zonder primitieve datatypes dan

[Verwijderd]

Verwijderd schreef op 19 augustus 2002 @ 02:57:
De bedoeling is om een interface te bieden, die het mogelijk maakt om wiskundige zaken in te voeren en zodoende ook te verwerken
het is de bedoeling dat al enkele veel voorkomende zaken opgenomen zijn, maar er moet de mogelijkheid zijn om de bibiotheek uit te breiden, hierbij lijkt me een OO aanpak best geschikt, maar OO met of zonder primitieve datatypes dan

En wat is er mis met bestaande talen/libs?
Verder nog steeds een nogal vage beschrijving imho .

[Verwijderd]

er is niets mis met bestaande talen of iets dergeijks
we willen gewoon graag dit als projectje starten, en trachten er zoveel mogelijk nieuwe en efficiente dingen in te steken

[.oisyn]

Ik zie het hele nut niet van typen in een wiskundige scripttaal
Neem nou bijvoorbeeld de scripttaal van Derive (niet echt een taal te noemen; het is meer een opsomming van expressies). Dat ziet er zo uit:

code:

a := 4
f(x) := 2 * x + 5
z := a * f(5)

en over het algemeen zijn alle getallen floating point getallen... en verder is er nog onderscheid tussen functies en vectoren, en daar houdt het zo'n beetje op.
Ik weet niet wat de bedoeling van de taal is (geef eens een voorbeeld), maar ik als potentiele eindgebruiker van jouw scripttaal () zie het nut van verschillende typen niet in...

[Soultaker]

.oisyn schreef op 19 augustus 2002 @ 03:12:
Ik zie het hele nut niet van typen in een wiskundige scripttaal

Het hangt er een beetje van af wat je 'typen' noemt. In de wiskunde kan een variabele 'alles' zijn wat je maar wilt, maar niet alle mogelijke operaties zijn gedefinieerd op 'alle dingen'. Binnen die context zou je in plaats van 'typen' het beter kunnen hebben over classificaties of verzamelingen; het komt feitelijk op hetzelfde neer.

Je zult toch op de een of andere manier typen moeten onderscheiden; je kunt een vector niet bij een kommagetal optellen, om maar wat te noemen.

Ik ben het echter met je eens dat het voor de gebruiker van een scripttaal praktisch is als het typesysteem transparant is (zoals deels in Perl het geval is) en de meeste zinnige conversies (integer naar floating point, etc.) automatisch plaatsvinden. Op die manier zal je je zelden druk hoeven maken over de feitelijke typen van variabelen.

[Verwijderd]

ik begin me vooral af te vragen, of het geen zin heeft om volledig OO te werken, geen datatypes gebruiken, maar enkel objecten die functies hebben waar argumenten kunnen aan worden doorgegeven

En als dat nodig blijkt kan een integer object bijvoorbeeld een floating point object teruggeven zonder dat de gebruiker zich er iets van meot aantrekken,

[.oisyn]

Soultaker: Uiteraard bedoel ik typen naar de gebruiker toe. Intern zal er ongetwijfeld wel met typen gewerkt worden, en dat zei ik ook al: onderscheid tussen getallen, vectoren en functies... en dan is een functie niet eens een type (want is de naam van een functie wel een variabele? ligt er natuurlijk aan hoe je dat in je taal definieert)

Maar het is imho onzin om in een wiskundige taal van tevoren aan te geven dat v bijvoorbeeld een vector is, en geen getal. Lijkt me het beste dat dat tijdens de assignment wordt bepaald (de variabele krijgt gewoon het type van de rhs van de = operator)

En onderscheid tussen integers en floating point getallen lijkt me helemaal onzin. Als ik per se een integer van iets wil hebben dan gebruik ik daar wel een functie voor (floor (), ceil (), round ())

Oh een breuk lijkt me trouwens nog wel handig als (interne) type... voor de nauwkeurigheid Aan de andere kant, dan kun je normale getallen ook als breuk behandelen, maar dan met 1 als noemer

offtopic:
DISCLAIMER: de contents van deze post zijn 100% "IMHO" en hoe ik het zou doen

[Verwijderd]

Gestel dat je enkel OO zou werken, dan kan je in principe ook niet meer a*b opnemen in de syntax, dan moet dat al a.multiply(b) worden

of niet?

[.oisyn]

moet jij je eens voorstellen dat je een wiskundige scripttaal voor je neus hebt waar je a.multiply (b) moet doen als je a met b wilt vermenigvuldigen... zou jij het dan gebruiken?

offtopic:
En om een hele offtopic discussie te veroorzaken, waarom zou a * b als een methode van a moeten worden aangeroepen (zoals in C++ het geval is)? Waarom is a 'belangrijker' dan b? Imho is het beter om een statische functie aan te maken die a en b als argumenten heeft . Maar voor sommige operatoren is het wel logisch... alle assignments bijvoorbeeld, en de << en >> bij resp. ostream en istream waar duidelijk is dat het op het object werkt. Maar goed, gelukkig is het in C++ beide mogelijk.

.

[Verwijderd]

idd, ik zou dus echt niet weten hoe ik het moet aanpakken, als je strcit OO werkt heb je de eenvoudige zaken die ingewikkelder worden, maar de gehele opbouw zal logischer zijn, doe je dat niet, dan kunnen bpaalde zelfgedefineerde types worden "verwaarloost" aangezien dat ze niet primitief kunnen worden aanzien, terwijl dit misschien voor de gebruiker types zijn die belangrijker zijn dan een integer

pffff
ik denk dat ik even ga slapen

[Soultaker]

Natuurlijk kun je prima operators gebruiken in een OO-taal. C++ is daar het schoolvoorbeeld van. De compiler vertaalt een infix operator als * gewoon naar een methode met die naam.

Compleet los hiervan, denk ik toch dat een notie van typen voor de gebruiker zinnig is. Aangezien, zoals gezegd, niet alle functies op alle soorten variabelen toepasbaar zijn, is het nuttig om formeel aan te kunnen geven welke domeinen wel en niet toegestaan zijn. Ik denk daarbij aan zoiets:

code:

isPriem(p in N) = ...

Waarbij isPriem alleen toegepast kan worden op positieve gehele getallen. Natuurlijk kun je dit ook gewoon niet doen en het checken laten plaatsvinden in de functie zelf, maar ik vind dit zelf minder mooi, aangezien dit geen uniformiteit biedt en al helemaal geen compile-time safety kan garanderen.

Als het gaat om 'wiskundige programmeertalen' leg ik al snel de link met functionele programmeertalen (die eigenlijk op wiskundige denkwijzen gebaseerd zijn) en die staan er om bekend dat ze zeer strict getypeerd zijn (en er dus geen run-time type mismatch kan voorkomen). Ik denk dat jij echter meer richting iets als Maple zit te denken (wat ook wat meer een scripttaal is) en in dat geval is het introduceren van stricte typen inderdaad wat veel van het goede.

Maar goed, zoals velen al voor mij zeiden: zonder meer concrete informatie over het doel van de taal is het moeilijk om in te schatten wat verstandig is.

[Soultaker]

.oisyn schreef op 19 augustus 2002 @ 03:46:
waarom zou a * b als een methode van a moeten worden aangeroepen (zoals in C++ het geval is)?

In de praktijk blijkt dat dit soort binaire operatoren eigenlijk altijd op twee dezelfde typen werken, dus het maakt dan niet echt uit op welk object de methode wordt aangeroepen (als je het werk door b wilt laten doen, kan a een methode in b aanroepen).

Het is in C++ trouwens prima mogelijk om een methode op b aan te roepen; edit zie onder voor code die WEL klopt .

Maar voor sommige operatoren is het wel logisch... alle assignments bijvoorbeeld, en de << en >> bij resp. ostream en istream waar duidelijk is dat het op het object werkt.

Je zou eventueel nog kunnen bepleiten dat bij het sturen van uitvoer beiden moet kunnen:

code:

  cout << 4;
  4 >> cout;

In het laatse geval werkt de operator >> dus op cout en heeft een int als argument. Dit is in C++ mogelijk maar vooral een aardige gimmick (en dus ook niet in de STL aanwezig). Het nut is nogal beperkt.

Het is niet altijd een voordeel om iets op meerdere manieren te kunnen doen, als de eerste manier al goed genoeg is. Daarbij is het natuurlijk prettig om te weten dat als je '<<' leest, er uitvoer gegenereert wordt, en bij '>>' invoer (ongeacht wat voor streams er feitelijk gebruikt worden).

[Verwijderd]

.oisyn schreef op 19 augustus 2002 @ 03:46:
waarom zou a * b als een methode van a moeten worden aangeroepen (zoals in C++ het geval is)?

Dat is in C++ niet het geval:

code:

S operator * (S const &, S const &);
S & operator *= (S &, S const &);

[.oisyn]

Verwijderd schreef op 19 augustus 2002 @ 04:04:
[...]

Dat is in C++ niet het geval:

code:

S operator * (S const &, S const &);
S & operator *= (S &, S const &);

Maar goed, gelukkig is het in C++ beide mogelijk.

code:

class A
{
public:
    int i;
    A () : i (0) { }
    A (int pI) : i (pI) { }

    A operator * (A a)
    {
        return A (i * a.i);
    }
};



int main ()
{
    A a (4), b (5);
    A c = a * b;

    cout << c.i << endl;

    return 0;
}

het is dus beide mogelijk, wat ik al zei

[.oisyn]

[nohtml]

Soultaker schreef op 19 augustus 2002 @ 04:03:
[...]


In de praktijk blijkt dat dit soort binaire operatoren eigenlijk altijd op twee dezelfde typen werken, dus het maakt dan niet echt uit op welk object de methode wordt aangeroepen (als je het werk door b wilt laten doen, kan a een methode in b aanroepen).

das idd waar, maar als je het vanuit een puur OO standpunt bekijkt dan klopt het eigenlijk niet dat het een methode van a is (okee, je kunt tegen a zeggen dat ie zichzelf moet vermenigvuldigen met b, maar aan de notatie a * b is niet zichtbaar dat je tegen a aan het praten bent, om het zo maar even te noemen )

Het is in C++ trouwens prima mogelijk om een methode op b aan te roepen; edit zie onder voor code die WEL klopt .

uiteraard, en het is ook gewoon mogelijk om een statische operator te definieren die een neutrale positie inneemt (En die verdient dus ook mijn voorkeur)

Je zou eventueel nog kunnen bepleiten dat bij het sturen van uitvoer beiden moet kunnen:

code:

  cout << 4;
  4 >> cout;

In het laatse geval werkt de operator >> dus op cout en heeft een int als argument. Dit is in C++ mogelijk maar vooral een aardige gimmick (en dus ook niet in de STL aanwezig). Het nut is nogal beperkt.

Ja maar dan zit je met het probleem dat de >> operator left-to-right-associative is
Dus dan zit je met het probleem dat 4 >> 5 >> cout wordt geparsed als ((4 >> 5) >> cout), oftewel: 0 >> cout, want 4 >> 5 resulteert in 0

[ Voor 0% gewijzigd door .oisyn op 19-08-2002 04:53 . Reden: haakje vergeten ]

[Alarmnummer]

Verwijderd schreef op 19 augustus 2002 @ 03:39:
Gestel dat je enkel OO zou werken, dan kan je in principe ook niet meer a*b opnemen in de syntax, dan moet dat al a.multiply(b) worden

of niet?

Je zou gerust meerdere notaties mogen hanteren:
5*6
5.multiply(6)
Intern kan je alles behandelen zoals bv de laatste, en de 1e is daarom ook wel een syntactisch suiker. En lees verder mijn eerste reply even ivm typesysteem.

[Macros]

Ik ben halverwege met lezen gestopt omdat ik het a een beetje onzinnige discussie vind en b nogal een domme/vreemde vraag.
Je hebt 2 talen, de taal waarin jij progt om het te maken en de taal waarin de gebruiker progt om wiskundige dingen te doen. Waar jij het in progt is dus totaal niet boeiend voor ons. Lijkt me het beste dat je dat in OO doet. Maakt niet uit met welke datatypes enzo.

De taal waar de gebruiker in progt is wel belangrijk. Je wil een wiskunde scripting taal maken. In alle jaren dat ik wiskunde heb gedaan heb ik nooit de woorden OO zien vallen, dus ik neem aan dat je geen objecten met methodes hoeft te proggen dan.
Over de datatypes. Ik denk dat je hooguit intergers hebt (zonder limiet), breuken (2 integers) en floats (zonder limiet voor getallen die niet als breuk te schrijven zijn). Dan nog een paar cast functies en dat zijn alle datatypes die je nodig hebt.

[Soultaker]

Macros schreef op 19 augustus 2002 @ 11:26:
Over de datatypes. Ik denk dat je hooguit intergers hebt (zonder limiet), breuken (2 integers) en floats (zonder limiet voor getallen die niet als breuk te schrijven zijn). Dan nog een paar cast functies en dat zijn alle datatypes die je nodig hebt.

Ik zou als gebruiker redelijk ongelukkig zijn met deze verdeling, aangezien het dan niet mogelijk is om echt grote getallen nauwkeurig weer te geven, noch getallen met willekeurige precisie op te slaan. Ook wil je in een wiskundige taal (onder andere) met complexe getallen, vectoren, matrices, verzamelingen en functies kunnen rekenen.

Het komt er dus weer op neer dat je verschillende domeinen hebt waaruit je je variabelen wilt kunnen halen. Hoe je ze intern representeert maakt weer weinig uit en aangezien domeinen kunnen overlappen, kan in veel gevallen automatische conversie optreden, maar het onderscheid in typen hou je.

[Soultaker]

.oisyn schreef op 19 augustus 2002 @ 04:52:
uiteraard, en het is ook gewoon mogelijk om een statische operator te definieren die een neutrale positie inneemt (En die verdient dus ook mijn voorkeur)

Ach, het hangt er een beetje vanaf. Als de operator toch op twee operanden van hetzelfde type werkt, mag 'ie van mij in de klasse van dat type gedefinieerd zijn. Ik vind het wel zo netjes als de operators op een bepaalde klasse ook in die klasse gedefinieerd zijn.

Ja maar dan zit je met het probleem dat de >> operator left-to-right-associative is
Dus dan zit je met het probleem dat 4 >> 5 >> cout wordt geparsed als ((4 >> 5) >> cout), oftewel: 0 >> cout, want 4 >> 5 resulteert in 0

Ah, you got me there! Het levert sowieso problemen op als streams zelf ook ingevoerd/uitgevoerd kunnen worden, maar inderdaad, doordat de associativiteit vaststaat is het toch al niet (mooi) mogelijk.

[Ettepet]

Kijk ook eens naar de taal REXX. Een grappig script-taaltje, met wiskundige inslag ("oneindige precisie", enz.), krachtige stringcommando's en helemaal afgestemd om zo gebruikersvriendelijk mogelijk te zijn.. (bijv. geen variabele-declaraties nodig)

Zelf voor het laatst gezien op de Commodore Amiga, onder de naam ARexx.

[Rataplan]

ADD, BRANCH & JUMP

en iets anders kan je pc niet. Het gaat er dus om in hoeverre je het vertalen van generiek wiskundige problemen via dat scripttaaltje naar binaire code faciliteert, en zolang we geen concrete voorbeelden krijgen is het moeilijk om optimalisaties te voorspellen... Ik zou zeggen: niet de taal die je gebruikt, maar de oplossing die je creeert is relevant.

Wil iemand hier eens gaten in schieten? Want ik volg nog steeds voor geen meter waar we hier heengaan.

_{of ben ik nu weer aan het insectenzieken?}

[Alarmnummer]

volgens mij de laatste

[ACM]

Kan zo gauw niet zien of het al gezegd is:
Kijk es naar Matlab, Maple en Splus.

De eerste twee zijn erg krachtige wiskundige rekenpakketten voor zo'n beetje alle wiskundige toepassingen, de laatste is een statistisch rekenpakket.
Alle drie hebben ze een, imho, erg krachtige scripting taal met alledrie leuke trekjes.
Maple staat het bijvoorbeeld toe dat je je functies/whatever opbouwt met wiskundige symbolen (niet echt een taal-feature, meer een pakket-feature) en Splus beschouwt een array net zo makkelijk als een integer, zonder dat je als statisticus daar om hoeft te denken (dus een functie die je op 1 integer/float/whatever toepast kan je ook op een compeet array van duizenden elementen toepassen, zonder dat je moeilijk moet doen met foreach-structuren etc).