Alternatief voor PHP bij het maken van bedrijfsapplicaties

[Verwijderd]

Op mijn werk heb ik een aantal opgaves op te lossen, zoals een kostprijsberekening met veel parameters of een algoritme om een container zo efficient mogelijk te laden met verschillende formaten dozen.

Aanvankelijk zijn mijn collega's lang geleden begonnen met Excel. De sheets zijn van een niveau dat je je rekenmachine er bij moet houden om tot het eindantwoord te komen.

Mijn taak is om op een zeer breed gebied de werkdruk van de werknemers te verlichten, door het introduceren van handige oplossingen. Zo heb ik in Excel een kostprijsberekening gemaakt die uiteindelijk 232 kB aan code geworden is. Ik ben het overzicht geheel kwijt. Als ik een wijziging wil doorvoeren, moet ik mezelf elke keer minimaal een half uur inlezen en kijken welke cel op welk blad ook alweer wat betekent. Ook is het niet (makkelijk) dynamisch genoeg (te krijgen).

Aangezien 95% van de excel 'scripts' berekeningen zijn waar uiteindelijk een getal, of een lijst van getallen uit komt, zou ik dit perfect in PHP kunnen doen. En ik kan dit ook in PHP.

Het probleem is dan echter dat het niet practisch is om een server met PHP neer te zetten. Om een lang verhaal kort te maken zou er een nieuwe server moeten komen.

Een andere optie is om VBA te gebruiken. Uiteindelijk zie ik het min of meer als workaround om de beperkingen van Excel tegen te gaan. Ik heb al wat VBA gebruikt, maar eigenlijk wil ik hier niet mee verder.

Daarom dacht ik dat het practischer zou zijn om een stand-alone programma te maken.

Voordelen:
* dynamischer dan excel
* veel beter overzicht dan met excel
* mensen met minder computerkunde kunnen niet per ongeluk formules wissen en met foutieve informatie verder rekenen
* geen server nodig i.t.t. PHP

Nadelen:
* misschien toch makkelijk met centrale database? -> toch server nodig
* hoe alle clienten van updates te voorzien (veranderde inkoopsprijzen etc.)?
* ik zal een programmeertaal moeten leren

De grote vraag is nu dan ook: WELKE programmeertaal is het beste geschikt om dit soort problemen op te lossen?

Mijn overwegingen (willekeurige volgorde):
* Java -> nog nooit een letter code van gezien, maar aangezien PHP op Java gebaseerd zou zijn, lijkt het me een reeele optie. Bovendien is het vandaag de dag redelijk populair en kan ik er waarschijnlijk in de toekomst nog wel meer mee.
* C# -> ben ik vorig jaar mee begonnen, maar snel weer mee gestopt. Vanwege gebrekkige tutorials en het niet aan de praat krijgen van allerlei zaken kwam het niet erg van de grond.
* C / C++ -> heel lang geleden heb ik wel eens C-programma's (in dos-venster) geschreven. Ik weet nog hoe het werkt, maar dat betekent niet dat ik kan gaan zitten en programma's kan gaan schrijven. Ook hierop is PHP gebaseerd. Eventuele tweede optie.
* VB -> het is me nooit helemaal duidelijk geweest wat het voordeel / sterke punt van deze taal is. Vroeger moest je altijd allerlei DLL's downloaden om programma's die in deze taal geschreven waren aan de praat te krijgen...
* Delphi -> nooit in verdiept.

Kortom: Ik denk dat Java een geschikte optie is om te gaan leren. Wie wil er even mee-brainstormen?

[disjfa]

* misschien toch makkelijk met centrale database? -> toch server nodig

Dat is gewoon einde en klaar. Welke taal je verder wilt is geen probleem toch

[Verwijderd]

disjfa schreef op dinsdag 02 oktober 2007 @ 10:27:
[...]


Dat is gewoon einde en klaar. Welke taal je verder wilt is geen probleem toch

Laten we er even van uit gaan dat ik met de eenvoudigste problemen begin en alles zo lang lokaal houd.

[Voutloos]

Een server plaatsen is toch eenvoudig? In ieder geval veel makkelijker dan orde proberen te schepen in een gedecentraliseerde chaos van excel sheets en verschillende, oude client software en oude berekeningen.

Het lijkt mij zelfs dat een server + onderhoud goedkoper is dan de bestaande chaos in stand houden.

[Gurbe de n00b]

Je kunt toch ook bijv. de inkoopprijzen in een los document zetten (xml, csv whatever) om ze zo makkelijk te kunnen vervangen.

En bij een Excel document moet je toch ook de inkoopprijzen updaten ?

Persoonlijk lijkt het mij dat webbased niet echt handig is in dit geval, ik zou het bij een desktop applicatie houden.

Tevens zijn er bij het .Net framework ook direct tools beschikbaar die die via het internet kijkt of je de laatste versie gebruikt.

[ Voor 17% gewijzigd door Gurbe de n00b op 02-10-2007 10:36 . Reden: Toevoegingkje ]

[Verwijderd]

Oke, ik ben het er mee eens dat een server plaatsen op zich geen probleem is.

Maar als ik dan toch opnieuw begin, is het dan verstandig om een eigenlijk niet online applicatie als PHP script te schrijven, of een stand-alone programma te maken.

Misschien was het niet helemaal duidelijk, maar er is GEEN oude client software, alleen een chaos van excel sheets, en die moet verdwijnen. Ik heb geprobeerd om één excel bestand er van te maken, maar doordat er een beetje code in elke cel staat, is er totaal geen overzicht.

En bij een Excel document moet je toch ook de inkoopprijzen updaten ?

Dat is gewoon een xlt (mall) die op een netwerkschijf staat en die ik zo nu en dan update.

Je kunt toch ook bijv. de inkoopprijzen in een los document zetten (xml, csv whatever) om ze zo makkelijk te kunnen vervangen.

Dat was ook eigenlijk de bedoeling. Mijn vraag was eigenlijk meer een overweging hoe het het makkelijkste zou kunnen.

[ Voor 29% gewijzigd door Verwijderd op 02-10-2007 10:39 ]

[Voutloos]

Verwijderd schreef op dinsdag 02 oktober 2007 @ 10:37:
Ik heb geprobeerd om één excel bestand er van te maken, maar doordat er een beetje code in elke cel staat, is er totaal geen overzicht.

Er groeien nu dus allemaal nieuwe regeltjes en features omdat iedereen wat aan kan klooien. Misschien dus handiger om een echt functioneel ontwerp te maken en features vast te leggen (desnoods met openhouden vraagstuk client / webbased).
Ja, als je een stricter programma hebt moeten veel mensen gaan wennen en gaat iedereen zeiken 'omdat verandering eng is', maar anders kom je nooit van legacy af.

[Verwijderd]

Om te beginnen kan je natuurlijk PHP lokaal draaien, mbv van iets als XAMPP.

[Verwijderd]

Verwijderd schreef op dinsdag 02 oktober 2007 @ 10:42:
Om te beginnen kan je natuurlijk PHP lokaal draaien, mbv van iets als XAMPP.

Het is geen probleem om PHP lokaal te draaien. Als er een server moet komen, dan komt die er, dat is ook geen probleem. De vraag is of het wel verstandig is om überhaupt in PHP te beginnen.

Er groeien nu dus allemaal nieuwe regeltjes en features omdat iedereen wat aan kan klooien. Misschien dus handiger om een echt functioneel ontwerp te maken en features vast te leggen (desnoods met openhouden vraagstuk client / webbased).
Ja, als je een stricter programma hebt moeten veel mensen gaan wennen en gaat iedereen zeiken 'omdat verandering eng is', maar anders kom je nooit van legacy af.

Ga er maar niet van uit dat iedereen 'wat aan kloot'. Er is sinds ik het voor het eerst gepubliceerd heb (in juni) nog nooit iets gewijzigd door de gebruikers (bij gebrek aan excel-kennis). Bovendien komen ze liever naar me toe om ideeen te spuien die ik later kan verwerken. Tot op heden staat iedereen heel positief tegenover de nieuwe sheets die ik gemaakt heb, dat is in ieder geval al in mijn voordeel.

[TeeDee]

Verwijderd schreef op dinsdag 02 oktober 2007 @ 10:24:
Op mijn werk heb ik een aantal opgaves op te lossen, zoals een kostprijsberekening met veel parameters of een algoritme om een container zo efficient mogelijk te laden met verschillende formaten dozen.

offtopic:
dat algoritme is altijd leuk om te maken

Het probleem is dan echter dat het niet practisch is om een server met PHP neer te zetten. Om een lang verhaal kort te maken zou er een nieuwe server moeten komen.

Waarom is het niet praktisch om een server neer te zetten? Lijkt me juist wel praktisch!

Daarom dacht ik dat het practischer zou zijn om een stand-alone programma te maken.

Mee eens.

Voordelen:
* dynamischer dan excel
* veel beter overzicht dan met excel
* mensen met minder computerkunde kunnen niet per ongeluk formules wissen en met foutieve informatie verder rekenen

Tot hier ga je goed!

* geen server nodig i.t.t. PHP

Juist hierbij lijkt het me ook handig om een centrale machine te hebben. Opslag van gegevens zoals prijzen, vorige berekeningen (lijkt me geen efficiente bedoening als elke prijsberekening uniek is) etc. etc.

Nadelen:
* misschien toch makkelijk met centrale database? -> toch server nodig
* hoe alle clienten van updates te voorzien (veranderde inkoopsprijzen etc.)?
* ik zal een programmeertaal moeten leren

Hier zie ik geen nadelen in hoor

De grote vraag is nu dan ook: WELKE programmeertaal is het beste geschikt om dit soort problemen op te lossen?

Door deze vraag te stellen haal je een hoop mensen hierheen die zeggen: Gebruik <insert taal etc> zonder vaak enige onderbouwing.

* Java -> nog nooit een letter code van gezien, maar aangezien PHP op Java gebaseerd zou zijn, lijkt het me een reeele optie. Bovendien is het vandaag de dag redelijk populair en kan ik er waarschijnlijk in de toekomst nog wel meer mee.

Afaik is PHP op C(++) gebaseerd. Of lijkt het er in ieder geval op. Op zich is dit een goede optie... (psst, C# lijkt er ook op )

* C# -> ben ik vorig jaar mee begonnen, maar snel weer mee gestopt. Vanwege gebrekkige tutorials en het niet aan de praat krijgen van allerlei zaken kwam het niet erg van de grond.

Mjah, mijn voorkeur gaat naar C# uit. (Maar dat is persoonlijk) Het feit dat je geen goede tutorials kan vinden is imo onzin. Download een Visual Studio Variant en je kan middels het 'sleur en pleur' toch al vrij vlot het e.e.a in elkaar zetten. Als ik het zo hoor (Excel) is jullie office omgeving op Windows ge-ent. Lijkt het me persoonlijk een logische keus om aan de slag te gaan met .Net (hetzij VB.net, hetzij C#) Je hebt alleen het .Net framework nodig.

* C / C++ -> heel lang geleden heb ik wel eens C-programma's (in dos-venster) geschreven. Ik weet nog hoe het werkt, maar dat betekent niet dat ik kan gaan zitten en programma's kan gaan schrijven. Ook hierop is PHP gebaseerd. Eventuele tweede optie.

Verder geen ervaring mee, dus kan er niet veel meer zinnigs over zeggen dan: je hebt er al ervaring mee.

* VB -> het is me nooit helemaal duidelijk geweest wat het voordeel / sterke punt van deze taal is. Vroeger moest je altijd allerlei DLL's downloaden om programma's die in deze taal geschreven waren aan de praat te krijgen...

Gelukkig is er voor VB een vervangen: VB.net. Lijkt in de verste verte niet op de oude VB behalve dan de syntax. Ook hier heb je het .Net framework voor nodig. (Over het algemeen draait dit al op je Windows omgeving.)

* Delphi -> nooit in verdiept.

Ik ook niet.

Kortom: Ik denk dat Java een geschikte optie is om te gaan leren. Wie wil er even mee-brainstormen?

Als je daar nu al je pijlen op gericht hebt, ben ik bang dat onze ideeën je niet al te snel van gedachte zullen veranderen.

Waar je erg op moet letten is: Schrijf een goed, afgebakend Functioneel Ontwerp. Als ik het zo hoor zijn er in de loop van de tijd features bijgekomen.

Trouwens, .Net heeft het ClickOnce Deployment principe. Op die manier haal je het hele updaten van de clients naar (komt ie weer) de centrale server.

[Verwijderd]

TeeDee: Bedankt voor je positieve reactie!!!

Ik vind het ook erg leuk om dat soort algoritmes te bedenken (de gedachtengang op papier heb ik al af).

In het kort komt het er op neer:
* het is toch handiger met een centrale (database) server, iets wat ik uit wou stellen, maar misschien toch verstandiger om direct mee te beginnen
* liever een stand-alone programma dan een webbased (dus geen PHP)
* .NET lijkt een aantrekkelijke optie

Als je daar nu al je pijlen op gericht hebt, ben ik bang dat onze ideeën je niet al te snel van gedachte zullen veranderen.

Ik heb niet specifiek mijn pijlen daarop gericht, maar het leek me in eerste instantie het meest geschikt, omdat de drempel van C# iets verhoogd is voor mij omdat het eerder niet erg lukte (ligt overigens meer aan mezelf dan aan de taal) en ik wist niet dat VB zo erg vernieuwd is.

Waar je erg op moet letten is: Schrijf een goed, afgebakend Functioneel Ontwerp. Als ik het zo hoor zijn er in de loop van de tijd features bijgekomen.

Dit is geen probleem, de functionaliteit is niet veranderd sinds ik begonnen ben. De enige veranderingen zijn verfijningen van de berekeningen.

Wellicht is het toch verstandig om nog eens goed naar C# te kijken. Toen ik dat thuis eens ging proberen leek het me ook een goede keuze, maar nu heb ik de mogelijkheden om cursussen te doen en boeken te kopen.

[Ramon]

Tja, jij wil alleen een advies in welke taal je moet programmeren maar dat lijkt me helemaal niet handig om daarmee te beginnen. Eerst moet je zoals hierboven staat een lijst hebben met wat je allemaal in je programma zou willen hebben. Om de werknemers te laten inzien dat het nodig is om te vernieuwen moet je ook met hen communiceren en je moet ook proberen voor hen een meerwaarde te creeeren waarom ze zouden overstappen. Dit zijn allemaal dingen waar je een beslissing over zal moeten nemen voordat je een programmeertaal gaat kiezen of gaat denken of het webbased/gecentraliseerd moet of dat het een gewone desktop applicatie moet zijn.

Als je wil weten of iets een desktop-app of een webbased-app moet worden kan je bijvoorbeeld nadenken over handelingen en berekeningen die gedaan moeten worden. Voeren je gebruikers berekeningen uit die een paar minuten duren, dan zou het niet handig zijn om dat webbased te doen, maar zijn de berekeningen in onder de seconde klaar dan is dat geen probleem.

Over het kiezen van een programmeertaal; het klinkt leuk om iets te kiezen wat je nog niet kent voor een project, maar je neemt dan wel een risico met of je het wel door kan zien tot het eind.

[Kalentum]

Misschien ook nog het overwegen waard: er is een PHP compiler voor het .NET framework. Hierdoor kan je dus in PHP objecten gebruiken van .NET en zo Windowsapplicaties maken.

Zie http://www.php-compiler.n...anger_for_.net_developers

Ik heb geen idee of dit goed werkt maar je zou het even kunnen proberen.

[Verwijderd]

Eerst moet je zoals hierboven staat een lijst hebben met wat je allemaal in je programma zou willen hebben.

Dit is 100% bekend voor de 2 programma's waar ik het over heb. Één programma is werkend en wordt al een paar maanden gebruikt in Excel.

Om de werknemers te laten inzien dat het nodig is om te vernieuwen moet je ook met hen communiceren en je moet ook proberen voor hen een meerwaarde te creeeren waarom ze zouden overstappen.

Het is een vraag vanuit de werknemers. Ze zien zelf in dat het nodig is. Bovendien zijn deze programmaatjes maar een heel klein deel van het geheel. We hebben hier zeer regelmatig vergaderingen over.

Als je wil weten of iets een desktop-app of een webbased-app moet worden kan je bijvoorbeeld nadenken over handelingen en berekeningen die gedaan moeten worden. Voeren je gebruikers berekeningen uit die een paar minuten duren, dan zou het niet handig zijn om dat webbased te doen, maar zijn de berekeningen in onder de seconde klaar dan is dat geen probleem.

Wij denken andersom. Ik denk: Als het niet webbased hoeft, doe het dan niet. Jij denkt: Als het webbased kan, doe het dan.

Over het kiezen van een programmeertaal; het klinkt leuk om iets te kiezen wat je nog niet kent voor een project, maar je neemt dan wel een risico met of je het wel door kan zien tot het eind.

Ik ben me wel degelijk zeer bewust van dit risico. Daarom probeer ik hier te overwegen of ik door zal gaan met Excel (zelf geen zin in), of dat ik het in PHP kan maken (aangezien ik het wiel al een keer uitgevonden heb in Excel, kan ik dit venster sluiten, het in gaan kloppen en ben ik over een of twee weken klaar), of dat ik het standalone zou maken.

Daarom de vraag of je even wilt toelichten waarom je als het mogelijk is webbased zou verkiezen boven standalone (zoals ik je begrijp). Zelf denk ik namelijk andersom.

[killercow]

is php gtk niet iets voor je?
Kun je lekker bij php blijven (scheelt toch weer), en kun je toch een lokale app bouwen.

Dat je eigenlijk het beste een webapp kunt bouwen met een centrale server is nu wel duidelijk genoeg lijkt me. Webbased heeft als voordeel dat je net telkens een nieuwe versie hoeft uit te rollen, dat de browser je enige te supporten platform is, en dat dingen als backups en data intergriteit netjes op de server afgehandeld kan worden.

Besides, een dikke server kan een ingewikkelde query/berekening toch sneller dat de desktop machines. En die paar miliseconde response tijd die je extra nodig hebt vanwege het netwerk boeit dan zeker niet.

[sig69]

killercow schreef op dinsdag 02 oktober 2007 @ 11:25:
is php gtk niet iets voor je?
Kun je lekker bij php blijven (scheelt toch weer), en kun je toch een lokale app bouwen.

Dat je eigenlijk het beste een webapp kunt bouwen met een centrale server is nu wel duidelijk genoeg lijkt me.

Sorry maar dat haal ik er toch niet helemaal uit. Volgens mij kan het nog alle kanten op.

Webbased heeft als voordeel dat je net telkens een nieuwe versie hoeft uit te rollen,

Op de cliens niet nee, maar de server zal toch ook geupdate moeten worden. Hier kan je bijvoorbeeld ClickOnce deployment van .Net tegenover zetten. Niet echt een argument voor webbased dus.

dat de browser je enige te supporten platform is,

True

en dat dingen als backups en data intergriteit netjes op de server afgehandeld kan worden.

Heeft ook niet echt veel met webbased of niet te maken. Een standalone client met centrale database komt op hetzelfde neer

Besides, een dikke server kan een ingewikkelde query/berekening toch sneller dat de desktop machines. En die paar miliseconde response tijd die je extra nodig hebt vanwege het netwerk boeit dan zeker niet.

Ik weet niet hoe zwaar die berekeningen precies zijn, maar als het echt om hele zware berekeningen gaat dan is deze situatie ook minder fijn als er meerdere gebruikers tegelijk lekker gaan zitten rekenen. Verder weten we helemaal niets van de aldaar gebruikte hardware voor de desktops / workstations dus eigenlijk valt hier helmaal niets over te zeggen.

[Janoz]

of een algoritme om een container zo efficiënt mogelijk te laden met verschillende formaten dozen.

Je weet dat dit een NP-Hard probleem is en dat een algoritme hiervoor verzinnen niet zo simpel is?

[writser]

Als ik jou was zou ik de PHP oplossing kiezen. Waarom?

- Je kent de taal al.
- Je hebt geen gezeur met gebruikers die nog een oude versie gebruiken, iedereen draait dezelfde versie. je kan dus makkelijk wat bugs fixen en / of functionaliteit toevoegen.
- Als je toch met een centrale server wil gaan werken bespaar je je een hoop gekloot met netwerkconnecties.
- Platformonafhankelijk
- GUI maken is eenvoudig
- Je kent de taal nog steeds

Samengevat het is gewoon makkelijk.

Als je het leuk vindt om een nieuwe taal te leren o.i.d. moet je dat vooral doen. Ook in C++, Java, Python, C#, Ruby en ASP kun je een prima applicatie maken, maar dat gaat je gewoon meer tijd kosten.

[ Voor 9% gewijzigd door writser op 02-10-2007 11:52 ]

[Blue-eagle]

Het klinkt als behoorlijk belangrijke software - is het niet een idee om een professioneel team van programmeurs in te huren? Dan heb je direct continuïteit en een kwaliteitsgarantie. Jij stelt de eisen (broncode bij iedere release, volledige documentatie, et cetera) en levert de specificatie.

Als je in je eentje bezig gaat loop je altijd het o-zo-waarschijnlijke risico dat je tegen een boom knalt en het niet na kan vertellen. Zie dan iemand anders maar in jouw code in te werken...

[TeeDee]

writser schreef op dinsdag 02 oktober 2007 @ 11:49:
- Je hebt geen gezeur met gebruikers die nog een oude versie gebruiken, iedereen draait dezelfde versie. je kan dus makkelijk wat bugs fixen en / of functionaliteit toevoegen.

Zoals vaker aangehaald heeft bijvoorbeeld .Net het ClickOnce deployment principe. Kan me niet voorstellen dat andere frameworks/talen een soortgelijk iets hebben.

- Als je toch met een centrale server wil gaan werken bespaar je je een hoop gekloot met netwerkconnecties.

Die mag je me even uitleggen.
Of je nu 200 gebruikers via een Webbased applicatie heb of 200 gebruikers via een Standalone applicatie lijkt mij niks uit te maken.

- Een simpele webinterface is lekker makkelijk te maken.

Voor een kostenberekenings applicatie lijkt me de insteek: een simpele webinterface niet correct.

- Je kent de taal nog steeds

Maar je hebt je horizon niet verbreed. Begrijp me niet verkeerd hoor; je moet goed weten waar je aan begint om op een andere taal over te stappen, alleen moet je je ook afvragen: gebruik ik wel de juiste tools/taal voor deze job?

[Verwijderd]

Ik zou toch echt gaan voor Excel.

Het klinkt misschien gek om een rekensheet als container te gebruiken maar in praktijk blijkt het toch heel praktisch...

[RubenDJ]

Heb je al eens aan FileMaker gedacht (of ken je het überhaupt)?
• het is een database- en presentatielaag in 1
• je hoeft er niet echt voor te kunnen programmeren
• er is niet per sé een server nodig maar het kan wel
• ingebouwde rekenfuncties
• je kunt er zo mee aan de slag

[writser]

Maar je hebt je horizon niet verbreed.

Als je je horizon wil verbreden kun je ook proberen om het te implementeren in assembly op een wasmachine. Schiet alleen niemand wat mee op. De topicstarter wil voor zijn werk een applicatie maken. Dan zou ik de efficientste manier kiezen waarop je een redelijke applicatie kan maken. Het lijkt me duidelijk dat dat met PHP is, vanwege alle redenen die ik en anderen al aangaven.

Maar de topicstarter wil zijn programma eigenlijk niet in PHP maken (ik quote: liever een stand-alone programma dan een webbased (dus geen PHP)). Beetje vreemd omdat hij daar geen enkele valide reden voor geeft. Wil je wat experimenteren dan kun je deze applicatie natuurlijk maken in elke taal die je zelf wil.

[Janoz]

Beetje vreemd omdat hij daar geen enkele valide reden voor geeft.

Kijk, en daar zit 'm de crux. Jij bent degene die er enkel een webapplicatie in ziet. Jij bent degene die naar dit probleem met een 'php tenzij' mindset zit te kijken. Kijken we nogmaals naar de twee voorbeelden die Ts geeft:

• een kostprijsberekening met veel parameters

Dit wil je niet in een webapplicatie bouwen. Vele parameters geeft onoverzichtelijke schermen. Dit zou je alleen in een webapplicatie moeten gieten als er een duidelijke workflow bestaat en het goed in een wizzard achtige structuur te gieten is. Voor dit onderdeel moet ik volledig met mark platvoet meegaan. Hiervoor is Excel gewoon het meest geschikt. Een spreadsheet applicatie is juist bedoeld om dit soort berekeningen te doen (itt de 'database vervanger' waarvoor mensen het vaak gebruiken)

• of een algoritme om een container zo efficient mogelijk te laden met verschillende formaten dozen.

Dit is een behoorlijk lastig probleem en het uitrekenen van een leuke benadering van een goede oplossing gaat wat tijd duren. Dat is niet iets wat je wilt in een request gebaseerde webapplicatie en daarnaast wil je dat ook helemaal niet op een centrale server uit gaan rekenen. Daarnaast is het opgeven van een berg dozen nu ook weer niet iets wat je even makkelijk in een html formpje giet, om over de weergave van het antwoord al helemaal te zwijgen.

Voor dit onderdeel zou ik eerder naar een op de client draaiend stand allone applicatie neigen. Hiervoor zou ik dan Java of een .NET variant gebruiken (C# of VB). C(++) en Delphi zijn leuk, maar beiden voor dit soort toepassingen imho redelijk end of life.


Ik blijf trouwens nog steeds erg nieuwschierig hoe tygetjuh denkt het dozen in de containers probleem op te gaan lossen..

[ Voor 4% gewijzigd door Janoz op 02-10-2007 12:53 ]

[TeeDee]

writser schreef op dinsdag 02 oktober 2007 @ 12:12:
[...]

Als je je horizon wil verbreden kun je ook proberen om het te implementeren in assembly op een wasmachine. Schiet alleen niemand wat mee op. De topicstarter wil voor zijn werk een applicatie maken. Dan zou ik de efficientste manier kiezen waarop je een redelijke applicatie kan maken. Het lijkt me duidelijk dat dat met PHP is, vanwege alle redenen die ik en anderen al aangaven.

Je haalt alleen dat stukje uit mijn quote.
Nog maar een keertje dan:

Begrijp me niet verkeerd hoor; je moet goed weten waar je aan begint om op een andere taal over te stappen, alleen moet je je ook afvragen: gebruik ik wel de juiste tools/taal voor deze job?

En nog maar even een quote:

Als je het leuk vindt om een nieuwe taal te leren o.i.d. moet je dat vooral doen. Ook in C++, Java, Python, C#, Ruby en ASP kun je een prima applicatie maken, maar dat gaat je gewoon meer tijd kosten.

Janoz schreef op dinsdag 02 oktober 2007 @ 12:51:
[...]
Ik blijf trouwens nog steeds erg nieuwschierig hoe tygetjuh denkt het dozen in de containers probleem op te gaan lossen..

Ik ook
Doet me een beetje aan Travelling Salesman denken.

[ Voor 25% gewijzigd door TeeDee op 02-10-2007 13:06 ]

[voodooless]

TeeDee schreef op dinsdag 02 oktober 2007 @ 13:03:
Ik ook

Dan weet ik nog wel een leuk, leerzame, betrekkelijk snelle methode om tot een suboptimale oplossing te komen: een genetisch algoritme Niet dat dat de meest voor de hand liggende methode is, maar 't is wel leuk om eens naar te kijken.

Anyway, altijd voor alles een website maken is misschien wel helemaal hip, en het kan vast wel, maar de inspanning die nodig is om iets te maken wat op Excel lijkt in een webbrowser, en dan ook nog eens foutloos zijn werk doet is gewoon belachelijk groot.

Excel is leuk, maar zoals al gezegd is ben je snel de structuur kwijt en wordt het al heel gouw een gigantische warboel.

Voordat je gaat kijken waarin je het gaat maken zou ik eerst eens inventariseren WAT je precies moet maken, hoe dat er structureel eruit ziet, en wat je daar precies voor nodig hebt. Dan kun je gaan kijken welke taal en libs daar het beste bij passen. Kijk daarbij ook naar aanpasbaarheid van je reken modellen en dat soort zaken. Het houden van een duidelijke structuur lijkt hier van absoluut belang. Een echte OO taal zoals C++, Java of C# (in willekeurige volgorde) is dan wel heel handig om je daarbij een heel groot handje te helpen. De leercurve is echter in het begin best fors om dat onder de knie te krijgen. Uiteindelijk zal je daar echter de vruchten van plukken.

[ Voor 3% gewijzigd door voodooless op 02-10-2007 13:29 ]

[writser]

Kijk, en daar zit 'm de crux. Jij bent degene die er enkel een webapplicatie in ziet. Jij bent degene die naar dit probleem met een 'php tenzij' mindset zit te kijken.

Klopt, en je argumenten zijn duidelijk. Maar de topicstarter zegt zelf: "Aangezien 95% van de excel 'scripts' berekeningen zijn waar uiteindelijk een getal, of een lijst van getallen uit komt, zou ik dit perfect in PHP kunnen doen". Vraag me af waarom hij dan verder zoekt.

[Janoz]

Omdat hij twijfelt (en terecht). Te zien aan de eerste regel van een volgende allinea.

Een andere optie is om VBA te gebruiken.

Vervolgens komt hij tot een vraagstelling wat hij nu moet kiezen en het antwoord daarop is dat het waarschijnlijk beter niet in php kan.

@TeeDee:
Traveling Salesmen is inderdaad ook NP-Hard. Dit probleem is een variant van het Knapsack probleem. Beiden zijn wel combinatorische optimalisatie problemen.

[Yoozer]

Verwijderd schreef op dinsdag 02 oktober 2007 @ 10:24:
Als ik een wijziging wil doorvoeren, moet ik mezelf elke keer minimaal een half uur inlezen en kijken welke cel op welk blad ook alweer wat betekent. Ook is het niet (makkelijk) dynamisch genoeg (te krijgen).

Je wilt dus iets invullen en dan zonder gezeur gelijk het antwoord zien?

Het probleem is dan echter dat het niet practisch is om een server met PHP neer te zetten. Om een lang verhaal kort te maken zou er een nieuwe server moeten komen.

Afhankelijk van het aantal mensen die er gelijk gebruik van maken kun je ook, zoals eerder genoemd, overwegen XAMPP op je eigen workstation neer te zetten. Zoveel vreet 't niet, mensen gaan (hopelijk) geen bestanden uploaden; het probleem is alleen dat je 'm aan moet hebben staan. Ik heb zo hier bij m'n eigen baan een testserver met een Wiki gedraaid, en dat ging prima als overtuigingsmiddel. Aan de andere kant is wat jij maakt geen Wiki, dus .

Ik heb al wat VBA gebruikt, maar eigenlijk wil ik hier niet mee verder.

Groot gelijk .

Met je voordelen ben ik 't 100% eens.

Nadelen:
* misschien toch makkelijk met centrale database? -> toch server nodig
* hoe alle clienten van updates te voorzien (veranderde inkoopsprijzen etc.)?
* ik zal een programmeertaal moeten leren

Dit zegt niet zoveel over de taal, maar wel over de aanpak. Als je 'm standalone wil maken kun je met .NET of Java heel snel iets leuks maken, maar het wordt dan wel een soort "business"-calculator: plug er een paar getallen in, en klaar. Je bent dan dus van de gebruiker zelf afhankelijk of 'ie wel de juiste getallen uit de prijslijsten haalt.

Updates is heel makkelijk; op het moment dat je je idee aan management kunt verkopen zorg je er gewoon voor dat als jij een mail doorstuurt van "jongens, nieuwe versie" dat mensen die ook downloaden.

De grote vraag is nu dan ook: WELKE programmeertaal is het beste geschikt om dit soort problemen op te lossen?

Da's eigenlijk de foute vraag; iedere taal laat toe dat je bepaalde dingen doet. Waar het om gaat is waar jij het snelste in kan ontwikkelen.

Kortom: Ik denk dat Java een geschikte optie is om te gaan leren. Wie wil er even mee-brainstormen?

Je hebt ervaring met AWT/Swing/watdanook? Bij VB.NET (de klassieke VB kun je beter gewoon overslaan) heb je een gratis IDE waar je snel knoppen en tekstvakken in kunt sleuren en pleuren. Een gratis en goede ontwikkelomgeving is erg lekker om te hebben. Dat geldt voor C# ook. Voor Java heb je Eclipse, en daar kun je ook een aardige GUI mee bouwen.

Waarom zoveel gedoe over die GUI? Nou, dat is wat het verkoopt aan je collega's. Zorg er voor dat het snel werkt, dat de cursor met 1 keer op tab hengsten naar het juiste volgende veld gaat, en je krijgt fans. Taal maakt dan niet meer zoveel uit, als het maar snel is, en als jij er maar mee kan werken.

Het argument tegen webbased krijgt er dan nog een puntje bij. Je hoort wel eens vaker van die verhalen waar een oude terminal of DOS-applicatie wordt vervangen door een intranetapplicatie. Deze werken niet per definitie sneller; vaak door de nieuwe GUI (die wennen is) en het vele POST-en van formulieren.

Als laatste: wat je noemt qua Excel - vaak zitten er op kantoor mensen die wel eens wat gespeeld hebben met macro's (en daarom niet schrikken van VB of VB.NET), maar Java is niet zo'n hobbytaal die bij Office zit. Denk ook aan je opvolger .

[ Voor 11% gewijzigd door Yoozer op 02-10-2007 14:57 ]

[ATS]

Ik zou zelf bij Excel blijven, maar daar een interface bij maken. Dat kan in VBA van Excel zelf, maar dat kan ook in een willekeurige andere taal waarin je excel als object kan aanspreken. Als je je sheets behoorlijk indeelt, dan hoeft dat helemaal geen warboel te worden.

[Grijze Vos]

Janoz schreef op dinsdag 02 oktober 2007 @ 14:36:
Traveling Salesmen is inderdaad ook NP-Hard. Dit probleem is een variant van het Knapsack probleem. Beiden zijn wel combinatorische optimalisatie problemen.

Volgens mij zijn ze allebei NPC, en dus reduceerbaar tot elkaar.

[voodooless]

Grijze Vos schreef op dinsdag 02 oktober 2007 @ 15:37:
Volgens mij zijn ze allebei NPC, en dus reduceerbaar tot elkaar.

http://en.wikipedia.org/wiki/Travelling_salesman_problem

[Janoz]

TSP is niet NPC. Een eis van NPC is dat van een gegeven oplossing in polinomiale tijd te zeggen is of deze valide is of niet. Je kunt van een oplossing niet binnen polinomiale tijd zeggen dat hij de kortste is.

Een variant van TSP waarbij de vraag niet 'vind de korste route', maar 'vind een route korter dan X' is, is wel NPC. Dan kun je wel snel kijken of een gegeven oplossing voldoet aan het criterium. Hetzelfde geldt ook voor het Knapsack probleem. Ook hiervan kun je met een aanpassing van het criterium er een NPC probleem van maken en in dat geval zijn ze inderdaad tot elkaar te reduceren.

[? ?]

Verwijderd schreef op dinsdag 02 oktober 2007 @ 10:24:
* Java -> nog nooit een letter code van gezien
* C# -> ben ik vorig jaar mee begonnen, maar snel weer mee gestopt
* C / C++ -> heel lang geleden heb ik wel eens C-programma's (in dos-venster) geschreven
* VB -> het is me nooit helemaal duidelijk geweest
* Delphi -> nooit in verdiept.

Oke call me crazy, maar hoe ga jij ooit een programma schrijven dat de optimale stakkering moet geven van dozen in een vrachtwagen.

Een 3D-view is toch op z'n minst nodig als output en dat is allemaal niet zo in 123 te schrijven. Toch wel andere koek dat wat Excel VBA code.
Als een 3D-view niet noodzakelijk is, dan is de oplossing zo simpel dat je die dozen ook gewoon zonder programma in een container/vrachtwagen propt.

Er is voor zulke kleine toepassingen niet 1 magische programmeertaal.
Kun je .NET, go for it, PHP is imho een webtaal voor websites en rich websites. Overuse van PHP vind ik persoonlijk niet echt 'correct'. Er zijn mensen die alles in PHP doen omdat het simpel 'lijkt' en je vlug resultaat hebt.

[ Voor 15% gewijzigd door ? ? op 02-10-2007 17:10 ]

[? ?]

Yoozer schreef op dinsdag 02 oktober 2007 @ 14:52:
[...]
met macro's (en daarom niet schrikken van VB of VB.NET), maar Java is niet zo'n hobbytaal die bij Office zit.

en .NET wel? geez. Maak geen opmerkingen over dingen waar je niets van af weet, dank.

[MrBucket]

Verwijderd schreef op dinsdag 02 oktober 2007 @ 11:20:
Wij denken andersom. Ik denk: Als het niet webbased hoeft, doe het dan niet. Jij denkt: Als het webbased kan, doe het dan.
(...)
Daarom de vraag of je even wilt toelichten waarom je als het mogelijk is webbased zou verkiezen boven standalone (zoals ik je begrijp). Zelf denk ik namelijk andersom.

In het algemeen zou ik ook eerder voor webbased kiezen, vanwege de eenvoudige onderhoudbaarheid. Berekeningetje aanpassen doe je op een centrale plaats en iedereen kan er mee werken. Dat redt je bij lange na niet met een windows client. Click-once is ook zo makkelijk nog niet om in te duiken.

Maar er zijn voor zowel webbased als stand-alone voor- en nadelen te noemen. Het ligt een beetje aan de karakteristieken van je applicatie.
- Veel gebruikers of weinig? Bij weinig gebruikers (tot 5 man) kun je nog handmatig een nieuwe client uitrollen; bij meer zul je ofwel een gestructureerde manier moeten vinden (clickonce, client op een fileshare zetten), of een web-oplossing gebruiken.
- Rijke GUI nodig, of niet? Als je een interactieve UI wil, is dit (over het algemeen) makkelijker te realiseren in een windows client. Scheelt weer een hoop geemmer met javascript, browser-compatibility en/of Ajax(!).
- Moet de applicatie gebruik gaan maken van een database, en moet de applicatie buiten het bedrijfsnetwerk te benaderen zijn? Als beide antwoorden ja zijn, dan moet je heel goed weten waar je mee bezig bent...
- Zijn het zware berekeningen die uitgevoerd moeten worden? Die kun je beter niet van 20 man tegelijk op een server laten draaien, liefst lokaal in een windows client.

Enz.

[Verwijderd]

Waar je ook enigszins naar kan kijken is de leercurve van de te gebruiken taal icm krachtigheid ervan. Als je hiermee een goede afweging maakt komt je toch altijd op Delphi uit

Nee maar ff serieus, weet niet precies je functie binnen het bedrijf maar als het maken v/d applicaties/tools een "bijkomstigheid" is dien je (en zeker het bedrijf) wel te letten op continuiteit van het geheel. Ooit zal jij daar weggaan (om wat voor reden dan ook, al is het pensioen). Als niet iedereen binnen het bedrijf zo bedreven is met programmeren/scripten etc. is het niet zo handig als je opvolger eerst een jaar op cursus moet, vervolgens weer een jaar door jouw code heen moet ploegen om te kijken waar ie moet wezen voor iets aan te passen.

Gezien de populariteit van de verschillende .Net (C#, VB.Net) talen en het aantal bedrijven wat eventueel daarin ondersteuning kan geven (ja, Java en alle andere ook) zou ik daar mijn keuze op laten vallen in jouw geval.
Zo kan je zelf "sleutelen" en indien nodig (professionele) hulp erbij inroepen.

Een Web FrontEnd kan je bijna altijd wel inpassen, welke oplossing/taal je ook kiest.

[Yoozer]

era.zer schreef op dinsdag 02 oktober 2007 @ 18:22:
en .NET wel? geez. Maak geen opmerkingen over dingen waar je niets van af weet, dank.

Zo, verkeerde been uit bed? Ik had het over VBA, maar als je beter had gelezen had je dat ook gezien, dank. Als je al weet wat een Sub is in VBA is VB.NET over het algemeen minder intimiderend en beter te begrijpen dan een curly braces-taal die zwaar de OO in gaat.

edit: en 3d nodig voor stapelen, juist ja . Wat dacht je van 4 of 5 2d-tekeningen afhankelijk van hoeveel lagen dozen je hebt? Is ook nog eens makkelijker te begrijpen ook.

[ Voor 34% gewijzigd door Yoozer op 02-10-2007 22:28 . Reden: tsk ]

[Koppensneller]

Yoozer schreef op dinsdag 02 oktober 2007 @ 22:15:
[...]
edit: en 3d nodig voor stapelen, juist ja . Wat dacht je van 4 of 5 2d-tekeningen afhankelijk van hoeveel lagen dozen je hebt? Is ook nog eens makkelijker te begrijpen ook.

En als je nou eens dozen van verschillende hoogte hebt? Dus geen duidelijke, gescheiden lagen... Dan kom je toch op een 3D view uit.

[Verwijderd]

Ik weet niet hoe zwaar die berekeningen precies zijn...

Excel berekent het realtime op een willekeurige Celeron.

Je weet dat dit een NP-Hard probleem is en dat een algoritme hiervoor verzinnen niet zo simpel is?

eigenlijk offtopic, maar ik zal even een tipje van de sluier oplichten dat de dozen 1 of 2 breed inde container gezet kunnen worden en altijd 3 hoog staan. Dan blijft alleen de lengte opvullen nog over en zorgen dat er geen langer/breder pakket boven een klein pakket staat. Maar als je inderdaad echt willekeurige pakketten hebt, dan wordt het een stuk lastiger.

Het klinkt als behoorlijk belangrijke software - is het niet een idee om een professioneel team van programmeurs in te huren?

Het is een overweging geweest om een programmeur aan te nemen. Een groot nadeel is dat de productie dusdanig ingewikkeld in elkaar zit dat ik enkele maanden nodig gehad heb om er een 'formule' voor te bedenken die werkt op alle producten. Tweede probleem is dat die formule een benadering is die continue bijgewerkt wordt, al dan niet door het aanpassen van de productielijn of het herberekenen van de werkelijke productietijden en dat weer in de kostprijsberekening terug zetten. Dat is eigenlijk een deel van mijn werk wat ik dan uit handen zou geven aan iemand die er niets van snapt, maar wel kan programmeren. Vandaar de gedachtengang om zelf een cursus te gaan volgen.

Ik zou toch echt gaan voor Excel.
Het klinkt misschien gek om een rekensheet als container te gebruiken maar in praktijk blijkt het toch heel praktisch...

Kan je me een hint geven (zonder VBA) hoe ik het aan kan pakken. Dankzij een 'gestructureerde' collega heb ik gelukkig al een kant en klare database in excel met de artikelnummers, afmetingen en gewichten van alle artikelen.

Heb je al eens aan FileMaker gedacht (of ken je het überhaupt)?
het is een database- en presentatielaag in 1
je hoeft er niet echt voor te kunnen programmeren
er is niet per sé een server nodig maar het kan wel
ingebouwde rekenfuncties
je kunt er zo mee aan de slag

Ik kende het niet en heb even gekeken. Ik denk echter niet dat dit een oplossing is, aangezien ik eigenlijk geen database nodig heb (het is een uitgebreide formule) en met 'ingebouwde rekenfuncties' zie ik het niet veel meer doen dan Excel.

Beetje vreemd omdat hij daar geen enkele valide reden voor geeft.

Zoals al eerder opgemerkt ben ik van mening dat een applicaties niet webbased moet zijn, als het niet hoeft. Blijkbaar denken sommige mensen andersom: als het webbased kan, doe het dan.

Je wilt dus iets invullen en dan zonder gezeur gelijk het antwoord zien?

Ja, maar dat is nu het geval. De gebruikers vullen de productspecificaties in (een tiental parameters) en het antwoord (kostprijs, winst, noem maar op) komt er direct uitrollen. Wat ik bedoel met wijzigingen doorvoeren is dat ik de berekeningen aanpas en met dynamischer bedoel ik in plaats van een beperkte lijst met 'IF' in Excel gewoon een geavanceerdere 'FOR' kan gebruiken. Nu moet ik de lijst met 'IF'-jes steeds aanpassen als er iets in de materialen verandert.

Als je 'm standalone wil maken kun je met .NET of Java heel snel iets leuks maken, maar het wordt dan wel een soort "business"-calculator: plug er een paar getallen in, en klaar. Je bent dan dus van de gebruiker zelf afhankelijk of 'ie wel de juiste getallen uit de prijslijsten haalt.

Je zegt het op een manier dat ik aan mezelf begin te twijfelen of ik wel duidelijk genoeg was. Je slaat namelijk de spijker op de kop. (Alleen worden er geen 'getallen uit de prijslijst gehaald', maar is het een berekening voor de prijslijst) De gebruiker voert de producteigenschappen in. Het programma berekent wat de grondstoffen kosten en hoeveel productietijd (= productiekosten) en komt tot een conclusie.

Updates is heel makkelijk; op het moment dat je je idee aan management kunt verkopen zorg je er gewoon voor dat als jij een mail doorstuurt van "jongens, nieuwe versie" dat mensen die ook downloaden.

Waarom zoveel gedoe over die GUI? Nou, dat is wat het verkoopt aan je collega's. Zorg er voor dat het snel werkt, dat de cursor met 1 keer op tab hengsten naar het juiste volgende veld gaat, en je krijgt fans. Taal maakt dan niet meer zoveel uit, als het maar snel is, en als jij er maar mee kan werken.

Jij snapt het.

Ik zou zelf bij Excel blijven, maar daar een interface bij maken. Dat kan in VBA van Excel zelf, maar dat kan ook in een willekeurige andere taal waarin je excel als object kan aanspreken. Als je je sheets behoorlijk indeelt, dan hoeft dat helemaal geen warboel te worden.

De interface doet het en werkt makkelijk. Alleen heb ik 6 sheets met naar schatting zo'n 100 - 200 cellen met berekeningen (van soms wel 4 regels op een 1280x1024 scherm). Als ik zoiets zie met variabelen als IF(!Blad1:D12>1200;"Te groot";IF(!Blad1:D12>1120;(!Blad1:C45/!Blad3:G19)^Blad6:S2;(!Blad1:C45/!Blad3:G19)^Blad6:S3 etc. etc. etc. dan ben ik gewoon het overzicht kwijt. Bovendien heeft Excel te beperkte mogelijkheden met if / for / while en is het dus geen oplossing.

- Veel gebruikers of weinig

Weinig. Momenteel 6 - 7, in de toekomst zeker niet meer dan 10.

- Rijke GUI nodig, of niet? Als je een interactieve UI wil, is dit (over het algemeen) makkelijker te realiseren in een windows client. Scheelt weer een hoop geemmer met javascript, browser-compatibility en/of Ajax(!).

Gewoon duidelijk en zakelijk, maar het is bij nader inzien wel wenselijk dat (net als in Excel) waardes direct herberekend worden zonder elke keer op een knop te moeten klikken.

- Moet de applicatie gebruik gaan maken van een database, en moet de applicatie buiten het bedrijfsnetwerk te benaderen zijn? Als beide antwoorden ja zijn, dan moet je heel goed weten waar je mee bezig bent...

Op beide antwoorden een volmondig NEE. Er is geen informatie voor in een database, op enkele variabelen die regelmatig veranderen na. De applicatie hoeft sowieso niet eens via het netwerk te benaderen te zijn.

- Zijn het zware berekeningen die uitgevoerd moeten worden? Die kun je beter niet van 20 man tegelijk op een server laten draaien, liefst lokaal in een windows client.

Een willekeurge 686 zou de berekeningen van 20 man aankunnen.

Als niet iedereen binnen het bedrijf zo bedreven is met programmeren/scripten etc. is het niet zo handig als je opvolger eerst een jaar op cursus moet, vervolgens weer een jaar door jouw code heen moet ploegen om te kijken waar ie moet wezen voor iets aan te passen.

Het is wel iets om bij stil te staan, maar niet te lang. Er is momenteel niemand die voldoende Excel niveau heeft om een sheet te maken zoals ik gedaan heb. Bovendien is de materie van een niveau dat een professionele programmeur ook minimaal een paar maanden bezig is om door te krijgen waar het over gaat. Uiteindelijk kan je dan tot de conclusie komen dat ze (nu al) niet meer van me af kunnen zonder grote problemen.

Tot zover bedankt voor het bijstaan. Ik sta versteld van het aantal reacties!!! Morgen een vergadering en dan heb ik in ieder geval wat overwegingen om mee op de proppen te komen.

[.oisyn]

KoppenSneller schreef op dinsdag 02 oktober 2007 @ 23:03:
[...]


En als je nou eens dozen van verschillende hoogte hebt? Dus geen duidelijke, gescheiden lagen... Dan kom je toch op een 3D view uit.

Dozen van verschillende hoogten stapelt sowieso erg lastig. Dat een doos ergens past wil natuurlijk niet zeggen dat ie daar ook stabiel ligt. Dus tenzij je de overige lege ruimte op kunt vullen, lijkt het probleem me een stuk moeilijker dan slechts het knapsack probleem zo goed mogelijk oplossen.

.edit: ah de post van tygetjuh komt er net tussendoor, het is dus niet echt een probleem

Ik zou het trouwens in assembly doen, met een eigen OS eromheen

[ Voor 41% gewijzigd door .oisyn op 02-10-2007 23:15 ]

[Verwijderd]

Verwijderd schreef op dinsdag 02 oktober 2007 @ 23:10:
[...]
Het is een overweging geweest om een programmeur aan te nemen. Een groot nadeel is dat de productie dusdanig ingewikkeld in elkaar zit dat ik enkele maanden nodig gehad heb om er een 'formule' voor te bedenken die werkt op alle producten. Tweede probleem is dat die formule een benadering is die continue bijgewerkt wordt, al dan niet door het aanpassen van de productielijn of het herberekenen van de werkelijke productietijden en dat weer in de kostprijsberekening terug zetten. Dat is eigenlijk een deel van mijn werk wat ik dan uit handen zou geven aan iemand die er niets van snapt, maar wel kan programmeren. Vandaar de gedachtengang om zelf een cursus te gaan volgen.
[...]

Optie is wel, om door een "professional" (inhuur/freelance/bedrijf), de grote opzet te laten maken in een "ontwikkel taal", maar die dingen die jullie constant bijschaven dmv parameters, invoer etc kunnen bijschaven. Maybe de formules nog variabel maken door het geheel enigszins te mixen met een "scripting" component binnen de applicatie. Voordeel is dat je dan met scripting (VBS etc.) wel makkelijk gebruik kan maken van alle gedefinieerde objecten, formules, methoden binnen de al geprogrammeerde applicatie, maar toch enigszins van standaard gedrag kan afwijken.

(denk aan hele bibliotheek met diverse oplossingen etc., combi's van parameters/variabelen en specifieke formules)

Zo wordt het bulk werk gedaan door een bedrijf met kennis van ontwerpen/ontwikkelen van applicatie's en jullie behouden toch enige flexibiliteit in de applicatie zonder voor ieder wisse wasje weer iemand in te moeten huren.

.. zomaar ff ideetje....

.oisyn schreef op dinsdag 02 oktober 2007 @ 23:11:
Ik zou het trouwens in assembly doen, met een eigen OS eromheen

tsja, dan kan je beter je eigen customized CPU ontwikkelen

[ Voor 6% gewijzigd door Verwijderd op 02-10-2007 23:22 ]

[JochemK]

Filemaker om NP-Hard problemen op te lossen, ik zou zeggen SUCCES!

Wat betreft het inladen van de vrachtwagen (algoritmisch gezien) je kunt dit al snel reduceren tot een eenvoudiger probleem, omdat een hoop van de parameters al vastliggen, en de afmetingen waarschijnlijk zo klein zijn, datje zelfs met een brute force, of simpel backtracking algoritme al een heel eind komt.

Als je gaat voor een vrachtwagen met willekeurige afmetingen, waarin een willekeurig aantal pakjes met willekeurige afmetingen moet, dan krijg je een grotere uitdaging, kijk maar naar het aantal keer dat ik willekeurige heb moeten typen voor de omschrijving

Wat programmeertaal betreft, ik zou ook gaan voor een windows applicatie, zoals misschien wel blijkt uit m'n verhaaltje hierboven kon het nog wel eens een stevige rekenpartij worden, en als een aantal gebruikers dit tegelijk op de server gaan draaien, wordt je niet blij. (Bovendien gaan ze dan klagen, dat de server traag is enzo, terwijl als je ze op hun eigen bak een schermpje geeft waar vooral veel meuk op beweegt, dan zijn ze tevreden, want dan is de bak tenminste niet vastgelopen)

[OxiMoron]

Voor php heb je geen webserver nodig, je kunt het ook gewoon in je console runnen..

[Yoozer]

Verwijderd schreef op dinsdag 02 oktober 2007 @ 23:20:
Optie is wel, om door een "professional" (inhuur/freelance/bedrijf), de grote opzet te laten maken in een "ontwikkel taal", maar die dingen die jullie constant bijschaven dmv parameters, invoer etc kunnen bijschaven. Maybe de formules nog variabel maken door het geheel enigszins te mixen met een "scripting" component binnen de applicatie. Voordeel is dat je dan met scripting (VBS etc.) wel makkelijk gebruik kan maken van alle gedefinieerde objecten, formules, methoden binnen de al geprogrammeerde applicatie, maar toch enigszins van standaard gedrag kan afwijken.

Elke taal, mits uitgebreid genoeg, gaat uiteindelijk lijken op een slechte kopie van LISP (of wat was het ook al weer?). Als je dat wil hebben hoef je geen bedrijf in te huren omdat MS het al voor je gedaan heeft in de vorm van -juist ja- macro's. Kortom, maak het te simpel en het is misschien niet voldoende, maak het ingewikkeld en dan had je sowieso al beter gelijk kunnen beginnen in een echte programmeertaal.

Verwijderd schreef op dinsdag 02 oktober 2007 @ 23:10:
Je zegt het op een manier dat ik aan mezelf begin te twijfelen of ik wel duidelijk genoeg was. Je slaat namelijk de spijker op de kop. (Alleen worden er geen 'getallen uit de prijslijst gehaald', maar is het een berekening voor de prijslijst) De gebruiker voert de producteigenschappen in. Het programma berekent wat de grondstoffen kosten en hoeveel productietijd (= productiekosten) en komt tot een conclusie.

Nee, je was duidelijk genoeg, alleen denk ik dat mensen afgeleid zijn door de "welke programmeertaal?"-vraag.

Op het moment dat je een "business-calculator" hebt heb je met databases of uitlezen van files even niks meer te maken. Dat maakt de ontwikkeling stukken makkelijker, en dan is de voorwaarde alleen maar dat 't snel werkt en niet in de weg zit. Ik zou mijn inspanningen dan eerst gaan richten op het maken van prototypes en het maken van flowcharts (of die heb je nog omdat daar je Excel-formules op gebaseerd zijn). Met de formule in Excel zelf kun je niet echt iets als je overstapt.

Je hebt ook al prototypes van de applicatie gemaakt? Gewoon schetsen over hoe jij denkt hoe het programma eruit moet zien, met de knoppen, dropdowns en textboxes? Je kunt je prototype eventueel al bouwen in gewone HTML (qua look en feel dan); maar niet te uitgebreid, anders denkt men dat dat je applicatie is.

Je wilt weten waar je op moet controleren (welke user input is nodig, wat accepteer je), of alles logisch gegroepeerd is (hoort eigenschap Y bij groep X). Je kunt dan ook scheiden in functionaliteit: afhankelijk van hoeveel types berekeningen je moet doen kun je de schermen onderverdelen in tabbladen of een lijst. De dozenberekening hoort niet thuis bij de kostprijsberekening, maar de laatste kan bijvoorbeeld wel 2 types hebben voor binnen- of buitenland (ik noem maar een voorbeeld).

Bovendien is de materie van een niveau dat een professionele programmeur ook minimaal een paar maanden bezig is om door te krijgen waar het over gaat. Uiteindelijk kan je dan tot de conclusie komen dat ze (nu al) niet meer van me af kunnen zonder grote problemen.

Dat geeft jou als ontwikkelaar nog een taak erbij: maak genoeg en duidelijk genoege documentatie (of dit doe je al, kan natuurlijk ook ).

KoppenSneller schreef op dinsdag 02 oktober 2007 @ 23:03:
En als je nou eens dozen van verschillende hoogte hebt? Dus geen duidelijke, gescheiden lagen... Dan kom je toch op een 3D view uit.

Het gaat er meer om dat een 2D of 3D view helemaal niks te maken moet hebben met de berekeningen of de keuze van de programmeertaal. Een raytracer hoeft ook niet perse pixels op het scherm weer te geven om uit te vinden waar de lichtbron op een bol of vierkant past. Het uitvinden wat je moet berekenen is de eerste horde, niet "oh shit, nu moet ik 3D-zooi gaan leren".

[ Voor 8% gewijzigd door Yoozer op 03-10-2007 09:01 ]

[Verwijderd]

OxiMoron schreef op woensdag 03 oktober 2007 @ 08:43:
Voor php heb je geen webserver nodig, je kunt het ook gewoon in je console runnen..

Maar het moet wel nog steeds geinstalleerd staan op elke client...

offtopic: leuk dat iedereen zo nieuwschierig is naar de container. Zo heel erg lastig is het niet. De gebruiker heeft al bepaald of er in een 20' of een 40' wordt geleverd (die dus standaardafmetingen hebben). Vervolgens wordt de pakketbreedte uitgelezen uit de database (770/920/1020/1070/1220 mm breed) en de lengte (willekeurig). De hoogte is altijd standaard, wat het al tot een 2 dimensionaal probleem maakt. Niet al te pittig, maar toch al gauw te veel voor Excel.

[Verwijderd]

Yoozer schreef op woensdag 03 oktober 2007 @ 08:59:
[...]
Elke taal, mits uitgebreid genoeg, gaat uiteindelijk lijken op een slechte kopie van LISP (of wat was het ook al weer?). Als je dat wil hebben hoef je geen bedrijf in te huren omdat MS het al voor je gedaan heeft in de vorm van -juist ja- macro's. Kortom, maak het te simpel en het is misschien niet voldoende, maak het ingewikkeld en dan had je sowieso al beter gelijk kunnen beginnen in een echte programmeertaal.
[...]

Geloof niet dat je helemaal begrijpt waar ik op doel.
Is nogal een verschil of je Excel gaat inzetten met gebruik van VBA in Excel, of je je eigen applicatie met een vast objectmodel en bijbehorende methoden/formules redelijk (mogelijk) beinvloedbaar maakt op een vooraf gedefinieerde manier.

[Yoozer]

Verwijderd schreef op woensdag 03 oktober 2007 @ 09:25:
Geloof niet dat je helemaal begrijpt waar ik op doel.
Is nogal een verschil of je Excel gaat inzetten met gebruik van VBA in Excel, of je je eigen applicatie met een vast objectmodel en bijbehorende methoden/formules redelijk (mogelijk) beinvloedbaar maakt op een vooraf gedefinieerde manier.

Na nog eens te lezen komt 't er dus op neer dat je ze een soort library of DLL laat maken die een hoop van wat "lelijk" zou zijn door zelf code te bakken verwerkt in een reeks geschikte methods?

[Janoz]

Verwijderd schreef op woensdag 03 oktober 2007 @ 09:19:
offtopic: leuk dat iedereen zo nieuwschierig is naar de container. Zo heel erg lastig is het niet. De gebruiker heeft al bepaald of er in een 20' of een 40' wordt geleverd (die dus standaardafmetingen hebben). Vervolgens wordt de pakketbreedte uitgelezen uit de database (770/920/1020/1070/1220 mm breed) en de lengte (willekeurig). De hoogte is altijd standaard, wat het al tot een 2 dimensionaal probleem maakt. Niet al te pittig, maar toch al gauw te veel voor Excel.

Dat een probleem makkelijk te omschrijven is betekent niet dat het ook makkelijk op te lossen is. Zelfs in 1D is dit al een lastig probleem. Na nog even wat nalezen is je omschrijving duidelijk een 2d variant van het bin packing problem (waarbij elke laag een bin voorstelt). Zeker de variabele lengte maakt het erg lastig.

[Verwijderd]

Yoozer schreef op woensdag 03 oktober 2007 @ 09:57:
[...]
Na nog eens te lezen komt 't er dus op neer dat je ze een soort library of DLL laat maken die een hoop van wat "lelijk" zou zijn door zelf code te bakken verwerkt in een reeks geschikte methods?

Nee.
(kom er nog op terug, ff druk nu)

[roy-t]

* C# -> ben ik vorig jaar mee begonnen, maar snel weer mee gestopt. Vanwege gebrekkige tutorials en het niet aan de praat krijgen van allerlei zaken kwam het niet erg van de grond.

Huh? *ongeloof* ik heb nog nooit voor een taal zoveel goede tutorials gezien, van videotutorials tot codesnippets, en dan ook altijd nog de MSDN er gratis bij kunnen pakken

Ik zou zelf (omdat ik nu al een jaar met C# werk) met C# te werk gaan, maar eerlijk gezegt schelen C# en Java niet al te veel van elkaar qua taal, wat mij echt naar C# trok was de veel betere intellisense en veel makkelijkere opzet van forms in Visual Studio, in vergelijking met het (zonder plugins) "mindere" Eclipse (ik ben er inmiddels achter dat met de nodige plugins Eclips een stuk dichter bij VS komt)

Zelf zou ik omdat het excel is toch bij C# gaan kijken, er zijn waarschijnlijk meer tutorials / handige koppelingen bij een MS taal dan bij een OS taal

PHP komt uberhaupt niet in aanmerking omdat de client pc's prima zelf even kunnen rekenen. Maar dat had je zelf al geconstateerd.

Ook is VBScript lang zo slecht nog niet maar dit heeft voor jou al afgedaan.

Achja het wordt iig weer een smaak kwestie doe een taal waarvan jij denkt "dit is logisch" en waarvan de ontwikkelomgeving die vibe ook weer geeft. (en nogmaals dat was voor mij een reden om C# ipv Java te kiezen, maar voor een ander zal dat misschien weer door de vele plugins voor Eclipse/Netbeans juist andersom zijn. Ik zelf had liever een Editor die meteen de basis functionaliteiten al goed voor elkaar had)

Succes met je keuze!

[? ?]

Yoozer schreef op dinsdag 02 oktober 2007 @ 22:15:
[...]

Zo, verkeerde been uit bed? Ik had het over VBA, maar als je beter had gelezen had je dat ook gezien, dank. Als je al weet wat een Sub is in VBA is VB.NET over het algemeen minder intimiderend en beter te begrijpen dan een curly braces-taal die zwaar de OO in gaat.

Ik herhaal wat ik zei: verspreid geen bull*. 'Zwaar in de OO' gaat? Waar haal je 't toch. .NET is even OO als java. En voor de duidelijkheid: ik kan nog perfect procedureel programmeren in een java applicatie. Maar de opbouw is even OO als java. En voor zover ik weet wordt je form ook opgebouwd met een inherit ve class en een initialize() etc in .NET -net zoals in java- en alles erop en eraan. 't is niet omdat je in een standaard project het niet default getoond wordt dat het er niet is hoor.

edit: en 3d nodig voor stapelen, juist ja . Wat dacht je van 4 of 5 2d-tekeningen afhankelijk van hoeveel lagen dozen je hebt? Is ook nog eens makkelijker te begrijpen ook.

5 plannen om dozen te stapelen laat me niet lachen. Het schiet zo al niet op met 1 plan met 10 stapjes om een IKEA kast in elkaar te zetten. Dat gaat kostbesparend zijn, ff 2 uur een plan lezen voor elke verzending! Ik zou zeggen doe het in COBOL !

^{o ja: sarcasme enzo..}

Als je hier moet komen vragen hoe je 't moet doen, dan ben je eigenlijk niet geschikt voor het werk. Laat dat een algemene leiddraad zijn voor dit soort topics misschien. zucht.

[ Voor 7% gewijzigd door ? ? op 03-10-2007 15:28 ]

[? ?]

Dat is eigenlijk een deel van mijn werk wat ik dan uit handen zou geven aan iemand die er niets van snapt

Anderen die gespecialiseerd zijn kunnen dingen beter dan jij, daarom haal je er een consultant en programmeur bij.

Trouwens, ik programmeer dagelijks dingen waar ik niets van af weet, zolang de contactpersoon mij vertelt wat de eisen zijn, hoe ze 't willen en er een goede analyse is (die gemaakt wordt ism jou bv) weet de programmeur wat hij moet doen. Dat is de taak van een programmeur: programmeren.

[Grijze Vos]

Janoz schreef op dinsdag 02 oktober 2007 @ 16:32:
TSP is niet NPC. Een eis van NPC is dat van een gegeven oplossing in polinomiale tijd te zeggen is of deze valide is of niet. Je kunt van een oplossing niet binnen polinomiale tijd zeggen dat hij de kortste is.

Een variant van TSP waarbij de vraag niet 'vind de korste route', maar 'vind een route korter dan X' is, is wel NPC. Dan kun je wel snel kijken of een gegeven oplossing voldoet aan het criterium. Hetzelfde geldt ook voor het Knapsack probleem. Ook hiervan kun je met een aanpassing van het criterium er een NPC probleem van maken en in dat geval zijn ze inderdaad tot elkaar te reduceren.

Ah, inderdaad, je hebt gelijk. Je moet het omvormen tot het beslissingsprobleem wat je beschreven hebt.

[Yoozer]

era.zer schreef op woensdag 03 oktober 2007 @ 15:25:
Ik herhaal wat ik zei: verspreid geen bull*. 'Zwaar in de OO' gaat? Waar haal je 't toch. .NET is even OO als java.

Je leest het nog steeds niet, he? Te druk bezig met "Waa! mama! ze beledigen Microsoft!"

Ik heb het laatste anderhalf jaar vrolijk in VB.NET (voor ASP.NET) gespendeerd en ik weet verdomde goed waar ik over praat. Mijn collega kwam van een VB Classic achtergrond. Die kun je geen C# of Java voorschotelen. VB.NET echter wel, want het lijkt er veel meer op. Ook al is .NET op een hele hoop punten gewoon niet meer compatibel, het feit dat de taal er al niet radicaal anders uit ziet doet al een hoop goed, en Iemand die VBA gewend is moet ook VB.NET pakken, geen Java of C#. VBA is het hobbytaaltje wat je er bij krijgt; ik heb nergens gezegd dat VB.NET dat is.

[benoni]

Stukje terug:

RubenDJ schreef op dinsdag 02 oktober 2007 @ 12:11:
Heb je al eens aan FileMaker gedacht (of ken je het überhaupt)?
• het is een database- en presentatielaag in 1
• je hoeft er niet echt voor te kunnen programmeren
• er is niet per sé een server nodig maar het kan wel
• ingebouwde rekenfuncties
• je kunt er zo mee aan de slag

Op zich is een hybride van spreadsheet en database een aardig idee voor als je snel van ontwerp naar een enigszins werkende (deel)oplossing wilt. Alleen wordt de Filemaker oplossing een ramp als je serieus moet gaan programmeren en de boel wilt opschalen naar meerdere werkgroepen en -plekken.

Het is dan slimmer om met zoiets als Servoy aan de slag te gaan. Dat een fatsoenlijke backend database toch het beste uitgangspunt is heb je uit de rest van de reacties wel kunnen afleiden, maar je zou wel met scriptable front ends kunnen werken zodat je (een deel van) je applicaties clientside kunt draaien.

edit:

Ik had niet voldoende gelezen en zie nu dat je niet eens een database nodig hebt...

[ Voor 4% gewijzigd door benoni op 03-10-2007 20:44 ]

[MrBucket]

Verwijderd schreef op dinsdag 02 oktober 2007 @ 23:10:
Aantal gebruikers
Weinig. Momenteel 6 - 7, in de toekomst zeker niet meer dan 10.
Rijke GUI nodig, of niet?
Gewoon duidelijk en zakelijk, maar het is bij nader inzien wel wenselijk dat (net als in Excel) waardes direct herberekend worden zonder elke keer op een knop te moeten klikken.
Database nodig / applicatie buiten het bedrijfsnetwerk benaderen?
Op beide antwoorden een volmondig NEE. Er is geen informatie voor in een database, op enkele variabelen die regelmatig veranderen na. De applicatie hoeft sowieso niet eens via het netwerk te benaderen te zijn.
Zwaarte van de berekeningen?
Een willekeurge 686 zou de berekeningen van 20 man aankunnen.

Nou, dan ben je volgens mij vrij om elk platform te kiezen dat je maar wil.

Ik zou persoonlijk geen 'verouderde' technieken kiezen als C / C++ (i.v.m. leercurve en moeilijkheid om een GUI te maken), VB (let op: VB.NET is wat anders) of ASP (wederom: anders dan ASP.NET).

[Verwijderd]

Janoz schreef op dinsdag 02 oktober 2007 @ 16:32:
TSP is niet NPC.

Heb je hier een bewijs voor?

[Voutloos]

offtopic:
notabene direct boven de post die je quote staat het antwoord gang-ster.

[? ?]

Beste topicstarter, maak je project en kom hier binnen een paar maand graag nog eens posten hoe je 't allemaal aangepakt hebt en hoe het is uitgedraaid.

[ Voor 76% gewijzigd door ? ? op 04-10-2007 00:14 ]

[Verwijderd]

Voutloos schreef op woensdag 03 oktober 2007 @ 21:46:

offtopic:
notabene direct boven de post die je quote staat het antwoord gang-ster.

En wat is het antwoord dan wel? Ik weet in ieder geval dat wat Janoz zegt totale onzin is, maar blijkbaar is het zo overduidelijk dat jullie het allebei niet begrijpen.

[Voutloos]

quote: http://en.wikipedia.org/w...esman_problem#NP-hardness

The problem has been shown to be NP-hard (more precisely, it is complete for the complexity class FPNP; see the function problem article), and the decision problem version ("given the costs and a number x, decide whether there is a roundtrip route cheaper than x") is NP-complete.

Als je het daar niet mee eens bent, kan je ook meer zeggen dan 'ik weet dat het onzin is'. Weerleg het maar, geef maar aan met welke definitie zoals die op wikipedia staat je het niet eens bent, of wijzig gewoon een handjevol wiki pagina's.

[Verwijderd]

Voutloos schreef op donderdag 04 oktober 2007 @ 08:05:
[...]
Als je het daar niet mee eens bent, kan je ook meer zeggen dan 'ik weet dat het onzin is'. Weerleg het maar, geef maar aan met welke definitie zoals die op wikipedia staat je het niet eens bent, of wijzig gewoon een handjevol wiki pagina's.

Het punt is dat Janoz iets claimde; de bewijslast ligt bij Janoz. Het al dan niet eens zijn met die pagina heeft _niets_ te maken met dat ik zeg dat Janoz iets zegt dat hij niet kan bewijzen.

Als Janoz reageert, zal ik dit waarschijnlijk ook doen. In de tussentijd mag je zelf bedenken wat nodig is voor Janoz om dit te bewijzen.

[Janoz]

Verwijderd schreef op donderdag 04 oktober 2007 @ 02:11:
[...]

En wat is het antwoord dan wel? Ik weet in ieder geval dat wat Janoz zegt totale onzin is, maar blijkbaar is het zo overduidelijk dat jullie het allebei niet begrijpen.

Dan weet je dat verkeerd en raad ik je aan de volgende keer bij algoritmiek ietsje beter op te letten. In de rest van mijn post staat het namelijk keurig uitgelegd, maar ik zal hieronder nogmaals een poging wagen dit uit te leggen:

Een non deterministisch polynomiaal compleet probleem is een probleem waarbij de juistheid van een gegeven antwoord binnen polynomiale tijd kan worden gecontroleerd, maar het vinden van dit antwoord niet in polynomiale tijd kan.

Zodra ik je een route langs alle steden geef kun jij niet in polynomiale tijd zeggen dat dat de korste is en daarom is TSP niet NPC, maar NP-Hard. Veranderen we de vraagstelling van TPC en zoeken we niet naar de korste route, maar naar een route die korter is dan een gegeven afstand, dan kun jij wel binnen polynomiale tijd controleren of een gegeven antwoord klopt. Je moet dan immers gewoon kijken of alle steden aangedaan worden en kijken of de som van de edges niet groter is dan die maximale afstand. Deze variant is dus wel NPC.

[Verwijderd]

Janoz schreef op donderdag 04 oktober 2007 @ 08:58:
[...]

Dan weet je dat verkeerd en raad ik je aan de volgende keer bij algoritmiek ietsje beter op te letten.

HAHAHAHA, jij bent grappig.

In de rest van mijn post staat het namelijk keurig uitgelegd, maar ik zal hieronder nogmaals een poging wagen dit uit te leggen:

Een non deterministisch polynomiaal compleet probleem is een probleem waarbij de juistheid van een gegeven antwoord binnen polynomiale tijd kan worden gecontroleerd, maar het vinden van dit antwoord niet in polynomiale tijd kan.

Wow, jij bent grappig(en je hebt geen idee waar je over spreekt).

Zodra ik je een route langs alle steden geef kun jij niet in polynomiale tijd zeggen dat dat de korste is en daarom is TSP niet NPC, maar NP-Hard.

Wow, verkeerde toepassing logica. Ik vroeg om een bewijs van jou dat ik niet zo'n bewijs ooit zou kunnen maken.

Veranderen we de vraagstelling van TPC en zoeken we niet naar de korste route, maar naar een route die korter is dan een gegeven afstand, dan kun jij wel binnen polynomiale tijd controleren of een gegeven antwoord klopt. Je moet dan immers gewoon kijken of alle steden aangedaan worden en kijken of de som van de edges niet groter is dan die maximale afstand. Deze variant is dus wel NPC.

Tja, iets van wikipedia afhalen en in je eigen woorden vertellen kan iedereen wel...

Ik vraag me toch af bij wie _jij_ algoritmiek hebt gevolgd (en op welke universiteit).

Tenslotte: Een groot gedeelte van de complexiteitsklassehierarchie reduceert tot P wanneer P=NP. Dit betekent dat FPNP == NPC in dat geval. Dus dit betekent dat jouw "bewijs" zou impliceren P/=NP. Maar je hebt geen "bewijs" gegeven (anders dan volgens intimidatie).

[.oisyn]

Ah ja, de welbekende "ik stel een vraag en de discussie gaat niet verder totdat ik een antwoord van je heb, opdat door dat antwoord te proberen te formuleren je tot inzicht komt dat je ongelijk hebt"-methode, ipv gewoon meteen to the point komen, wat een hoop modder gooien scheelt (waarbij de modder vooral van jouw kant komt, maar dat terzijde) en de discussie een stuk makkelijker laat verlopen. Tactisch.

[Janoz]

Ik heb geen bewijs gegeven. Ik pas puur de definitie van NPC toe. Als jij wilt beweren dat TSP NPC is dan daag ik je uit om hier een psuedo algorithme neer te zetten waarin je laat zien hoe je een antwoord controleerd in polynomiale tijd. Let op, ik zeg duidelijk gegeven antwoord. Ik heb het niet over een algorithme dat dit antwoord zoekt. Ik weet wel degelijk waar ik het over heb.

Het is jammer dat je je post doorspekt met gelach en beweringen dat ik grappig zou zijn terwijl je zelf duidelijk niet op de hoogte bent van de definities.

mvg

Janoz, Master of Computer Science.

[TeeDee]

Master of Computer Science.

ooo, dacht dat jij altijd maar wat aan liep te modderen

gang-ster: door je zo op te stellen en door 'n reactie te plaatsen als "grappig, wow etc" getuigt nu niet echt van een stukje professionaliteit.

[Yoozer]

Verwijderd schreef op donderdag 04 oktober 2007 @ 10:05:
Wow, jij bent grappig(en je hebt geen idee waar je over spreekt).

Laat me raden - jij hebt nu niet even de tijd/zin om uit te typen waarom jij gelijk hebt?

Maar je hebt geen "bewijs" gegeven (anders dan volgens intimidatie).

Waar zie jij in vredesnaam intimidatie?

Even wat anders; P/NP, allemaal erg interessant, maar het heeft niks meer met de topicstart te maken, en PHP in de titel eigenlijk ook niet meer. Met het risico dat ik een backseat moderator genoemd wordt; misschien een goed idee om dit topic even te hernoemen en een splitsing te overwegen?

[Verwijderd]

Janoz schreef op donderdag 04 oktober 2007 @ 10:39:
Ik heb geen bewijs gegeven. Ik pas puur de definitie van NPC toe. Als jij wilt beweren dat TSP NPC is dan daag ik je uit om hier een psuedo algorithme neer te zetten waarin je laat zien hoe je een antwoord controleerd in polynomiale tijd. Let op, ik zeg duidelijk gegeven antwoord. Ik heb het niet over een algorithme dat dit antwoord zoekt. Ik weet wel degelijk waar ik het over heb.

Wow, wat een spelfouten. Probeer de basisschool nog maar een keer.

En hoe je er toch bij komt dat je weet waar je het over hebt? Geen idee.

Het punt is dat _jij_ beweert dat TSP geen element is van de complexiteitsklasse NPC. Dit geldt alleen als P/=NP, maar DAT WETEN WE NIET. Ik heb nooit beweerd dat het wel een element is van de complexiteitsklasse NPC.

Het is jammer dat je je post doorspekt met gelach en beweringen dat ik grappig zou zijn terwijl je zelf duidelijk niet op de hoogte bent van de definities.

Nogmaals: HAHAHAHAHAHAHA (je geeft niet aan _wat_ ik verkeerd heb gezegd(dat kan ook niet, want ik heb niets verkeerds gezegd))

mvg

Janoz, Master of Computer Science.

Tja, ik zie al waar je dat papiertje gehaald hebt(Groningen). Dat je een Msc CS hebt, interesseert me niets, want je begrijpt er nog steeds niets van. Zelfs met mijn uitleg begreep je het nog steeds niet.

Deze "groet"(ik dacht dat we dat niet deden op GoT) is weer een bewijs met intimidatie. De meeste idioten op dit forum zullen meteen denken "die zal het wel weten", omdat hij een Msc. CS heeft. Dat werkt bij mij niet. Sterker nog: ik vind het irritant gedrag dat jij tegen mij gaat lopen vertellen dat ik fout zit, terwijl jij de basis concepten van NP-Volledigheid niet eens begrijpt.

Ik mag hopen dat .oisyn mijn bewijs wel heeft begrepen.

[Verwijderd]

Yoozer schreef op donderdag 04 oktober 2007 @ 11:05:
Laat me raden - jij hebt nu niet even de tijd/zin om uit te typen waarom jij gelijk hebt?

Dat heb ik al uitgelegd. Dat het publiek niet in staat is dit te begrijpen is niet mijn probleem. Op een college algoritmiek leg ik het je graag 20 keer opnieuw uit. Op een willekeurig forum niet.

Waar zie jij in vredesnaam intimidatie?

"algoritmiek ietsje beter op te letten."

[Janoz]

Als jij gewoon wilt zeggen dat nog niet te bewijzen is of er geen algoritme bestaat waarbij je de correctheid van een gegeven oplossing binnen polynomiale tijd kunt berekenen, zeg dat dan gewoon (zoals je ziet is dat in 1 regeltje te doen). Dat komt behoorlijk wat geciviliseerder over dan als een kansloze neanderthaler in het rond te hakken.

[Verwijderd]

TeeDee schreef op donderdag 04 oktober 2007 @ 11:00:
[...]

ooo, dacht dat jij altijd maar wat aan liep te modderen

gang-ster: door je zo op te stellen en door 'n reactie te plaatsen als "grappig, wow etc" getuigt nu niet echt van een stukje professionaliteit.

Een meta-argument getuigt nu niet van inzicht in complexiteitstheorie. Als je van mij een professioneel antwoord(een die ook voor leken, zoals blijkbaar iedereen in deze thread, begrijpbaar is) wilt hebben dan kan dat, maar dan ook onder professionele voorwaarden.

[.oisyn]

Verwijderd schreef op donderdag 04 oktober 2007 @ 11:07:
Ik mag hopen dat .oisyn mijn bewijs wel heeft begrepen.

Ik zie geen bewijs, ik zie als buitenstaander in de discussie echter wel waar de discrepantie ligt. Namelijk dat Janoz er (indirect) vanuit gaat dat er geen algoritme in polynomiale tijd kan bestaan die verifiëert of iets de korste route is, terwijl jij zegt dat dat nooit bewezen is en het dus wel kan bestaan (ookal is die nog niet bekend). Als je dat echter in een van je eerdere posts gewoon duidelijk kenbaar had gemaakt, ipv reacties als "oh, heb je daar een bewijs van?" om vervolgens te zeggen dat hij totaal niet weet waar hij over praat (wat gewoon niet waar is, Janoz weet weldegelijk waar hij over praat, het gaat hier gewoon om een verschil in interpretatie), dan hadden we nu niet 10 fucking posts hoeven besteden aan een oninteressante discussie waarin jij je professionaliteit nou niet echt bepaald laat blijken.

Dus, zullen we nu weer ontopic?

[ Voor 3% gewijzigd door .oisyn op 04-10-2007 11:26 ]

[Verwijderd]

Janoz schreef op donderdag 04 oktober 2007 @ 11:19:
Als jij gewoon wilt zeggen dat nog niet te bewijzen is of er geen algoritme bestaat waarbij je de correctheid van een gegeven oplossing binnen polynomiale tijd kunt berekenen, zeg dat dan gewoon (zoals je ziet is dat in 1 regeltje te doen). Dat komt behoorlijk wat geciviliseerder over dan als een kansloze neanderthaler in het rond te hakken.

Ik wilde zeggen dat wat jij zei totale onzin was(en dat geef je nu ook toe). Blijkbaar had je een paar posts nodig om dit in te zien. Je mag me dan nu wel voor "kansloze neanderthaler" uitmaken, jij blijft een kansloze Msc.

[Verwijderd]

.oisyn schreef op donderdag 04 oktober 2007 @ 11:24:
[...]

Ik zie geen bewijs

Tenslotte: Een groot gedeelte van de complexiteitsklassehierarchie reduceert tot P wanneer P=NP. Dit betekent dat FPNP == NPC in dat geval. Dus dit betekent dat jouw "bewijs" zou impliceren P/=NP. Maar je hebt geen "bewijs" gegeven (anders dan volgens intimidatie).

Dit lijkt me toch een informeel bewijs.

[TeeDee]

Verwijderd schreef op donderdag 04 oktober 2007 @ 11:22:
[...]
Een meta-argument getuigt nu niet van inzicht in complexiteitstheorie.

Kan me niet herinneren dat ik aangegeven heb dat ik er wel verstand van heb. Vond het alleen een beetje een kinderbipsen reactie. En niet alleen die, er zijn er inmiddels in dit topic wel meer te zien.

Als je van mij een professioneel antwoord(een die ook voor leken, zoals blijkbaar iedereen in deze thread, begrijpbaar is) wilt hebben dan kan dat, maar dan ook onder professionele voorwaarden.

Right. En wat zijn je professionele voorwaarden? Of blijf je reacties plaatsen waarop vervolgens mensen moeten reageren omdat er anders toch niks uitkomt?
lekker offtopic allemaal

[Verwijderd]

TeeDee schreef op donderdag 04 oktober 2007 @ 11:31:
[...]

Kan me niet herinneren dat ik aangegeven heb dat ik er wel verstand van heb.

Ik kan me niet herinneren dat de mening van een willekeurig individu zonder kennis van de materie er toe doet.

Right. En wat zijn je professionele voorwaarden? Of blijf je reacties plaatsen waarop vervolgens mensen moeten reageren omdat er anders toch niks uitkomt?
lekker offtopic allemaal

Nou, nou, nou wat zou ik nu eens met "professionele voorwaarden" bedoelen? Ik laat deze vraag graag door iemand anders beantwoorden.

[Janoz]

Verwijderd schreef op donderdag 04 oktober 2007 @ 11:25:
[...]

Ik wilde zeggen dat wat jij zei totale onzin was(en dat geef je nu ook toe). Blijkbaar had je een paar posts nodig om dit in te zien. Je mag me dan nu wel voor "kansloze neanderthaler" uitmaken, jij blijft een kansloze Msc.

Totale onzin is het niet. Iemand beweert dat TSP NPC is en ik geef aan dat het op dit moment nog niet in die groep wordt ingedeeld en daarom behoort tot de NP-Hard groep van combinatorische optimalisatie problemen. Misschien had ik hier en daar beter de term 'zal zeer waarschijnlijk niet bestaan' moeten gebruiken ipv 'is niet'. Als jij alleen maar wat in het rond gaat hakken kan ik in eerste instantie niet anders opmaken dan dat jij in de veronderstelling bent dat TSP daadwerkelijk tot NPC behoort. En zoals je zelf pas veel later al aangeeft is dat inderdaad niet zo. Als je me vervolgens sideways blijft aanvallen op mijn argumentatie waarom TSP (op dit moment nog) niet tot NPC wordt gerekend wordt het heel lastig om te interpreteren wat je nu daadwerkelijk bedoeld. Blijft wel staan dat ik blijkbaar in 1 zin kan zeggen waar jij 10 rantposts voor nodig hebt.

[Verwijderd]

.oisyn schreef op donderdag 04 oktober 2007 @ 11:24:
(wat gewoon niet waar is, Janoz weet weldegelijk waar hij over praat, het gaat hier gewoon om een verschil in interpretatie)

Volgens mij kan wat Janoz zei zo in een tentamen worden gezet als: "Janoz zegt dit en dat, waarom heeft hij geen gelijk?"

De interpretatie is compleet helder voor iemand die weet waar hij/zij over praat, aangezien al de beweringen van Janoz een specifieke betekenis hebben.

TSP is niet NPC.

Dit kan maar op een manier worden geinterpreteerd: TSP is geen element van de complexiteitsklasse NPC, wat verder reduceert naar een bewijsverplichting voor deze bewering. Dit bewijs is niet bekend. Conclusie: Janoz misbruikt concepten en dit wordt vaak gedaan door mensen die er niets van begrijpen. (Vooral dus op dit soort fora)

Kijk, ik begrijp ook wel dat jullie vriendjes moeten blijven, als admins onder elkaar, maar je kunt ook gewoon zeggen: "Inderdaad gang-ster, je hebt gelijk, Janoz had niet moeten zeggen dat je je algoritmiek nog maar eens moest ophalen en Janoz zou zelf maar eens een cursus algoritmiek moeten volgen".

[Creepy]

Verwijderd schreef op donderdag 04 oktober 2007 @ 11:53:
Kijk, ik begrijp ook wel dat jullie vriendjes moeten blijven, als admins onder elkaar, maar je kunt ook gewoon zeggen: "Inderdaad gang-ster, je hebt gelijk, Janoz had niet moeten zeggen dat je je algoritmiek nog maar eens moest ophalen en Janoz zou zelf maar eens een cursus algoritmiek moeten volgen".

Dat laatste is door Janoz zelf ook net aangegeven. Kunnen we dan nu weer ontopic?

edit:
En ook stoppen met op de man spelen want de grenzen van het fatsoen zijn hier door een bepaalde persoon nog grof overtreden.

[ Voor 11% gewijzigd door whoami op 04-10-2007 12:26 ]

[Verwijderd]

Janoz schreef op donderdag 04 oktober 2007 @ 11:40:
[...]


Totale onzin is het niet. Iemand beweert dat TSP NPC is en ik geef aan dat het op dit moment nog niet in die groep wordt ingedeeld en daarom behoort tot de NP-Hard groep van combinatorische optimalisatie problemen. Misschien had ik hier en daar beter de term 'zal zeer waarschijnlijk niet bestaan' moeten gebruiken ipv 'is niet'. Als jij alleen maar wat in het rond gaat hakken kan ik in eerste instantie niet anders opmaken dan dat jij in de veronderstelling bent dat TSP daadwerkelijk tot NPC behoort. En zoals je zelf pas veel later al aangeeft is dat inderdaad niet zo. Als je me vervolgens sideways blijft aanvallen op mijn argumentatie waarom TSP (op dit moment nog) niet tot NPC wordt gerekend wordt het heel lastig om te interpreteren wat je nu daadwerkelijk bedoeld. Blijft wel staan dat ik blijkbaar in 1 zin kan zeggen waar jij 10 rantposts voor nodig hebt.

Nee, hoor. In mijn bewijs had ik dit in minder woorden al uitgedrukt. Dat jij dat niet begreep of begrijpt, daar kan ik niets aan doen(ik ging er vanuit dat er een gelijke communicatiepartner was, maar dit was dus niet het geval).

[Verwijderd]

Creepy schreef op donderdag 04 oktober 2007 @ 11:55:
[...]

Dat laatste is door Janoz zelf ook net aangegeven. Kunnen we dan nu weer ontopic?

Perfect

[.oisyn]

Verwijderd schreef op donderdag 04 oktober 2007 @ 11:53:
Kijk, ik begrijp ook wel dat jullie vriendjes moeten blijven, als admins onder elkaar

Admins? Da's voor mij al weer anderhalf jaar geleden. En als je de tijd neemt om mijn posthistorie door te nemen (waarbij het begrijpelijk is dat je daar geen zin in hebt) dan zul je zien dat het mij echt niet uitmaakt of ik een vriend, (ex)collega of een vreemde voor m'n neus heb in een discussie.

maar je kunt ook gewoon zeggen: "Inderdaad gang-ster, je hebt gelijk, Janoz had niet moeten zeggen dat je je algoritmiek nog maar eens moest ophalen en Janoz zou zelf maar eens een cursus algoritmiek moeten volgen".

Te kort door de bocht. Feit blijft dat ik een gruwelijke hekel heb aan het soort posts dat je hier tentoongesteld hebt, namelijk het soort posts waarbij je dmv vragen iemand tot inzicht probeert te laten komen, wat bij beginners idd meestal lukt maar bij professionals alleen maar tot verkeerde interpretaties leidt met een verhitte en moeizame discussie als gevolg, wat voorkomen had kunnen worden als je in het begin al meteen de vinger op de zere plek had gelegd. Janoz was wellicht niet helemaal correct in z'n woordvoering (maar tevens was het ook geen totale onzin, en het is imho een aan zekerheid grenzende waarschijnlijkheid dat P!=NP), maar jij moet je ook beseffen dat jouw bedoelingen niet geheel as-is worden opgevat als je op die manier discussiert, wat leidt tot irritaties en onduidelijkheden. Janoz post maakte namelijk deel uit van een discussie over het TSP probleem, waarin jij 1 bewering eruit pikt. De context in Janoz' hoofd is dus geheel anders dan de context in de jouwe.

Dus ja, jij had idd gelijk en Janoz ging uit van een verkeerde aanname. Het had handig geweest als je dat meteen had gezegd, bijvoorbeeld:

Janoz schreef op dinsdag 02 oktober 2007 @ 16:32:
TSP is niet NPC.

Ho ho, het is nog niet bewezen dat P!=NP, dus die bewering klopt niet helemaal.

---

Creepy schreef op donderdag 04 oktober 2007 @ 11:55:
[...]

Dat laatste is door Janoz zelf ook net aangegeven. Kunnen we dan nu weer ontopic?

Oh sorry, deze post stond er nog niet toen ik mijn post aan het tikken was. Eens.

[ Voor 6% gewijzigd door .oisyn op 04-10-2007 12:30 ]

[Verwijderd]

offtopic:
Al dat gelul over bewijs is een compleet gebrek aan communicatieve vaardigheden. Dergelijke mensen zijn geen knip voor een stuiver waard. Als ik bij de bakker een 'halfje wit' bestel krijg ik toch ook geen pak halfvolle melk? Het getuigt van intelligentie wanneer men andermans uitspraken juist interpreteert.

Verdomme, mijn dwangmatige post neurose speelt weer op...

[Verwijderd]

Maar wat is nou een alternatief voor PHP?

[Verwijderd]

Verwijderd schreef op donderdag 04 oktober 2007 @ 13:28:

offtopic:
Al dat gelul over bewijs is een compleet gebrek aan communicatieve vaardigheden. Dergelijke mensen zijn geen knip voor een stuiver waard. Als ik bij de bakker een 'halfje wit' bestel krijg ik toch ook geen pak halfvolle melk? Het getuigt van intelligentie wanneer men andermans uitspraken juist interpreteert.

Verdomme, mijn dwangmatige post neurose speelt weer op...

Zeker nog nooit van Socrates gehoord?

[? ?]

Verwijderd schreef op donderdag 04 oktober 2007 @ 13:33:
Maar wat is nou een alternatief voor PHP?

ASP

[Verwijderd]

Verwijderd schreef op donderdag 04 oktober 2007 @ 14:10:
Zeker nog nooit van Socrates gehoord?

Jawel hoor. Wat is je punt?

[NMe]

En nu heb ik er genoeg van. Vanaf nu géén beschuldigingen of insinuaties meer in dit topic (of die nu van een crewlid afkomen, een ex-crewlid of een "normale" user). Op de man spelen is iets waar ik in elk geval geen zin in heb, en wat ook gewoon niet nodig is om tot een valide discussiepunt te komen. Als je dat wél nodig hebt, schort er verder wat aan je communicatieve vaardigheden en kun je je beter weghouden uit inhoudelijke discussies met argumentaties.

Wie de schoen past trekke hem aan overigens, ik gooi gewoon wat in de groep.

[Verwijderd]

-NMe- schreef op donderdag 04 oktober 2007 @ 22:11:
heel verhaal

Amen en back to topic

[ Voor 4% gewijzigd door Verwijderd op 05-10-2007 03:27 ]