[Alg] Slechtste programmeervoorbeelden deel 3

[NMe]

Het is alweer tijd voor deel 3 van deze succesvolle topicreeks.

Vorige delen:
[alg] slechtste prog voorbeelden.
[alg] Slechtste programmeervoorbeelden deel 2

Regels:
Uiteraard is het in dit topic niet de bedoeling dat andere users en/of topics aangehaald worden om ze voor gek te zetten. Lachen om je eigen code, of over dingen die je "wel eens tegengekomen bent" is prima, maar hou het onderling netjes.

Daarnaast is het niet de bedoeling dat je hier maar even snel een kort vraagje komt stellen. Als een vraag niet topicwaardig is, dan is hij wat dit forum betreft ook niet postwaardig.

[Alex)]

Ik gisteren nog...

JavaScript:

...this.getElementsByTagName('img')[0]...

Het ging over een <a> met daarin een <img> die dynamisch was aangemaakt (via JS, userscripts)... iets zegt me dat gewoon "this.firstChild" ook had volstaan... (dit was btw in een onclick-eventhandler)

[Voor 8% gewijzigd door Alex) op 21-07-2007 16:13]

[Anoniem: 26306]

Afhankelijk van het feit of het mogelijk is dat er whitespace of andere elementen binnen dat a element kunnen staan. Als dat niet zo is, had firstChild inderdaad wel volstaan. En dat scheelt flink wat overhead

[Alex)]

JavaScript:

var link = document.createElement('a');

var image = document.createElement('img');

link.appendChild(image);

Daar zit geen whitespace tussen de <a> en de <img>, lijkt me...

[Anoniem: 140111]

@ oisyn, implode gaat hier helaas niet werken, tenzij ik met een 2de array ga werken natuurlijk.

[xtra]

Alex) schreef op zaterdag 21 juli 2007 @ 16:12:
Ik gisteren nog...

JavaScript:

...this.getElementsByTagName('img')[0]...

Het ging over een <a> met daarin een <img> die dynamisch was aangemaakt (via JS, userscripts)... iets zegt me dat gewoon "this.firstChild" ook had volstaan... (dit was btw in een onclick-eventhandler)

Ergens heb je wel gelijk. Je moet dan wel blijven opletten of het een dynamische img is of een die er al was. Bij de laatste is een enter al genoeg om je script te verpesten. Om fouten voor te zijn had ik waarschijnlijk ook 'jouw' constructie genomen. (Of de reference die je toch al hebt bij het dynamisch aanmaken gebruiken)

[Alex)]

xtra schreef op maandag 23 juli 2007 @ 14:38:
[...]

Ergens heb je wel gelijk. Je moet dan wel blijven opletten of het een dynamische img is of een die er al was. Bij de laatste is een enter al genoeg om je script te verpesten. Om fouten voor te zijn had ik waarschijnlijk ook 'jouw' constructie genomen. (Of de reference die je toch al hebt bij het dynamisch aanmaken gebruiken)

Het is dynamisch aangemaakt - geen extra tekens dus

Aan die references heb ik niets omdat het om code binnen een eventhandler gaat en je dan dus een scope-issue krijgt... tenzij je ergens een public array (o.i.d.) bijhoudt met daarin alle objecten... maar dat maakt niet uit, inmiddels heb ik alles werkend. IE deed moeilijk, dus ik heb uiteindelijk mijn hele mooie document.createElement-constructie overboord moeten gooien en het moeten vervangen door iets met innerHTML

Het leek wel alsof IE de DOM niet updatete, in Fx had ik geen problemen maar IE vertelde doodleuk dat hij het object niet kende

[D-Raven]

Een abstracte klasse Document hebben waarop een hoop algemene afhandeling wordt gedaan.
Waarin een property staat met een harde verwijzing, zoiets als dit.

C#:

public virtual VenderXGrid Grid { get; }

En dan vervolgens een Document implementatie te hebben waarbij je VendorYGrid wilt gebruiken....

"Maar we wisselen toch nooit van Grid?" ...

[Orphix]

D-Raven schreef op maandag 23 juli 2007 @ 15:27:
Een abstracte klasse Document hebben waarop een hoop algemene afhandeling wordt gedaan.
Waarin een property staat met een harde verwijzing, zoiets als dit.

C#:

public virtual VenderXGrid Grid { get; }

En dan vervolgens een Document implementatie te hebben waarbij je VendorYGrid wilt gebruiken....

"Maar we wisselen toch nooit van Grid?" ...

Mja ik vind het nog niet eens zo'n gekke gedachtengang. Ten eerste is het in heel veel gevallen zo dat er inderdaad nooit van vendor wordt gewisseld in de levensduur van een product. Daarnaast zou de enige oplossing zijn een generieke interface te maken die door zowel VendorX en VendorY worden geimplementeerd. Dit is veel werk en error-prone. Ik kan me goed voorstellen dat je zo'n ontwikkeling laat wachten tot het moment echt daar is. (wat misschien wel nu is )

[D-Raven]

Tjah daar valt ook wel weer iets voor te zeggen. Tis alleen nogal een rotwerk om uiteindelijk alles te gaan refactoren. Helemaal als je niet in een keer alles kan/mag omzetten. Dan moet je namelijk dubbele code gaan opnemen zodat de 2 dingen toch nog naast elkaar gebruikt kunnen worden (for the time being) ... bleeeehh

[Anoniem: 37526]

code:

    var ajaxRequest;
    try{
        
        ajaxRequest = new XMLHttpRequest();
    } catch (e){
        
        try{
            ajaxRequest = new ActiveXObject("Msxml2.XMLHTTP");
        } catch (e) {
            try{
                ajaxRequest = new ActiveXObject("Microsoft.XMLHTTP");
            } catch (e){
                
                alert("Sorry, Notepad will not work with your browser.");
                return false;
            }
        }
    }

O my...

[Standeman]

Ik kwam vandaag ook een mooie tegen:

Java:

        if (wrappedData.length>32) {
            // It is a wrapped RSA Private key without key reference info
            return wrappedData;
        }
        else if (wrappedData.length<32) {
            // It is a wrapped DES or 2DES key without key reference info
            return wrappedData;
        }
        else {
            // It is a wrapped DES or 2DES key with key reference info
            int length = wrappedData[16];
            byte[] wrappedDesKey = new byte[length];
            System.arraycopy(wrappedData, 0, wrappedDesKey, 0, length);

            return wrappedDesKey;
        }

Volgens mij is 1 if zonder else's genoeg

[LuCarD]

Standeman schreef op vrijdag 03 augustus 2007 @ 15:29:
Ik kwam vandaag ook een mooie tegen:

Java:

        if (wrappedData.length>32) {
            // It is a wrapped RSA Private key without key reference info
            return wrappedData;
        }
        else if (wrappedData.length<32) {
            // It is a wrapped DES or 2DES key without key reference info
            return wrappedData;
        }
        else {
            // It is a wrapped DES or 2DES key with key reference info
            int length = wrappedData[16];
            byte[] wrappedDesKey = new byte[length];
            System.arraycopy(wrappedData, 0, wrappedDesKey, 0, length);

            return wrappedDesKey;
        }

Volgens mij is 1 if zonder else's genoeg

ow? echt waar? en wat als de key exact 32 chars lang is?

[Anoniem: 178962]

LuCarD schreef op vrijdag 03 augustus 2007 @ 15:36:
[...]
ow? echt waar? en wat als de key exact 32 chars lang is?

Beter lezen

Het kan inderdaad met 1 if zonder else.

[LuCarD]

Anoniem: 178962 schreef op vrijdag 03 augustus 2007 @ 15:39:
[...]

Beter lezen

Het kan inderdaad met 1 if zonder else.

hmm ik ging er vanuit dat hij een gedeelte code had weggelaten...

[Anoniem: 178962]

Hoewel het niet eens zo'n grote WTF is. Het kan goed zijn dat er eerst 3 verschillende acties stonden, maar bij achteraf nadenken en aanpassen dat dit eruit is gekomen.

Het maakt verder ook weinig uit denk ik, een beetje compiler zal dat stukje wel voor de je optimaliseren denk ik en anders nog.

[Standeman]

Het was ook meer de leesbaarheid waar ik me aan stoorde.. En een echt grote WTF was het idd niet.

[Anoniem: 178962]

Standeman schreef op vrijdag 03 augustus 2007 @ 15:57:
Het was ook meer de leesbaarheid waar ik me aan stoorde.. En een echt grote WTF was het idd niet.

Ja maar, ja maar, er staat toch commentaar in?

[Anoniem: 49627]

Echt een 'slecht programmeervoorbeeld' is het niet maar toch een 'leuk' foutje/bugje dat ik vanmorgen had gemaakt.

Java:

new StringBuffer('[').append(someString).append(']');

[Marcj]

Anoniem: 49627 schreef op dinsdag 14 augustus 2007 @ 14:40:
Echt een 'slecht programmeervoorbeeld' is het niet maar toch een 'leuk' foutje/bugje dat ik vanmorgen had gemaakt.

Java:

new StringBuffer('[').append(someString).append(']');

Ik moest zelf ook even in de Java API kijken voordat ik het zag

[Anoniem: 37526]

Standeman schreef op vrijdag 03 augustus 2007 @ 15:29:
Ik kwam vandaag ook een mooie tegen:

Java:

...

Volgens mij is 1 if zonder else's genoeg

Daar ben ik het niet mee eens. Wat nou als er bij "wrapped DES or 2DES key without key reference info" opeens een extra functie moet worden toegevoegd?

De drie mogelijkheden zijn er gemaakt om de drie verschillende type keys duidelijk in de programmacode te scheiden, en ook om aan te tonen hoe je kunt zien of het een x, y of z key is. Het kan inderdaad korter, maar leesbaarder word het er niet op.

[Anoniem: 178962]

Anoniem: 49627 schreef op dinsdag 14 augustus 2007 @ 14:40:
Echt een 'slecht programmeervoorbeeld' is het niet maar toch een 'leuk' foutje/bugje dat ik vanmorgen had gemaakt.

Java:

new StringBuffer('[').append(someString).append(']');

Oei oei, die is sneaky zeg

offtopic:
Java ook altijd

[Voor 4% gewijzigd door Anoniem: 178962 op 14-08-2007 16:58]

[.oisyn]

Nou zie ik geen toString() en/of assignment, maar volgens komt dat meer omdat dat gewoon weggelaten is in de quote. De issue is volgens mij wel dat er geen constructor bestaat voor char. Wel voor int, maar een char is toch niet impliciet te converteren naar int in Java, of wel?

[Voor 11% gewijzigd door .oisyn op 14-08-2007 17:05]

[JKVA]

Anoniem: 178962 schreef op dinsdag 14 augustus 2007 @ 16:57:
[...]

Oei oei, die is sneaky zeg

offtopic:
Java ook altijd

Lol, ik had hem door.

Maar serieus, ik had hem al weleens gezien bij Java Puzzlers. Lekkere instinker.

Mark, ik neem aan dat dat statement gewoon ergens in real life code stond, tussen een stel ifs en zo? Dan kijk je er zo overheen.

[JKVA]

.oisyn schreef op dinsdag 14 augustus 2007 @ 17:04:
Nou zie ik geen toString() en/of assignment, maar volgens komt dat meer omdat dat gewoon weggelaten is in de quote. De issue is volgens mij wel dat er geen constructor bestaat voor char. Wel voor int, maar een char is toch niet impliciet te converteren naar int in Java, of wel?

Wel dus. Jammergenoeg in zulke gevallen.

Wat het overigens lulliger maakt, is dat append(char) wel bestaat.

[Voor 7% gewijzigd door JKVA op 14-08-2007 17:07]

[Anoniem: 178962]

.oisyn schreef op dinsdag 14 augustus 2007 @ 17:04:
Nou zie ik geen toString() en/of assignment, maar volgens komt dat meer omdat dat gewoon weggelaten is in de quote. De issue is volgens mij wel dat er geen constructor bestaat voor char. Wel voor int, maar een char is toch niet impliciet te converteren naar int in Java, of wel?

Volgens mij wordt in dit geval inderdaad de char impliciet naar een int omgezet, al zal de compiler wellicht wel een waarschuwing geven.

[Anoniem: 49627]

Anoniem: 178962 schreef op dinsdag 14 augustus 2007 @ 17:06:
Volgens mij wordt in dit geval inderdaad de char impliciet naar een int omgezet, al zal de compiler wellicht wel een waarschuwing geven.

De compiler is zo lief om helemaal niets te zeggen, die vertrouwt, om compleet ongegronde redenen, op mijn onuitputtelijke wijsheid.

@JVKA
Ik had dit fragment echt vlak daarvoor geschreven en viel gelukkig vrijwel direct op.
edit: ik snap nu wat je met 'reallife code' bedoeld. Ja het stond wat meer verspreid door de code Dit is uiteraard even het versimpelde voorbeeld.

[Voor 13% gewijzigd door Anoniem: 49627 op 14-08-2007 20:34]

[dingstje]

Alex) schreef op zaterdag 21 juli 2007 @ 16:12:
Ik gisteren nog...

JavaScript:

...this.getElementsByTagName('img')[0]...

Het ging over een <a> met daarin een <img> die dynamisch was aangemaakt (via JS, userscripts)... iets zegt me dat gewoon "this.firstChild" ook had volstaan... (dit was btw in een onclick-eventhandler)

Ik zou toch ook een dergelijke constructie gebruikt hebben ipv firstChild, om de simpele reden dat als ik over 2 jaar die code aanpas ik niet meer weet dat er ergens een methode is die verwacht dat de eerste child een img is. Je zou wel kunnen argumenteren 'documenteer het dan', maar uiteindelijk stop je een nieuwe requirement in je systeem dat de eerste child binnen je anker een image moet zijn, wat imho niet netjes is.

[JKVA]

Anoniem: 49627 schreef op dinsdag 14 augustus 2007 @ 20:31:
[...]
De compiler is zo lief om helemaal niets te zeggen, die vertrouwt, om compleet ongegronde redenen, op mijn onuitputtelijke wijsheid.

@JVKA
Ik had dit fragment echt vlak daarvoor geschreven en viel gelukkig vrijwel direct op.
edit: ik snap nu wat je met 'reallife code' bedoeld. Ja het stond wat meer verspreid door de code Dit is uiteraard even het versimpelde voorbeeld.

offtopic:
Ik weet niet of het een bestaande term is. Ik ben bang van niet. Maar goed, de boodschap kwam over.

[.oisyn]

dingstje schreef op dinsdag 14 augustus 2007 @ 20:59:
[...]

Ik zou toch ook een dergelijke constructie gebruikt hebben ipv firstChild, om de simpele reden dat als ik over 2 jaar die code aanpas ik niet meer weet dat er ergens een methode is die verwacht dat de eerste child een img is. Je zou wel kunnen argumenteren 'documenteer het dan', maar uiteindelijk stop je een nieuwe requirement in je systeem dat de eerste child binnen je anker een image moet zijn, wat imho niet netjes is.

Dat is met de code die daar staat niet veel anders. Het enige verschil is dat het de eerste IMG tag moet zijn ipv gewoon de eerste tag. Geef dat ding dan gewoon een naam

[dingstje]

.oisyn schreef op dinsdag 14 augustus 2007 @ 21:48:
[...]

Dat is met de code die daar staat niet veel anders. Het enige verschil is dat het de eerste IMG tag moet zijn ipv gewoon de eerste tag. Geef dat ding dan gewoon een naam

Ik had me eventjes laten meeslepen waardoor ik het globale plaatje niet meer zag

[Anoniem: 114584]

Ik weet niet of iets soortgelijks al langs gekomen is, maar dit kwam ik zojuist tegen:

PHP:

switch(true) {
case ($x == 1 || $x == 2 || $x == 3):
    ...
    break;
case ($x == 4 || $x == 5):
    ...
    break;
case ($x == 6 || $x == 7 || $x == 8):
    ...
    break;
default:
    ...
}

Hier heeft iemand toch echt iets niet helemaal begrepen ...

[Anoniem: 178962]

Al kan zo'n dergelijke constructie wel handig zijn als de cases iets complexer zijn, vooral de default optie is dan erg handig (itt veel if's en elses).

[Voor 92% gewijzigd door Anoniem: 178962 op 16-08-2007 14:24]

[Anoniem: 37526]

Anoniem: 178962 schreef op donderdag 16 augustus 2007 @ 14:24:


Al kan zo'n dergelijke constructie wel handig zijn als de cases iets complexer zijn, vooral de default optie is dan erg handig (itt veel if's en elses).

Dat zeker. Al is dit wel een grappige, waarbij de X prima in de switch-parameter kan.

[Anoniem: 42901]

Kom ik net dit tegen...

C++:

if (x)
    if (y)
        if (z)
        {
            // Uiteindelijke code
        }

[Anoniem: 178962]

Zonder een rijtje met else statements is die niet heel nuttig inderdaad.

[Anoniem: 42901]

Anoniem: 178962 schreef op donderdag 16 augustus 2007 @ 16:38:
Zonder een rijtje met else statements is die niet heel nuttig inderdaad.

Dat was er inderdaad niet(en dat stond er eerder ook niet: tis niet weggehaald om vervolgens niet te worden gerefactored).

[JMfx]

C#:

            try
            {
                percentWeek.Add(((iplusplus - icurrent) / icurrent) * 100);
            }
            catch (Exception)
            {
                //Division by zero.
                percentWeek.Add(0);
            }

Ik ging er vanuit dat de arrayList wel een DivisionByZero exception geeft als icurrent 0 is. Maar de arraylist voegt in dat geval 'infinity' toe.

[BasieP]

JMfx schreef op maandag 27 augustus 2007 @ 21:34:

C#:

            try
            {
                percentWeek.Add(((iplusplus - icurrent) / icurrent) * 100);
            }
            catch (Exception)
            {
                //Division by zero.
                percentWeek.Add(0);
            }

Ik ging er vanuit dat de arrayList wel een DivisionByZero exception geeft als icurrent 0 is. Maar de arraylist voegt in dat geval 'infinity' toe.

sowieso vind ik een try catch een rare keus voor het opvangen van dit soort 'fouten'
zoiets is meer mijn style:

C#:

percentWeek.add(icurrent>0?(iplusplus - icurrent) / icurrent * 100:0);

(ow en je hebt nutteloze haakjes in je code )

[Voor 3% gewijzigd door BasieP op 27-08-2007 21:39]

[Not Pingu]

JMfx schreef op maandag 27 augustus 2007 @ 21:34:

C#:

            try
            {
                percentWeek.Add(((iplusplus - icurrent) / icurrent) * 100);
            }
            catch (Exception)
            {
                //Division by zero.
                percentWeek.Add(0);
            }

Ik ging er vanuit dat de arrayList wel een DivisionByZero exception geeft als icurrent 0 is. Maar de arraylist voegt in dat geval 'infinity' toe.

Nee, vreemd genoeg geven rekenoperaties op wederzijdse floats in C# geen exception als die resulteren in een NaN of Infinity waarde. Ben het in mijn 3D renderer vaak tegengekomen bij matrixtransformaties.

[riezebosch]

Not Pingu schreef op maandag 27 augustus 2007 @ 21:50:
[...]


Nee, vreemd genoeg geven rekenoperaties op wederzijdse floats in C# geen exception als die resulteren in een NaN of Infinity waarde. Ben het in mijn 3D renderer vaak tegengekomen bij matrixtransformaties.

Wel geinig detail is dat de Math functies er ook prima mee overweg kunnen. Als je een oneindig getal in Math.Atan stopt (positief of negatief) komt er gewoon 90 of -90 graden uit (in radialen dan). Leuke is dat je met rondjes draaien dan ook gewoon door kan rekenen met overstaande gedeeld door aanliggende, ook op het moment dat je aanliggende 0 wordt.

[Anoniem: 14829]

BasieP schreef op maandag 27 augustus 2007 @ 21:38:
sowieso vind ik een try catch een rare keus voor het opvangen van dit soort 'fouten'
zoiets is meer mijn style:

C#:

percentWeek.add(icurrent>0?(iplusplus - icurrent) / icurrent * 100:0);

(ow en je hebt nutteloze haakjes in je code )

"conditie ? true : false" probeer ik zoveel mogelijk te mijden. Een normale if/else wordt door de compiler net zo efficient gecompileerd, en is na een half jaar een stuk beter leesbaar voor m'n collega's en ook voor mijzelf.
Idem voor die 'nutteloze haakjes'. Niet iedereen heeft MVDWOA altijd direct paraat, en dan zijn wat extra haakjes een stuk verduidelijkender en voor de compiler maakt 't geen barst uit.

[Anoniem: 178962]

Inderdaad, die haakjes zijn helemaal niet zo nutteloos, ze maken de code duidelijker leesbaar en helpen om fouten te voorkomen (hij zal immers altijd zich aan de haakjes houden, ook als je zelf een foutje maakt in de juiste volgorde, dan is het gedrag nog zoals je verwacht).

[.oisyn]

JMfx schreef op maandag 27 augustus 2007 @ 21:34:

C#:

            try
            {
                percentWeek.Add(((iplusplus - icurrent) / icurrent) * 100);
            }
            catch (Exception)
            {
                //Division by zero.
                percentWeek.Add(0);
            }

Ik ging er vanuit dat de arrayList wel een DivisionByZero exception geeft als icurrent 0 is. Maar de arraylist voegt in dat geval 'infinity' toe.

Even for the record, je berekening heeft niets met een ArrayList te maken. Dat je de berekende waarde in de lijst wilt stoppen doet er niet toe - je berekent éérst de waarde, en daarna stop je 'm pas in de lijst. De lijst heeft geen controle over de berekening, en zal dus zelf ook geen DivisionByZero exception gooien (een ArrayList hoeft immers niets te delen).

[PrisonerOfPain]

Anoniem: 14829 schreef op maandag 27 augustus 2007 @ 23:41:
Niet iedereen heeft MVDWOA altijd direct paraat, en dan zijn wat extra haakjes een stuk verduidelijkender en voor de compiler maakt 't geen barst uit.

Dus ik mag van een andere programmeur niet verwachtten dat 'ie de grammatica regels van z'n eigen programmeertaal onder de knie heeft? Net als dat ik niet mag verwachtten dat een programmeur basale syntax constructies onder de knie heeft zoals de ?: operator?

Anoniem: 178962 schreef op maandag 27 augustus 2007 @ 23:46:
Inderdaad, die haakjes zijn helemaal niet zo nutteloos, ze maken de code duidelijker leesbaar en helpen om fouten te voorkomen

Als ik haakjes zie verwacht ik een afwijkende situatie, als dat niet het geval is vind ik ze maar on overzichtelijk en maken ze het juist onduidelijker.

[Niemand_Anders]

Not Pingu schreef op maandag 27 augustus 2007 @ 21:50:
[...]


Nee, vreemd genoeg geven rekenoperaties op wederzijdse floats in C# geen exception als die resulteren in een NaN of Infinity waarde. Ben het in mijn 3D renderer vaak tegengekomen bij matrixtransformaties.

JMfx schreef op maandag 27 augustus 2007 @ 21:34:

C#:

            try
            {
                percentWeek.Add(((iplusplus - icurrent) / icurrent) * 100);
            }
            catch (Exception)
            {
                //Division by zero.
                percentWeek.Add(0);
            }

Ik ging er vanuit dat de arrayList wel een DivisionByZero exception geeft als icurrent 0 is. Maar de arraylist voegt in dat geval 'infinity' toe.

Heeft niemand jouw ooit verteld dat je altijd je variabelen moet controleren voordat je ze gebruikt? Verder behoort een exception een onverwachte situatie te zijn. Een variabele met de waarde 0 is zeker geen exception.

En dan hebben we het nog nieteens over de performance.

C#:

if (icurrent == 0)
    //add 0
else
    //add calculated value

Is een stuk sneller dan het afvangen van een exception. Je moet als programmeur altijd zoveel mogelijk exceptions voorkomen. Kijk ook eens na het geheugen gebruik van je applicatie wanneer je een exception optreed. Afhankelijk van je stacktrace pakt je programma eenvoudig 'ineens' 5mb extra. Op een desktop computer zal dat niet snel een probleem zijn (tenzij de gebruiker al flink aan het swappen is), maar op een server is dit dodelijk. Want daar heb je niet 1 bezoeker, maar vak tientallen en bij drukken sites soms wel duizenden requests per minuut op 1 machine.

Als laatste puntje wil je ik nog even op de naming guidelines van Microsoft wijzen.

[gorgi_19]

JMfx schreef op maandag 27 augustus 2007 @ 21:34:

C#:

            try
            {
                percentWeek.Add(((iplusplus - icurrent) / icurrent) * 100);
            }
            catch (Exception)
            {
                //Division by zero.
                percentWeek.Add(0);
            }

Ik ging er vanuit dat de arrayList wel een DivisionByZero exception geeft als icurrent 0 is. Maar de arraylist voegt in dat geval 'infinity' toe.

Als je een DivisionByZero wilt krijgen, moet je niet met doubles / floats gaan werken, maar met decimals.

[Woy]

gorgi_19 schreef op dinsdag 28 augustus 2007 @ 09:03:
[...]

Als je een DivisionByZero wilt krijgen, moet je niet met doubles / floats gaan werken, maar met decimals.

Je moet zowiezo geen DivisionByZero willen krijgen

[Anoniem: 43565]

rwb schreef op dinsdag 28 augustus 2007 @ 09:13:
[...]

Je moet zowiezo geen DivisionByZero willen krijgen

In dat geval is het toch een Exception i.p.v. een if-else
De vraag is dan of je het gewoon op nul wilt zetten ipv paniek wilt schoppen, schermpjes wilt oppoppen en logs wilt vol schrijven.

[Voor 21% gewijzigd door Anoniem: 43565 op 28-08-2007 09:29]

[PolarBear]

JMfx schreef op maandag 27 augustus 2007 @ 21:34:

C#:

            try
            {
                percentWeek.Add(((iplusplus - icurrent) / icurrent) * 100);
            }
            catch (Exception)
            {
                //Division by zero.
                percentWeek.Add(0);
            }

Ik ging er vanuit dat de arrayList wel een DivisionByZero exception geeft als icurrent 0 is. Maar de arraylist voegt in dat geval 'infinity' toe.

\

Als je specifiek de DivisionByZero exception wil handelen kan je overigens ook dit doen (even afgezien van het feit of dit met exceptions afhandelen het netst is:

Visual Basic .NET:

            Try
                'Code
            Catch zeroEx As DivideByZeroException
                'Divide by zero afhandelen
            Catch ex As Exception
                'overige fouten afhandelen
            End Try

Niemand_Anders schreef op dinsdag 28 augustus 2007 @ 08:48:
Als laatste puntje wil je ik nog even op de naming guidelines van Microsoft wijzen.

Als je ergens op wijst mag je dat wel iets uitgebreider doen. Linkje, waar gaat het mis etc. Dan kunnen we er nog wat van leren cq er over discusseren.

[Voutloos]

'iplusplus' is een slechte variabelenaam, daar heb je niet eens een coding style doc voor nodig.
Je zou denken op basis van die naam dat het altijd 1 meer is dan icurrent (of i), maar waarom dan niet gewoon 1 (of 100, heb je meteen een percentage ) neer zetten als noemer in dat sommetje? Als het iets anders is (waarschijnlijk), geef het dan een betere naam, bijvoorbeeld i_next, next_value of next_element of wat het ook mag voorstellen.

[JMfx]

Wat betreft het gebruik van exceptions in plaats van checks op de waarde 0, misschien zit er wel wat in. Ik denk dat het niet zoveel uitmaakt welke manier ik gebruik voor mijn applicatie. Het is puur een desktop applicatie (geen server toepassing).

De haakjes zijn natuurlijk ter verduidelijking, daar lijkt mij niet zoveel mis mee. De ?: operators vind ik persoonlijk erg onduidelijk, veel onoverzichtelijker dan if / else. Ik zou die niet gebruiken. Wat betreft de naamgeving, de code loopt door een arraylist. Zie hieronder.

C#:

            for (int i = 0; i < balanceWeek.Count - 1; i++)
            {
                icurrent = Convert.ToDouble(balanceWeek[i]);
                iplusplus = Convert.ToDouble(balanceWeek[i + 1]);

                if (icurrent != 0)
                {
                    percentWeek.Add(((iplusplus - icurrent) / icurrent) * 100);
                }
                else
                {
                    //Prevent infinity being added to the arraylist.
                    percentWeek.Add(0);
                }
            }

[Voutloos]

Het staat nu dicht bij elkaar, dus je zoekt het toevallig makkelijk op, maar iets als current_week_balance en next_week_balance is imo toch echt veel beter.

[PrisonerOfPain]

Niemand_Anders schreef op dinsdag 28 augustus 2007 @ 08:48:
Is een stuk sneller dan het afvangen van een exception. Je moet als programmeur altijd zoveel mogelijk exceptions voorkomen. Kijk ook eens na het geheugen gebruik van je applicatie wanneer je een exception optreed. Afhankelijk van je stacktrace pakt je programma eenvoudig 'ineens' 5mb extra.

Zeker bij een desktop applicatie maakt het geheugengebruik mij absoluut niet uit, dan gebruik ik gewoon wat voor mij het meest makkelijke of duidelijke is. (Dat exceptions in dit geval misschien niet nodig zijn even buiten beschouwing gelaten). Door te kijken naar de implementatie van bepaalde features overtreed je trouwens ook nog een basis principe in het object georiënteerd denken namelijk de scheiding van interface (de taal) en implementatie (de compiler).

JMfx schreef op dinsdag 28 augustus 2007 @ 11:30:De ?: operators vind ik persoonlijk erg onduidelijk, veel onoverzichtelijker dan if / else.

Waarschijnlijk omdat je (en anderen) alles op een regel probeert te proppen, wat compleet overbodig is. Meestal schrijf ik het daarom ook zo op:

C#:

percentWeek.Add(
    icurrent != 0
        ? (iplusplus - icurrent) / icurrent * 100
        : 0
);

[JMfx]

PrisonerOfPain schreef op dinsdag 28 augustus 2007 @ 11:59:

[...]


Waarschijnlijk omdat je (en anderen) alles op een regel probeert te proppen, wat compleet overbodig is. Meestal schrijf ik het daarom ook zo op:

C#:

percentWeek.Add(
    icurrent != 0
        ? (iplusplus - icurrent) / icurrent * 100
        : 0
);

Maar waarom zou je deze manier van schrijven gebruiken? Je hebt nu meer coderegels dan het if / else equivalent (afgezien van wat haakjes). En de if / else is veel overzichtelijker.

[JKVA]

JMfx schreef op dinsdag 28 augustus 2007 @ 13:29:
[...]


Maar waarom zou je deze manier van schrijven gebruiken? Je hebt nu meer coderegels dan het if / else equivalent (afgezien van wat haakjes). En de if / else is veel overzichtelijker.

Dit kan veel overzichtelijker zijn dan if else als je bijvoorbeeld variabelen wilt initialiseren o.b.v. bepaalde criteria. Je moet bij een if else je variabele vooraf (op null) initialiseren, met de ternary operator niet. Dan kan alles inline.

Java:

String test = (bladiebla != null) bladiebla.getStringOfzo()
    ? bladiebla.getStringOfzo()
    : "leeg";

[Anoniem: 178962]

PrisonerOfPain schreef op dinsdag 28 augustus 2007 @ 07:56:
[...]
Als ik haakjes zie verwacht ik een afwijkende situatie, als dat niet het geval is vind ik ze maar on overzichtelijk en maken ze het juist onduidelijker.

Tjah, dat kun je wel verwachten, maar dan nog moet je het met haakjes heel gemakkelijk kunnen lezen en weet je direct zonder ook maar na te denken wat er staat.

Hoe meer je moet nadenken bij het lezen van code, des te groter dat er fouten worden gemaakt, mensen maken namelijk nogal eens fouten bij het nadenken

Opmaak van formules als in nutteloze haakjes, spaties, enters, zelfs commentaar in de formule moet gewoon geen enkel probleem zijn en kun je alleen maar aanmoedigen als in ieder geval een poging de code beter leesbaar te maken.

Het is aan de programmeur natuurlijk om te bepalen wanneer dat het als overbodig overkomt en wanneer het nuttig is, als je daar niet goed in bent dan is het beste om gewoon altijd de haakjes te plaatsen dan ben je in ieder geval nog consistent.

Voor de compiler etc maakt het allemaal geen hol uit, dus wat dat betreft is er weinig reden het niet te doen (buiten jouw persoonlijke smaak, maar gezien je andere voorbeelden is die nogal anders als die van mij).

[.oisyn]

Anoniem: 178962 schreef op dinsdag 28 augustus 2007 @ 13:44:
[...]

Tjah, dat kun je wel verwachten, maar dan nog moet je het met haakjes heel gemakkelijk kunnen lezen en weet je direct zonder ook maar na te denken wat er staat.

Behalve het feit dat teveel haakjes dingen juist helemaal niet duidelijker maken, omdat je door de haakjes de grammatica niet meer kunt zien. Dat haakjes altijd verduidelijken is helemaal niet zonder meer waar.

[Anoniem: 178962]

.oisyn schreef op dinsdag 28 augustus 2007 @ 13:46:
[...]

Behalve het feit dat teveel haakjes dingen juist helemaal niet duidelijker maken, omdat je door de haakjes de grammatica niet meer kunt zien. Dat haakjes altijd verduidelijken is helemaal niet zonder meer waar.

Anoniem: 178962 schreef op dinsdag 28 augustus 2007 @ 13:44:
[...]
Het is aan de programmeur natuurlijk om te bepalen wanneer dat het als overbodig overkomt en wanneer het nuttig is, als je daar niet goed in bent dan is het beste om gewoon altijd de haakjes te plaatsen dan ben je in ieder geval nog consistent.

Dat zeg ik Gamma..

[Erkens]

Niemand_Anders schreef op dinsdag 28 augustus 2007 @ 08:48:
Een variabele met de waarde 0 is zeker geen exception.

Afhankelijk van de situatie kan dat wel degelijk een exception zijn. Bijvoorbeeld als er in principe nooit de mogelijkheid is dat die variabele op 0 kan staan.

.oisyn schreef op dinsdag 28 augustus 2007 @ 13:46:
[...]

Behalve het feit dat teveel haakjes dingen juist helemaal niet duidelijker maken, omdat je door de haakjes de grammatica niet meer kunt zien. Dat haakjes altijd verduidelijken is helemaal niet zonder meer waar.

true, hoewel ik de voorkeur geef om vooral bij de ternary operator er een paar haakjes extra bij te doen. Juist om enige onduidelijkheid te voorkomen ook als dat niet echt nodig.

[Rowdy.nl]

Sommige van mijn collega's (waaronder ik) vinden de ?: constructie heel handig en gebruiken 'm veelvuldig. Sommige andere collega's rennen d'r onderhand gillend van weg. Tis imho een kwestie van persoonlijke voorkeur, 't een is niet (altijd) beter dan 't ander...

Maar is dat niet een andere discussie?

[Janoz]

Ik gebruik de ternary operator eigenlijk alleen bij het toekennen of bij het afdrukken. Vaak is het om een default waarde te kunnen gebruiken. Zeker wanneer je veel gegevens afdrukt (of append aan een later te gebruiken string) vind ik een if juist veel lelijker.

[PrisonerOfPain]

JMfx schreef op dinsdag 28 augustus 2007 @ 13:29:
[...]
Maar waarom zou je deze manier van schrijven gebruiken? Je hebt nu meer coderegels dan het if / else equivalent (afgezien van wat haakjes). En de if / else is veel overzichtelijker.

Het aantal regels is niet relevant, noch het aantal tekens. Wat voor mij belangrijker is is dat je op deze manier minder dubbele code hebt (twee keer de percentWeek.Add aanroep).

Anoniem: 178962 schreef op dinsdag 28 augustus 2007 @ 13:44:
[...]
Tjah, dat kun je wel verwachten, maar dan nog moet je het met haakjes heel gemakkelijk kunnen lezen en weet je direct zonder ook maar na te denken wat er staat.

Zodra je een tijd ervaring hebt met een bepaalde programmeertaal mag je er toch vanuit gaan dat je de voorrangsregels van de betreffende taal kent? Zeker aangezien die regels meestal duidelijk in de manual gespecificeerd zijn. Een van de weinige keren dat ik haakjes prefereer is in PHP als && en and door elkaar gebruikt worden (die hebben namelijk andere voorrangsregels maar betekenen hetzelfde), maar goed dat word sowieso amper gebruikt. Als ik veel haakjes wou zien had ik wel voor een op s-expressions gebaseerde programmeertaal gekozen.

[Anoniem: 178962]

Je schrijft code dan ook niet zodat je het zelf goed kunt lezen, je schrijft code zodat een ander het goed kan lezen (En daarbij hopelijk ook zo dat je het zelf kunt lezen )

[.oisyn]

Janoz schreef op dinsdag 28 augustus 2007 @ 14:06:
Ik gebruik de ternary operator eigenlijk alleen bij het toekennen of bij het afdrukken. Vaak is het om een default waarde te kunnen gebruiken. Zeker wanneer je veel gegevens afdrukt (of append aan een later te gebruiken string) vind ik een if juist veel lelijker.

En soms moet het:

C++:

class MyClass
{
    MyOtherClass myVar;

    MyClass(bool myParam) : myVar(myParam ? 1 : 2)
    {
    }
};

Wat tevens ook een van de belangrijkste redenen is waarom het ding überhaupt bestaat.

[Voor 7% gewijzigd door .oisyn op 28-08-2007 14:15]

[Anoniem: 43158]

k

[Voor 100% gewijzigd door Anoniem: 43158 op 28-08-2007 14:17]

[Anoniem: 43158]

Anoniem: 49627 schreef op dinsdag 14 augustus 2007 @ 14:40:
Echt een 'slecht programmeervoorbeeld' is het niet maar toch een 'leuk' foutje/bugje dat ik vanmorgen had gemaakt.

Java:

new StringBuffer('[').append(someString).append(']');

Dit werkt toch wel gewoon bij mij als ik hiervan een println doe. Ik ben wel geen ervaren java programmeur dusja misschien mag ik de .toString() wel niet doen om dat bugje te krijgen.

[Anoniem: 43158]

Anoniem: 114584 schreef op donderdag 16 augustus 2007 @ 14:21:
Ik weet niet of iets soortgelijks al langs gekomen is, maar dit kwam ik zojuist tegen:

PHP:

switch(true) {
case ($x == 1 || $x == 2 || $x == 3):
    ...
    break;
case ($x == 4 || $x == 5):
    ...
    break;
case ($x == 6 || $x == 7 || $x == 8):
    ...
    break;
default:
    ...
}

Hier heeft iemand toch echt iets niet helemaal begrepen ...

De taal RPGIV waar ik in programmer kent enkel deze switch

code:

Select;
   When x = 1; 
   .... 
   Other;
EndSl;

[Anoniem: 43158]

[

Anoniem: 114584 schreef op donderdag 16 augustus 2007 @ 14:21:
Ik weet niet of iets soortgelijks al langs gekomen is, maar dit kwam ik zojuist tegen:

PHP:

switch(true) {
case ($x == 1 || $x == 2 || $x == 3):
    ...
    break;
case ($x == 4 || $x == 5):
    ...
    break;
case ($x == 6 || $x == 7 || $x == 8):
    ...
    break;
default:
    ...
}

Hier heeft iemand toch echt iets niet helemaal begrepen ...

De taal RPGIV waar ik in programmer kent enkel deze switch

Java:

Select;
   When x = 1; 
   .... 
   Other;
EndSl;

[--MeAngry--]

Anoniem: 43158 schreef op dinsdag 28 augustus 2007 @ 14:38:
[
[...]


De taal RPGIV waar ik in programmer kent enkel deze switch

Java:

Select;
   When x = 1; 
   .... 
   Other;
EndSl;

Ja maargoed, je programmeert niet in een andere taal om je aan de regels van de vorige taal te houden
PHP heeft nog wel niet voor niets case-fallthrough.

[Janoz]

Anoniem: 43158 schreef op dinsdag 28 augustus 2007 @ 14:23:
[...]


Dit werkt toch wel gewoon bij mij als ik hiervan een println doe. Ik ben wel geen ervaren java programmeur dusja misschien mag ik de .toString() wel niet doen om dat bugje te krijgen.

Dan zou ik toch nog eens even goed gaan kijken. Als ik het uitvoer is namelijk het haakje open verdwenen. Check eventueel ff javadoc

[PrisonerOfPain]

Anoniem: 178962 schreef op dinsdag 28 augustus 2007 @ 14:12:
Je schrijft code dan ook niet zodat je het zelf goed kunt lezen, je schrijft code zodat een ander het goed kan lezen (En daarbij hopelijk ook zo dat je het zelf kunt lezen )

In teamverband volg ik gewoon de opgestelde regels, in alle andere gevallen kies ik wat mij het beste ligt (of de huidige coding guideline).

Zag net nog een leuk voorbeeldje op wikipedia:

C:

  vehicle = arg == 'B' ? bus :
            arg == 'C' ? car :
            arg == 'A' ? airplane :
            arg == 'T' ? train :
            arg == 'H' ? horse :
            feet;

[Not Pingu]

Niemand_Anders schreef op dinsdag 28 augustus 2007 @ 08:48:

Heeft niemand jouw ooit verteld dat je altijd je variabelen moet controleren voordat je ze gebruikt? Verder behoort een exception een onverwachte situatie te zijn. Een variabele met de waarde 0 is zeker geen exception.

Ligt aan de situatie. Delen door 0 kan niet en als een getal dat als deler gebruikt wordt, na berekening uitkomt op 0, lijkt me dat een redelijk exception. Het is ook een stuk makkelijker met debuggen: ipv. alleen als resultaat te zien dat je app een stuk langzamer wordt door het afhandelen van NaN/Infinity, meteen een aanwijzing hebben waar de ongeldige waarde erinsluipt.

Als je een gigantische hoop rekenwerk doet (bijv. een stel matrixtransformaties) is het niet altijd even makkelijk om te achterhalen waar het nou fout ging. Zeker at debugtime wil je dan die informatie hebben.

[Janoz]

Delen door 0 kan wel. Daar komt oneindig uit tenzij je 0 deelt door 0. "Delen door nul is flauwekul" is een rijmpje dat op de basisschool onderwezen wordt omdat het concept van oneindig nogal lastig uit te leggen is. Hetzelfde geldt voor de wortel uit een negatief getal . Zoals riezebosch eerder al aangaf kun je vaak nog wel gewoon verder rekenen met deze het resultaat van een delen door nul actie.

Zelf een waarde toe gaan kennen in een dergelijke context lijkt me eerder fout. Wanneer je een percentage uitrekend over een bepaalde periode en de periode blijkt 0 te zijn dan is bij een groei de groei inderdaad oneindig en bij een gelijk gebleven hoeveelheid (0/0) inderdaad de groei ongedefinieerd. Inf en NaN zijn de enige juiste uitkomsten uit een dergelijke berekening.

[apNia]

Wellicht leuk om in de startpost te zetten: The Daily WTF (tegenwoordig 'Worse Than Failure')

http://worsethanfailure.com/

edit: en dan voornamelijk het code deel

[Voor 29% gewijzigd door apNia op 28-08-2007 15:45]

[Anoniem: 43158]

ik krijg deze output in de commandline: [Test]

en dit is mijn code:

Java:

public class ExportData
{
public static void main(String[] args)
 { 
      StringBuffer buff = new StringBuffer().append('[').append("Test").append(']');
            
      
      System.out.println(buff.toString());
 }

}

[NetForce1]

Anoniem: 43158 schreef op dinsdag 28 augustus 2007 @ 15:45:
ik krijg deze output in de commandline: [Test]

en dit is mijn code:

Java:

...

Het probleem zat em in de constructor-aanroep, probeer dit maar eens:

Java:

public class ExportData {
public static void main(String[] args) { 
      StringBuffer buff = new StringBuffer('[').append("Test").append(']');
      System.out.println(buff.toString());
 }
}

[Anoniem: 43565]

Janoz schreef op dinsdag 28 augustus 2007 @ 15:31:
Delen door 0 kan wel. Daar komt oneindig uit tenzij je 0 deelt door 0. "Delen door nul is flauwekul" is een rijmpje dat op de basisschool onderwezen wordt omdat het concept van oneindig nogal lastig uit te leggen is. Hetzelfde geldt voor de wortel uit een negatief getal . Zoals riezebosch eerder al aangaf kun je vaak nog wel gewoon verder rekenen met deze het resultaat van een delen door nul actie.

Zelf een waarde toe gaan kennen in een dergelijke context lijkt me eerder fout. Wanneer je een percentage uitrekend over een bepaalde periode en de periode blijkt 0 te zijn dan is bij een groei de groei inderdaad oneindig en bij een gelijk gebleven hoeveelheid (0/0) inderdaad de groei ongedefinieerd. Inf en NaN zijn de enige juiste uitkomsten uit een dergelijke berekening.

Er kan ook een exception uit komen. Hangt er van af of je ints of floats/doubles gebruikt.

Voor Java:
int/0 geeft een ArithmeticException.
float/0 geeft Infinity
0.0/0 geeft NaN
0.0/0.0 geeft NaN
float/0.0 geeft Infinity

Is certificeringsstof en er zit 'een' vorm van logica in

[Janoz]

Anoniem: 43158 schreef op dinsdag 28 augustus 2007 @ 15:45:
ik krijg deze output in de commandline: [Test]

en dit is mijn code:

Java:

public class ExportData
{
public static void main(String[] args)
 { 
      StringBuffer buff = new StringBuffer().append('[').append("Test").append(']');
            
      
      System.out.println(buff.toString());
 }

}

Ja, maar die code is nu eenmaal niet hetzelfde als de geposte code he

[Janoz]

Anoniem: 43565 schreef op dinsdag 28 augustus 2007 @ 15:56:
[...]

Er kan ook een exception uit komen. Hangt er van af of je ints of floats/doubles gebruikt.

Voor Java:
int/0 geeft een ArithmeticException.
float/0 geeft Infinity
0.0/0 geeft NaN
0.0/0.0 geeft NaN
float/0.0 geeft Infinity

Is certificeringsstof en er zit 'een' vorm van logica in

Ik weet het (/me is ook rijkelijk gecertificeerd), maar die beperking heeft vooral met het gebruikte datatype type te maken. In een int is namelijk lastig op te slaan dat het oneindig of NaN is.

[Not Pingu]

Janoz schreef op dinsdag 28 augustus 2007 @ 15:31:
Zoals riezebosch eerder al aangaf kun je vaak nog wel gewoon verder rekenen met deze het resultaat van een delen door nul actie.

Maar in welk geval wil je dat? Ervan uitgaande dat de berekeningen die je wilt implementeren wiskundig gewoon kloppen en nuldeling ofwel per definitie wordt afgevangen of niet mogelijk hoort te zijn, is een nuldeling gewoon een onverwacht iets.

Bovendien heeft doorrekenen met die infinitywaarde geen enkele zin, want dat had waarschijnlijk een betekenisvolle real-waarde moeten zijn die nu niet meer betekenisvol is (behalve dan als aanwijzing dat er iets fout gaat in je code).

Dan kun je mensen wel uitmaken voor kleuters, maar het feit blijft dat infinity/nan in de meeste gevallen een showstopper is. Je kunt het goed functioneren van je code dan niet meer garanderen.

[Janoz]

Je kunt wel degelijk doorrekenen met een Inf of een NaN. Alle operatoren ondersteunen deze waarden gewoon. Een leuk voorbeeld is bijvoorbeeld degene die riezebosch aangaf. Uit atan(Inf) komt gewoon 90 (of 1/2 Pi).

Het punt is dat een berekening waar Inf uitkomt waarschijnlijk gewoon Inf uit hoort te komen. De uitkomst Inf is dus helemaal geen teken dat er iets fout gegaan is.

De enige fouten die in een computer voorkomen zijn eerder overflows en afrondfouten.

[.oisyn]

Janoz schreef op dinsdag 28 augustus 2007 @ 15:31:
Delen door 0 kan wel. Daar komt oneindig uit tenzij je 0 deelt door 0. "Delen door nul is flauwekul" is een rijmpje dat op de basisschool onderwezen wordt omdat het concept van oneindig nogal lastig uit te leggen is. Hetzelfde geldt voor de wortel uit een negatief getal

Nou zou ik delen door 0 en de wortel van een negatief getal niet bepaald over 1 kam willen scheren. De wortel uit een negatief getal is goed-gedefinieerd en geeft een complex getal. De oneindigheid als gevolg van deling door 0 is echter niet helemaal correct. Als je het zou benaderen dan klopt het idd:
lim_{x -> 0} (1/x) = 0.

Maar volgens wiskundige definities kun je een reëel getal niet delen door 0. Het is ongedefinieerd. Het zou alles kunnen zijn, want x*0 = 0 voor alle x. De basisschool was daadwerkelijk correct (itt de stelling over de wortel van negatieve getallen)

[Anoniem: 43565]

Janoz schreef op dinsdag 28 augustus 2007 @ 16:17:
[...]

Ik weet het (/me is ook rijkelijk gecertificeerd), maar die beperking heeft vooral met het gebruikte datatype type te maken. In een int is namelijk lastig op te slaan dat het oneindig of NaN is.

ik ben geen wiskundige maar ik dacht dat je een Exception kreeg omdat delen door 0 gewoon niet kan en een Inf, omdat een float nooit exact nul hoeft te zijn (afrondingsfouten) en dus gelezen kan worden als oneindig klein.

Maar dan hou je inderdaad NaN over wat een betere uitkomst zou zijn en dat kun je inderdaad niet in een int opslaan.

[.oisyn]

Anoniem: 43565 schreef op dinsdag 28 augustus 2007 @ 17:04:
[...]

ik ben geen wiskundige maar ik dacht dat je een Exception kreeg omdat delen door 0 gewoon niet kan en een Inf, omdat een float nooit exact nul hoeft te zijn (afrondingsfouten) en dus gelezen kan worden als oneindig klein.

Inf staat voor infinity, niet voor infinitesimal. IEEE floats hebben geen aparte representatie voor infinitesimal. Een deling door 0 geeft gewoon infinity, tenzij de noemer ook 0 is, dan geeft het indefinite (ofwel NaN)

[Anoniem: 43565]

.oisyn schreef op dinsdag 28 augustus 2007 @ 18:29:
[...]

Inf staat voor infinity, niet voor infinitesimal. IEEE floats hebben geen aparte representatie voor infinitesimal. Een deling door 0 geeft gewoon infinity, tenzij de noemer ook 0 is, dan geeft het indefinite (ofwel NaN)

ik bedoel dat een deling door infinitesmall infinity opleverd.

m.i. geeft 0 zelf namelijk in alle gevallen alles danwel niets als uitkomst en zijn computers gewoon gek

[Voor 12% gewijzigd door Anoniem: 43565 op 28-08-2007 18:39]

[.oisyn]

Oh ok, maar dat kan dus niet, want er is geen aparte representatie voor infinitesimal (let op de spelling ). Maar uit berekeningen die voorbij FLOAT_MAX gaan komt meestal wel infinity ja.

[Free rider]

.oisyn schreef op dinsdag 28 augustus 2007 @ 18:29:
Een deling door 0 geeft gewoon infinity, tenzij de noemer ook 0 is, dan geeft het indefinite (ofwel NaN)

"tenzij de noemer ook 0 is" Ik neem aan dat je de teller bedoelt.
Maar dat is niet juist. Stel dat de teller positief is. Als de noemer (0) positief zou zijn, is het resultaat inderdaad Inf. Maar als de noemer negatief zou zijn, is het resultaat -Inf. Maar geen van beide stellingen zijn waar, immers 0 is niet kleiner en ook niet groter dan 0.

[riezebosch]

.oisyn schreef op dinsdag 28 augustus 2007 @ 16:35:
[...]

Nou zou ik delen door 0 en de wortel van een negatief getal niet bepaald over 1 kam willen scheren. De wortel uit een negatief getal is goed-gedefinieerd en geeft een complex getal. De oneindigheid als gevolg van deling door 0 is echter niet helemaal correct. Als je het zou benaderen dan klopt het idd:
lim_{x -> 0} (1/x) = 0.

Maar volgens wiskundige definities kun je een reëel getal niet delen door 0. Het is ongedefinieerd. Het zou alles kunnen zijn, want x*0 = 0 voor alle x. De basisschool was daadwerkelijk correct (itt de stelling over de wortel van negatieve getallen)

Waarom is 0/0 eigenlijk geen 1, zoals geldt voor elke andere x?

[.oisyn]

Ik bedoelde idd teller, maar voor de rest begrijp ik je verhaal niet helemaal. Toen ik het had over "infinity" deed ik geen uitspraak of dat positief dan wel negatief zou zijn. Als je deelt door 0 (zij het +0 of -0) en de teller is niet 0, is het +inf als teller en noemer hetzelfde teken hebben, en -inf anderzijds.

Even voor de goede orde, hier had ik het natuurlijk over de IEEE floating point regels, dat stuk heb je echter uit de quote gehaald. Niet dat het correcte wiskunde is (waarvan ik al eerder heb aangegeven dat het dat niet is)

[.oisyn]

riezebosch schreef op dinsdag 28 augustus 2007 @ 23:23:
[...]

Waarom is 0/0 eigenlijk geen 1, zoals geldt voor elke andere x?

Je bedoelt als in x/x? Waarom is het dan geen 0, zoals voor elke andere x in 0/x?

[Gomez12]

Ach tja, nog even over de haakjes bij berekeningen. Worst case praktijkvoorbeeld wat ik ooit eens ben tegengekomen was gewoon 2 regels met gezamelijk 460 tekens, enkeltekenige ( $a, $i, $b etc ) variabelen en zonder haakjes 1 formule uitgeschreven. Heeft me toen ongeveer een uur gekost om de formule compleet te begrijpen.

Na herschrijven was het 10 regels code met behoorlijke variabelen en haakjes en goede enters en indentin ( plus 2 regels comments ). Meeste collega´s zagen nu in 1 oogopslag wat het deed.

En na navragen bij programmeur was het een optimalisatie slag die welgeteld ,08 sec afhaalde van een functie die gewoon 1 sec duurde. Toen collega maar even uitgelegd dat dit een compleet overbodige optimalisatie was die meer koste dan het opleverde ( collega´s negeerden deze regels gewoon omdat het te veel tijd koste om te gaan uitzoeken wat het deed ).

Betreffende collega had trouwens wel meer van dit soort kuntstukjes in zijn code gebouwd, regels kan ik maar 255 tekens lang maken,ach tja als je een beetje gaat concatenaten kan ik meerdere regels van 255 tekens maken die gewoon 1 statement zijn ( hoogtepunt 21 regels over 1 statement doen en dan raar opkijken als je collega´s jouw code weigeren te debuggen . Alleen maar omdat de debugger alleen maar per statement/regel keek dus als hier iets fout in ging dan kon iemand even 21 regels samengeperste troepcode op het oog gaan zitten debuggen of herschrijven.... )
Maar ja, gelukkig is het al enkele jaren een ex-collega...

[kenneth]

Zie ik in onze code ergens ranzige datefuncties (met variabelenamen als i, j, k, l, m, n ) ... ik vroeg me af waar het vandaan kwam ... blijkt het hier te zijn http://www.codeproject.com/csharp/GregToISO.asp
Zie ook de commentaren ...

/me gaat maar eens omschrijven ... zitten bugs in

[PrisonerOfPain]

kenneth schreef op donderdag 30 augustus 2007 @ 13:04:
Zie ik in onze code ergens ranzige datefuncties (met variabelenamen als i, j, k, l, m, n ) ... ik vroeg me af waar het vandaan kwam ... blijkt het hier te zijn http://www.codeproject.com/csharp/GregToISO.asp
Zie ook de commentaren ...

/me gaat maar eens omschrijven ... zitten bugs in

C#:

using System;
using System.Globalization;

Calendar c = new Calendar();
int weekNumberISO = c.GetWeekOfYear(someTime, CalendarWeekRule.FirstFourDayWeek, DayOfWeek.Monday);

[kenneth]

Juist

Toen ik zag wat de code zou moeten doen, wist ik al 99% zeker dat dit gewoon in het .NET framework zit. Dat soort dingen voel je gewoon aan ... zou je denken

[ikke007]

Vandaag een geniale van mijn collega. Ik heb hier een tabel met daarin diverse xsl templates. (template_id, template). Ik vraag mijn collega welke template de actieve template is.
"template_id 0 is de actieve, want zodra deze niet meer actief is wordt hij handmatig hernoemd naar max(template_id)+1".

Oftewel: De oudste niet-actieve template is id 1, en de nieuwste niet-actieve template is 20 en 0 is de actieve. logisch!

[Voor 0% gewijzigd door ikke007 op 30-08-2007 15:49. Reden: typo]

[Dido]

kenneth schreef op donderdag 30 augustus 2007 @ 14:43:
Toen ik zag wat de code zou moeten doen, wist ik al 99% zeker dat dit gewoon in het .NET framework zit. Dat soort dingen voel je gewoon aan ... zou je denken

Mwah, blindelings vertrouwen op correcte implementatie van wat ingewikkelder date-functions wordt je in bepaalde omgevingen keihard afgeleerd, hoor. Het is al enige tijd terug, maar ik heb ooit de ingebouwde weeknummer-functie moeten herschrijven (en dat is ook vrij onleesbare code geworden - soit, het werkt, en er is geen denkbare reden om het voor 2300 aan te passen) omdat de Australische leverancier erin geslaagd was om alleen het Amerikaanse weeknummer te implementeren (dus niet ISO) en dat nog fout te doen ook.

[gorgi_19]

Wat heb je dan als alternatief? Alles herbenoemen? Evt. kan je nog datums er achter frotten.

[kenneth]

Dido schreef op donderdag 30 augustus 2007 @ 16:08:
[...]

Mwah, blindelings vertrouwen op correcte implementatie van wat ingewikkelder date-functions wordt je in bepaalde omgevingen keihard afgeleerd, hoor.

Oh, zeker met datumfuncties ben ik zeer terughoudend geworden ja, maar waarom zou je een buggy (!) implementatie maken van iets wat al in 't framework zit? Als het al beter is, zeg dan waarom. Maar blijkbaar wist deze meneer gewoon niet van het bestaan af van System.Globalization.

[Dido]

kenneth schreef op donderdag 30 augustus 2007 @ 16:18:
Oh, zeker met datumfuncties ben ik zeer terughoudend geworden ja, maar waarom zou je een buggy (!) implementatie maken van iets wat al in 't framework zit? Als het al beter is, zeg dan waarom. Maar blijkbaar wist deze meneer gewoon niet van het bestaan af van System.Globalization.

Een buggy implementatie is natuurlijk sowieso nooit een alternatief (hell, als je het dan doet, dan test je het toch geautomatiseerd even door voor de eerstvolgende x00 jaar?).

En als er een werkende implementatie bestaat verdient het vaak aanbeveling die te gebruiken, natuurlijk.