[algoritme][C++]datum - veel dagen

[xychix]

Dit is de code die ik nu heb.

code:

ADatum &ADatum::operator-(const int dagen) const
{
    ADatum temp(12,12,2002); //evt 0-0-000 constructor maken of bij tijd over zelfs huidige dag !
    temp = *this;
    int i=0;
    static int aantdagenSCHRIK[13]={0,31,29,31,30,31,30,31,31,30,31,30,31};
    static int aantdagen[13]     ={0,31,28,31,30,31,30,31,31,30,31,30,31};

    while(i<dagen)
    {
        if(temp.IsSchrikkeljaar())
        {
            temp.pData->dag--;
            if(temp.pData->dag < 1)
            {
                temp.pData->maand--;
                if(temp.pData->maand < 1)
                {
                    temp.pData->jaar--;
                    temp.pData->maand = 12;
                }       
                temp.pData->dag = aantdagenSCHRIK[temp.pData->maand];
            }
        }
        else
        {
            temp.pData->dag--;
            if(temp.pData->dag < 1)
            {
                temp.pData->maand--;
                if(temp.pData->maand < 1)
                {
                    temp.pData->jaar--;
                    temp.pData->maand = 12;
                }       
                temp.pData->dag = aantdagen[temp.pData->maand];
            }
        }
        i++;
    }
    return temp;
}

alleen dit is ontzettend traag. weet iemand een duidelijk en sneller algorithme ?

stappen per jaar gaat niet, je zit dan met schrikkeljaar, en het kan zijn dat je in een schrikkeljaarbegint maar al onder de 29-02 zit. als je dat 365 dagen naar beneden gaat kom je niet langs de schrikkel.

Ook per 4 jaar is geen oplossing want ook dat is niet een constant aantal dagen (bij eeuwwisselingen (1900) mist een schrikkeljaar !)

per 400 jaar kan wel, is wel constant maar dan hebbie zulke grote stappen dat de 1 daga stapjes binnen de 400 jaar toch weer tijdrovend zijn !

Probleem definitie
Ik heb een datum bv 17-02-5004 en daar wil ik 36503 dagen vanaf halen. (elke willekeurige datum en aantal dagen moet gebruikt kunnen worden).

de uitkomst is een nieuwe datum.

hoe kan ik deze berekening snel uitvoeren ?

[Rhythmic]

Wat probeer je eigenlijk te doen? Een datum berekenen aan de hand van een "basisdatum" + een bepaald aantal dagen?
(altijd handig om het probleem helder te hebben voordat je gaat nadenken over een oplossing)

[JayTaph]

1. Maak snelle routine die datum omzet naar aantal dagen vanaf jaar 0, of 1900 als je zeker hier niet onder komt voor de extra snelheid. (dus aantal jaren * 365, + aantal schrikkeljaren (schrikkeljaar = jaar % 4 or jaar % 400 and not jaar % 1000 geloof ik).

2. datumindagen -= dagen;

3. Maak snelle routine die aantal dagen omzet naar een jaar (gerekend vanaf 0, of 1900 als je hier niet onder komt voor de extra snelheid).

4. Rest van de dag vrij..

[whoami]

Je kunt je datum omzetten naar een double ofzo, daar dan het aantal dagen bij optellen en dan terug omzetten naar een datum.

Denk ik.

[xychix]

Op donderdag 25 april 2002 10:24 schreef JayTaph het volgende:
1. Maak snelle routine die datum omzet naar aantal dagen vanaf jaar 0, of 1900 als je zeker hier niet onder komt voor de extra snelheid. (dus aantal jaren * 365, + aantal schrikkeljaren (schrikkeljaar = jaar % 4 or jaar % 400 and not jaar % 1000 geloof ik).

2. datumindagen -= dagen;

3. Maak snelle routine die aantal dagen omzet naar een jaar (gerekend vanaf 0, of 1900 als je hier niet onder komt voor de extra snelheid).

4. Rest van de dag vrij..

Ik heb een method IsSchrikkel (en vele anderen zie hier:

code:

    ADatum( unsigned int dag, unsigned int maand, unsigned int jaar);
    ADatum( AString datum);
    ADatum( const ADatum &bronobject);
    ~ADatum();

    AString     GetJulian()                             const;
    AString     GetJulianY2K()                          const;
    int         GetDag()                                const;
    int         GetMaand()                              const;
    int         GetJaar()                               const;
    void        SetDag(int dag)                         ;
    void        SetMaand(int maamd)                     ;
    void        SetJaar(int jaar)                       ;
    bool        IsSchrikkeljaar()                       const;
    AString     GetMaandnaam()                          const;
    AString     GetDagnaam()                            const;
    
    ADatum     &operator+(const int dagen)              const;
    ADatum     &operator-(const int dagen)              const;
    int         operator-(const ADatum &bronobject)     const;
    bool      operator<(const ADatum &bronobject)       const;
    bool      operator>(const ADatum &bronobject)       const;
    bool        operator==(const ADatum &bronobject)    const;
    bool        operator!=(const ADatum &bronobject)    const;
    ADatum     &operator=(const ADatum &bronobject)     ;

maar dan nog zit je met schrikkeljaren etc.
- als ik 4 jaar zak heb ik dan wel/niet een schrikkejaar gehad.

- Wanneer meet je of het een schrikkeljaar is ?? (als je vanaf 25-02-1996 naar beneden gaat begin je in een schrikkeljaar !!! toch kom je niet langs de "schrikkel dag"

hoe wou je dat oplossen ?

en als je het gaat omzetten naar een double zit je in de method "ZetDatumOmNaarDouble" met het zelfde probleem, je verplaatst dan alleen het probleem !

[JayTaph]

- Wanneer meet je of het een schrikkeljaar is ?? (als je vanaf 25-02-1996 naar beneden gaat begin je in een schrikkeljaar !!! toch kom je niet langs de "schrikkel dag"

Je weet toch wanneer een jaar een schrikkeljaar is, en je weet of je wel of niet voor die schrikkeldag zit (en dus wel of niet die schrikkeldag moet tellen). Wat is nu het probleem??

[xychix]

het probleem is dat ik onderhand zolang in deze materie bezig ben dat ik niet een heldere korte en SNELLERE versie van helemaal boven geposte method kan schrijven..

Ik vraag jullie niet mijn method te herschrijven maar een pseudocode oplossing is welkom aangezien het "ozo simplel is als ik jullie moet geloven.."

[Dash2in1]

Op donderdag 25 april 2002 10:13 schreef xychix het volgende:
Probleem definitie
Ik heb een datum bv 17-02-5004 en daar wil ik 36503 dagen vanaf halen. (elke willekeurige datum en aantal dagen moet gebruikt kunnen worden).

de uitkomst is een nieuwe datum.

hoe kan ik deze berekening snel uitvoeren ?

Elke willekeurige datum?
Anders kan je evt vanuit een bepaalde 'startdatum' een numerieke representatie berekenen voor de datum .. dus wat hierboven al staat 1 voor 1-1-1900, 2 voor 2-1-1900 .. etc
(wat niet al te moeilijk moet zijn)
en dan de ene min de andere en terugrekenen vanaf die 'startdatum'

[curry684]

Paar minuutjes Googlen:

code:

void
Date::buildFromJulian(size_t julianDay) {
static const long solarDay=86400;
static const double epsilon= 2.2204460492503131E-16;

double f, jdt;
long alfa, a, b, c, d, e, z;

internalWeekDay=((julianDay+1) % 7) +1;

jdt = julianDay + 0.5;
z = (long)::floor(jdt);
f = solarDay / 2;
f += f*epsilon;
if (f > solarDay) {
f -= solarDay;
}
f /= 3600.0;
if (z < 2299161) {
a = z;
}
else {
alfa = (long)::floor(((z - 1867216.25)/36524.25));
a = z + 1 + alfa - alfa/4;
}
b = a + 1524;
c = (long)::floor((b - 122.1)/365.25);
d = (long)::floor((365.25 * c));
e = (long)::floor(((b - d)/30.6001));
internalDay = (int)(b - d - (long)::floor((30.6001*e)));
if(e < 14) {
internalMonth = (int)(e - 1);
}
else {
internalMonth = (int)(e - 13);
}

if (internalMonth < 3) {
internalYear = c - 4715;
}
else {
internalYear = c - 4716;
}

char buffer[32]="";
internalJulian=julianDay;
#ifdef GIST_SIZE_T_IS_ULONG
sprintf(buffer, "%.2lu/%.2lu/%.4d",
internalDay, internalMonth, internalYear);
#else
sprintf(buffer, "%.2d/%.2d/%.4d",
internalDay, internalMonth, internalYear);
#endif
internalString=buffer;
}

size_t
Date::julianDate(size_t day, size_t month, int year) {
bool reform;
long a, b=0L, c, d;
double x1;
size_t xj;

if (month<3) { year--; month += 12; }
reform = (year==1582) &&
((month==10) && (day>=15) || (month>10)) || (year>1582);
if (reform) { a = year/100; c = a/4; b = 2 - a + c; }
x1 = 365.25 * year;
if (year<0) x1 -= 0.75;
c = (long) (x1);
d = (long) (30.6001 * (month + 1));
xj = c + d + day + 1720994L;
if (reform) xj += b;
return (xj+1);
}

Wat je hiermee kunt zul je zelf maar ff moeten nagaan

Hint: Googlen naar Julian date format

[JayTaph]

doe het zo:

* tel terug naar begin van de maand. Op de 24ste is dat dus 24.
* tel terug naar het begin van het jaar. Om dit lekker snel te doen, gebruik je een lookup-table, net zoals je al gedaan had, alleen dan niet met de dagen per maand, maar met het aantal dagen vanaf het begin van het jaar. (EXCLUSIEF schrikkeljaar). Dus je lookup wordt: 0, 31, 59 etc).
* Tel je terug vanaf 24 januari, dan is dat dus 24 + 0 = 24 dagen. Tel je terug vanaf 24 maart, is dat dus 24 + 59 = geenzininomoptellen).
* Daarna ga je controleren of je in een schrikkeljaar zit en zo ja, of je NA de schrikkeldag zit (dus maand 3 of hoger). Is dat zo, tel er 1 bij op. Dit is dus je schrikkeldag in het eerste jaar.
* Nu gaat het snel, want je telt alle jaren die je terug wilt gaan (tot 1900 bijvoorbeeld) terug, 2002-1900 is 102*365 = veel dagen.
* Daarna ga je kijken hoeveel jaren er tussen 1900 en 2002 (2002 NIET MEEREKEND DUS) schrikkeljaar zijn. Zoveel dagen tel er erbij op.

Et voila, je hebt je datum in dagen.

[xychix]

Op donderdag 25 april 2002 10:53 schreef JayTaph het volgende:
doe het zo:

* tel terug naar begin van de maand. Op de 24ste is dat dus 24.
* tel terug naar het begin van het jaar. Om dit lekker snel te doen, gebruik je een lookup-table, net zoals je al gedaan had, alleen dan niet met de dagen per maand, maar met het aantal dagen vanaf het begin van het jaar. (EXCLUSIEF schrikkeljaar). Dus je lookup wordt: 0, 31, 59 etc).
* Tel je terug vanaf 24 januari, dan is dat dus 24 + 0 = 24 dagen. Tel je terug vanaf 24 maart, is dat dus 24 + 59 = geenzininomoptellen).
* Daarna ga je controleren of je in een schrikkeljaar zit en zo ja, of je NA de schrikkeldag zit (dus maand 3 of hoger). Is dat zo, tel er 1 bij op. Dit is dus je schrikkeldag in het eerste jaar.
* Nu gaat het snel, want je telt alle jaren die je terug wilt gaan (tot 1900 bijvoorbeeld) terug, 2002-1900 is 102*365 = veel dagen.
* Daarna ga je kijken hoeveel jaren er tussen 1900 en 2002 (2002 NIET MEEREKEND DUS) schrikkeljaar zijn. Zoveel dagen tel er erbij op.

Et voila, je hebt je datum in dagen.

hhmm... dat is inderdaad een goed begin....

dan kan ik het aantal dagen dat ik eraf wou trekken er af halen.. en dan weer terug rekenen naar een datum...

dus delen door 366, het restant is resterende dagen.
dan kijken hoeveel van de jaren GEEN schrikkel jaar waren, voor ieder "GEEN"schrikkeljaar" een bij het restant optellen, kijken of er dan nog een jaar uit kan, daarnaa aan de hand van de eerder genoemde array bepalen in welke maand we zitten, ook ff checken of we in een schrikkeljaar zitten...

vervolgens het restant bewaren alszijne de dag van de maand...


opgelost


of snap ik het nu zelf niet meer ?

[JayTaph]

Volgens mij wel, maar mijn interesse gaat op dit moment eventjes uit naar de brandweerauto die hier voor de deur staat, dus je moet het eventjes zelf uitproberen..

[Soultaker]

Als je het handig wil doen, gaan je niet "kijken" of "tellen" maar gewoon op basis van het wiskundige model berekeningen uitvoeren.

De decompositie in dagen, maanden en jaren is een goed begin. Van de 12 maanden kun je een tabelletje maken: januari begint met de 1e dag (dag 0) van het jaar, februari met de 32e (dag 31), etcetera.

Voor maanden en dagen wordt de code dus zoiets:

code:

int dagenCum[12]  = {0 ,31,59,90,120,151,181,212,243,273,304,334};
int dagenSCum[12] = {0 ,31,60,91,121,152,182,213,244,274,305,335};

int dagInJaar(jaar, maand, dag)
{
  return (schikkeljaar(jaar) ? dagenSCum : dagenCum) [maand-1] + dag-1;
}

Voor de jaren kun je simpele wiskunde gebruiken: een schikkeljaar is deelbaar door 4, maar niet deelbaar door 100, tenzij het jaar deelbaar is door 400. Je kunt dus zo wel berekenen hoeveel schikkeljaren er in een gegeven periode geweest zijn, zonder de jaren afzonderlijk na te lopen.

Dat leidt tot de volgende berekening van het aantal dagen sinds het jaar 0:

code:

365*d.jaar+1
+((d.jaar-1)/4)
-((d.jaar-1)/100)
+((d.jaar-1)/400)
+dagInJaar(d)

Op deze manier kun je dus in constante tijd een willekeurige datum omrekenen naar het aantal dagen sinds het jaar 0 (wat negatief is indien de datum VOOR het jaar 0 valt).

Terugrekenen gaat op een vergelijkbare manier, hoewel dat wat ingewikkelder is om in constante tijd te doen. Dat laat ik aan je creativiteit over, anders is er geen leuk werk meer voor jou over.

[curry684]

Hmmm jongens ik zal het maar even verklappen maar jullie staan allemaal het wiel opnieuw uit te vinden

Die 2 routines die ik een stuk hierboven gaf rekenen een datum (dd/mm/yyyy) om naar het aantal dagen sinds 1 januari 4713 BC, en vice versa. Hierbij kun je dus simpelweg tussendoor even -= 36503 doen.

[JayTaph]

Het gaat niet om het stuk code. Het gaat erom dat xychix weet hoe je zo'n vraagstuk oplost. Gaan sproeien met een stuk code lost misschien wel z'n probleem op dat moment op, maar weet hij dan wat hij gedaan heeft? Nee, en daar gaat het juist om (in /14).

[xychix]

curry bedankt voor die code, ik zal he eens door kijken..

zoals je in mijn "available" method list (hierboven ergens) kunt zien heb ik al een werkende julian gemaakt. en ook isschrikkel werkt al !

ik ga wel ff rustig die code doorlezen en zien of ik het snap en dan zelf nogmaals kan bouwen..

[Soultaker]

Op donderdag 25 april 2002 13:29 schreef curry684 het volgende:
Hmmm jongens ik zal het maar even verklappen maar jullie staan allemaal het wiel opnieuw uit te vinden

Die 2 routines die ik een stuk hierboven gaf rekenen een datum (dd/mm/yyyy) om naar het aantal dagen sinds 1 januari 4713 BC, en vice versa.

Ik ben het helemaal met JayTaph eens. Vrijwel al van dit soort functies zijn al een keer door iemand geprogrammeert, maar dat zegt niet dat het onverstandig is om zelf over de materie na te denken.

Daarbij vind ik de door jou (of Google) gepresenteerde code uitermate ranzig aangezien met floating point getallen gerekend wordt, terwijl alle berekeningen ook prima met gehele getallen uit te voeren zijn. Nu ga je een in principe exact probleem met een benadering oplossen. Dat is niet echt mijn idee van een mooi algoritme. Los daarvan is de werking van het algoritme (hoe men van de probleemstelling tot de code gekomen is) mij volkomen onduidelijk.

[curry684]

Op zaterdag 27 april 2002 18:13 schreef Soultaker het volgende:
Ik ben het helemaal met JayTaph eens. Vrijwel al van dit soort functies zijn al een keer door iemand geprogrammeert, maar dat zegt niet dat het onverstandig is om zelf over de materie na te denken.

Blaaaat... no offence naar xychix, maar het lijkt me wel duidelijk dat hij evenmin als jij en ik jaren ervaring heeft in wiskundige algoritmes. Dan kun je wel met een hoop moeite een stervenslangzame routine in mekaar draaien (heeft ie ook gedaan, hulde), maar als je vervolgens iets sneller wilt (waar dit hele topic om draait) kom je toch bij wiskundig geanalyseerde algoritmes uit. Zoals degene dit ik met Google in een paar minuutjes vond.

Daarbij vind ik de door jou (of Google) gepresenteerde code uitermate ranzig aangezien met floating point getallen gerekend wordt, terwijl alle berekeningen ook prima met gehele getallen uit te voeren zijn. Nu ga je een in principe exact probleem met een benadering oplossen.

Alsof tijd een exact probleem is... weet je dat er in onze Gregoriaanse kalender een rekenfout zit van een paar seconden per jaar die door het schrikkeljaarsysteem nog steeds niet gecompenseerd kan worden? Dat er ooit een keer 10 dagen (!!!) op de kalender zijn overgeslagen omdat er een te grote fout in was geslopen? Zolang je floating point fout maar vele cijfers achter de milliseconde-komma's zit, en ja de floating point error van dit algoritme zal op z'n best een paar nanoseconde per jaar zijn, heb je imho nog steeds een betere gain-to-cost ratio dan alle andere geleverde implementaties.

Dat is niet echt mijn idee van een mooi algoritme. Los daarvan is de werking van het algoritme (hoe men van de probleemstelling tot de code gekomen is) mij volkomen onduidelijk.

Dat is het voor- en nadeel van code die anderen voor je geoptimaliseerd hebben: onleesbaar maar getest. Verder behoeft het algoritme weinig toelichting: de Juliaanse kalender is in de astronomie nog steeds een standaard (zie Google's 24400 hits) en vandaar dat er zo'n precieze algo's de ronde doen.

[Soultaker]

Op maandag 29 april 2002 23:06 schreef curry684 het volgende:
Blaaaat...

Als dat je reactie is, zeg dan maar helemaal niets.

[Confusion]

Soultaker schreef:
Als dat je reactie is, zeg dan maar helemaal niets.

Werk doen dat anderen al voor je gedaan hebben is redelijk zinloos, tenzij je er iets van leert. Van dit probleem oplossen leer je echter niets, behalve dat de door ons verzonnen tijdrekening zuigt en dat het snel implementeren lastig is. Zonde man, je had je programma allang af kunnen hebben

[Soultaker]

Op maandag 29 april 2002 23:29 schreef Fused het volgende:
Werk doen dat anderen al voor je gedaan hebben is redelijk zinloos, tenzij je er iets van leert. Van dit probleem oplossen leer je echter niets, behalve dat de door ons verzonnen tijdrekening zuigt en dat het snel implementeren lastig is.

Ik leef toch in de veronderstelling dat ik het overgrote deel van mijn programmeerkennis en -ervaring met het oplossen van dit soort problemen heb opgedaan. Ik denk dus dat ik van problemen als deze wel degelijk wat geleerd heb, wat nog wordt bevestigd als ik mijn code vergelijk met die van de gemiddelde GoT-bezoeker, die zich beperkt tot het copy-past-en van andermans code.

Naar mijn mening is dit verschil in instelling nou precies wat gedreven programmeurs onderscheidt van mensen die eigenlijk alleen oog hebben voor het doel en niets geven om beheersing van de middelen. Dit zijn dan ook de mensen die op GoT elke keer weer op het bestaan van de FAQ, Google, tutorials, manuals, etcetera gewezen moeten worden.

Ik wil hiermee niet zeggen dat ik tegen het hergebruiken van code ben. Natuurlijk niet. Als iets al bestaat en goed werkt, kun je het net zo goed gebruiken. Voorwaarde is wel dat je zelf tot op een zeker nivo over het probleem nagedacht hebt, omdat je anders onmogelijk kan beoordelen of de gevonden implementatie geschikt is.

Tot slot, denk ik dat met de door diverse mensen gegeven aanwijzingen een efficiente en compacte implementatie voor het omrekenen van data van en naar dagen te maken is. Niets 'zuigen' of 'lastig te implementeren' dus, hoewel je er natuurlijk wel bij moet nadenken.

Zonde man, je had je programma allang af kunnen hebben

Heu? Ik ben hier geen programma over aan 't schrijven hoor.

[curry684]

Op maandag 29 april 2002 23:11 schreef Soultaker het volgende:
Als dat je reactie is, zeg dan maar helemaal niets.

Wat kinderachtig om zo te reageren op 1 woord en de pagina uitleg van het gebruik van dat woord te negeren.

Ik snap jou niet, laat ik even citeren wat er in post numero uno staat na een lap trage code:

alleen dit is ontzettend traag. weet iemand een duidelijk en sneller algorithme?

Met daarbij de toelichting:

Probleem definitie
Ik heb een datum bv 17-02-5004 en daar wil ik 36503 dagen vanaf halen. (elke willekeurige datum en aantal dagen moet gebruikt kunnen worden).

de uitkomst is een nieuwe datum.

hoe kan ik deze berekening snel uitvoeren ?

Wat is nu exact je probleem met dat ik die jongen help met exact z'n vraagstelling en niet inga op al jullie mumbo-jumbo die zal leiden tot een inferieure, tragere oplossing voor een door professionals tot in den treure uitgekristalliseerd probleem?!?

Ik vergelijk het van Google trekken van dit soort routines met het gebruiken van de standard libs en API's: als iemand anders het probleem al eens goed opgelost heeft moet je niet je vingers eraan willen branden om dan mogelijk met een algoritme te komen dat lijkt te werken en vervolgens in een andere situatie 3 eeuwen ernaast zit.

[curry684]

ps. nog voor Xychix: op de volgende pagina's van de NASA-website (!!!) vind je charmantere implementaties van die functies in IDL, kun je zelf makkelijk even omschrijven naar C/C++:
• Julian naar Gregoriaans converter.
• Gregoriaans naar Julian converter.

[Confusion]

Soultaker schreef:
Ik leef toch in de veronderstelling dat ik het overgrote deel van mijn programmeerkennis en -ervaring met het oplossen van dit soort problemen heb opgedaan.

Ik veronderstel dat jij zeker veel van je programmeerkennis en -ervaring hebt opgedaan met het oplossen van problemen. Alleen is dit niet één van die problemen waar iets van te leren valt op programmeergebied (althans, misschien zie ik het gewoon niet?). Ik zie alleen een wiskundig puzzeltje.

Je leert veel van problemen oplossen, wanneer je daar een nieuwe aanpak voor nodig hebt: het eerste probleem dat je met een linked list op lost, het eerste probleem dat je met recursie oplost, het eerste probleem dat je met bit-schuif-operaties oplost, etc.

Heu? Ik ben hier geen programma over aan 't schrijven hoor.

Was meer in het algemeen bedoeld.

[Soultaker]

Op dinsdag 30 april 2002 00:06 schreef curry684 het volgende:
Wat kinderachtig om zo te reageren op 1 woord en de pagina uitleg van het gebruik van dat woord te negeren.

Als je je reactie, hoe zinnig ook, al zo begint, ontgaat me de lust om er nog serieus op in te gaan. Dat wil niet zeggen dat ik het niet gelezen heb of het er niet mee eens ben. Als je wilt dat er met rede op jou stellingen gereageerd wordt, zul je tenminste respect moeten tonen voor de meningen van anderen. Als je vind dat die meningen niet kloppen, ontkracht ze dan, maar doe ze niet af met "blaaaat".

Wat is nu exact je probleem met dat ik die jongen help met exact z'n vraagstelling en niet inga op al jullie mumbo-jumbo die zal leiden tot een inferieure, tragere oplossing voor een door professionals tot in den treure uitgekristalliseerd probleem?!?

Ten eerste geef ik heel vaak de voorkeur aan een helder geschreven programma, wat dan misschien niet voluit geoptimaliseert is. Dat soort verschillen zijn meestal marginaal. Wat wel belangrijk is, is ruimte- en tijdcomplexiteit. Aangezien die nogal te wensen overlieten, kon het dus wel uit om zelf een algoritme te verzinnen. De suggesties die gedaan zijn, zijn in mijn ogen dan ook niet inferieur.

Ik vergelijk het van Google trekken van dit soort routines met het gebruiken van de standard libs en API's: als iemand anders het probleem al eens goed opgelost heeft moet je niet je vingers eraan willen branden om dan mogelijk met een algoritme te komen dat lijkt te werken en vervolgens in een andere situatie 3 eeuwen ernaast zit.

En daar heb je gelijk mijn tweede argument: functies opzoeken in Google, API's en libraries kunnen we allemaal wel (als het goed is, tenminste). Naar mijn mening is het doel van GoT juist om problemen wat fundamenteler te bespreken en niet met een ad hoc oplossing aan te komen zetten met het argument 'dit werkt toch'. Dat zou betekenen dat je voor elk zelfde onderwerp met een andere programmeertaal een nieuwe thread zou moeten starten en onderwerpen over algemene zaken zoals bijvoorbeeld ontwerp wel af kunt schaffen.

Ten derde het argument wat ik al eerder noemde: als je je nooit verdiept in dit soort problemen, kun je een oplossing van iemand anders ook nooit doorgronden en nooit beoordelen wat de eigenschappen van die implementatie zijn. Jij zegt dat de algoritmes die door mij en anderen zijn voorgesteld er in sommige situaties '3 eeuwen naastzitten' maar uit niets blijkt dat de door jou gevonden code nauwkeuriger werkt. Uit wat schijnbaar willekeurige constanten en operaties op de invoerparameters kan ik in ieder geval niet opmaken wat er precies met de invoer gebeurt en of er bijvoorbeeld gecorrigeerd wordt voor zaken als schrikkelseconden.

Tenslotte zul je niet voor elk probleem een standaardoplossing kunnen vinden. Als je gewend bent om problemen met eigen implementaties op te lossen (of in ieder geval over de werking van implementaties na te denken) bestaat de mogelijkheid dat je in zo'n geval zelf met een geschikte oplossing komt.

[Soultaker]

Op dinsdag 30 april 2002 00:37 schreef Fused het volgende:
Je leert veel van problemen oplossen, wanneer je daar een nieuwe aanpak voor nodig hebt: het eerste probleem dat je met een linked list op lost, het eerste probleem dat je met recursie oplost, het eerste probleem dat je met bit-schuif-operaties oplost, etc.

Daar zit inderdaad wel een kern van waarheid in. Mijn ervaring is dat een heleboel problemen op dezelfde basisprincipes (algoritmen, datastructuren, etcetera) terug te voeren zijn.

In de praktijk zul je ze echter moeten combineren. Om de juiste principes te herkennen bij een gegeven probleem, zul je een zekere routine moeten opbouwen. Daardoor zijn dit soort problemen, zelfs als ze geen nieuwe principes bevatten, vaak toch leerzaam.

In dit specifieke voorbeeld is het bijvoorbeeld van belang dat je inziet, dat je geen lusjes hoeft te doorlopen om tot een oplossing te komen. Om dat te verzinnen hoef je geen genie te zijn, natuurlijk, maar uit het feit alleen al dat xychix het niet bedacht had en JayTaph wel, blijkt al dat er verschil zit tussen het 'oplossingsvermogen' van verschillende programmeurs.

[JayTaph]

Op dinsdag 30 april 2002 00:06 schreef curry684 het volgende:

Wat is nu exact je probleem met dat ik die jongen help met exact z'n vraagstelling en niet inga op al jullie mumbo-jumbo die zal leiden tot een inferieure, tragere oplossing voor een door professionals tot in den treure uitgekristalliseerd probleem?!?

Omdat als ik zo'n stukje code (die jij ook nog niet eens zelf in elkaar hebt gezet, laat staan begrijpt of kunt bewijzen), inlever bij mijn baas, ik hoogst persoonlijk zo gigantisch hard door hem naar buiten word geschopt, dat ik jaren later nog steeds niet precies weet wat me is overkomen.

Als ik een stuk code schrijf, dan moet dat duidelijk zijn in elke vorm. Voor zowel mezelf, voor eventuele collega's die er later aan moeten werken, voor de klant en voor de baas.

Waarom word in je copypaste-functie a gelijk aan z als z kleiner is dan 2299161? En waar staat die 1720994 of 1867216.25 precies voor? En whatthehell is xj en waarom moet ik daar b (whatever dat is) erbij optellen zodra reform!=0 is? Oeps, bugje in de code, om de 10 jaar gaat er 1 dag in het jaar fout.. en nu? Kan je een grove inschatting geven aan de baas waar er eventueel een mogelijke fout kan zitten? Nee, omdat alles zodanig is geoptimaliseerd dat alles van elkaar afhangt en samenhangt.
Zou ik zo'n stuk code onder mijn hoede krijgen, dan ben ik al mijn kostbare tijd aan het verspillen met het onnodig uitzoeken van algoritmes en wiskundige optimalisaties omdat iemand het niet nodig achtte om duidelijk te zijn.

Het is een onduidelijk geheel dat zodanig berust op een wiskundige algoritme dat het programmeertechnisch een chaos is geworden waar je absoluut geen grip meer op kunt krijgen zolang je niet de complete kennis hebt van de juliaanse kalender en converterings-algoritmes. Iets wat je ZEKER niet nodig zou moeten hebben voor een functie dat niet eens tijd-kritisch genoemd mag worden (ik kan zo ook niet echt een context bedenken waarin deze functie WEL tijd-kritisch zou moeten zijn).

Optimalisatie is 1 ding, en mocht de nood echt zo hoog worden dat ik een zo snelle routine heb, dan kun je altijd naderhand nog kijken of dit een geschikte routine is voor je doeleinden maar dat lijkt me sterk. Daarbij lijkt me de tijdwinst tussen xychix eerste functie en "onze" oplossing zodanig groot genoeg dat die optimalisatie niet eens rendabel is.

Daarnaast help je xychix niet. Net zoals je een leerling niet help door zijn huiswerk te maken. Waar je hem wel mee helpt is door het probleem (maakt niet uit welk) te analyseren, in stappen op te delen en deze een voor een uit te werken. En pas daarna mag je eventueel gaan nadenken over optimalisatie mocht het nodig zijn.

Ik vergelijk het van Google trekken van dit soort routines met het gebruiken van de standard libs en API's: als iemand anders het probleem al eens goed opgelost heeft moet je niet je vingers eraan willen branden om dan mogelijk met een algoritme te komen dat lijkt te werken en vervolgens in een andere situatie 3 eeuwen ernaast zit.

En zoals soultaker de woorden uit mijn mond nam: Dat verklaard meteen hier het niveau van de meeste mensen. Zolang de ctrl-c en ctrl-v toetsjes werken is er niets mis.. maar o wee als ze zelf eventjes moeten nadenken over hetgeen waar ze mee bezig zijn.


Traag? Zeker niet voor zijn doel. Superieur? Wiskundig gezien zeker maar op alle andere vlakken duidelijk niet. Leesbaarheid en modulariteit zijn in dit geval veel belangrijker.

Dus mocht je de volgende keer weer willen pronken met superieure code (van iemand anders), dan graag wel in een toepasselijk topic.

[curry684]

Op dinsdag 30 april 2002 00:55 schreef Soultaker het volgende:
Als je je reactie, hoe zinnig ook, al zo begint, ontgaat me de lust om er nog serieus op in te gaan. Dat wil niet zeggen dat ik het niet gelezen heb of het er niet mee eens ben. Als je wilt dat er met rede op jou stellingen gereageerd wordt, zul je tenminste respect moeten tonen voor de meningen van anderen.

Tja wellicht leg jij een andere emotionele waarde in 'blaat' dan ik, ik geef het namelijk geen. Je gaf imho een enorm verhaal dat irrelevant was voor de eigenlijke kwestie, oftewel een 'blaatverhaal'.

Als je vind dat die meningen niet kloppen, ontkracht ze dan, maar doe ze niet af met "blaaaat".

Erm die enorme lap tekst achter dat woord lijkt me toch in de eerste plaats niet 'afdoen met een woord' en ten tweede genoeg poging tot ontkrachting. Ik stoorde me dan ook vooral aan het negeren van die pagina tekst, en met deze zin impliceer je wederom dat je niet verder hebt gelezen.

Ten eerste geef ik heel vaak de voorkeur aan een helder geschreven programma, wat dan misschien niet voluit geoptimaliseert is. Dat soort verschillen zijn meestal marginaal. Wat wel belangrijk is, is ruimte- en tijdcomplexiteit. Aangezien die nogal te wensen overlieten, kon het dus wel uit om zelf een algoritme te verzinnen. De suggesties die gedaan zijn, zijn in mijn ogen dan ook niet inferieur.

Op zich een begrijpelijk verschil van mening, en een niet-verschil aan mening. Als ik code ergens anders vandaan haal herschrijf ik de code altijd naar mijn eigen coding style en becommentariseer ik het hele ding, waarvoor doorgronding idd nodig is. Tot zoverre inderdaad is het rommelige onduidelijke code. Ik heb echter ook al aangegeven hoe je met Google 24400 pagina's uitleg kunt krijgen over de Juliaanse kalender en conversiemethodes, en daarmee vind ik a) de methode voldoende getest en bewezen en b) dat ik niet meer uitleg hier hoef te geven, hij kan het zelf ook vinden.

En daar heb je gelijk mijn tweede argument: functies opzoeken in Google, API's en libraries kunnen we allemaal wel (als het goed is, tenminste).

Blijkbaar niet, anders hadden anderen deze wel eerder gepresenteerd dan ik.

Naar mijn mening is het doel van GoT juist om problemen wat fundamenteler te bespreken en niet met een ad hoc oplossing aan te komen zetten met het argument 'dit werkt toch'.

En dat vind ik dus onzin. Die jongen vraagt een sneller algoritme omdat ie er zelf niet uitkomt, en dat lever ik. Dan is zijn vraag opgelost, hebben medelezers ook nuttige info en most of all: de deur staat niet dicht voor verdere discussie en/of uitpluizing van het algoritme indien mensen daar behoefte aan hebben. Volgens mij heeft Xychix voldoende kennis om met Google dit algo uit te kunnen pluizen, en zo niet kunnen we er hier met z'n allen over verder jeremieren. Maar om bij voorbaat professionele en bestaande en vooral doorgeteste oplossingen af te zweren omdat 'je het dan niet zelf doet' is onzin.

Heb jij ooit het bewijs geleverd voor de formule sqr(b*b - 4ac) / 2a waarmee je de hele middelbare school 2e-graadsvergelijkingen hebt opgelost? Nee, maar hij werkt wel en het is de snelste manier. Heb jij ooit bewezen dat m*g*h de zwaarteenergie van een object aangeeft? Nee maar het werkt wel! Wat ik vooral probeer te zeggen: ga nou asjeblieft niet het opnieuw uitvinden van het wiel heilig verklaren en pak voor standaardproblemen de globaal geaccepteerde standaardoplossingen.

Ten derde het argument wat ik al eerder noemde: als je je nooit verdiept in dit soort problemen, kun je een oplossing van iemand anders ook nooit doorgronden en nooit beoordelen wat de eigenschappen van die implementatie zijn.

Daarom becommentariseer ik dit soort leencode altijd en herschrijf ik het tot mijn eigen codestyle met leesbare variabelen e.d.

Jij zegt dat de algoritmes die door mij en anderen zijn voorgesteld er in sommige situaties '3 eeuwen naastzitten' maar uit niets blijkt dat de door jou gevonden code nauwkeuriger werkt.

Ik zeg niet dat jouw algo per definitie onnauwkeuriger is, ik zeg alleen dat de kans aanzienlijk is dat je rekenfouten/bugs introduceert. Daarentegen wordt het door mij geleverde algo al tientallen jaren door de NASA gebruikt om ruimteschepen op de maan te zetten: en geloof maar dat een miniem rekenfoutje dan fataal is.

En als laatste voor Jaytaph:

Omdat als ik zo'n stukje code (die jij ook nog niet eens zelf in elkaar hebt gezet, laat staan begrijpt of kunt bewijzen), inlever bij mijn baas, ik hoogst persoonlijk zo gigantisch hard door hem naar buiten word geschopt, dat ik jaren later nog steeds niet precies weet wat me is overkomen.

Mijn baas schupt me juist de deur uit als ik dagen verspil op het opnieuw uitvinden van het wiel waarna het vierkant blijkt te zijn. Hij ziet liever binnen korte tijd snelle betrouwbare code...

[Soultaker]

Mooi is dat; type ik een uitgebreide reactie, blijkt de topic gesloten te zijn wanneer ik m'n bericht verstuur. Had 'm dan gewoon open gelaten, dan had ik niet voor niets zitten typen.

[curry684]

D2K had topic gesloten omdat hij meende dat het richting moddergooien afdaalde, na discussie via ICQ heropend daar de licht off-topic discussie zekers interessant is voor het forum.

Ik ben vooral benieuwd naar wat Xychix ondertussen te zeggen heeft, en wat z'n originele insteek was voor het topic: is ie geinteresseerd in een goed functionerende date-class (waarvoor ik de aanzet gaf) of is ie vooral benieuwd naar hoe je zelf een algoritme ontwikkeld voor snelle datumberekeningen (waar Soultaker en Jaytaph naar sturen).

[xychix]

Op dinsdag 30 april 2002 16:49 schreef curry684 het volgende:
D2K had topic gesloten omdat hij meende dat het richting moddergooien afdaalde, na discussie via ICQ heropend daar de licht off-topic discussie zekers interessant is voor het forum.

Ik ben vooral benieuwd naar wat Xychix ondertussen te zeggen heeft, en wat z'n originele insteek was voor het topic: is ie geinteresseerd in een goed functionerende date-class (waarvoor ik de aanzet gaf) of is ie vooral benieuwd naar hoe je zelf een algoritme ontwikkeld voor snelle datumberekeningen (waar Soultaker en Jaytaph naar sturen).

hierbij de door mij 100% zelf bedachte code met dank aan iedereen hier
_{vooral aan JayTaph}

code:

int ADatum::ToInteger() const
{
    //aantal dagen verschil met 1900.

    int jaar, datumnummer;
    jaar = this->GetJaar() - 1900;
    datumnummer = this->GetDagnummer();
    while(jaar > 0)
    {
        if (IsSchrikkeljaar(jaar - 1))
        {
            if(jaar > 4)
            {
                jaar = jaar - 4;
                datumnummer = datumnummer + (3*365 + 366);
            }
            else
            {
                jaar = jaar -1;
                datumnummer = datumnummer + 366;
            }
        }
        else
        {
            jaar = jaar -1;
            datumnummer = datumnummer + 365;
        }
    }
    while(jaar < 0)
    {
        if (IsSchrikkeljaar(jaar))
        {
            if(jaar < -4)
            {
                jaar = jaar + 4;
                datumnummer = datumnummer - (3*365 + 366);
            }
            else
            {
                jaar = jaar +1;
                datumnummer = datumnummer - 366;
            }
        }
        else
        {
            jaar = jaar +1;
            datumnummer = datumnummer - 365;
        }
    }
    return datumnummer;
}

void ADatum::FromInteger(const int datumnummerInvoer)
{
    static int aantdagenSCHRIK[13]={0,31,29,31,30,31,30,31,31,30,31,30,31};
    static int aantdagen[13]     ={0,31,28,31,30,31,30,31,31,30,31,30,31};
    int jaar, maand, dag, datumnummer;
    datumnummer = datumnummerInvoer;
    jaar = 1900;
    dag = 1;
    maand = 1;
/*  if(datumnummer == 0)
    {

    }*/
    while(datumnummer > 366)
    {
        if(IsSchrikkeljaar(jaar))
        {
            if(datumnummer > ((3*365) + 366) )
            {
                jaar = jaar + 4;
                datumnummer = datumnummer - ((3*365) + 366);
            }
            else
            {
                jaar = jaar + 1;    
                datumnummer = datumnummer - 366;                
            }
        }
        else
        {
            jaar = jaar + 1;
            datumnummer = datumnummer - 365;
        }

    }

    while(datumnummer <= 0)
    {
        if(IsSchrikkeljaar(jaar))
        {
            if(datumnummer < ((3*-365) - 366) )
            {
                jaar = jaar - 4;
                datumnummer = datumnummer + ((3*365) + 366);
            }
            else
            {
                jaar = jaar - 1;    
                datumnummer = datumnummer + 366;                
            }
        }
        else
        {
            jaar = jaar - 1;
            datumnummer = datumnummer + 365;
        }

    }


    if(IsSchrikkeljaar(jaar))
    {
        while(aantdagenSCHRIK[maand] < datumnummer)
        {
            maand++;
            datumnummer = datumnummer - aantdagenSCHRIK[maand];
        }
        dag = datumnummer;
    }
    else if(datumnummer == 366)
    {
        jaar++;
        maand = 1;
        dag = 1;
    }
    else
    {
        while(aantdagen[maand] < datumnummer)
        {
            maand++;
            datumnummer = datumnummer - aantdagen[maand];
        }
        dag = datumnummer;
    }
    this->SetDag(dag);
    this->SetMaand(maand);
    this->SetJaar(jaar);
}

[xychix]

ik ben eens met pen en papier begonnen...

ik heb alleen nog een probleem bij de overgang 31-12-1900
naar 1-1-1901

daar slaat hij een int over !

maar daar kom ik nog wel uit !

de code is nog niet netjes gemaakt, zit nog wat waardeloos commentaar in ( int == 0 ofzo...)
excuses daarvoor

waarschijnlijk is de code nog niet 100% geoptimaliseerd, maar dat was niet het hoofddoel ! het is stukken sneller nu !

[JayTaph]

Da's mooi dat we in ieder geval hebben kunnen helpen. En als je nog snellere code nodig dan heeft Curry684 hier ergens nog een algoritme liggen

[xychix]

het doel was om er iets van te leren, we hebben hier al een Datum Klasse draaien, deze zal nooit is productie gaan, als het dus nog sneller moet zal ik niet alleen stappen van 1 of 4 maar ook van 100 / 400 jaar gaan nemen.

want van 400 jaar kun je exact zeggen hoeveel dagen het bevat.

van 1 / 4 en 100 kun je dat niet..

[woutertjez]

Ik heb ook een methode met de Juliaanse dag gebruikt net zoals curry684 (ben er pas net mee klaar).

Als je dit stuk code twee keer gebruikt en dan de ene uitkomst van de andere afhaalt, dan heb je het aantal dagen verschil.

Ik ben er hier vanuit gegaan dat de datum als een getal wordt ingelezen. In de vorm van YYYYMMDD

code:

      #include <math.h>
      #include <string.h>
      #include <stdlib.h>
    
      sprintf(conv_greg_date, "%d", (int)greg_date);        //date converted to string

    
    if (strlen(conv_greg_date) == 9)                    //Date before the year 0 (BC)
    {
        i = -1;
        conv_years[0] = conv_greg_date[0];
        conv_years[1] = conv_greg_date[1];
        conv_years[2] = conv_greg_date[2];
        conv_years[3] = conv_greg_date[3];
        conv_years[4] = conv_greg_date[4];
        conv_years[5] = '\0';
    }
    else if (strlen(conv_greg_date) == 8)        //Datum in de vorm van YYYYMMDD
    {
        i = 0;
        conv_years[0] = conv_greg_date[0];
        conv_years[1] = conv_greg_date[1];
        conv_years[2] = conv_greg_date[2];
        conv_years[3] = conv_greg_date[3];
        conv_years[4] = '\0';
    }
    else if (strlen(conv_greg_date) == 7)     //Datum in de vorm van YYYMMDD
    {
        i = 1;
        conv_years[0] = conv_greg_date[0];
        conv_years[1] = conv_greg_date[1];
        conv_years[2] = conv_greg_date[2];
        conv_years[3] = '\0';
    }
    else if (strlen(conv_greg_date) == 6)     //Datum in de vorm van YYMMDD
    {
        i = 2;
        conv_years[0] = conv_greg_date[0];
        conv_years[1] = conv_greg_date[1];
        conv_years[2] = '\0';
    }
    else if (strlen(conv_greg_date) == 5)     //Datum in de vorm van YMMDD
    {
        i = 3;
        conv_years[0] = conv_greg_date[0];
        conv_years[1] = '\0';
    }
    else if (strlen(conv_greg_date) == 4)      //Datum in de vorm van MMDD  (jaar nul)
    {
        i = 4;
        conv_years[0] = '0';
        conv_years[1] = '\0';
    }
    
    conv_months[0] = conv_greg_date[4 - i];
    conv_months[1] = conv_greg_date[5 - i];
    conv_months[2] = '\0';
    conv_days[0] = conv_greg_date[6 - i];
    conv_days[1] = conv_greg_date[7 - i];
    conv_days[2] = '\0';
    
    yyyy = atoi(conv_years);
    mm = atoi(conv_months);
    dd = atoi(conv_days);

    
    day = dd

    if (mm > 2)
    {
        month = mm;
        year = yyyy;
    }
    else
    {
        month = mm + 12;
        year = yyyy - 1;
    }

    greg_part = 0;
    if (greg_date >= 15821015)   //Overgang op Gregoriaanse kalender)
    {
        hulp = (int)floor(year/100);
        greg_part = 2 - hulp + (int)floor(hulp/4);
    }

    julian_day = floor(365.25*year) + floor(30.6001*(month + 1)) + day + 1720994.5 + greg_part;
          //Julian Day is nu bekend

Misschien dat je er wat aan hebt. Bij mij werkt het in ieder geval wel goed. Ik gebruik 't zelf om de Local Sidereal Time uit te rekenen, dus ik heb maar een stukje van m'n code eruit gecopy-paste.

[curry684]

Op donderdag 02 mei 2002 15:34 schreef JayTaph het volgende:
Da's mooi dat we in ieder geval hebben kunnen helpen. En als je nog snellere code nodig dan heeft Curry684 hier ergens nog een algoritme liggen

[Soultaker]

Op vrijdag 03 mei 2002 11:32 schreef xychix het volgende:
als het dus nog sneller moet zal ik niet alleen stappen van 1 of 4 maar ook van 100 / 400 jaar gaan nemen.

Zoals ik al in mijn eerste reactie zei: je kan beter helemaal geen stappen nemen! Het is een probleem van constante tijd, dus in principe zou het niet uit hoeven maken hoever je data van het jaar 1900, jaar 0 of een andere referentiedatum afliggen.

In mijn eerste reactie staat ook een regeltje code wat daarbij behulpzaam kan zijn, maar ik zou niet meteen durven garanderen dat 't ook voor jaartallen onder 0 werkt. Daar zul je dus even zelf mee aan de slag moeten.