Gathering of Tweakers

ik krijg deze output in de commandline: [Test]

en dit is mijn code:
Java:

1 2 3 4 5 6 7 8 9 10 11

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

quote:

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

en dit is mijn code:
Java:

1

...

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

1 2 3 4 5 6

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

quote:

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

quote:

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

en dit is mijn code:
Java:

1 2 3 4 5 6 7 8 9 10 11

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

quote:

The_Tzar 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.

quote:

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.

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.

quote:

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)

quote:

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.

quote:

The_Tzar 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)

quote:

.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

The_Tzar wijzigde dit bericht 28-08-2007 18:39 (12%)

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.

quote:

.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.

quote:

.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?

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)

quote:

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?

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...

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 ...

* gaat maar eens omschrijven ... zitten bugs in

quote:

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 ...

* gaat maar eens omschrijven ... zitten bugs in

C#:

1 2 3 4 5

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

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

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!

ikke007 wijzigde dit bericht 30-08-2007 15:49 (0%)
Reden: typo

quote:

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.

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

quote:

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.

quote:

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.