Overleg sjabloon:FRCNEWYEAR

Ik weet niet of het mogelijk is (vermoed van wel) om eenvoudig voor een doorlopende reeks jaren een jaaraanvangsdatum op te geven.

Als dat kan is hier de reeks voor de overige jaren (systeem van commissie Romme):
1806: 23 september
1807: 24 september
1808 t/m 1891: 23 september
1892 t/m 1899: 22 september
1900 t/m 1991: 23 september
1992 t/m 2091: 22 september
2092 t/m 2099: 21 september
2100 t/m 2199: 22 september
2200 t/m 2291: 23 september
Vervolgens steeds herhaling van 400 jaar eerder, t/m 5791, want vanaf 5792, 9792, 13792 enz. valt de aanvangsdag steeds 1 dag eerder, dus van 13792 t/m 13799 op 19 september.

Uiteraard heeft het weinig praktisch nut, en bovendien zal tegen die tijd de gregoriaanse kalender wel vervallen of aangepast zijn. Maar het is niet veel werk, en het is bevredigender het vanaf het begin gedurende vele eeuwen voor elkaar te hebben.

Helaas snap ik niets van het sjabloon, anders zou ik het zelf doen. - LexTH 15 jun 2008 19:39 (CEST)

Bedankt, deze info zocht ik inderdaad. Ik heb 1806 en 1807 alvast bij de uitzonderingen gezet. Voor de rest moet ik mijn kennis van de parser functions even opfrissen.

Dat vanaf 5792 wordt natuurlijk veroorzaakt door de 4000-jarige cyclus die de FRC wel heeft en de GC (nog) niet, maar die wel al enige tijd wordt voorgesteld en er ook wel zal komen tegen die tijd. Bovendien is dat vèr na onze tijd, dus daar ga ik me niet druk om maken. Verder is er als ik me goed herinner nooit iets besloten over negatieve FRC-jaartallen.

Het makkelijkste zal zijn om het Gregoriaanse jaartal modulo 400 te testen tegen waarden van 0 t/m 399. Dan krijgen we het lijstje:

000 t/m 091: 22 september
092 t/m 099: 21 september
100 t/m 199: 22 september
200 t/m 291: 23 september
292 t/m 299: 22 september
300 t/m 391: 23 september
392 t/m 399: 22 september

400 modulo 400 is 0, dus dan begint het lijstje van voren af aan. De afwijkende jaren van 1792 t/m 1807 moeten apart worden vermeld, zoals dat nu ook al gebeurt. RToV 15 jun 2008 22:10 (CEST)

Dit lijkt me inderdaad correct. Modulo 400 werkt reuze handig, daar had ik domweg niet aan gedacht, terwijl het eigenlijk erg voor de hand ligt.

Ik schreef hierboven systeem commissie Romme, maar eigenlijk is dat niet helemaal correct. Dan zou het zonder de uitzonderingsjaren zijn, want het voorstel gold ook al voor de eerste schrikkeljaren. De uitzonderingen zijn nodig omdat in werkelijkheid juist niet het systeem Romme gevolgd is, zodat het pas na het jaar XVI kan ingaan. XV is het laatste jaar waarvan officieel vastgesteld is dat het schrikkeljaar zou zijn, en dan mag XVI niet ook schrikkeljaar zijn, wat het volgens Romme wel is.

Wat betreft negatieve jaartallen: er is inderdaad besloten dat de kalender niet met terugwerkende kracht werkt. Data voor het jaar I worden in de gregoriaanse kalender uitgedrukt.

Het heen en terugstappen wordt veroorzaakt doordat in de eeuwjaren, behalve in de 400-vouden, een schrikkeldag wordt overgeslagen; dan gaat de aanvangdatum (die in de greg. kal. wordt uitgedrukt) naar 1 dag later. Na de jaren C, CC en CCC, dus in 1892, 1992 en 2092 wordt juist de republikeinse schrikkeldag overgeslagen, zodat vanaf dan de aanvangsdag 1 dag eerder valt. CD (2192) is geen rep. schrikkeljaar, dan gebeurt er dus niets. Misschien is benadering via deze weg nog wel eenvoudiger.

J=jaartal (greg)

INT(J/100)-INT(J/400)-INT((J-192)/100)+INT((J-192)/400)+21 levert de dag in september. Uiteraard na de uitzonderingsjaren.

- LexTH 16 jun 2008 03:12 (CEST)

Verweg liggende jaren

Ik probeer de sjablonen te begrijpen, en daarbij stuitte ik op de opmerking dat de tijdfuncties niet (goed) werken voor 1970 en na 2038. Ik dacht dat ik het niet goed begreep omdat ze hier veelvuldig worden gebruikt, en er nu juist wordt geprobeerd het voor en na die datum voor elkaar te krijgen. Maar inmiddels is RToV er ook op gestuit.

De enige manier om het voor elkaar te krijgen is dus nieuwe sjablonen maken waarin de tijdfuncties vermeden worden. Dat kan, maar is het zinvol? Als het enige doel is het actuele kalenderblad te tonen hoeft alleen met de toekomst rekening gehouden te worden. Alleen als het de bedoeling is de sjablonen ook te gebruiken bij berekeningen voor andere tijdstippen dan het heden is deze grote operatie zinvol. Is dit inderdaad de bedoeling? - LexTH 17 jun 2008 16:27 (CEST)

Wat ik wilde zeggen, Lex: algoritmiseren kun je, dus programmeren zal ook wel lukken. Ik raad je aan je te verdiepen in sjablonen, parserfunctions en magic words als je dat nog niet hebt gedaan. Daarmee kun je veel plezier beleven en nuttig werk doen voor Wikipedia. Verdere info is via deze pagina's te vinden.

Wat betreft je vraag. We zijn bezig om het sjabloon geschikt te maken voor alle jaartallen: dat is een nobel streven. Het sjabloon maakt gebruik van een functie die is onderworpen aan systeembeperkingen: het zij zo. Ik had deze en andere beperkingen al eerder ontdekt en besloten ze te negeren, in afwachting van een structurele oplossing. Die komt waarschijnlijk binnen enkele jaren met de invoering van 64-bits Unix. Voor 32-bits varianten zal ook wel wat worden verzonnen.

Zal nog even kijken of ik Romme kan activeren vanavond. Je poging was op de goede weg, maar niet helemaal juist. Leg ik je uit als ik mijn geheugen voor de werking van de FRC-functies heb opgefrist.

Ben trouwens blij met je interesse voor de Franse kalender en de sjablonen. Op Gebruiker:RToV/Bouwen/Franse republikeinse kalender vind je meer info. Zie ook m:Help:Magic words#Local time voor analogieën. RToV 17 jun 2008 18:30 (CEST)

Bedankt voor de informatie RToV, ik ga er zeker naar kijken. Gedeeltelijk had ik het al gevonden, maar niet alles. En die uitleg zie ik graag tegemoet. - LexTH 17 jun 2008 21:06 (CEST)

Romme doet het nu. Het probleem met die onverwachte operator bleek een bug in {Date2FrcDate} te zijn. Had niets met onze wijziging te maken, maar kwam zo wel aan het licht. Voor uitleg heb ik vandaag geen tijd meer. Tot later. RToV 17 jun 2008 21:26 (CEST)

Afronden geeft niet de juiste resultaten, maar als ik het vervang door floor, wat rekentechnisch het juiste is, zelfs als je met negatieve getallen werkt, komt er steeds een foutmelding. De formule doet het in de evaluator wel goed, dus misschien zit er nog steeds een fout in een van de andere sjablonen. - LexTH 17 jun 2008 22:28 (CEST)

Ik heb het nu voor elkaar, geen foutmelding meer. Maar het eindresultaat was nu een dag eerder dan de bedoeling is. De formule met round produceert als aanvangsdatum 20080923, terwijl die met floor correct 20080922 geeft. Kennelijk compenseert de wijziging van sjabloon Date2FrcDate deze fout toevallig net. Deze bugfix kan m.i. niet correct zijn, want FRCNEWYEAR krijgt als parameter Ymd mee i.p.v. alleen een jaartal. Maar nu ga ik naar bed. - LexTH 18 jun 2008 03:14 (CEST)

Ik geloof dat het nu voor elkaar is, tenminste als de huidige restrictie tot 1970-2038 vervalt bij de #time-functies. Het laatste probleem school in FRCNEWYEAR/Romme. Enerzijds evolueert de #time-functie niet losse jaartallen, anderzijds wordt de parameter ook in delingen gebruikt. RToV, om de eerste reden had jij kennelijk de parameter verlengd tot Ymd, en om de tweede reden had ik er weer Y van gemaakt. Nu heb ik de eerst #time-functie vervangen door rechtstreeks gebruik van de parameter. Door al dat gepruts begin ik wel te snappen hoe de sjablonen werken, aanvankelijk begreep ik er niets van. - LexTH 18 jun 2008 16:18 (CEST)

Ik zie dat je je prima amuseert en laat je lekker je gang gaan. Dat komt mij goed uit, want vanavond heb ik geen tijd. Wel een paar hints:

• #time evalueert wel degelijk onvolledige input, maar jaartallen (juister: numerieke input) worden opgevat als een tijd, indien mogelijk. Dus 2008 wordt 20:08 uur. Dit staat ook op m:Help:ParserFunctions onder #time.
• Vanwege deze eigenschap werken {{Date2FrcDate}} en zijn subsjablonen met een volledige datum YYYYMMDD als parameter. Dat heeft tevens het voordeel ze elkaar kunnen aanroepen en daarbij hun parameter 1-op-1 kunnen doorgeven. Ook /Romme werkt daarom met een volledige datum.
• {{Date2FrcDate}} is het enige sjabloon dat omrekent van een Gregoriaanse naar een Franse datum. {{FRCNEWYEAR}} is op te vatten als een subsjabloon ervan, en dit is de enige plaats waar de relatie tussen de kalenders is vastgelegd. Deze relatie ligt op jaar en dagnummer in dat jaar, dus een Greg datum YYYYDDD correspondeert met één Franse datum YYYDDD.
• De overige Frc-functies rekenen de Franse datum om naar een jaar, een maandnummer, een dagnaam, een decadenummer enz. in de Franse kalender. Ook hier werken alle sjablonen met een volledige datumspecificatie. In dit geval een Franse in het formaat YYYDDD.
• Het geheel van {{Date2FrcDate}}, {{Date2FrcDate/2}}, {{FRCNEWYEAR}} en {{FRCNEWYEAR/Romme}} is nogal krakkemikkig. Nu we hebben gekozen voor Romme, kan hier wel een beter algorithme voor worden bedacht. (Met de equinoxmethode ging dat natuurlijk niet.) Ik denk dat je hier het beste mee kunt beginnen, dat maakt zoeken naar mijn bugs overbodig. Eigen bugs zijn doorgaans makkelijker te vinden en op te lossen. :-)

Veel plezier vanavond, zal morgen proberen te kijken wat je hebt gedaan. RToV 18 jun 2008 18:30 (CEST)

Ik heb Romme opgenomen in FRCNEWYEAR, dat nu ook met de YYYYMMDD parameter werkt. Die wordt nu dus overal gebruikt, wat ook ik een verbetering vind. Ik was ook begonnen met het samenvoegen van Date2FrcDate en Date2FrcDate/2, om te vermijden dat parameters nodeloos berekend worden. Maar daar staat tegenover dat sommige variabelen dan meermaals berekend moeten worden. Omdat de parameternamen het geheel begrijpelijker maken heb ik er verder vanafgezien. Alleen heb ik de programmaregel in stukken gebroken, omdat hij ver buiten het scherm uitstak en je dus steeds moest schuiven.

Bij de Romme operatie zag ik trouwens dat het probleem dat YYYY geëvalueerd moest worden door #time:Y ook bij de uitzonderingsjaren voorkwam; dit kwam niet naar voren doordat die jaren niet gecontroleerd kunnen worden. Ik heb het nu trouwens toch gedaan door de uitzonderingsjaren even te veranderen in recente. - LexTH 18 jun 2008 22:31 (CEST)

Wat denk je hier van: Er komen maar drie #time-functies voor: Y, z en Ymd. Het is niet moeilijk om daar aparte functies voor te schrijven die voor alle jaren van de gregoriaanse kalender werken. Je kunt het immers beperken tot maar 1 soort invoerparameter, YYYYMMDD. Y en Ymd zijn zeer eenvoudig, z is iets meer werk. Eigenlijk zijn Y en Ymd zo eenvoudig dat ze gewoon in de programmaregel kunnen worden gezet "trunc({{{1}}}/10000)" en "{{{1}}}-10000", want de laatste wordt alleen gebruikt om het vorig jaar te bepalen. Op deze wijze hoeft er niet gewacht te worden op een verbetering van de #time-functie. Een leuke toepassing zou zijn dat je dan een kalender met invuldatum op de pagina zou kunnen zetten, maar ik heb geen idee hoe dat moet. - LexTH 19 jun 2008 11:43 (CEST)

Ik heb de #time-functies verwijderd uit FRCNEWYEAR en Date2FrcDate. Daartoe heb ik Sjabloon:GregDoY aangemaakt, dat de #time:z functie vervangt. De overige #time-functies konden vrij eenvoudig direct in de programmaregel worden vervangen. Maar je zit nu inderdaad volkomen vast aan het YYYYMMDD-formaat van de parameter.

Er is nog wel een probleem met de uiteindelijke afbeelding, omdat daar LOCALDAYNAME, LOCALDAY, LOCALMONTHNAME en LOCALYEAR rechtstreeks in gebruikt worden. Wil je de kalender ook een andere dan de huidige datum laten tonen dan moet hier nog wel het een en ander veranderd worden. - LexTH 19 jun 2008 16:29 (CEST)

Nee hoor, je hoeft niets te veranderen. Verdiep je even in sjablonen en parameterdefaults, dan kom je er wel uit. En op Gebruiker:Robert Prummel kun je een voorbeeld vinden.

1. time heeft, naast enkele nadelen, het voordeel dat het formaat van de inputdatum vrij is. {#time: Y 19860426} werkt net zo goed als {#time: Y 26 april 1986. Dat was mijn motivatie voor het gebruik ervan: zo veel mogelijk standaard functionaliteit bieden. Er is wel iets te zeggen om hiervan af te wijken, maar ik bedenk ineens een manier waarop allebei kan. Vervang {{{1}}} in je nieuwe sjabloon door de volgende expressie:

• {{#ifeq: {{{1}}} | {{#expr: {{{1}}} }} | {{{1}}} | {{#time: Ymd {{{1}}} }} }}

Toelichting: #expr geeft puur numerieke input ongewijzigd terug, waarbij de vergelijking dus waar is en {{{1}}} direct wordt gebruikt. Zitten er mintekens of schuine strepen in, dan gaat #expr rekenen en is de vergelijking onwaar. Bij andere vervuiling, zoals letters of spaties, geeft #expr een foutmelding en is de vergelijking ook onwaar. In dat geval wordt {{{1}}} via #time gebruikt. Bevat {{{1}}} pure onzin, dan wordt de standaard foutmelding van #time teruggegeven.

Ik had je nog willen wijzen op mijn controlepagina's: Gebruiker:RToV/Bouwen/Franse republikeinse kalender/Vorig jaar, Gebruiker:RToV/Bouwen/Franse republikeinse kalender/Dit jaar en Gebruiker:RToV/Bouwen/Franse republikeinse kalender/Volgend jaar. Als onderaan deze pagina's rode sjabloonlinks verschijnen, ben je tegen de 2MB paginalimiet aangelopen. (Meer info hierover ergens op Meta.) Als het zo ver is hoor ik het wel van je. :-) Nu eerst even eten. RToV 19 jun 2008 18:07 (CEST)

Ik snap nog niet alles wat je hier schrijft, maar kun je bij de eerste invoer van de datum niet gewoon altijd {{#time:Ymd|{{{1}}}}} toepassen? Als het al YYYYMMDD is verandert er gewoon niets. Die controlepagina's gebruikte ik al om te kijken of alles goed gaat, maar van een paginalimiet had ik geen weet. D.w.z. ik had wel eens van het bestaan gehoord, maar snapte niet wat het betekent. Ik begrijp nu dat het dataverkeer dat nodig is om 1 pagina op te bouwen niet 2 MB mag overschrijden? Het was me al wel opgevallen dat het extreem lang duurt voor deze pagina's geopend worden. Dan gaat het echter snel. Kennelijk wordt een pagina eerst compleet opgebouwd, en als hij klaar is verstuurd. Ik heb trouwens nog iets gemerkt, misschien weet jij hoe dat werkt. Om middernacht veranderde de datum niet. Kennelijk werd uit een cache gelezen. Met ?purge kreeg ik wel de nieuwe datum te zien. Maar wat mij nu verbaast is dat als er iets veranderd is in een subsjabloon er wel meteen een verandering volgt, terwijl dat subsjabloon niet eens op de pagina staat. - LexTH 19 jun 2008 18:39 (CEST)

Dom van me: als je altijd de #time-functie toepast bij eerste invoer snijd je de mogelijkheid af om verder weg liggende jaren te gebruiken. Met die constructie kan het wel, mits je het in YYYYMMDD doet. - LexTH 19 jun 2008 18:58 (CEST)

Tonen willekeurige dag

Ik heb een sjabloon sjabloon:RevKalenderDatumG toegevoegd waar je de datum eenvoudig in YYYYMMDD kunt meegeven. Tussen 1970 en 2038 wordt de gregoriaanse datum uitgebreid getoond, daarbuiten in de vorm YYYYMMDD. Voor 1792 wordt vermeld dat de gregoriaanse kalender van kracht is. De kalender bleek inderdaad ook in de uitzonderingsjaren te werken. Geen foutmeldingen tegengekomen! Het is de bedoeling nog een aanroepsjabloon {{RevKalenderDatum}} te maken, dat voor de periode waarin #time werkt ook andere vormen van datuminvoer mogelijk maakt. Ook moet er nog een {{RevKalenderDatumR}} komen, waarmee je de gewenste datum in YYYMMDD (FRC) kunt invoeren om de bijbehorende gregoriaanse datum te zien. Daarvoor moet echter eerst nog FrcDate2Date geschreven worden.

Ik ben er trouwens op gestuit dat binnen de FRC de functies met de parameter DDD werken, behalve voor het jaar, die werken wel met YYYDDD. Wat denk je, moeten de functies herzien worden zodat ze alle inderdaad met YYYDDD werken? De functies worden er wel langer van, en dat geeft misschien problemen met de 2MB paginalimiet. Ik ben het wel met je eens dat het beter is om het te doen, dat is veel prettiger bij onderhoud. Ik kreeg een tijdlang door mij onbegrepen foutmeldingen, omdat ik keurig met YYYDDD werkte. Het is dus een afweging, of zie ik het verkeerd met die paginalimiet? - LexTH 20 jun 2008 13:44 (CEST)

Ik heb meteen nog iets anders verbeterd. Het stoorde me al enige tijd dat tijdens de aanvullende dagen een halfleeg kalenderblad wordt getoond. Ik wist dit alleen uit de theorie, want ik had de betreffende blaadjes nog nooit gezien. Nu uiteraard wel. Het stoort destemeer omdat niemand natuurlijk precies wist welke dag bedoeld werd met alleen de naam; daarom was het gebruikelijk er "de derde aanvullende dag van het jaar VII" bij te zetten. Nu wordt het volgnummer getoond, samen met "Jour compl.". - LexTH 20 jun 2008 14:57 (CEST)

Mooi werk. Het jaartal toevoegen is niet zo'n probleem: modulo 1000 inbouwen en klaar. Het zou inderdaad met de page limit te maken kunnen hebben dat die er niet in zit: hetzij nooit ingebouwd, hetzij later eruit gehaald. In dat laatste geval moet je iets kunnen vinden in de bewerkingsgeschiedenis.

De toevoeging van het jaartal in Arabische cijfers (op het kalenderblad) vind ik minder, met enig Brits understatement. Veel mensen, waaronder ik, zijn nl heel goed in staat om zelf Romeinse cijfers te lezen. Die omzetting erachter komt ons erg flauw, overbodig, ja zelfs debiliserend over. Al is het ongetwijfeld goed bedoeld.

Om het RTL-publiek terwille te zijn, had ik de vertaling subtiel verwerkt in de title, die werd getoond als de muis boven het Romeinse jaartal hing. Zou het graag weer zo willen zien werken. Sorry dat ik me zo expliciet uitdruk, maar dan is het maar duidelijk hoe ik erover denk. :-) Verder niets dan lof voor je werk. RToV 20 jun 2008 20:37 (CEST)

Bedankt voor je waarderende woorden. Wat betreft de Arabische cijfers verschil ik van mening met jou. Ik ben er namelijk van overtuigd dat de Romeinse cijfers verbonden zijn met zeer kleine jaartallen, en niet met de republikeinse kalender. Denk ook aan het nummeren van paragrafen en artikelen, waar het eveneens voorkomt. Bij iets hogere jaartallen zouden ze naar mijn overtuiging vervangen zijn door Arabische. Ook ik lees en schrijf deze getallen nog zonder moeite, maar ik weet dat er velen zijn die er toch beduidend langer naar moeten kijken, en bovendien nemen ze veel meer plaats in. Mijns inziens is de enige reden dat er Romeinse i.p.v. Arabische cijfers gebruikt werden dat een zeer klein gewoon getal niet direct als jaartal wordt herkend. Zodra het getal zo groot is dat het vaker als jaartal voorkomt dan voor iets anders denk je meteen daaraan, zeker als het in de buurt van het huidige ligt. Bovendien is het geheel in strijd met de opzet, die vooral naar makkelijk gebruik streeft, en vergissingen zoveel mogelijk wil tegengaan.

Eigenlijk zou ik dus juist de hele Romeinse weergave willen schrappen, al begrijp ik dat er mensen zijn die het aan de kalender koppelen, ook al is dat naar mijn mening ten onrechte. Ik heb geen idee hoe dat met die erboven zwevende cursor zou moeten. Begrijp ik het goed dat dat er ingezeten heeft? Je zou ook kunnen denken aan een omslagpunt bij bijvoorbeeld 15 of 20. - LexTH 20 jun 2008 22:19 (CEST)

Misschien kan het zo je goedkeuring wegdragen? Door het Arabische getal voorop te zetten, en bovendien het gelijkteken weg te halen, komt het niet meer als een uitleg van het andere getal over. Zo had ik het niet bedoeld, maar ik begrijp wel dat het zo begrepen kan worden. Tevens zie je het enorme verschil in omvang dat in de praktijk kan voorkomen. - LexTH 20 jun 2008 22:39 (CEST)

Ik heb de afgelopen dagen rustig door zitten knutselen. Uiteindelijk is er nu het sjabloon sjabloon:RepublikeinseKalender.

Er kan zowel een Franse als een gregoriaanse datum worden meegegeven, het mag ook met tekst, en als extraatje kan het jaartal ook niet of juist uitsluitend in Romeinse cijfers worden aangeduid. - LexTH 22 jun 2008 12:52 (CEST)

{{RepublikeinseKalender|19590229|rom=167}}

{{RepublikeinseKalender|19590229|rom=167}}

{{RepublikeinseKalender|1671306|rom=167}}

{{RepublikeinseKalender|1671306|rom=167}}

Er kan nu gekozen worden voor Arabische of Romeinse cijfers, beide, of een van beide met een in te stellen omslagjaar. Dat lijkt me toch wel voor elk wat wils.

Tevens heb ik inventief gebruikt gemaakt van het nu bestaan van zowel Date2FrcDate als FrcDate2Date, al zeg ik het zelf. Bij aanleveren van een gregoriaanse datum wordt nu juist de republikeinse routine aangeroepen, en omgekeerd. Dit heeft tot gevolg dat een getoonde datum altijd minstens eenmaal de omrekening moet passeren. En daarmee wordt een niet-bestaande schrikkeldag, of een te hoog dagnummer van de maand, keurig omgerekend. - LexTH 22 jun 2008 17:46 (CEST)

Mooi werk, maar de opmaak hierboven loopt wat door elkaar. (Schermbreedte 1024px.)

Even iets anders, ik heb de sjablooninfo van RepKalender wat gewikificeerd. (Ook daar liep de opmaak door elkaar.) Niets gewijzigd aan de sjablooncode, maar bij mijn tweede edit is toch een wijziging doorgevoerd. Geen idee hoe dat komt. Lijkt me het beste als jij er even naar kijkt. RToV 22 jun 2008 19:55 (CEST)

Het is me een raadsel wat er gebeurd is. Mijn laatste wijziging van 17:11 was ongedaan gemaakt. Je zou denken dat jij een oudere versie aan het bewerken was, en die ondanks de waarschuwing over de mijne had gezet. Maar jij was veel later met het plaatsen, dus dat lijkt me onwaarschijnlijk. Bedankt voor de waarschuwing; het enige verschil in werking was dat, als je een gregoriaanse datum zonder g= invoerde, een dag voorbij het maandeinde niet gecorrigeerd werd, maar dat alleen buiten de periode 1970 - 2038. 29 februari 1959 bleef dus staan. Zeer moeilijk te constateren dus als je het niet gericht uitprobeert. Ik heb de complete code er gewoon weer overheen geplakt. Bedankt voor de waarschuwing.

De uitleg is nu inderdaad veel overzichtelijker, ik was niet erg tevreden met mijn opmaak. Ook daarvoor bedankt. - LexTH 22 jun 2008 20:42 (CEST)

Ik stond vanavond onder de douche na mijn dagelijkse training op de loopband, en toen bedacht ik ineens dat er een fout in de uitleg geslopen was. Ik wist dat " |g=8 may " niet zou werken, het moet zonder g= , maar ik had het me niet gerealiseerd toen ik de tekst bekeek. Ik kon natuurlijk de tekst verbeteren, maar heb er voor gekozen het sjabloon te verbeteren. Nu kan het met en zonder g=.

Ik word er trouwens steeds gehaaider in. Eerst zou ik een dergelijke aanvulling uitgeprobeered hebben op mijn testpagina, omdat de ervaring leert dat het met de accolades nooit meteen klopt. Maar nu heb ik eerst de tekst op twee plaatsen uit elkaar getrokken, zodat er ruimte ontstond voor de toe te voegen regels. De regels tussengevoegd, de ruimte weer verwijderd, en zowaar, in een keer goed. Geen foutmeldingen en het werkte ook nog.

Dit hier lijkt me trouwens een particulier communicatiepunt voor ons. Vermoedelijk wordt er erg weinig meegelezen, want er zullen maar weinig mensen geïnteresseerd zijn in overleg op een sjabloonpagina.

Er is nog iets vreemd aan de hand, naast het rare ongedaan maken van die regelwijziging in RepKalender. Ik ben er van overtuigd dat ik op de overlegpagina van de hoofdpagina over de kalender een korte mededeling had geplaatst, maar die staat er niet. Het is echter niet helemaal uitgesloten dat ik wel de vooruitblik heb gezien, maar vergeten heb de pagina op te slaan. - LexTH 22 jun 2008 23:22 (CEST)

Opschonen

Ik heb geprobeerd het sjabloon:RevolutionaireKalender met frcdate aan te sturen, maar dat lukt niet. Dat komt waarschijnlijk doordat de jaarroutines YYYDDD verwachten, en de overige DDD. Het sjabloon wordt nergens zo gebruikt, ook niet door Robert Prummel.

Mijn voorstel is de aanroep op de kalenderpagina en ook op onze eigen pagina's te doen via het nieuwe sjabloon, dan kan RevolutionaireKalender vereenvoudigd worden tot het tonen van enkel meegegeven strings. Dat maakt het veel overzichtelijker voor het geval iemand de opmaak wil wijzigen.

Het plaatsen van de aanroeproutine op de kalenderpagina heeft tevens het voordeel dat hij makkelijker te vinden is voor mensen die de kalender willen gebruiken. Niet alleen de aansturing is met het nieuwe sjabloon beter en makkelijker, er staat ook - dank zij jou - een mooie uitleg bij. - LexTH 23 jun 2008 14:34 (CEST)

Ik begrijp nu wat je bedoelt met die zwevende cursor die het jaartal in Arabische cijfers moet tonen als je hem boven het jaartal houdt. Ik heb waarschijnlijk nooit afgewacht tot de tekst getoond werd, maar het bleek niet goed te werken als je de tekst als string meegaf. Dan kreeg je gewoon de tekst die eronder stond te zien. Ik heb een extra parameter jr gemaakt die door de zwevende cursor getoond wordt, en die wordt nu ook aangeleverd.

Ik heb meteen alles verwijderd wat betrekking had op invoer van frcdate. Dat kon niet eerder geprobeerd worden omdat FrcDate2Date ontbrak. Het is nu overbodig en het werkte toch niet.

De verstekwaarden heb ik laten staan. Het is zo toch wel overzichtelijk genoeg, en het voordeel is dat je nu door gewoon de routine aan te roepen toch het plaatje krijgt, al was het maar voor het beeld op zijn eigen pagina. - LexTH 23 jun 2008 18:49 (CEST)

Ik heb het ook werkend gemaakt voor negatieve jaren; eerst alleen voor de republikeinse kalender, daarna ook voor de gregoriaanse. Doordat de YYYDDD en YYYYMMDD codes samengesteld werden door het jaar bij de rest op te tellen kreeg je voor negatieve jaren dat dag 10 van jaar -5 gecodeerd werd als -4990, en 31 december -8 werd -78769. Alles werkte, al zijn de codes natuurlijk moeilijk te lezen voor negatieve jaren. Bij het fijnslijpen voor uitzonderlijke gevallen, o.a. onjuiste datuminvoer, werd het moeilijk leesbaar zijn me te gortig. Nu is alles omgebouwd voor -510 en -81231. Ik kon dat rustig stap voor stap invoeren doordat het voor positieve jaartallen niet uitmaakt.

Omdat de conventie is dat het jaar -1 direct gevolgd wordt door +1 wordt -3 weergegeven als -4. Ik heb er voor gekozen -1, -5, -9 enz. schrikkeljaar te laten zijn, en niet -4, -8, -12 enz. Anders zou er ten onrechte een schrikkeljaar worden overgeslagen wegens het ontbreken van het jaar 0. 12 maart -5 wordt dus gecodeerd als -40312. Je voert echter wel gewoon -50312 in.

Bij het aanroepen van de sjablonen voor het Franse jaar wordt nu steeds YYYDDD gebruikt. - LexTH 28 jun 2008 17:17 (CEST)

Reuzeprobleem

Ik kreeg voor mij onverklaarbare foutmeldingen, nietszeggend, want "niet herkend leesteken" e.d., bij invoer van bepaalde data. 18010305 gaf de foutmelding, maar g=18010305 niet, en 18010922 ook niet.

In RepKalender komt de aanroep van RevKalenderDatumG 2x voor, voor met en zonder g=. In de ene regel ging het altijd goed, in de andere alleen van Frans nieuwjaar tot 31 december. Uiteraard heb ik de goede regel gekopieerd naar de slechte, maar dat hielp niet. Ook heb ik de parameter die meegegeven werd aan RevKalenderDatumG laten weergeven, en die was goed. Als ik de waarde er vast inzette was het ook goed. Ook hielp het weglaten van EnterDate en FrcDate2Date-Date2FrcDate. Deze kunnen bij normale invoer weggelaten worden.

Het bijzondere van de niet-werkende regel was dat hij als enige 5-diep zat in de #if-structuur en daarbij meer dan 1-diep andere sjablonen aanriep.

Ik heb het op kunnen lossen door de #if-structuur om te gooien zodat hij nu nog maar 3-diep zit i.p.v. 5-diep. Het is echter wel op het randje, want het blijkt dat er nu nog 1 niveau over is. Bij aanroep zonder parameter zijn er nog 35 niveau's over. Wellicht is het aan te raden om te kijken of er bezuinigd kan worden. Want nu kun je het niet in een ander sjabloon gebruiken.

Waarschijnlijk omdat ik er geen ervaring mee heb ben ik meer dan een dag bezig geweest om het uit te zoeken. Ik had domweg niet aan een dergelijke beperking gedacht, en zocht het aanvankelijk steeds in fouten in de programmaregels. - LexTH 28 jun 2008 17:14 (CEST)

Je hebt me vandaag iets nieuws geleerd: deze beperking kende ik nog niet, was er ook nog niet tegenaan gelopen. Waar is deze info te vinden en hoe kun je zien hoeveel niveau's (of levels) er over zijn?

Bij de voorbeelden, iets hoger op deze pagina, valt me op dat er iets niet goed gaat met een /noinclude. Deze overlegpagina zit daardoor nu in de sjablonencat. Dat lijkt ook door het genoemde probleem te komen.

Ik zou zeggen: eerst terugsnoeien tot de essentie, dan optimaliseren, dan weer uitbouwen.

Er valt oa winst te behalen in Date2FrcDate en vice versa. Nu we hebben gekozen voor de methode-Romme, kun je 22 september 1792 = 1 vendemiere I als uitgangspunt nemen. Bereken in de ene kalender het aantal dagen verschil tussen deze datum en de ingegeven datum. Tel in de andere kalender hetzelfde aantal dagen en bereken de datum waarop je uitkomt. Dat zijn twee simpele algorithmen.

Of nog beter: neem het Juliaanse dagnummer als omrekenbasis. Zie en:Julian day voor uitleg en omrekenvoorbeelden. Leuke materie. M'n vingers jeuken om ermee aan de slag te gaan, maar geen tijd... RToV 28 jun 2008 22:57 (CEST)

Hee, ik dacht dat je met vakantie was omdat je al tijden helemaal niet op wikipedia geschreven hebt. Anders had ik je wel gevraagd of je een oplossing voor mijn probleem wist. Maar dat wist je dus ook niet. Ik weet juist helemaal geen info te vinden, de oplossing van het probleem is gewoon eigen deductie. Maar heeft me wel wel vele, vele uren gekost. Je kunt testen hoeveel niveau's over zijn door de regels te omgeven met

{{#if:1|{{#if:1|{{#if:1|{{#if:1|{{#if:1|{{#if:1|{{#if:1|

......... programma ..........

}}}}}}}}}}}}}}

en dan zoveel keer dat er net geen foutmelding komt. Het bleek dat je om {{RepKalender}} 35 stel kunt plaatsen.

Waar ik tegenaan loop is dat er geen variabelen zijn, en ik weet ook geen stringbewerkingsoperatoren. RIGHTSTR$ en MIDSTR$ zou het hier wel een stuk eenvoudiger maken. Weet jij misschien of het toch bestaat? Met variabelen hoef je lang niet zo diep te gaan. Nu verhoogt de test op onjuiste invoer en correctie voor nabij het jaar 0 het alleen al met 3 niveaus. Tijdens het televisiekijken kreeg ik wel een idee om het aantal niveaus hier te reduceren, maar ik moet nog bekijken of dat wel werkt. - LexTH 29 jun 2008 00:22 (CEST)

Het maximale aantal niveaus van sjabloonaanroepen blijkt 40 te zijn. - LexTH 29 jun 2008 02:25 (CEST)

Het maximum geldt voor het eerstaangeroepen sjabloon. Op [1] mag een eigen set 40-diep worden opgebouwd. - LexTH 29 jun 2008 11:28 (CEST)

Ik ben eigenlijk met wikibreak, want weinig tijd. Maar ik kijk nog wel eens rond en stuitte op jouw forse uitbreiding van Franse Republikeinse Kalender. Waarvoor complimenten. De rest weet je en een beetje begeleiden kost niet zo veel tijd.

Stringfuncties zijn in de wiki niet aanwezig. Op meta staat ergens waar je een verzoek kunt indienen, maar dat staat er al een poosje.

Variabelen bestaan niet. De wikisyntax is geen programmeertaal, maar slechts tekstsubstitutie. Zoals je hebt ontdekt, gaat de wiki-software 40x over de brontekst heen. Bij iedere pass worden sjabloonaanroepen vervangen door de inhoud van die sjablonen en parameters vervangen. Bij geneste accoladeparen worden alleen de binnenste geëvalueerd. De resulterende tekst gaat de volgende pass in. Bij iedere pass geldt de page limit van 2MB. Wordt die overschreden, dan stopt de interpreter. De rest van de brontekst blijft dan ongeëvalueerd staan en er komt geen volgende pass.

Een berekeningen kun je in een subsjabloon zetten, dat je dan gebruikt als functie. Maar als je het resultaat van dezelfde berekening meermalen nodig hebt, is dat ongunstig mbt de page limit. Om een voorbeeld van deze methode te geven:

Inhoud sjabloon {{sjab}}:
 {{switch|{{{1}}}}} {{switch|{{{1}}}}}
 
Inhoud sjabloon {{switch}}:
 {{#switch:{{{1}}}|1=A|2=B|3=C|4=D|5=E|6=F|7=G|8=H|9=I|10=J}}
 
Aanroep:
 {{sjab|4}}

Resultaat na eerste pass:
 {{switch|4}} {{switch|4}}
 
Na tweede pass:
 {{#switch:4|1=A|2=B|3=C|4=D|5=E|6=F|7=G|8=H|9=I|10=J}} {{#switch:4|1=A|2=B|3=C|4=D|5=E|6=F|7=G|8=H|9=I|10=J}}

Na derde pass:
 D D

Een zuinigere methode is de berekening als parameter mee te geven aan een subsjabloon. De berekening wordt dan eerst geëvalueerd en het resultaat wordt gebruikt bij de substitutie van het subsjabloon:

Inhoud sjabloon {{sjab}}:
 {{sjab/2|{{#switch:{{{1}}}|1=A|2=B|3=C|4=D|5=E|6=F|7=G|8=H|9=I|10=J}}}}

Inhoud sjabloon {{sjab/2}}:
 {{{1}}} {{{1}}}
 
Aanroep:
 {{sjab|4}}

Resultaat na eerste pass:
 {{sjab/2|{{#switch:4|1=A|2=B|3=C|4=D|5=E|6=F|7=G|8=H|9=I|10=J}}}}
 
Na tweede pass:
 {{sjab/2|D}}

Na derde pass:
 D D

Zoek de verschillen. Bij veelvoudig aanroepen van het subsjabloon worden de verschillen natuurlijk duidelijker. :-) Het komt erop neer dat je tov een programmeertaal het probleem vaak omgekeerd, of binnenste buiten, moet benaderen.

Ook belangrijk mbt de page limit: bij if-structuren worden eerst beide takken volledig geëvalueerd; pas daarna wordt de if zelf geëvalueerd. Met geneste structuren kan de onzuinige methode hard aantikken. RToV 29 jun 2008 11:25 (CEST)

Bedankt voor je mooie uitleg. Ik heb het begrepen, maar moet er nog wel goed over nadenken hoe de adviezen verwerkt moeten worden in de efficiëntste opbouw. - LexTH 29 jun 2008 11:52 (CEST)

De methode met subsjabloon werkt efficiënter, maar wel ten koste van een extra niveau. Het is dus een kwestie van afwegen. Ik denk: zo veel mogelijk toepassen, maar als je in de buurt van de 40 niveaus komt niet. D.w.z. in de lijn van die diepe structuur. Een nevenlijn die minder diep is heeft helemaal geen last van die beperking. Het gaat tenslotte alleen om de diepste; of dat er 1 is of 100 die even diep zijn maakt niet uit.

Dat deze pagina voorkwam bij de categorie werd niet veroorzaakt door het probleem, maar doordat in RevKalenderDatumG domweg <noinclude> vergeten was. - LexTH 29 jun 2008 13:06 (CEST)

FRCNEWYEAR is nu vereenvoudigd; hij heeft geen subsjablonen meer. Er is wel een evenknie bijgekomen, FIRSTDAY, die op overeenkomstige wijze rechtstreeks het dagnummer van 1 januari berekent. De dieptemarge is gegroeid van 1 naar 3. - LexTH 29 jun 2008 16:33 (CEST)

Omrekening via Juliaanse dagnummer

Ik kon het toch niet laten en heb twee sjablonen gemaakt voor omrekening tussen Juliaanse dag en Franse datum. Beiden lijken goed te werken:

• {{FrcDate2JulianDay|216000}} = {{FrcDate2JulianDay|216000}} (22 september 2007)
• {{JulianDay2FrcDate|2454366}} = {{JulianDay2FrcDate|2454366}} (idem)

Ik wil er nog meer mee testen en daarna de Gregoriaanse tegenhangers {{Date2JulianDay}} en {{JulianDay2Date}} maken. Als omrekening van Greg via Jul naar Frc en terug goed werkt, kunnen de uitzonderingsjaren worden ingebouwd. Voel je vrij om mee te doen.

Voordeel van deze sjablonen is dat de omrekening veel simpeler is. Waarschijnlijk geven ze veel minder problemen. Als ze eenmaal werken kunnen Date2FrcDate, FrcDate2Date, FRCNEWYEAR enz worden vervangen en uiteindelijk de bittenbak in. Zou zeggen, kijk eens wat je ervan vindt. RToV 29 jun 2008 21:00 (CEST)

Het is jammer van het dubbele werk. Ik ben zojuist klaar met het uitgebreid testen van mijn vereenvoudigde versies van Date2FrcDate en FrcDate2Date. Compleet met uitzonderingsjaren, en ook getest op de overgang naar negatieve jaren. Ik heb de jouwe nog niet bekeken, maar vermoed dat ze op hetzelfde principe gebaseerd zijn. Het verschil zal zijn dat ik met het verschil tussen de twee juliaanse dagen werk. Voordeel van jouw mehode is natuurlijk dat je dan ook de JD beschikbaar heb; het wordt er alleen iets langer door.

Denk echter ook aan de diepte. De huidige omrekening is lekker plat. De nieuwjaarsdag van beide, uitgedrukt in het dagnummer van het andere systeem wordt in een formule uitgerekend, dus zonder subsjablonen, met alleen aanlevering van het jaartal. Alleen voor de uitzonderingen is nog een switch nodig. - LexTH 29 jun 2008 22:03 (CEST)

Ik denk niet dat het jammer is. Het doel van deze exercitie is toch vooral lering ende vermaeck, ervaring opdoen met de wikisoftware. Zolang we er iets van leren en er plezier aan beleven, is het geen verspilde moeite.

Het begrip Juliaans mbt kalenders heeft drie betekenissen die tot verwarring leiden:

1. De Juliaanse kalender, genoemd naar Julius Caesar en de voorloper van de Gregoriaanse kalender;
2. Het Juliaanse dagnummer, genoemd naar een andere Julius. Dit is een getal dat de dagen telt sinds maandag 1 januari ergens heel lang geleden in de Proleptic Julian Calendar. Op 22 sep 2007 was het Juliaanse dagnummer 2454366. Iedere dag heeft zijn eigen volgnummer, dus datumberekeningen zijn een kwestie van optellen en aftrekken. Dat maakt deze kalender erg geschikt als basis voor omrekening tussen velerlei kalenders. Zowel hedendaagse als historische als toekomstige.
3. De Juliaanse datum: veel gebruikt in programmeertalen. Wordt weergegeven door een jaartal, gevolgd door een dagnummer binnen dat jaar: 0 t/m 365 of 1 t/m 366 al naar gelang de implementatie.

Deze drie hebben weinig meer met elkaar gemeen dan de naam.

Mmm.. Ik was bezig een uitlegje te schrijven, maar geloof dat ik niet helemaal helder meer ben. Dus ik ga maar gauw plat en dan de diepte in. :-) RToV 29 jun 2008 22:46 (CEST)

Dat van de lering ende vermaeck ben ik eigenlijk wel met je eens. Ja, Julius was het zoontje van de bedenker van het schoons, dat heb ik wel eens gelezen.

Ik heb je routines bekeken, en snap ze wel. Maar oei, wat zijn de formules lang. Al vind ik mijn methode om FRCNEWYEAR met 1 te verhogen als het een schrikkeljaar is, en verder de eeuw- en 400-jarenstappen wel zo overzichtelijk, zelfs als de 4000-jarenstap er nog bij zou komen. Ze zijn wel net zo plat als de mijne. Alleen heb je twee omrekeningen nodig, naar en van de JD voor 1 enkele omrekening. Daarmee rekening houdend vind ik de huidige methode toch beter. De bij de invoer toegepaste heen- en terugrekening voor de correctie van niet-bestaande data hoeft natuurlijk wel maar een keer, naar en van JD.

Het kan natuurlijk mooi gebruikt worden om de JD apart te vertonen. Dat is een leuk extraatje.

Het grote voordeel van de JD is dat je eenvoudig kunt bepalen hoe veel dagen er tussen twee data zitten. Het nadeel als je alleen maar tussen de RepK en de GregK wilt omrekenen is dat je een heleboel stappen heen en terug doet, omdat die voor beide precies hetzelfde zijn. Het is anders als je bijvoorbeeld naar de mohammedaanse kalender wilt omrekenen, omdat die heel anders is.

Het biedt natuurlijk nog een leuk pluspunt: datuminvoer als JD. De omrekenroutines voor Greg. en RepK zijn trouwens gelijk, alleen moet in de aanroep een andere offset staan. - LexTH 30 jun 2008 09:40 (CEST)

De formules zijn inderdaad lang, maar die van FrcDate2JulianDay heb ik sterk vereenvoudigd. Voor z'n broer moet ik nog wat verzinnen, iets dat ook de bug met de schrikkeldag oplost. (Zie Gebruiker:RToV/Test.) Het nadeel van twee sjablonen vind ik meevallen, je kunt ze nesten in de aanroep, bijvoorbeeld {{FrcMonthName|{{JulianDay2FrcDate|{{Date2JulianDay|20080701}}}}}}. Date2FrcDate heeft trouwens achter de schermen FRCNEWYEAR nodig, dus dat zijn ook twee sjablonen.

De Gregoriaanse routines zullen er iets anders uit gaan zien vanwege het afwijkende formaat van de inputdatum. Er zal ook een correctie in moeten voor schikkeljaren, omdat 29 februari nu eenmaal niet de laatste dag van het jaar is. Maar verder klopt je constatering dat er veel overeenkomsten zijn.

JD als invoerdatum: je zou bv ook kunnen denken aan een pagina waar de actuele datum volgens diverse kalenders worden getoond. Of een automatisch actualiserende lijst van Islamitische feestdagen tov de Gregoriaanse kalender. Leuke dingen voor de Wiki. Zulke dingen kunnen het beste via de Julian Day worden gekoppeld, willen ze een beetje onderhoudbaar blijven. Je krijgt dan steeds paren van sjablonen, waarbij je naar believen sjablonen uit de linker en rechter rij kunt nesten:

• Date2JulianDay en JulianDay2Date
• FrcDate2JulianDay en JulianDay2FrcDate
• Islamitisch2JulianDay en JulianDay2Islamitisch
• Chinees2JulianDay en JulianDay2Chinees
• JulianDate2JulianDay en JulianDay2JulianDate

Waar heb ik zoiets eerder gezien? Misschien op de site van Mathworld? Morgen eens kijken, voor vandaag gaat het licht uit. RToV 30 jun 2008 22:25 (CEST)

Het JD-systeem geeft een jaar + dagnummer, niet meer. Vervolgens moet het dagnummer in maand- en maanddagnummers worden omgezet, en daar dient GregMMDD voor, of voor omgekeerd GregDoY. M.i. is het JD-systeem mooi universeel, maar als je alleen Frc en Greg. wilt koppelen nodeloos ingewikkeld. Vergeet niet dat Date2FrcDate en FrcDate2Date, met hun bescheiden aantal hulpsjablonen, de volledige omzetting al doen. Ik denk dat de huidige omzetting zeer efficiënt is. In plaats van FRCNEWYEAR en FIRSTDAY kun je de JD-slag gebruiken. De rest blijft nog steeds nodig. Voordeel is dat het universeler is, en het nadeel van de lange formules is niet zo groot, want het is niet diep. Als je de omzetting maar niet op je testpagina's zet, zodat hij honderden malen op gelijke diepte wordt uitgevoerd. We hebben trouwens weer een aantal niveaus beschikbaar voor leuke dingen. - LexTH 1 jul 2008 00:56 (CEST)

Ik zie dat je in de procedure de sjabloon FrcYear gebruikt. Dit is echter sinds mijn recente wijziging niet de bedoeling. Negatieve jaren worden met 1 verlaagd wegens de conventie dat het jaar 0 niet bestaat. Dat is echter alleen een cosmetische operatie voor de uitvoer. Intern wordt het jaarnummer nog steeds eenvoudig bepaald door trunc(YYYDDD/1000), dan blijven de schrikkeljaren ook kloppen. Trunc, en niet floor, omdat dag 10 van jaar -123 nu gecodeerd wordt als -123010. Het wordt echter getoond als -124.

De codes zijn als volgt:

      jaar           code
(intern) (uitvoer)  YYYDDD
   2         2       2010
   1         1       1010
   0        -1       0010
  -1        -2      -1010
  -2        -3      -2010

Door deze constructie lopen de schrikkeljaren gewoon door, en is ook de JD omzetting eenvoudig. Maar je moet de jaar-0 stap intern nooit maken; pas bij uitvoer.

Opm.: De invoerprocedure maakt van 0203, -0203, en -10203 (YYMMDD) altijd 0032 (YYYDDD), en van -20203 en lager -1032 enz. - LexTH 1 jul 2008 18:13 (CEST)

De routines

Ik heb eerst de routines wat aangepast voor negatieve YYYDDD codes, dat was het probleem niet. De heen-en terugomrekening is nu goed. Maar de JD is geheel en al fout voor negatieve YYYDDD. In 1791 zit een sprong van 4504 jaar, d.w.z. dat het JD-nummer daaronder het overeenkomstige aantal dagen te groot is. Omgekeerd, als je JD 1 ingeeft, krijg je als jaartal -11000, terwijl dat -6500 moet zijn. Daardoor merkte ik het, want ik weet dat we daar nog lang niet aan toe zijn. Dit heeft trouwens niets met mijn aanpassingen te maken, dat ligt in de ordegrootte van een jaar. Ik weet waar de fout zit: eerst wordt JD van dag 1 van jaar 1 afgetrokken, en dan wordt er gerekend. Je krijgt dan een omslag, waarbij 4000+400+100+4+1 allemaal tegelijk bereikt worden. Er moet dus afgetrokken worden, maar daar ga ik nu niet naar kijken. - LexTH 1 jul 2008 21:13 (CEST)

Het systeem is (d4000 = het aantal dagen in 4000 jaar):

a=floor(JD/d4000)

b=floor((JD-a*d4000)/d400)

c=floor((JD-a*d4000-b*d400)/d100)

d=floor((JD-a*d4000-b*d400-c*d100)/d4)

e=floor((JD-a*d4000-b*d400-c*d100-d*4)/d1)

JJJ=a*4000+b*400+c*100+d*4+e

DDD=JD-a*d4000-b*d400-c*d100-d*d4-e*d1

Dit is best te doen als je variabelen hebt, maar die zijn er niet. Daarom moeten de vorige berekeningen steeds herhaald worden. Na drie regels ben ik opgehouden, want het scherm begon al aardig vol te raken, en het neemt met elke regel progressief toe:

<includeonly>{{#expr:1
+floor({{{1}}}/1460969)*4000
+floor(({{{1}}}-floor({{{1}}}/1460969)*1460969)/146097)*400
+floor(({{{1}}}-floor({{{1}}}/1460969)*1460969-(({{{1}}}-floor({{{1}}}/1460969)*1460969)/146097)*146097)/36524)*100
+floor(({{{1}}}-xxx)/1461)*4
+floor(({{{1}}}-xxx)/365)*1
}}{{Aanvul3|{{#expr:abs{{{1}}}mod1460969mod146097mod36524mod1461mod365}}}}</includeonly>

Ik geloof echter dat de sprong eenmalig is, alleen bij het jaar 0. Daar zit misschien nog een mogelijkheid. - LexTH 2 jul 2008 10:34 (CEST)

De correctie voor de stap bij 0 werkt goed. Maar het dagnummer nog niet voor negatieve rep. jaren. Ik heb daarvoor een correctie geprobeerd (versie systeem2, voorafgaand aan systeem1), maar dat gaat niet goed. Misschien kun je daar ook eens naar kijken.

Verder gaat het niet goed met de schrikkeldag. mod365 kan nooit 365 opleveren. In systeem2 deed ik daar wel een poging toe: niet verder dan mod1461 gaan en er dan 0, 1, 2 of 3 maal 365 afrekken. Het houdt wel in dat de jaarberekening 3x gedaan moet worden. - LexTH 2 jul 2008 13:11 (CEST)

De JulianDay2FrcDate routines werken nu in principe ook. De omzetting is goed, ook voor alle schrikkeljaren. Het was toch mogelijk de modmodmod constructie toe te passen, alleen moest er voor de laatste dag van de 4-jaarscyclus en de 400-jaarscyclus een correctie worden toegevoegd. Dit omdat 4 jaar een dag meer is dan 4x1 jaar, en 400 een dag meer dan 4x100 jaar. Het negatiefprobleem is opgelost door 10 4000-cycli op te tellen, en na afloop 40000 jaar af te trekken. Dit heeft echter een vreemde consequentie. Tot mijn verbazing is het jaar -1 (=0 intern) nu geen schrikkeljaar meer. Toch is dat correct: de 4000-jaarscyclus eindigt met een niet-schrikkeljaar. Daarom wordt hij ook direct voorafgegaan door een gewoon jaar. De huidige omzetting gaat niet verder dan de 400-jaarscyclus, en die eindigt met een schrikkeljaar, en wordt dus ook door een schrikkeljaar voorafgegaan. Daardoor heb je het probleem niet. Ik kan het vermoedelijk oplossen door de sprongcorrectiemethode weer toe te passen. Dan worden de schrikkeljaren 4000 jaar in de toekomst en 4000 jaar in het verleden overgeslagen, maar niet bij het begin. Laat je gedachten er eens over gaan, ik neig naar het laatste.

De correctie voor de afwijkende jaren is nog niet aangebracht. Ik heb wel al een idee hoe dat op te lossen is, maar heb nog niets geprobeerd. - LexTH 3 jul 2008 02:07 (CEST)

JD>FRC en FRC>JD werken nu beide goed buiten de uitzonderingsjaren. De sprongcorrectie werkte niet. Ik heb FRC voor het jaar I een dag eerder gezet om niet direct bij het begin een schrikkeldag over te slaan. Anders begin je bij het teruggaan met de maximale verschuiving, die dan steeds als hij bijna nul is weer maximaal wordt gezet. Niet logisch dus.

JD>FRC werkt ook goed in de uitzonderingsjaren, aan FRC>JD wordt nog gewerkt, maar nu stop ik er mee. - LexTH 3 jul 2008 17:12 (CEST)

Volgens mij werken beide routines nu goed. Nu de Greg<>JD nog. Maar ik blijf van mening dat het nodeloos ingewikkeld is als je alleen FRC<>Greg wilt doen. Niet als aanroep, maar wegens de hoeveelheid gegenereerde code en de diepte. Daar moet ik nog eens naar kijken. Niet dat ik denk dat de diepte verminderd kan worden, want ik heb speciaal op de diepte gelet. Soms wordt er in de breedte gewerkt waar een niveau dieper wat code zou besparen. - LexTH 4 jul 2008 03:09 (CEST)

FRC<>JD, Greg<>JD en Juliaans<>JD zijn er nu alle zes. - LexTH 4 jul 2008 18:42 (CEST)

Diepte

Je uitleg van wat er precies gebeurt met de substituties in passes was uitstekend, want ik ben er mee aan de gang gegaan, en nu begrijp ik inderdaad hoe het werkt, en waar je op moet letten. :-)

Ik ben begonnen met voor elk sjabloon waar ik mee bezig ben het aantal benodigde passes te vermelden. Dat geeft wat meer inzicht. De structuurverandering waarmee het reuzeprobleem ondervangen is veranderde de toestand van 1 tekort in 1 over. Dat is natuurlijk erg op het randje. Door de routine waarmee onjuiste datuminvoer gecorrigeerd wordt te veranderen van FrcDate2Date-Date2FrcDate in GregMMDD-GregDoY kon nogmaals flink worden bespaard, zodat er nu 12 over zijn. Er was nog wel wat aanvullend werk nodig, maar ik geloof dat het nu nog wat beter voor elkaar is. Zelfs moedwillig pesterige invoer levert geen foutmeldingen meer op, en geeft bovendien altijd een logisch alternatief voor de onjuiste datum. Ik dacht een reuzenklapper van 17 niveaus te maken door het weglaten van het invullen van vandaag als verstekwaarde in RevolutionaireKalender zelf. Een vaste tekst voor het plaatje is ook wel voldoende. Maar het blijkt dat binnen het plaatje een eigen set van 40 niveaus beschikbaar is; deze diepte hindert het aanroepen dus geenszins. - LexTH 30 jun 2008 18:03 (CEST)

Ruzie met moderatoren

Ik heb een invulpagina gemaakt zodat eenieder op eenvoudige wijze andere data kan bekijken. Omdat ik geen idee heb hoe je op een pagina echt iets kunt invullen - ik vermoed dat dat alleen kan als je een programma laat draaien, Java of zoiets - moest ik me behelpen met bewerken van een pagina, en dan op Toon bewerking ter controle laten drukken.

Ik had de pagina eerst compleet gemaakt, met de opwekking erin om de pagina niet op te slaan. Maar na plaatsing heb ik nog een beetje fijngeslepen. Toen werd de pagina verwijderd wegens 'geëxperimenteer in de hoofdnaamruimte'. Ik heb de pagina opnieuw geplaatst, met in de samenvatting dat deze pagina niet meer gewijzigd hoeft te worden, wat ik ook helemaal niet gedaan heb. Toch is ook die weggehaald. Vervolgens wilde ik er een sjabloon van maken, maar dat is minder handig omdat je dan niet een deel van de pagina ter bewerking kunt aanbieden. Dan is het risico groter dat onwetenden de pagina verminken. Tenslotte heb ik hem maar in mijn eigen gebruikersruimte geplaatst. Dat is dus noodgedwongen, niet omdat ik mezelf op de voorgrond wil plaatsen, want ik beschouw het nog steeds als jouw kindje, waar ik op voortgeborduurd heb.

Ik had indertijd wel gelezen dat je eerst de Engelse routines hebt "gejat", en die vervolgens vervangen hebt door eigen routines. Inmiddels heb ik de Engelse routines bekeken, en dat is inderdaad erg primitief vergeleken met jouw werk. In verband hiermee heb ik een vraag: intern wordt de Franse datum uitgedrukt in jaar+jaardagnummer. Daar kun je, anders dan in de gregoriaanse kalender, makkelijk maand- en maanddagnummer uithalen. Maar YYYDDD is voor mensen wel moeilijker te lezen dan de YYYYMMDD van de gregoriaanse kalender. Daarom laat ik een datum dan ook invoeren als YYYMMDD. Het is eenvoudig het dagnummer om te zetten in YYYMMDD, dus kan de code net zo goed in de vorm YYYMMDD zijn, zodat ook de code makkelijk te lezen is. Voordeel zit vooral in de JD-omzetting, die dan ook met makkelijk leesbare codes kan werken. Het is niet veel werk om de code te veranderen, maar ik wil graag weten of je er bezwaar tegen hebt. - LexTH 5 jul 2008 13:58 (CEST)