Welke programmertaal voor simpele berekeningen?

[kemphaas]

Hoi allemaal, ik had een vraag over het volgende.

Ik zit vaak met mijn grafische rekenmachine (TI 83+) wat te programeren. Vaak gaat het dan om kansberekeningen en kleine simpele berekeningen. Nu wil ik graag op de pc programeren (liefst een taal die erg op BASIC lijkt omdat ik die dan al ken, maar dan iets uitgebreider), maar ik zit te twijfelen tussen Java en C/C++. Ik wil een niet al te moeilijk programma om mee te rekenen, om kleine programmaatjes mee te maken, en die simpele dingen kunnen uitvoeren. Kunnen jullie me helpen te kiezen tussen Java en C/C++?

Ik schat zelf dat het Java wordt, maar misschien dat jullie betere adviezen hebben.

Alvast bedankt.

[ Voor 8% gewijzigd door kemphaas op 07-11-2005 11:18 ]

[SchizoDuckie]

Nou, als je 'simpel' en 'java' in 1 zin noemt denk ik dat je je eerst nog even wat moet gaan inlezen.

Als het je 'eerste' programmeertaal is, is PHP dan niet iets voor je? dan hoef je niet te veel rekening te houden met types checken casten, etc.

[.oisyn]

SchizoDuckie schreef op maandag 07 november 2005 @ 11:15:
Nou, als je 'simpel' en 'java' in 1 zin noemt denk ik dat je je eerst nog even wat moet gaan inlezen.

Een simpele console applicatie in Java is toch niet moeilijk? Geldt eveneens voor C++ overigens.

Ik denk overigens dat het niet echt uitmaakt welke taal je pakt, dat wordt pas interessant als je wat meer wilt doen.

[ Voor 17% gewijzigd door .oisyn op 07-11-2005 11:18 ]

[Cyphax]

SchizoDuckie schreef op maandag 07 november 2005 @ 11:15:
Nou, als je 'simpel' en 'java' in 1 zin noemt denk ik dat je je eerst nog even wat moet gaan inlezen.

Als het je 'eerste' programmeertaal is, is PHP dan niet iets voor je? dan hoef je niet te veel rekening te houden met types checken casten, etc.

Nounounou, dat valt ook wel mee toch... toegegeven: in C/C++ kun je programma'tjes voor wat simpele berekeningen ook simpeler houden. Ik zou dan ook in C aan de slag gaan, maar ik zeg er wel bij: ik weet niet wat je onder "simpele berekeningen" verstaat.

[Boss]

Ik denk dat je meer iets hebt aan Visual Basic of Delphi. PHP is natuurlijk niet echt een programmeertaal en daardoor wel wat lastiger te draaien op je computer. Daarnaast compiled het niet en is debuggen ook niet echt het sterkste punt.

[Tubby]

Mja, simpele berekeningen doen met java/c# klinkt als een mug dood willen krijgen met een sloopkogel.

[kemphaas]

Om dit soort simulaties gaat het vooral, dit soort berekeningen wil ik kunnen nasimuleren.

Birthday Paradox

[Verwijderd]

Als je alleen maar berekingen wilt doen en de resultaten daarvan niet op één of andere manier wilt meenemen in een stukje software (bijvoorbeeld om op basis van de berekeningen apparaten aan te sturen) dan zou ik gewoon MATLAB gebruiken en niet gaan programmeren.

http://www.mathworks.com/products/matlab/

MATLAB is a high-level language and interactive environment that enables
you to perform computationally intensive tasks faster than with traditional programming languages such as C, C++, and Fortran.

[Tukk]

Als je het echt simpel en BASIC wil houden kun je de berekeningen ook maken in VB-Script in een HTML-pagina. Je hebt dan geen compiler nodig en je kan snel aanpassingen uitvoeren.

Wat ook kan is Excel, waarbij wat automatisering uitvoert in VBA.
Je hoeft geen GUI meer te maken, veel berekeningen kun je configuren ipv programmeren.

Het ligt er een beetje aan wat je wil om de moeite te nemen met C++ of Java aan de slag te gaan.

[ Voor 14% gewijzigd door Tukk op 07-11-2005 11:22 ]

[LB Back]

Tubby schreef op maandag 07 november 2005 @ 11:20:
Mja, simpele berekeningen doen met java/c# klinkt als een mug dood willen krijgen met een sloopkogel.

Inderdaad, hoe simpel? Je kunt ook Google gebruiken voor simpele berekeningen.

[kemphaas]

LB Back schreef op maandag 07 november 2005 @ 11:22:
[...]

Inderdaad, hoe simpel? Je kunt ook Google gebruiken voor simpele berekeningen.

Ik kan ook google gebruiken, en ik kan ook wel aantonen dat de kans op kop bij kop-munt 50% is, maar ik moet het kunnen simuleren, dus iets van een progje is dan wel handig, tenzij ik zelf 1000 keer wil gooien

[ Voor 5% gewijzigd door kemphaas op 07-11-2005 11:27 ]

[kemphaas]

Verwijderd schreef op maandag 07 november 2005 @ 11:21:
Als je alleen maar berekingen wilt doen en de resultaten daarvan niet op één of andere manier wilt meenemen in een stukje software (bijvoorbeeld om op basis van de berekeningen apparaten aan te sturen) dan zou ik gewoon MATLAB gebruiken en niet gaan programmeren.

http://www.mathworks.com/products/matlab/


[...]

Dit lijkt idd wel een goed alternatief. lijkt makkelijk te leren, maar is dit ook ergens te downloaden, want kopen zit er niet echt in als ik die prijs zie.

[ Voor 9% gewijzigd door kemphaas op 07-11-2005 11:29 ]

[Icey]

Hierboven word genoemt dat java enorm moeilijk is.. echter het maken van applets etc is vrij makkelijk te doen.

Na een maandje waarbij ik zo'n 4 uurtjes per week bezig was met Java had ik zelf al een applet gemaakt waarmee ik kon 'rock paper scissors'-en tegen 'de computer', die ook wat simpele statistieken bijhield (gemiddelde etc).

kemphaas schreef op maandag 07 november 2005 @ 11:25:
Ik kan ook google gebruiken, en ik kan ook wel aantonen dat de kans op kop bij kop-munt 50% is, maar ik moet het kunnen simuleren, dus iets van een progje is dan wel handig, tenzij ik zelf 1000 keer wil gooien

Dat is in java makkelijk te doen, maar dat zal in iedere programmeer taal wel makkelijk te doen zijn.

Een loopje, een rand, optellen en weer opnieuw beginnen in het looptje totdat je de 1000 bereikt heb.

[ Voor 47% gewijzigd door Icey op 07-11-2005 11:31 ]

[bonzz.netninja]

tja ik zou zoals tukk ook al zegt gewoon lekker exellen. Dit kan echt rete veel als je je erin verdiept

[kemphaas]

bonzz.netninja schreef op maandag 07 november 2005 @ 11:30:
tja ik zou zoals tukk ook al zegt gewoon lekker exellen. Dit kan echt rete veel als je je erin verdiept

Kan dit ook de berekening die ik boven al noemde Birthday Paradox

[bonzz.netninja]

keine anung, ik ben niet zo;n rekenwonder ik verbaas me alleen elke keer over de mogelijkheden van exel

[Tukk]

kemphaas schreef op maandag 07 november 2005 @ 11:32:
[...]


Kan dit ook de berekening die ik boven al noemde Birthday Paradox

Snel kijkend zie ik geen dingen die niet zouden kunnen (is dit jouw idee van simplele berekeningen?)

opmerking zonder bewijs:
Excel staat wel bekend om kleine afrondingsfoutjes die verder mee genomen worden in vervolgende berekeningen, pas hier voor op. Of dit ook nog geld in 2003 of XP weet ik niet.

edit:
Staat hier wat tussen?

[ Voor 22% gewijzigd door Tukk op 07-11-2005 11:39 ]

[Verwijderd]

Jij hebt dit nodig:

http://www.r-project.org/


Gratis, goed, doeltreffend, en niet moeilijk.

[MrSleeves]

Ik zat te denken aan Maple. Maar misschien is dat wat overkill voor wat je wilt.
Toen ik op de TU Delft zat, had ik een goed betaalbare uitvoering (campuslicentie); geen idee wat het normaal kost. Het wordt gemaakt door een universiteit in Canada.

[Bluestorm]

Voor statistieken en simulaties, etc is Matlab denk ik makkelijker dan Maple. Als je echt alleen statistiek wilt doen is S-plus misschien ook nog wel wat. Daar is een gratis demo of onderwijsversie van te downloaden volgens mij. Maar denk niet dat dat echt is wat je wilt.

edit:

Ik zie dat dat R-project ongeveer vergelijkbaar is met S-plus, maar dan opensource.

[ Voor 25% gewijzigd door Bluestorm op 07-11-2005 12:16 ]

[frickY]

Waarom noemt niemand de taal Pascal?

Dat is prima geschikt voo rdergelijke mogelijkheden in een command prompt.

[Bluestorm]

Persoonlijk zou ik liever gaan voor een taal met in iedergeval een command line interpreter, omdat je daar meestal al direct simpele berekeningen op kunt uitvoeren. En je kunt makkelijk experimenteren met functieaanroepen met verschillende parameters, etc.

Matlab heeft dan als bijkomend voordeel dat je van de uitkomsten heel makkelijk grafiekjes kunt maken, etc.

[Verwijderd]

de R code:

code:

N<-10000 # aantal simulaties
pers<-23  #aantal personen

data<-1:365
uit<-0

for (i in 1:N)                             # doe het experiment N maal
{
    trek<-sample(data,pers,replace=TRUE)   # trek 'pers' verjaardagen
    trek1<-outer(trek,trek,"-")-diag(pers) # matrix met alle dagen vergeleken
    if ( any(trek1==0) ) uit=uit+1/N       # check zelfde dag jarig
}
cat (uit)                                  # uitkomst

[leuk_he]

frickY schreef op maandag 07 november 2005 @ 12:34:
Waarom noemt niemand de taal Pascal?

Dat is prima geschikt voo rdergelijke mogelijkheden in een command prompt.

Niks mis mee, maar aangezine de TS zelf al java en C-bla noemt neem ik aan dat hij daar meer mee bekend is. Dus als compileer programma's is hij al voorzien. Kijk, je kunt dit met elke taal programeren als hij maar floating point variabelen ondersteund.


Ook goed om mee te zoeken:

[google=birhtday paradox programming] om implementaties hiervan te vinden in verschillende talen. Valt me op dat ocaml hier vaker bij voor komt.

Verder lijkt het me handig een taal te kiezen die vaker nodig zult hebben en waar je om hulp kunt vragen met je mede studenten/leerlingen. Overigens bestaat [ulr=http://en.wikipedia.org/wiki/BASIC_programming_language]Basic ook nog gewoon hoor[/url]

[kemphaas]

Verwijderd schreef op maandag 07 november 2005 @ 13:02:
de R code:

code:

N<-10000 # aantal simulaties
pers<-23  #aantal personen

data<-1:365
uit<-0

for (i in 1:N)                             # doe het experiment N maal
{
    trek<-sample(data,pers,replace=TRUE)   # trek 'pers' verjaardagen
    trek1<-outer(trek,trek,"-")-diag(pers) # matrix met alle dagen vergeleken
    if ( any(trek1==0) ) uit=uit+1/N       # check zelfde dag jarig
}
cat (uit)                                  # uitkomst

Bedankt voor de code, maar welke taal is het en in welk programma kan ik het invoeren en uit laten voeren?

[Verwijderd]

Mijn eerdere post en bovenstaande code horen bij elkaar.

Verwijderd schreef op maandag 07 november 2005 @ 11:42:
Jij hebt dit nodig:

http://www.r-project.org/


Gratis, goed, doeltreffend, en niet moeilijk.

[ Voor 14% gewijzigd door Verwijderd op 07-11-2005 13:55 ]

[curry684]

Tubby schreef op maandag 07 november 2005 @ 11:20:
Mja, simpele berekeningen doen met java/c# klinkt als een mug dood willen krijgen met een sloopkogel.

Hoezo dat? Een simpele berekening voor de statistiek 1 miljoen keer uitvoeren zal in C/C++ merkbaar sneller gaan dan in VB6. Your point being?

[kemphaas]

Verwijderd schreef op maandag 07 november 2005 @ 13:50:
Mijn eerdere post en bovenstaande code horen bij elkaar.


[...]

Sorry, niet echt goed opgelet. Ben nu nog op school, maar als ik straks thuis ben installeer ik het meteen en voer ik de code in. Alvast bedankt.

[curry684]

Hier heb je de C++ versie:

C++:

#include <iostream>
#include <time.h>
using namespace std;

// Constants for use in the application
const int   c_Iterations    = 10000;
const int   c_GroupSize = 23;
const int   c_DaysInYear    = 365;

// main: Entry point for the application
int main()
{
    int             l_Group[c_GroupSize];
    int             l_Clashes = 0;
    int             l_Index;
    int             l_SubIndex;
    int             l_Iteration;
    
    // Randomize
    srand((unsigned int)time(NULL));
        
    // Repeat for all iterations
    for(l_Iteration = 0; l_Iteration != c_Iterations; l_Iteration++)
    {
        // Fill group with random birthdays
        for(l_Index = 0; l_Index != c_GroupSize; l_Index++)
            l_Group[l_Index] = (rand() * c_DaysInYear) / RAND_MAX;

        // Check for collisions
        for(l_Index = 0; l_Index < c_GroupSize; l_Index++)
            for(l_SubIndex = l_Index + 1; l_SubIndex < c_GroupSize; l_SubIndex++)
                if(l_Group[l_Index] == l_Group[l_SubIndex])
                {
                    l_Clashes++;
                    l_Index = c_GroupSize;
                    break;
                }
    }
    
    // Output results
    cout << "Clashes: " << l_Clashes << endl;
    cout << "Hit %  : " << (double)l_Clashes * 100 / c_Iterations << endl;
    cin.get();
    return 0;
}

Kun je zelf kijken of je het te moeilijk vind C# en Java zijn een tikkie simpeler.

[ Voor 3% gewijzigd door curry684 op 07-11-2005 14:15 . Reden: vector was wat overkill... ]

[kemphaas]

curry684 schreef op maandag 07 november 2005 @ 14:07:
Hier heb je de C++ versie:

C++:

#include <iostream>
#include <time.h>
using namespace std;

// Constants for use in the application
const int   c_Iterations    = 10000;
const int   c_GroupSize     = 23;
const int   c_DaysInYear    = 365;

// main: Entry point for the application
int main()
{
    int             l_Group[c_GroupSize];
    int             l_Clashes = 0;
    int             l_Index;
    int             l_SubIndex;
    int             l_Iteration;
    
    // Randomize
    srand((unsigned int)time(NULL));
        
    // Repeat for all iterations
    for(l_Iteration = 0; l_Iteration != c_Iterations; l_Iteration++)
    {
        // Fill group with random birthdays
        for(l_Index = 0; l_Index != c_GroupSize; l_Index++)
            l_Group[l_Index] = (rand() * c_DaysInYear) / RAND_MAX;

        // Check for collisions
        for(l_Index = 0; l_Index < c_GroupSize; l_Index++)
            for(l_SubIndex = l_Index + 1; l_SubIndex < c_GroupSize; l_SubIndex++)
                if(l_Group[l_Index] == l_Group[l_SubIndex])
                {
                    l_Clashes++;
                    l_Index = c_GroupSize;
                    break;
                }
    }
    
    // Output results
    cout << "Clashes: " << l_Clashes << endl;
    cout << "Hit %  : " << (double)l_Clashes * 100 / c_Iterations << endl;
    cin.get();
    return 0;
}

Kun je zelf kijken of je het te moeilijk vind C# en Java zijn een tikkie simpeler.

Dankje, ik zal het eens invoeren in een C++ progje en kijken.

[Exirion]

kemphaas schreef op maandag 07 november 2005 @ 14:15:
Dankje, ik zal het eens invoeren in een C++ progje en kijken.

[kemphaas]

Exirion schreef op maandag 07 november 2005 @ 14:20:
[...]

Weet ik hoe je zo'n ding noemt. Iets wat ervoor zorgt dat de code ook echt een programma wordt.

[Exirion]

kemphaas schreef op maandag 07 november 2005 @ 14:23:
Weet ik hoe je zo'n ding noemt. Iets wat ervoor zorgt dat de code ook echt een programma wordt.

Een compiler

Waarom koop je niet gewoon een simpel boek over programmeren. Leer je wellicht meteen iets over verschillende talen, iets over compilers, assemblers, over interpreters en virtual machines e.d.

Altijd goed om met een goeie basis te beginnen.

[kemphaas]

Exirion schreef op maandag 07 november 2005 @ 14:24:
[...]

Een compiler

Waarom koop je niet gewoon een simpel boek over programmeren. Leer je wellicht meteen iets over verschillende talen, iets over compilers, assemblers, over interpreters en virtual machines e.d.

Altijd goed om met een goeie basis te beginnen.

Is idd wel een goed idee, ik wil sowieso wel meer erover leren, dus misschien is een boek erover niet zo'n slecht idee.

[Verwijderd]

kemphaas schreef op maandag 07 november 2005 @ 13:49:
[...]


Bedankt voor de code, maar welke taal is het en in welk programma kan ik het invoeren en uit laten voeren?

Dat is nu R (www.r-project.com) is hier boven ook al genoemd

[Supersheep40]

Als je vooral berekeningen wilt doen is een functionele taal als haskell misschien wel handiger dan een imperatieve taal zoals java en C. Zie bijv: http://www.haskell.org/

[kemphaas]

curry684 schreef op maandag 07 november 2005 @ 14:07:
Hier heb je de C++ versie:

C++:

#include <iostream>
#include <time.h>
using namespace std;

// Constants for use in the application
const int   c_Iterations    = 10000;
const int   c_GroupSize = 23;
const int   c_DaysInYear    = 365;

// main: Entry point for the application
int main()
{
    int             l_Group[c_GroupSize];
    int             l_Clashes = 0;
    int             l_Index;
    int             l_SubIndex;
    int             l_Iteration;
    
    // Randomize
    srand((unsigned int)time(NULL));
        
    // Repeat for all iterations
    for(l_Iteration = 0; l_Iteration != c_Iterations; l_Iteration++)
    {
        // Fill group with random birthdays
        for(l_Index = 0; l_Index != c_GroupSize; l_Index++)
            l_Group[l_Index] = (rand() * c_DaysInYear) / RAND_MAX;

        // Check for collisions
        for(l_Index = 0; l_Index < c_GroupSize; l_Index++)
            for(l_SubIndex = l_Index + 1; l_SubIndex < c_GroupSize; l_SubIndex++)
                if(l_Group[l_Index] == l_Group[l_SubIndex])
                {
                    l_Clashes++;
                    l_Index = c_GroupSize;
                    break;
                }
    }
    
    // Output results
    cout << "Clashes: " << l_Clashes << endl;
    cout << "Hit %  : " << (double)l_Clashes * 100 / c_Iterations << endl;
    cin.get();
    return 0;
}

Kun je zelf kijken of je het te moeilijk vind C# en Java zijn een tikkie simpeler.

Heb m ingevoerd in CodeBlocks en er komt idd steeds ongeveer 50% uit. Helemnaal top man, bedankt.

[Verwijderd]

De vraag is nu natuurlijk, snap je wat er precies gebeurt? Wat doen bijvoorbeeld al die {} in het programma, en wat doen die srand, time, rand... wat doet return?

Dit soort dingen zijn moeilijk te begrijpen als je er meteen zo ver in duikt. Ik zou beginnen met een tutorial van "Hoe laat ik mijn programma 'Hello World' zeggen?" In boekvorm is wel aan te raden, maar via internet kan ook.

[ Voor 11% gewijzigd door Verwijderd op 07-11-2005 15:37 ]

[kemphaas]

Verwijderd schreef op maandag 07 november 2005 @ 13:02:
de R code:

code:

N<-10000 # aantal simulaties
pers<-23  #aantal personen

data<-1:365
uit<-0

for (i in 1:N)                             # doe het experiment N maal
{
    trek<-sample(data,pers,replace=TRUE)   # trek 'pers' verjaardagen
    trek1<-outer(trek,trek,"-")-diag(pers) # matrix met alle dagen vergeleken
    if ( any(trek1==0) ) uit=uit+1/N       # check zelfde dag jarig
}
cat (uit)                                  # uitkomst

Vraagje, als ik de code heb ingevuld, hoe compile ik het geheel dan? Er zit niks van een knop van compile of finish ofzo bij.

[kemphaas]

Verwijderd schreef op maandag 07 november 2005 @ 15:36:
De vraag is nu natuurlijk, snap je wat er precies gebeurt? Wat doen bijvoorbeeld al die {} in het programma, en wat doen die srand, time, rand... wat doet return?

Dit soort dingen zijn moeilijk te begrijpen als je er meteen zo ver in duikt. Ik zou beginnen met een tutorial van "Hoe laat ik mijn programma 'Hello World' zeggen?" In boekvorm is wel aan te raden, maar via internet kan ook.

Heb op mijn rekenmachine veel geprogrammeerd dus kan wel een beetje overweg met zoiets. Het is makkelijker als je het ziet dan het zelf te maken.

[Exirion]

kemphaas schreef op maandag 07 november 2005 @ 15:47:
Het is makkelijker als je het ziet dan het zelf te maken.

Daarom leer je er zo ook niks van. Stel simpele doelen en ga steeds een stukje verder. Van klakkeloos kopieren is nog nooit iemand wijzer geworden.

[kemphaas]

Exirion schreef op maandag 07 november 2005 @ 15:48:
[...]

Daarom leer je er zo ook niks van. Stel simpele doelen en ga steeds een stukje verder. Van klakkeloos kopieren is nog nooit iemand wijzer geworden.

Weet ik, maar daarom moest ik eerst weten welke taal ik beter wil gaan leren, en nu ik heb gezien dat het werkt, wil ik er meer van weten en het zelf gaan leren.

[curry684]

Exirion schreef op maandag 07 november 2005 @ 15:48:
[...]

Daarom leer je er zo ook niks van. Stel simpele doelen en ga steeds een stukje verder. Van klakkeloos kopieren is nog nooit iemand wijzer geworden.

Ik geef normaal ook geen kant-en-klare code Maar in dit geval maak ik een uitzondering, omdat ie met een concrete vraag kwam en het in een paar regels goed illustreert of je de syntax kunt behappen. Of ie op basis hiervan nu wel of niet besluit met C++ verder te gaan is secundair, en op dat moment zal ie alsnog een boek moeten kopen. Deze code is illustratief, geen tutorial

[Verwijderd]

kemphaas schreef op maandag 07 november 2005 @ 15:36:
[...]


Vraagje, als ik de code heb ingevuld, hoe compile ik het geheel dan? Er zit niks van een knop van compile of finish ofzo bij.

Start R
->File -> New script
copy past het script in je scriptwindow.
selecteer het
klik de button Run Line or selection (3 icoon, naast save)
en zie de output in de console.

Hoe nou uit te maken wat er gebeurt?

Haal de for loop weg (inclusief {}) en run het script nog een keer
typ nu de namen in van de variabelen (trek, trek1) etc om te zien wat daar in staat. Zoek in de manual van R op wat de bepaalde functies doen: typ ?naam, bv ?any

Je krijgt dan uitleg wat er gebeurt.

[Verwijderd]

Als je sommen wil invoeren, deze parsen en uitrekenen, daarbij gelet op haakjes, MVDWOA enz. dan zou ik kiezen voor C++. Met het uitlezen van leestekens en operators (+,-,*,enz.) kun je deze op de geheugenstack pushen en er weer op het juiste moment af poppen. Met C++ heb je goed beheer over je geheugen zodat het niet in no-time vol loopt. Bij Java hoef je er niet op te letten en is het veel makkelijker, maar java is meer bedoelt om overzicht te houden in complexe bedrijfssystemen en niet voor wat dingetjes in en uit het geheugen te poppen om zo efficiënt mogelijk te rekenen. In Java kost het je simpelweg meer recourses en hou je minder invloed op dergelijke basale dingen zoals geheugenbeheer. Wat code betreft is het in Java waarschijnlijk simpeler.

Haskell is ook al gezegd. Persoonlijk zou ik voor Clean kiezen. Syntactisch bijna hetzelfde maar eigenlijk toch veel eliganter en het compiled efficienter. Door de handige recursie (wat veel slimmer wordt gecompiled dan in C++) kun je hele krachtige maar ogenschijnlijk simpele dingen doen. Maar om één of andere reden denk ik toch niet dat je daar naar op zoek bent. Pak gewoon C++, of Java. Java is wel iets makkelijker om te leren. Alles wat niet perse hoeft, kan simpelweg niet. En toch kun je er uiteindelijk precies hetzelfde mee bereiken als met C++.

Ga er verder maar van uit dat je in elke programmeertaal vrij snel simpele berekeningen kunt laten uitvoeren. Zou anders geen goede programmeertaal zijn

[ Voor 9% gewijzigd door Verwijderd op 07-11-2005 16:55 ]

[Tomatoman]

curry684 schreef op maandag 07 november 2005 @ 14:07:
Hier heb je de C++ versie:
[...]
Kun je zelf kijken of je het te moeilijk vind C# en Java zijn een tikkie simpeler.

Ter vergelijking heb ik dit voorbeeld even omgeschreven naar Delphi. Je zou deze code eigenlijk zonder meer in iedere andere Pascalcompiler kunnen gebruiken. Het is aardig om de C++ versie en de Delphiversie te vergelijken. Afgezien van het feit dat ik de iteratie in een aparte procedure heb gezet (dat werkt in dit geval wat handiger in Delphi) is de code vrijwel exact gelijk. De syntaxis is anders, maar de constantes, variabelen en alle programmastappen zijn gelijk. In C++ is de code wat compacter, in Delphi is de code wat gemakkelijker leesbaar. Qua performance zal er geen meetbaar verschil zijn.

Delphi:

program BirthdayParadox;

{$APPTYPE CONSOLE}

// Global constants and variables for use in the application
const
  Iterations = 10000;
  GroupSize = 23;
  DaysInYear = 365;
var
  Group: array[1..GroupSize] of Integer;
  Clashes: Integer = 0;
  Iteration: Integer;

// IterateOnce is called once for every iteration
procedure IterateOnce;
var
  Index, SubIndex: Integer;
begin
  // Fill group with random birthdays
  for Index := 1 to GroupSize do
    Group[Index] := Random(DaysInYear);

  // Check for collisions
  for Index := 1 to GroupSize do
    for SubIndex := Index + 1 to GroupSize do
      if Group[Index] = Group[SubIndex] then
      begin
        Clashes := Clashes + 1;
        Exit;
      end;
end;

// Entry point for the application
begin
  Randomize;

  // Repeat for all iterations
  for Iteration := 1 to Iterations do
    IterateOnce;

  // Output results
  WriteLn('Clashes: ', Clashes);
  WriteLn('Hit %: ', Clashes * 100 div Iterations);
  ReadLn;
end.

[ Voor 17% gewijzigd door Tomatoman op 07-11-2005 17:13 ]

[EXX]

Niet lachen, maar voor simpele progsels gebruik ik nog steeds Turbo Pascal V3.0. Ja, dat is DOS en ja, geen IDE of GUI. Maar wel supereenvoudig. Alles-in-een: geen installatie en includen/linken van allerlei libraries. Progseltje maken, compileren en runnen.

Je moet voor de editor alleen nog de Wordstar commands in je hoofd hebben

[Tomatoman]

EXX schreef op maandag 07 november 2005 @ 17:09:
Niet lachen, maar voor simpele progsels gebruik ik nog steeds Turbo Pascal V3.0. Ja, dat is DOS en ja, geen IDE of GUI. Maar wel supereenvoudig. Alles-in-een: geen installatie en includen/linken van allerlei libraries. Progseltje maken, compileren en runnen.

Kijk even naar de code hier direct boven. Waarschijnlijk kun je dat met Turbo Pascal compileren. Het enige verschil is dat Turbo Pascal een 16-bits DOS-applicatie oplevert, terwijl Delphi een 32-bits Windowsapplicatie bouwt (het is een console-applicatie, maar zeker geen DOS). Bestandsgrootte: 16.384 bytes.

[Verwijderd]

Ik geloof dat R toch de meest simpele code heeft voor de birthday paradox. (zie boven)

Ik gebruik 9 regels, die ik zou kunnen terugbrengen naar 6 statements.

Zowel de c++ als de Delphi versie zien er toch een stuk complexer uit. Uiteraard zijn die talen sneller als het gaat om zeer grote datasets, of miljarden berekeningen, maar de taal R is precies geschreven om dit soort dingen te doen op een simpele manier.

[EXX]

tomatoman schreef op maandag 07 november 2005 @ 17:19:
[...]
Kijk even naar de code hier direct boven. Waarschijnlijk kun je dat met Turbo Pascal compileren. Het enige verschil is dat Turbo Pascal een 16-bits DOS-applicatie oplevert, terwijl Delphi een 32-bits Windowsapplicatie bouwt (het is een console-applicatie, maar zeker geen DOS). Bestandsgrootte: 16.384 bytes.

Na wat kleine wijzigingen loopt het idd ook met Turbo Pascal 3.0. Als je compileert naar een executable krijg je overigens een .COM file van 11,754 bytes.

[Tomatoman]

Verwijderd schreef op maandag 07 november 2005 @ 17:43:
Ik geloof dat R toch de meest simpele code heeft voor de birthday paradox. (zie boven)

Ik gebruik 9 regels, die ik zou kunnen terugbrengen naar 6 statements.

Zowel de c++ als de Delphi versie zien er toch een stuk complexer uit. Uiteraard zijn die talen sneller als het gaat om zeer grote datasets, of miljarden berekeningen, maar de taal R is precies geschreven om dit soort dingen te doen op een simpele manier.

Het aantal regels code is niet maatgevend. Vaak is het duidelijker als je wat meer regels gebruikt. Dat neemt niet weg dat jouw code in R er interessant uitziet. Ik neem graag van je aan dat R in dit geval een uitstekende taalkeuze is. De hoeveelheid rekenwerk is voor een moderne processor peanuts, zelfs een scripttaal zou hier geen problemen mee mogen hebben. Het grote nadeel dat R mijns inziens heeft, is dat het een nogal obscuur bestaan leidt. Ik denk niet dat er veel gebruikers in dit forum zijn die er ooit van hebben gehoord. Daarom: vooral geschikt voor gevorderde programmeurs.

offtopic:
Jouw programmeervoorbeeld lijkt me geen compleet programma. Ik zie nergens output naar het scherm gaan. Het complete programma zal daarom een paar regels langer zijn.

Nu we toch bezig zijn: is er misschien iemand die het programmeervoorbeeld zou willen omzetten naar Java, Visual Basic, C# of Cobol? Dan hebben we de meestgebruikte oude en nieuwe programmeertalen naast elkaar staan. Lijkt me wel interessant, vooral omdat het hier om een real-life voorbeeld gaat.

[Verwijderd]

Ik vind de totale code-war weinig toegevoegde waarde hebben. Ik blijf er bij dat Java en C++ de beste opties zijn. Simpelweg om dezelfde reden dat MS Windows het beste OS is om mee te beginnen. Je bent ermee compatible en je hebt misschien niet het beste, maar wel het meest toepasbare geleerd.

[Tomatoman]

Code war? Er zijn hier in totaal 3 versies gepost, waarvan 2 in gangbare programmeertalen (C++ en Pascal/Delphi) en 1 in een taal die specifiek voor dit soort toepassingen is ontwikkeld (R). Omdat R zo specifiek is, laat ik die taal in het vervolg buiten beschouwing.

De bottom line is dat je het voorbeeldprobleem van de topicstarter met zeer weinig moeite en programmeerkennis kunt omzetten in een werkend programmaatje. Het gaat er niet om welke taal de beste is, het gaat er juist om dat in dit geval iedere genoemde taal geschikt is. De syntaxis verschilt, maar verder lijkt het allemaal ontzettend veel op elkaar.

[Confusion]

curry684 schreef op maandag 07 november 2005 @ 13:51:
Hoezo dat? Een simpele berekening voor de statistiek 1 miljoen keer uitvoeren zal in C/C++ merkbaar sneller gaan dan in VB6. Your point being?

Worden de allersimpelste operaties in alle talen niet naar precies dezelfde machinecode geoptimaliseerd? Ik zou het niet vreemd vinden als een miljoen optellingen, afgezien van de overhead, in bijvoorbeeld Python niet meer tijd kost dan in C?

[synthesix]

Je zou ook eens python kunnen proberen, dat is echt een super makkelijke taal vooral als je al wat programmeer ervaring hebt (tibasic toch?), het is overigens wel een interpreter taal, maar je akn het wel compilen tot een aantal uitvoerbaar bestanden en (dll's geloof ik ).

Het is iig veel en veel en veel makkelijker dan c of java, geen belachelijke verklaringen en includes en andere bullshit aan het begin van je file enzo... Ik had na 2 uurtje leren al een command line hoger lager spelletje gemaakt.

[kemphaas]

Ik heb R en C++ eens ingevoerd en vergeleken. R ziet er duidelijk makkelijker uit dan C++, maar om 1 miljoen simulaties te doen had R 4 minuten en 33 seconden nodig, en C++ had hiervoor maar 5 seconden nodig. Hier zit dus echt wel wat verschil in, maar de 50% klopt iig.

[chris]

Als je een taal wil met een (relatief) simpele syntax, kan je ook eens naar Ruby kijken. Het werkt heel simpel: je typt je code in, je dubbelklikt op het bestand en het wordt uitgevoerd. Je kan het installeren met de One-click Ruby Installer.

En er is ook een erg goed, gratis boek beschikbaar: Programming Ruby. Je kan dan altijd overstappen naar talen als Java/C++/C#/C enz. Je kan in principe met alles wel beginnen: met Ruby zul je sneller hele programma's kunnen schrijven, maar als je later voor snelheid wil gaan moet je vaak in b.v. c++ gaan schrijven, dan wordt er stukken meer van je verwacht als programmeur (lees: het is (meestal) een stuk moeilijker), maar je krijgt er wel een enorme performancewinst voor terug. Als je juist begint te leren in C++ leer je een stuk beter wat er allemaal bij programmeren komt kijken, schrijf je snellere programma's, maar ik denk dat het (in het begin) iets langer zal duren voordat je een programma zal maken.

Maar dus, Ruby!

[Tomatoman]

In Delphi kom ik op 650 milliseconden voor 1 miljoen simulaties (P4 3,0 GHz). Vreemd, ik had verwacht dat C++ ongeveer even snel zou zijn.

[Verwijderd]

Zoiets kan natuurlijk ook aan je pc liggen, of je compiler (er zijn verschillen tussen verschillende () c++ compilers), het hoeft niet perse de taal te zijn. Hoe heb je trouwens zo precies gemeten hoe lang het duurt?

[ Voor 17% gewijzigd door Verwijderd op 07-11-2005 20:21 ]

[Tomatoman]

Simpel, met GetTickCount. Dat is het aantal milliseconden dat is verstreken sinds de computer startte.

Delphi:

uses
  Windows;

...

var
  Time: LongWord;

// Entry point for the application
begin
  Randomize;

  Time := GetTickCount;

  // Repeat for all iterations
  for Iteration := 1 to Iterations do
    IterateOnce;

  Time := GetTickCount - Time;

  // Output results
  WriteLn('Clashes: ', Clashes);
  WriteLn('Hit %: ', Clashes * 100 div Iterations);
  WriteLn(Iterations, ' iterations performed in ', Time, ' ms');
  ReadLn;
end.

Maar we gaan nu wel erg off-topic.

[ Voor 28% gewijzigd door Tomatoman op 08-11-2005 23:23 ]

[blizt]

* blizt heeft de code van curry naar java omgeprutst:

Java:

import java.util.Random;

public class birthdayParadox
{
    //Constants for use in the application
    public static int c_Iterations = 10000;
    public static int c_GroupSize = 23;
    public static int c_DaysInYear = 365;

    public static void main(String[] args)
    {
        int[] l_Group = new int[c_GroupSize];
        int l_Clashes = 0;
        int l_Index;
        int l_SubIndex;
        int l_Iteration;

        // Randomize
        Random generator = new Random();

        // Repeat for all iterations
        for (l_Iteration = 0; l_Iteration != c_Iterations; l_Iteration++)
        {
            // Fill group with random birthdays
            for (l_Index = 0; l_Index != c_GroupSize; l_Index++)
            {
                l_Group[l_Index] = (generator.nextInt(c_DaysInYear));
            }

            // Check for collisions
            for (l_Index = 0; l_Index < c_GroupSize; l_Index++)
            {
                for (l_SubIndex = l_Index + 1; l_SubIndex < c_GroupSize;
                                  l_SubIndex++)
                {
                    if (l_Group[l_Index] == l_Group[l_SubIndex])
                    {
                        l_Clashes++;
                        l_Index = c_GroupSize;
                        break;
                    }
                }
            }
        }
        // Output results
        System.out.println("Clashes: " + l_Clashes);
        System.out.println("Hit %  : " +
                           (double) l_Clashes * 100 / c_Iterations);
    }
}

In JBuilder gecompiled, gaf dit onder andere deze resultaten:

Clashes: 5156

Hit % : 51.56

---

Clashes: 5055

Hit % : 50.55

---

Clashes: 5046

Hit % : 50.46

---

Clashes: 5091

Hit % : 50.91

edit:

Benchmark gaf tussen de 50 en 100 ms aan.

[ Voor 3% gewijzigd door blizt op 07-11-2005 21:57 . Reden: Informatie van benchmark toegevoegd. ]

[curry684]

kemphaas schreef op maandag 07 november 2005 @ 19:53:
Ik heb R en C++ eens ingevoerd en vergeleken. R ziet er duidelijk makkelijker uit dan C++, maar om 1 miljoen simulaties te doen had R 4 minuten en 33 seconden nodig, en C++ had hiervoor maar 5 seconden nodig. Hier zit dus echt wel wat verschil in, maar de 50% klopt iig.

Dan had je een debugbuild voor C++

Ik zie overigens geen codewar hier, ik vind het eigenlijk wel een keer leuk en informatief om hetzelfde probleem in tig talen op te lossen Mooiere illustratie van de verschillen tussen de talen kun je toch niet geven Je kunt in dit geval duidelijk zien dat de voor dit doel gespecialiseerde taal R ruimschoots de kortste en helderste code geeft, wat ook wel schand zou zijn als het niet zo was.

In debugbuild doet mijn Pentium-M 1.86Ghz over 10 miljoen iteraties overigens 12.5 seconde, tegenover 9 seconden in release. Scheelt relatief weinig in dit geval.

Men vroeg btw de C# versie:

C#:

using System;

namespace ConsoleTestCsharp
{

    /// <summary>
    /// Summary description for Class1.
    /// </summary>
    class main
    {
        // Constants for use in the application
        private const int    c_Iterations   = 10000000;
        private const int    c_GroupSize    = 23;
        private const int    c_DaysInYear   = 365;
            
        /// <summary>
        /// The main entry point for the application.
        /// </summary>
        [STAThread]
        static void Main(string[] args)
        {
            DateTime    l_Time      = DateTime.Now;
            Random      l_Random    = new Random();
            int[]       l_Group     = new int[c_GroupSize];
            int         l_Clashes   = 0;
            int         l_Index;
            int         l_SubIndex;
            int         l_Iteration;
            
            // Repeat for all iterations
            for(l_Iteration = 0; l_Iteration != c_Iterations; l_Iteration++)
            {
                // Fill group with random birthdays
                for(l_Index = 0; l_Index != c_GroupSize; l_Index++)
                    l_Group[l_Index] = l_Random.Next(c_DaysInYear);

                // Check for collisions
                for(l_Index = 0; l_Index < c_GroupSize; l_Index++)
                    for(l_SubIndex = l_Index + 1; l_SubIndex < c_GroupSize; l_SubIndex++)
                        if(l_Group[l_Index] == l_Group[l_SubIndex])
                        {
                            l_Clashes++;
                            l_Index = c_GroupSize;
                            break;
                        }
            }
            
            // Output results
            Console.WriteLine("Clashes : {0}", l_Clashes);
            Console.WriteLine("Hit %   : {0}", l_Clashes * 100 / c_Iterations);
            Console.WriteLine("Time    : {0}", DateTime.Now - l_Time);
            Console.ReadLine();
        }
    }
}

23.5 seconde En zoals je ziet vrijwel identiek aan de Java versie hierboven.

[ Voor 62% gewijzigd door curry684 op 07-11-2005 23:27 ]

[T-MOB]

Voor simulaties zou ik eigenlijk eerder een scripttaal pakken dan een compilerende taal. Dat is dan wel trager bij het uitvoeren van de code, maar het scheelt je de tijd van het compileren bij een kleine verandering. En dat is volgens mij dan weer de lol van het draaien van simulaties: kijken wat voor invloed het veranderen van een simpele parameter op het geheel heeft in een situatie waar je het lastiger kunt beredeneren/voorstellen.

Anyway, voor het vergelijk in PHP:

PHP:

<?php

function getmicrotime() {
    list($usec, $sec) = explode(" ", microtime());
    return ((float)$usec + (float)$sec);
}

// Start benchmark
$start = getmicrotime();

// Constants for use in the application
$c_Iterations = 10000;
$c_GroupSize  = 23;
$c_DaysInYear = 365;

// Clash counter
$clashes = 0;

// Repeat for all iterations
for($i=0; $i != $c_Iterations; $i++) {

    $a_Group = array();

    // Fill group with birthdays until a duplicate birthday is found
    for($j=0; $j != $c_GroupSize; $j++) {

        $birthday = rand(1,$c_DaysInYear);

        // Collision check
        if (!in_array($birthday, $a_Group)) {

            $a_Group[] = $birthday;

        } else {
            $clashes++;
            break;
        }
    }
}

// Benchmark time
$timePassed = getmicrotime() - $start;


// Output results
echo 'Clashes: ' .$clashes ."\n";
echo 'Hit %  : ' .$clashes * 100 / $c_Iterations ."\n";
echo 'Time   : ' .$timePassed .'s' ."\n";
?>

Bevat een optimalisatie door tijdens het vullen van de groep al te checken of de verjaardag bestaat. Dat scheelt de helft in executietijd ten opzichte van het eerder geposte algorithme in C++ maar zorgt nog altijd voor ~2.3s op een PIII 800 bij 10.000 iteraties.

[blizt]

Heb jij meer geluk dan ik T-mob, had ook al wat in PHP geschreven, maar dat liep vast (Debug gestart in Zend). Hoewel ik moet toegeven, dat ie het later wel deed, maar een stuk trager (op een Athlon XP 2400+, net als de Java-app).
Wat je zegt van parameters veranderen, kun je natuurlijk oplossen met 'n simpel inputdingetje lijkt me? Sowieso, als je een IDE hebt die de output gelijk laat zien na het compilen .. en de compiletijd is lager dan de executiontijd van je PHPscript ... ben je alsnog sneller uit toch?

[Verwijderd]

*programeer beginner

Ik zit op het mbo ICT niv.3
Naast HTML leer ik nu Javascript
Is dit nou een taal waar je wat mee kan, want zoals mij wordt vertelt schijnt het erg goed te zijn voor kleine berekeningen.
Ik heb nog nergens java script zien langskomen.
Ik zie wel vaak Java voor bijkomen, maar neem aan dat jullie echt JAVA bedoelen en niet Java sc. wat als ik het goed begrijpt iets heel anders is

[ Voor 10% gewijzigd door Verwijderd op 08-11-2005 01:06 ]

[curry684]

Javascript heet Javascript omdat men Java wel een catchy naam vond indertijd. Er is geen verdere relatie: leesvoer.

Javascript wordt met name clientside in webbrowsers gebruikt, en is als zodanig niet echt geschikt als standalone programmeertaal: je hebt er vrijwel altijd een serverside component als PHP of ASP.NET bij nodig.

Dat wil niet zeggen dat het geen krachtige taal is overigens, onze eigen crisp wordt wereldwijd als Javascript-god gezien wegens het implementeren van Lemmings in Javascript: klik

[T-MOB]

Verwijderd schreef op dinsdag 08 november 2005 @ 01:05:
Naast HTML leer ik nu Javascript
Is dit nou een taal waar je wat mee kan, want zoals mij wordt vertelt schijnt het erg goed te zijn voor kleine berekeningen.

In principe kun je een hele boel met javascript oplossen. Het is echter ontwikkeld voor het gebruik in websites. Vergeleken met een echte programmeertaal ben je daardoor beperkt in de mogelijkheden. Bovendien is het niet erg snel als het gaat om heel veel kleine berekeningen zoals in dit topic. Het ligt dus niet erg voor de hand om javascript te kiezen om de birthday paradox te simuleren. Daar zijn betere middelen voor voorhanden.

Ik heb nog nergens java script zien langskomen.

Naast het feit dat JS niet erg geschikt is voor het oplossen voor het probleem valt de taal onder de client-side scriptingtalen. Die vallen onder het Webdesign en Graphics forum en zul je dus niet tegenkomen in Programming en Webscripting (dat is althans de bedoeling). Maar aangezien je javascript aan het leren bent, waarom probeer je niet zelf het algorithme in JS te implementeren? Als je de code in deze post bestudeerd dan heb je als het goed is al een redelijke aanwijzing hoe het zou kunnen. Let wel op dat je niet gelijk met 10.000 herhalingen begint, dat zou wel eens erg lang kunnen duren...

[Verwijderd]

nou voor de grap dan ook nog maar de Fortran versie.

code:

    program birthday

    implicit none


    integer::sim=1000000
    integer,parameter::pers=23

    real,dimension(pers)::dag
    real,dimension(pers,pers)::help,help1

    integer::i
    real::uit


    do i=1,pers
        help1(i,i)=1
    enddo

    do i=1,sim
        call random_number (dag)
        help=spread(int(dag*365+1),dim=2,ncopies=size(dag))-spread(int(dag*365+1),dim=1,ncopies=size(dag))-help1
        if (ANY(help .eq. 0)) uit=uit+1/real(sim)
    enddo

    write (*,*) uit
    read (*,*)
  
    end program birthday

6 sec op een 1700 MHz Athlon

[Verwijderd]

tomatoman schreef op maandag 07 november 2005 @ 18:09:
[...]
Het grote nadeel dat R mijns inziens heeft, is dat het een nogal obscuur bestaan leidt. Ik denk niet dat er veel gebruikers in dit forum zijn die er ooit van hebben gehoord.

offtopic:
Jouw programmeervoorbeeld lijkt me geen compleet programma. Ik zie nergens output naar het scherm gaan. Het complete programma zal daarom een paar regels langer zijn.

R wordt momenteel erg veel gebruikt door statistici als simulatie & plot programma.

De output van het programma wordt naar het scherm gescreven met de obscure opdracht 'cat'.

[Verwijderd]

Als ik statistische rommel moet doen gebruik ik eigenlijk steevast eviews. Maar goed, dat is meer een statistisch pakket waarin je ook nog wat kan scripten dan een echte programmeertaal. Maar wel stukken uitgebreider dan R wat net een t-toets of f-toets standaard ondersteund.

Als ik echter een model moet simuleren kom ik weer uit op goed old C++. Gaat meestal beduidend sneller dan bv R en meer dan wat random trekken uit (niet altijd normale) verdelingen zit er bij mij toch niet in. De statieken komen dan weer mooi uit Eviews (of soms Excel)

[chris]

En in ruby:

Ruby:

#!/usr/bin/ruby

iterations = 10000
group_size = 23
days_in_year = 365

hits = 0.0

iterations.times do
        group = Array.new

        for i in 0..(group_size-1)
                group[i] = rand(days_in_year)
        end

        for i in 0..(group_size-1)
                for j in (i+1)..(group_size-1)
                        if(group[i]==group[j]) then
                                hits = hits + 1
                        end
                end
        end
end

print "Hits: ", hits, "\n"
print "Iterations: ", iterations, "\n"
print "Hits / Iterations: ", (hits / iterations), "\n"

[Verwijderd]

Vraag aan Curry:
in jouw C++ versie zie ik 2 keer dezelfde for loop:

C++:

// loop 1
for(l_Index = 0; l_Index != c_GroupSize; l_Index++)

//loop 2
for(l_Index = 0; l_Index < c_GroupSize; l_Index++)

De uitwerking van die loop is ongeveer hetzelfde, maar de eerste keer gebruik je != om uit je loop te kunnen springen, en de tweede keer gebruik je <. Waarom?

/offtopic

[curry684]

De 2e zou anders failen omdat ik 'm gebruik om uit de inner loop te jumpen. Kijk nog maar eens goed

[ Voor 3% gewijzigd door curry684 op 08-11-2005 15:00 ]

[.oisyn]

Wat natuurlijk onzin is, als je in de tweede loop met < eruit kunt springen, dan kan dat met de eerste ook

[ Voor 77% gewijzigd door .oisyn op 08-11-2005 15:11 ]

[Verwijderd]

curry684 schreef op dinsdag 08 november 2005 @ 15:00:
De 2e zou anders failen omdat ik 'm gebruik om uit de inner loop te jumpen. Kijk nog maar eens goed

Ok, duidelijk. Maar waarom gebruik je in die eerste loop dan != ipv <?

Ik heb tijdens mijn lessen java altijd geleerd om < te gebruiken, omdat het veiliger is. (bij != kun je makkelijker over de stop conditie heen springen) Het viel mij ook al op dat in het boek C++ primer - fourth edition ook altijd != wordt gebruikt. Mijn vraag is dus eigenlijk: waarom zou je != gebruiken als je ook met < kunt werken?

[.oisyn]

Sterker nog, het gaat zelfs gruwelijk fout. l_Index wordt op c_GroupSize gezet. Voor dat de conditie in de for gechecked wordt, wordt eerst het increment-gedeelte uitgevoerd. l_Index is dan dus c_GroupSize + 1. In de tweede loop springt ie eruit, maar in de eerste loop in de volgende iteratie wordt gewoon doorgegaan omdat l_Index != c_GroupSize.

[Verwijderd]

Verwijderd schreef op dinsdag 08 november 2005 @ 13:49:
Als ik statistische rommel moet doen gebruik ik eigenlijk steevast eviews. Maar goed, dat is meer een statistisch pakket waarin je ook nog wat kan scripten dan een echte programmeertaal. Maar wel stukken uitgebreider dan R wat net een t-toets of f-toets standaard ondersteund.

Komt niet verder dan een t-toets? Een kleine greep:

http://cran.au.r-project.org/src/contrib/PACKAGES.html

enne...nofi maar niet blaten over zaken waar je geen verstand van hebt.

[Verwijderd]

frickY schreef op maandag 07 november 2005 @ 12:34:
Waarom noemt niemand de taal Pascal?

Dat is prima geschikt voo rdergelijke mogelijkheden in een command prompt.

Pascal is toch min of meer genoemd.... als je even terug kijkt dan zie je dat Delphi genoemd is. De laatste keer dat ik in Delphi geprogrammeerd heb was de syntax nog steeds hetzelfde als in pascal.

O ja.... niet vergeten te melden dat ik denk dat Delphi waarschijnlijk wel iets voor je is.

[ Voor 11% gewijzigd door Verwijderd op 08-11-2005 16:55 ]

[Verwijderd]

Bla die bla.

Even voor de duidelijkheid. Als je bijvoorbeeld op zoek bent naar een simpele Durbin Watson test kun je lang zoeken. Zal vast wel in één van die modules zitten maar in welke?
Zelfde voor bv het testen op normaliteit. Gaat leuk als je de complete distributie hebt Kolmogorov-Smirnov, Lilliefors, Cramer-von Mises, Anderson-Darling ze staan er allemaal tussen. Maar als ik nu even mijn residuen wil testen? Welke module moet ik dan hebben? Waar o waar zit bv de Jarque-Bera test?

En zo kan ik nog wel even doorgaan. De basis komt niet verder dan een t-toets of f-toets. De rest is van diverse kwaliteit en een hoop basiszaken zijn lastig tot niet te vinden. Waar kan ik bv tests vinden die met ARCH of GARCH te maken hebben? Zoeken op ARCH levert geen resultaten. Zoeken op Heteroscedasticiteit 1 niet relevant resultaat.

De genoemde zaken zijn allemaal vrij basic maar allemaal "optional" en lastig te vinden in R.
Zodra de documentatie en kwaliteit van de algoritmes zich met de bekende commerciele pakketten kunnen meten wordt R zéér interessant. Maar voorlopig is het voor toegepaste statistiek gewoon nog niet daar. Te traag voor simulaties en te beperkt en te onhandig voor evaluaties. En als ik dan toch zelf moet gaan implementeren kies ik toch echt voor C++ of Java. Anderen misschien voor pascal of VB maar voorlopig heb ik nog geen één serieus model in R gezien.

[Verwijderd]

zoek in Google: durbin watson r language

Eerste link: http://cran.r-project.org...worth-EconometricsInR.pdf

Kijk eens wat daar allemaal staat. En wat noem jij een serieus model?

[ Voor 46% gewijzigd door Verwijderd op 08-11-2005 17:57 ]

[Verwijderd]

Volgens mij was het niet de bedoeling om de TS uiteindelijk toch nog te leren hoe een codewar eruit ziet. We hebben hem op weg geholpen met simpele voorbeelden in verschillende talen. Mocht de TS of iemand anders daar nog vragen over hebben, dan kan hij ze stellen. Het is niet interessant om over andere dingen te gaan posten.

In andere woorden... offtopic.

[curry684]

Verwijderd schreef op dinsdag 08 november 2005 @ 15:16:
[...]


Ok, duidelijk. Maar waarom gebruik je in die eerste loop dan != ipv <?

Ik heb tijdens mijn lessen java altijd geleerd om < te gebruiken, omdat het veiliger is. (bij != kun je makkelijker over de stop conditie heen springen) Het viel mij ook al op dat in het boek C++ primer - fourth edition ook altijd != wordt gebruikt. Mijn vraag is dus eigenlijk: waarom zou je != gebruiken als je ook met < kunt werken?

Omdat ik gewend ben != te gebruiken tenzij ik een goede reden heb om dat niet te doen zoals in het 2e geval. No other particular reason

[pierre-oord]

Weet je wat nog veel simpeler is?

Je kunt images van je rekenmachine op je PC uitvoeren. Je draait dan je rekenmachine software op je PC, die natuurlijk veel sneller rekend. Zo kun je heel snel veel berekeningen uitvoeren, heb ik ooit eens gebruikt omdat die rekenmachine me te lang duurde... is alweer tijdje terug wel.

Overigens, volgens mij mag je die images neit zomaar gebruiken (copyrighted) maar als je de rekenmachine hebt zal dat wel anders liggen, ik weet het niet precies.

Kijk maar eens naar eerste hit: http://www.google.nl/sear...en&q=ti+83+emulator&meta=

[Tomatoman]

De echte tweaker kan niet zonder Excel . Download: het originele Excelbestand



[edit]
Uiteraard geen macro's gebruikt, alles wordt gewoon met wat formules berekend. Hoewel het allemaal min of meer voor zich spreekt, zal ik de spreadsheet kort uitleggen. Er zijn in feite maar 3 formules. De formule die in elk van de 3 gekleurde cellen wordt gebruikt, heb ik ter verduidelijking onderaan de spreadsheet nog eens als tekst weergegeven. De formule in C5 is precies gelijk aan de formule in bijvoorbeeld C6, D5 en P1000. De formule in Z6 is gelijk aan de formule in Z5, zij het dat de rijverwijzing dan is gewijzigd in C6:Y6.

[ Voor 62% gewijzigd door Tomatoman op 09-11-2005 00:35 ]

[Verwijderd]

Verwijderd schreef op dinsdag 08 november 2005 @ 17:55:
zoek in Google: durbin watson r language

Eerste link: http://cran.r-project.org...worth-EconometricsInR.pdf

Kijk eens wat daar allemaal staat. En wat noem jij een serieus model?

Een model wat geld oplevert. Dat noem ik een serieus model.

Kijk trouwens eens naar de link. Als ik econometrische informatie wil verwerken heb ik nodig. (En in mijn ogen mist hier nog wel wat)

Het R basispakket en de volgende bibliotheken

car Regression tests and robust standard errors
sem Two stage least squares
MASS Robust regression, ordered logit/probit
lmtest Breusch-Pagan and Breusch-Godfrey tests
sandwich (and zoo) Heteroskedasticity and autocorrelation robust covariance
tseries Garch, ARIMA, and other time series functions
MNP Multinomial probit via MCMC
Hmisc LATEX export
xtable Alternative LATEX export
systemfit SUR and 2SLS on systems of equations
fracdiff Fractionally integrated ARIMA models
survival Tobit and censored regression
nlme Nonlinear fixed and random effects models
nnet Multinomial logit/probit
ts* Time series manipulation functions
nls* Nonlinear least squares
foreign* Loading and saving data from other programs
zoo required in order to have the sandwich package

Leuk. Zonder deze modules is R dus ongeschikt. Ook kan ik een aantal bibliotheken downloaden voor C++ (of java of VB of ....) en dan krijg ik precies dezelfde functionaliteit. Wat is dan de meerwaarde om een andere (trage) programmeertaal te leren. Een mooiere for loop?

Als ik een toets wil uitvoeren, wil ik het testen. Niet eerst op zoek gaan naar een implementatie van die toets dan de implementatie controleren en pas daarna de toets gebruiken. Voor dat soort zaken zijn IMHO de bekende statistische pakketten dan ook veel geschikter. Wil ik echter een model maken, heb ik de meeste van die toetsen niet nodig. Wél heb ik een betrouwbare manier nodig om uit verschillende verdelingen te trekken. Dat kan in R. Maar dat kan ook in C++ (Java, VB, ..) Belangrijk is dan wat ik ermee doe. En bv een binoniale boom bouwen gaat in die talen prima. In R?

R lijkt mij dan ook een perfecte script taal voor gebruik in een Open Source statistisch pakket. Er zijn een hoop basisfuncties aanwezig en door goede modules te integreren en gelijk mee te leveren komt er een hoop functionaliteit beschikbaar. Tot slot is de R taal redelijk simpel. Met een goede GUI kan R de concurrentie met de bestaande statistische pakketten waarschijnlijk wel aan, mits de missende functionaliteit aangevuld wordt en de bestaande modules beter geintegreerd worden in het standaard paket.

Echter om C++ en consorten te verslaan is er iets anders nodig: snelheid. En dat is er niet. Functionaliteit dan? Ook niet, ook voor de bekende talen zijn er goede statistische bibliotheken beschikbaar. De meerwaarde van R is dus redelijk beperkt en zit hem niet in het basispakket maar in de extra modules. Deze modules zijn echter ook weer niet zoveel verder ontwikkeld als de beschikbare modules in andere talen. Ook zijn mensen die echt de cutting edge nodig hebben zeker in staat hun eigen model ook in C++ te ontwikkelen. R biedt dan ook IMHO geen echte voordelen boven een standaard taal en is leuk maar (alweer) IMHO een verspilling van tijd. Maak die modules beschikbaar in C++ en je hebt alles wat R je biedt + de voordelen van een bekende, algemeen bruikbare taal. R is te beperkt om algemeen bruikbaar te zijn en ook niet specialistisch genoeg om echt een meerwaarde te hebben voor statistici. Misschien over 5 jaar. Maar daar heeft de TS niets aan

En even voor Remco56. Is R een bruikbare taal voor dit soort zaken: Ja. Is R de taal die je zou moeten leren als je in dit soort zaken geinteresseerd bent: (IMHO) Nee.

[farlane]

Verwijderd schreef op dinsdag 08 november 2005 @ 15:16:
Ok, duidelijk. Maar waarom gebruik je in die eerste loop dan != ipv <?

Ik heb tijdens mijn lessen java altijd geleerd om < te gebruiken, omdat het veiliger is. (bij != kun je makkelijker over de stop conditie heen springen) Het viel mij ook al op dat in het boek C++ primer - fourth edition ook altijd != wordt gebruikt. Mijn vraag is dus eigenlijk: waarom zou je != gebruiken als je ook met < kunt werken?

Ik vond het eerst ook raar. Maar een reden kan zijn ( in C++ ) met iterators werkt. Iterators moet je in een for loop vergelijken met != omdat ze niet gegarandeerd opeenvolgend zijn (theoretisch). Simpele lussen ed worden iha altijd met < geschreven

[Verwijderd]

Verwijderd schreef op woensdag 09 november 2005 @ 02:02:

Een mooi betoog!

Een model wat geld oplevert. Dat noem ik een serieus model.

Oi, bedrijven staan niet bekend om hun interesse in goede modellen, maar eerder om een zo efficient mogelijke afweging van kosten vs. modelcomplexiteit.

Kijk trouwens eens naar de link. Als ik econometrische informatie wil verwerken heb ik nodig. (En in mijn ogen mist hier nog wel wat)

Uiteraard, alleen je zei dat je niets kon vinden over simpele econometrische modellen in R, en ik gaf je de eerste link in Google.

Het R basispakket en de volgende bibliotheken
..

Leuk. Zonder deze modules is R dus ongeschikt. Ook kan ik een aantal bibliotheken downloaden voor C++ (of java of VB of ....) en dan krijg ik precies dezelfde functionaliteit. Wat is dan de meerwaarde om een andere (trage) programmeertaal te leren. Een mooiere for loop?

Uiteraard, standaard statistische technieken zijn in veel talen geimplementeerd. Echter, bedenk wel dat 1) je er veel voor moet betalen 2) de source niet wordt vrijgegeven, zodat je niet op fouten kunt checken 3) je voor elke wissewasje en upgrade nogmaals fijn mag betalen. 4) bovendien in commerciele pakketten ontbreken vaak commercieel oninteressante klassen van modellen die wel belangrijk zijn (denk bv aan IRT modellen).

Als ik een toets wil uitvoeren, wil ik het testen. Niet eerst op zoek gaan naar een implementatie van die toets dan de implementatie controleren en pas daarna de toets gebruiken. Voor dat soort zaken zijn IMHO de bekende statistische pakketten dan ook veel geschikter.

Achter elke model in R zit een wetenschappelijke publicatie. Die zoek je op, en je kunt de software implementatie controleren. Commerciele pakketten bieden deze faciliteit vaak niet. De documentatie is beroerd, en als je ze vraagt naar de gebruikte algoritmen, krijg je een non-sense antwoord dat het bedriijfsgeheim is.

Wil ik echter een model maken, heb ik de meeste van die toetsen niet nodig. Wél heb ik een betrouwbare manier nodig om uit verschillende verdelingen te trekken. Dat kan in R. Maar dat kan ook in C++ (Java, VB, ..) Belangrijk is dan wat ik ermee doe. En bv een binoniale boom bouwen gaat in die talen prima. In R?

Wederom, kijk eens op http://cran.au.r-project.org/src/contrib/PACKAGES.html Al die pakketten kun je binnen R zo binnenhalen. Verder, je bent niet'zomaar' geinteresseerd in binomial trees. Een bedrijf heeft een vraag, jij formuleert een antwoord met behulp van wetenschappelijke literatuur. Die verwijzen vaak naar een R pakket. Jij download dat pakket en gaat het gebruiken.

R lijkt mij dan ook een perfecte script taal voor gebruik in een Open Source statistisch pakket. Er zijn een hoop basisfuncties aanwezig en door goede modules te integreren en gelijk mee te leveren komt er een hoop functionaliteit beschikbaar. Tot slot is de R taal redelijk simpel. Met een goede GUI kan R de concurrentie met de bestaande statistische pakketten waarschijnlijk wel aan, mits de missende functionaliteit aangevuld wordt en de bestaande modules beter geintegreerd worden in het standaard paket.

Een gui is niet nodig voor dergelijk onderzoek. R is oa gebouwd om grafieken te genereren in Latex, iets wat zeer bruikbaar is, en redelijk uniek.

Missende functionaliteit? Het is makkelijker schieten op iets, dan te construeren. Maar waar zitten in bv Eviews implementaties van 'serieuze' Bayesiaanse modellen? Waar zit in Eviews de mogelijkheid om ongelijkheidsgerestricteerde modellen te schatten? Waar zijn de SEM modellen, waar zijn de IRT modellen, waar zijn de complexe steekproef technieken? Waar zijn de multiple impuatie technieken?

Echter om C++ en consorten te verslaan is er iets anders nodig: snelheid. En dat is er niet. Functionaliteit dan? Ook niet, ook voor de bekende talen zijn er goede statistische bibliotheken beschikbaar. De meerwaarde van R is dus redelijk beperkt en zit hem niet in het basispakket maar in de extra modules. Deze modules zijn echter ook weer niet zoveel verder ontwikkeld als de beschikbare modules in andere talen. Ook zijn mensen die echt de cutting edge nodig hebben zeker in staat hun eigen model ook in C++ te ontwikkelen. R biedt dan ook IMHO geen echte voordelen boven een standaard taal en is leuk maar (alweer) IMHO een verspilling van tijd. Maak die modules beschikbaar in C++ en je hebt alles wat R je biedt + de voordelen van een bekende, algemeen bruikbare taal. R is te beperkt om algemeen bruikbaar te zijn en ook niet specialistisch genoeg om echt een meerwaarde te hebben voor statistici. Misschien over 5 jaar. Maar daar heeft de TS niets aan

R is niet bijzonder snel, en dat komt omdat het een geinterpreteerde taal is. R is wel de taal waarin de cutting edge applicaties worden ontwikkeld. Kijk eens naar artikelen in JASA, RSS, Comp Stat, JSR. Ik ken maar weinig auteurs die een C++ implementatie van hun modellen maken, maar ik ken er zat die in R werken. Deze auteurs zijn de ontwikkelaars van de nieuwe statistische technieken. Dat deze technieken later door programmeurs worden omgezet in C++, en worden verkocht voor veel geld, snap ik best, maar het laat we de volgorde van zaken zien.

R is een zeer simpele taal die uitstekend in staat is vernieuwingen te ondersteunen op het gebied van de statistische wetenschap. In de praktijk blijkt dat voor normale hoeveelheden data R prima geschikt is om velerlei modellen mee te schatten. Uiteraard, als het we het hebben over de implementatie van statistische technieken in een ERP pakket, zal je de toevlucht moeten nemen naar C.

En even voor Kemhaas. Is R een bruikbare taal voor dit soort zaken: Ja. Is R de taal die je zou moeten leren als je echt in dit soort zaken geinteresseerd bent: Ja. Is R een taal als je wilt klikken en mikken in een mooie GUI: nee. [/quote]

[j-w]

Ik zou voor een functionele taal gaan, bv Haskell, http://www.haskell.org.

Als je deze taal goed gebruikt zullen je programmas waarschijnlijk een heel stuk korter, eleganter en leesbaarder worden dan bij het gebruik van een imperatieve taal.

[ Voor 24% gewijzigd door j-w op 09-11-2005 11:20 ]

[joepP]

j-w schreef op woensdag 09 november 2005 @ 11:19:
Ik zou voor een functionele taal gaan, bv Haskell, http://www.haskell.org.

Als je deze taal goed gebruikt zullen je programmas waarschijnlijk een heel stuk korter, eleganter en leesbaarder worden dan bij het gebruik van een imperatieve taal.

Je "vergeet" wel even de lastige leercurve, praktisch onleesbare en ononderhoudbare code (voor 99% van de programmeurs), en de zeer trage executie. Haskell wordt eigenlijk alleen serieus gebruikt binnen de academische wereld, iets wat ook door docenten wordt beaamd. Ik ben met je eens dat de resultaten vaak kort & elegant zijn, maar bruikbaar is het niet.

Voor de volledigheid lijkt het me leerzaam voor de TS als je zijn probleempje even in Haskell implementeert, en de resulterende code hier post.

[ Voor 5% gewijzigd door joepP op 09-11-2005 12:10 ]

[curry684]

.oisyn schreef op dinsdag 08 november 2005 @ 15:19:
Sterker nog, het gaat zelfs gruwelijk fout. l_Index wordt op c_GroupSize gezet. Voor dat de conditie in de for gechecked wordt, wordt eerst het increment-gedeelte uitgevoerd. l_Index is dan dus c_GroupSize + 1. In de tweede loop springt ie eruit, maar in de eerste loop in de volgende iteratie wordt gewoon doorgegaan omdat l_Index != c_GroupSize.

En daarom heeft juist die loop dus een < gekregen ipv een !=. Your point being?

[.oisyn]

Oh, nevermind, ik miste even dat je l_Index weer op 0 reinitializede

[Verwijderd]

nou voor de grap dan ook nog even in Mathcad.

[Verwijderd]

Hij kan ook nog in gewone windows cmd language:

code:

@ECHO OFF

set /a num=23
set /a sim=10

set /a res1=0
for /L %%A in (1,1,%sim%) DO set N=%%A & call :proc0
echo %res1% / %sim%
goto :eof

:proc0
echo.     
echo sim %N%
set /a res=0
for /L %%P in (1,1,%num%) DO set pers=%%P & call :proc1
set /a check=%num%-1
for /L %%Q in (1,1,%check%) DO set file=%%Q & call :proc2
if %res%==1 set /a res1=%res1%+1
goto :eof

:proc1
set /a r=%random%/90
echo %r%>pers%pers%
goto :eof

:proc2
echo     controle pers %file%
FOR /F %%G in ('type pers%file%') DO set contr=%%G
set /a check1=%file%+1
for /L %%S in (%check1%,1,%num%) DO set file1=%%S & call :proc3
goto :eof

:proc3
FOR /F %%H in ('type pers%file1%') DO set contr1=%%H
if %contr%==%contr1% set /a res=%res%+1
if %res%==2 set/a res=1
goto :eof

:eof

Hij is wel traag

[curry684]

offtopic:
die CMD-versie is bikkel

[Tomatoman]

curry684 schreef op donderdag 10 november 2005 @ 14:14:

offtopic:
die CMD-versie is bikkel

offtopic:
En ik vond het al stoer dat olav een Fortranversie had gebrouwen

[Verwijderd]

Verwijderd schreef op woensdag 09 november 2005 @ 11:17:
[...]

Een mooi betoog!

Dank je

Maar ik ben wel bang dat deze discussie enigszins verder gaat dan "simpel" berekeningen. Duidelijk is in ieder geval dat wij een ander uitgangspunt hebben. Aan de andere kant, een discussie waar eens wat dieper op de zaken wordt ingegaan is natuurlijk nooit weg. Al ben ik bang dat we uiteindelijk niet verder komen dan dat we "agree that we disagree". Maar ook dat kan nuttig zijn.

[...]

Oi, bedrijven staan niet bekend om hun interesse in goede modellen, maar eerder om een zo efficient mogelijke afweging van kosten vs. modelcomplexiteit.

Dat is absoluut onjuist. Er zijn zat bedrijven die veel geld over hebben voor een goed model. Denk daarbij aan banken maar ook bv aan het KNMI. Als banken via een goed model, aandelenkoersen beter kunnen voorspellen hebben zij daar veel voor over. En dat geld voor meer bedrijven. Toegepaste statistiek is ondertussen een echte bedrijfstak waar veel bedrijven veel geld in investeren. Zo heeft bv KLM veel geld over voor informatie over haar tariefstructuur, de NS voor informatie over haar dienstregeling en Airbus over het gebruik van haar toestellen. En zo kan ik nog wel een tijdje doorgaan. Het is niet voor niets dat vorig jaar een econometrisch bedrijf (waar ik niet aan verbonden ben) de ondernemingsprijs van Rotterdam gewonnen heeft. Goede modellen leveren bedrijven veel geld op. En zij hebben daar dus ook veel geld voor over.

[...]

Uiteraard, alleen je zei dat je niets kon vinden over simpele econometrische modellen in R, en ik gaf je de eerste link in Google.

Mijn punt is meer dat je zodra je iets meer wilt, je aangewezen bent op (een batterij van) extra modules. Ook in andere talen bestaan die modules. Een eerlijke vergelijking vergelijkt dus ofwel R zonder extra modules tegen een andere taal ofwel R met extra modules tegen een andere taal met de beschikbare modules voor die taal. En dan vraag ik me af welke R modules ik zou missen. Erg weinig ben ik bang. Ook ik kan in Google eenvoudig bibliotheken vinden in C++ die hetzelfde doen.
Dat die eerste link toevallig veel Econometrische informatie oplevert (waar ik inderdaad in geinteresseerd ben) neemt niet weg dat een hoop informatie niet zomaar te vinden is. Het blijven tenslotte niet door de R ontwikkelaars ondersteunde modules.

[...]

Uiteraard, standaard statistische technieken zijn in veel talen geimplementeerd. Echter, bedenk wel dat 1) je er veel voor moet betalen 2) de source niet wordt vrijgegeven, zodat je niet op fouten kunt checken 3) je voor elke wissewasje en upgrade nogmaals fijn mag betalen. 4) bovendien in commerciele pakketten ontbreken vaak commercieel oninteressante klassen van modellen die wel belangrijk zijn (denk bv aan IRT modellen).

Dat je ervoor moet betalen is niet echt relevant. De kwaliteit en de support kán dat compeseren.
De sourcecode is vaak bij statistische biblioteken "gewoon" beschikbaar. Wel is dit inderdaad een belangrijk punt. Zeker als je op de cutting edge van de statistiek werkt.
Betalen voor elk wissewasje en upgrade? Dit is hetzelfde als punt 1 En natuurlijk sterk afhankelijk van de bibliotheek.
In het vierde punt heb je gelijk. Maar persoonlijk vind ik een klasse modellen die (nog) geen commercieel nut hebben enkel geschikt voor onderzoekers. Voor mensen die modellen voor commercieel gebruik ontwikkelen is dat niet direct een belangrijk punt. iets om in de gaten te houden maar niet iets om gelijk door op een andere taal over te stappen

[...]

Achter elke model in R zit een wetenschappelijke publicatie. Die zoek je op, en je kunt de software implementatie controleren. Commerciele pakketten bieden deze faciliteit vaak niet. De documentatie is beroerd, en als je ze vraagt naar de gebruikte algoritmen, krijg je een non-sense antwoord dat het bedriijfsgeheim is.

Daarin is misschien EViews een uitzondering (al ken ik genoeg "vergelijkbare" producten die ook hun implementaties in de help files uitleggen) Vergeet niet dat EViews één van de weinige statistische pakketten is waaraan een nobelprijswinnaar daadwerkelijk heeft geprogrammeerd en ondersteuning levert (Engle) Ook gaat de documentatie vele malen verder dan strict noodzakelijk inclusief verwijzingen naar de wetenschappelijke artikelen waarop de toets gebaseerd is. Persoonlijk vind ik de documentatie van een pakket als EViews béter en vooral consistenter als die van R. De meeste C++ bibliothen daarentegen hebben inderdaad niet die kwaliteit van documentatie.

[...]

Wederom, kijk eens op http://cran.au.r-project.org/src/contrib/PACKAGES.html Al die pakketten kun je binnen R zo binnenhalen. Verder, je bent niet'zomaar' geinteresseerd in binomial trees. Een bedrijf heeft een vraag, jij formuleert een antwoord met behulp van wetenschappelijke literatuur. Die verwijzen vaak naar een R pakket. Jij download dat pakket en gaat het gebruiken.

Een binomial tree is een basismethode binnen de econometie Er zijn een hoop voorspelmodellen die daarop gebaseerd zijn. En eerlijk gezegd ben ik nog nóóit een verwijzing naar een R pakket tegengekomen. Meestal staan de artikelen die ik zie bol van de wiskundige formules en niet van een implementatie. Sterker nog ik ken verschillende gepubliseerde artikelen waarbij de implementatie van het algoritme door de auteurs gewoon incorrect is. Als je dat dan nogmaals op hún data gaat testen krijg je hele rare resultaten. Misschien kan R die fouten wat verminderen. Maar eerlijk gezegt betwijvel ik dat. Onderzoekers zijn gewoon geen programmeurs en hebben andere kwaliteiten, doelen en behoeften.

Daarnaast geeft dit aan dat als je méér wilt dan enkel de statistische modellen aanroepen, dat je dan al snel tegen de grenzen van R aanloopt. Een universiele taal heeft minder last van dat soort beperkingen

[...]

Een gui is niet nodig voor dergelijk onderzoek. R is oa gebouwd om grafieken te genereren in Latex, iets wat zeer bruikbaar is, en redelijk uniek.

Missende functionaliteit? Het is makkelijker schieten op iets, dan te construeren. Maar waar zitten in bv Eviews implementaties van 'serieuze' Bayesiaanse modellen? Waar zit in Eviews de mogelijkheid om ongelijkheidsgerestricteerde modellen te schatten? Waar zijn de SEM modellen, waar zijn de IRT modellen, waar zijn de complexe steekproef technieken? Waar zijn de multiple impuatie technieken?

Allereerst Latex. Ja, een mooie feature maar tegelijkertijd is het toch wel iets wat "verouderd" is. Het kan een hoop maar om je programmeertaal daar afhankelijk van te maken. Ik weet het niet. Persoonlijk vind ik dat ofwel de taal zelf voor grafieken moet kunnen zorgen ofwel de grafieken via meerdere alternatieve pakketten verzorgt moeten kunnen worden.

Daarnaast is EViews inderdaad zeker niet perfect. Eviews richt zich duidelijk op een deelgebied. Namelijk de econometrie. Sommige zaken zijn dan ook niet geimplementeerd of worden als een stiefkind behandeld. Echter EViews heeft ook niet de pretentie om een oplossing voor iedereen te zijn. R heeft dat wel. En waar andere pakketten misschien een beter alternatief zijn voor Eviews voor andere soorten statistiek, is ook R zeker geen universele oplossing. En ik ben realist genoeg om te weten dat R ook nooit een echt universeel pakket kan worden. Ook R heeft zijn sterke en zwakke punten. Probleem is dat de mensen achter R dat (in mijn ogen) te weinig zien. De kracht van R zit hem in de beschikbare modules. Maar als iemand die modules in VB zou implementeren blijft er weinig over van de voordelen van R. De basistaal is dus redelijk beperkt en een combinatie van C++ (of java of vb of....) en een goede bibliotheek heeft dus voor ontwikkelaars weinig tot geen nadelen. Wel kan de documentatie en support ontbreken. Maar R biedt geen garantie dat de documentatie en support wél op een hoog niveau zit.

[...]

R is niet bijzonder snel, en dat komt omdat het een geinterpreteerde taal is. R is wel de taal waarin de cutting edge applicaties worden ontwikkeld. Kijk eens naar artikelen in JASA, RSS, Comp Stat, JSR. Ik ken maar weinig auteurs die een C++ implementatie van hun modellen maken, maar ik ken er zat die in R werken. Deze auteurs zijn de ontwikkelaars van de nieuwe statistische technieken. Dat deze technieken later door programmeurs worden omgezet in C++, en worden verkocht voor veel geld, snap ik best, maar het laat we de volgorde van zaken zien.

Grappig, ik ken dus niemand die echt met R werkt. Wel met talen als C++. VB, Pascal en ken zelfs modellen in Excel. Maar R? Nog niet gezien. Maar ook al liggen de implementaties in andere talen achter op R. Voor hoeveel mensen is dat relevant? De meesten kennen die nieuwe ideeen niet eens en de mensen die het wel kennen hebben waarschijnlijk ook de kennis om het zelf te implementeren.

R is een zeer simpele taal die uitstekend in staat is vernieuwingen te ondersteunen op het gebied van de statistische wetenschap. In de praktijk blijkt dat voor normale hoeveelheden data R prima geschikt is om velerlei modellen mee te schatten. Uiteraard, als het we het hebben over de implementatie van statistische technieken in een ERP pakket, zal je de toevlucht moeten nemen naar C.

Dat R een simpele taal is en veel vernieuwingen snel ondersteund staat denk ik buiten kijf. Maar voor "simpele berekeningen" vind ik het té specialistisch terwijl voor echt commercieel gebruik het vaak niet geschikt is. Blijft over de onderzoeksmarkt. Maar de meeste mensen die ik ken combineren onderzoek aan een universiteit met een commerciele baan. Als je voor een commerciele opdracht al met commerciele producten (moet) werken is het niet logisch om bij je werk op de universiteit een andere taal te gebruiken.

Ik hoop dan ook al tijden op de implementatie van de beste R modules in C++. Met dezelfde documentatie en kwaliteit als die in R. Dat zou in mijn ogen uiteindelijk het beste zijn.
Snelheid, flexabiliteit én goede modellen in één oplossing vereenigd.

[Confusion]

Verwijderd schreef op woensdag 09 november 2005 @ 02:02:
Een model wat geld oplevert. Dat noem ik een serieus model.

Jij hebt het over modellen die over geld gaan. Dat is ongelijk aan modellen die geld opleveren. Het is al helemaal ongelijk aan modellen die interessant zijn.

Kijk trouwens eens naar de link. Als ik econometrische informatie wil verwerken

Het grootste deel van de wereld wil andere dingen.

Verwijderd schreef op vrijdag 11 november 2005 @ 04:24:
Allereerst Latex. Ja, een mooie feature maar tegelijkertijd is het toch wel iets wat "verouderd" is.

Wat een onzin. Alle wetenschappelijke artikelen worden erin geschreven en dat is precies waar je de resultaten voor nodig hebt. R is niet bedoeld voor de financiele wereld met hun, sorry dat ik het zeg hoor, modelletjes. Het Black-Scholes model is niets anders dan een diffusievergelijking met wat gesubstitueerde variabelen. Risico-analyse en koersvoorspellingen... er zijn een hoop interessantere dingen dan dat. Je kan kort of lang ouwehoeren en je statistische kennis tentoonspreiden, maar

Maar wel stukken uitgebreider dan R wat net een t-toets of f-toets standaard ondersteund.

sloeg nergens op, als je ziet hoeveel R gebruikt wordt. Het is gewoon totaal uncalled for brutality en ik vraag me af waarom jij het nodig vind zo uit te varen tegen R. Het gewicht dat jij geeft aan enonometrie, hoe interessant ik het persoonlijk ook vind, is niet maatgevend. De bruikbaarheid van R voor financiele toepassingen is ook niet maatgevend voor de waarde ervan.

[ Voor 4% gewijzigd door Confusion op 11-11-2005 09:12 ]

[Mithrandir]

Om maar even mee te pimpen met de verschillende programmeertalen, zie hier mijn prologversie!

Prolog:

iterations(1000).
groupsize(23).

go1 :- run(0, 0).

%Stoppen als we ver genoeg zijn
run(Iteration, Clashes) :-
  iterations(Max),
  Max =< Iteration, !,
  write('Clashes: '), write(Clashes), nl,
  HitPerc is (Clashes*100)/Max,
  write('Hit %  : '), write(HitPerc), nl.

%Loop mechanisme
run(Iteration, OldClashes) :-
  NewIteration = Iteration + 1,
  iterate(0, [], Clashes),
  NewClashes is OldClashes + Clashes,
  run(NewIteration, NewClashes).

%Stoppen na een clash
iterate(1, _, 1).

%Stoppen als we ver genoeg zijn
iterate(Clashes, Birthdays, Clashes) :-
  length(Birthdays, Length),
  groupsize(Groupsize),
  Length >= Groupsize, !.

%itereren maar!
iterate(Clashes, Birthdays, Answer) :-
  Birthday is random(365),
  NewBirthdays = [Birthday | Birthdays],
  birthdayCheck(Birthday, Birthdays, Clashes, NewClashes),
  iterate(NewClashes, NewBirthdays, Answer).
  
birthdayCheck(Birthday, Birthdays, Clashes, NewClashes) :-
    member(Birthday, Birthdays), !,
    NewClashes is Clashes + 1.

birthdayCheck(_, _, Clashes, Clashes).

edit:
Het schijnt dat met 10.000 items er opeens vieze floating point errors komen ofzo, maarja ... De stack schijnt niet groot genoeg te zijn? Maar mijn impelemntatie gaat maar 10.000 niveaus diep. Dat kán toch wel?

[ Voor 22% gewijzigd door Mithrandir op 11-11-2005 09:38 ]

[Verwijderd]

Nog een keer een code, en dit keer in SPSS:

code:

INPUT PROGRAM.
    LOOP #I = 1 TO 10000.
        do repeat r=v1 to v23.
            COMPUTE r = rnd(rv.uniform(0.5,365.5)).
        end repeat.
    END CASE.
    END LOOP.
    end file.
END INPUT PROGRAM.

set mxloop = 10000.
matrix.
    get m /variables = v1 to v23.
    compute m=t(m).
    compute ff= make  (1,1,0).
    loop lus=1 to 10000.
        do if  (mmax(csum(design(m(:,lus))))>1).
            compute ff=ff+1.
        end if.
    end loop.
    print (ff/10000).
end matrix.

exe.

Uitkomst:

Run MATRIX procedure:

FF/1000000
.5083740000

------ END MATRIX -----

[EXX]

Wie maakt als eerste een BASIC one-liner versie?