[Python] Kun je logisch nadenken aanleren/ aanscherpen?

[flugelisoke]

Ik ben bezig met de opleiding programmeur Python.

Ik ben een aantal weken bezig nu en wanneer ik zelf oplossingen moet verzinnen bij opdrachten, kom ik er vaak gewoon niet aan uit.

Dan weet ik het echt gewoon niet, ik weet dan niet waar te beginnen, waarom iets te doen. Dit is enorm frustrerend en het doet me twijfelen aan mijn intelligentie.

Herkent iemand dit?

Is logisch / abstract denken voor programmeren iets wat je standaard gewoon kan of niet.

Of is dit een eigenschap die je kunt aanleren?

Ik wil namelijk ontzettend graag slagen hierin, maar dit weerhoudt me momenteel.

[MAX3400]

hier ook niet geslaagd....

Grapje, ik moest ook programmeren op school. Kan ik niet. Zelfde symptomen als jij. Volgens mij toen nog Turbo Pascal en enige vorm van C# maar iets met ver verleden. Framework / logisch nadenken daarbinnen ligt me absoluut niet. Alsnog school niet afgemaakt maar dat heeft andere redenen.

Kan nog steeds niet programmeren; een VBA in Office? Geen idee. PHP en functies/variabelen? Geen idee. PowerShell? Dat wel. VBS? Gaat nog.

Constructief: heb je al eens met je studiegenoten of je leraar open/bloot gepraat over "dat je het niet ziet" en komen ze dan met een logische verklaring van, pak 'm beet, 10 minuten waarna je de opdracht wel snapt en alsnog de oplossing kan bouwen? Of lukt het absoluut niet?

[ThomasG]

Wat ik zelf vaak merk als programmeurs niet weten waar ze moeten beginnen, is dat ze het probleem wat ze moeten gaan oplossen niet begrijpen, of in ieder geval niet goed genoeg begrijpen. Programmeren is in feiten niets anders dan het probleem opdelen in kleine stukken, en deze stap voor stap op te lossen; en daarmee het grote probleem te op lossen.

De eerste stap is dus het analyzeren van het probleem, en het vervolgens opdelen in kleinere problemen; en die zijn vaak ook weer op te delen in kleinere problemen. Bij het geheel weet je niet waar je moet beginnen, bij de kleinere problemen is het veel duidelijker hoe en wat. In het begin kan dat vrij lastig zijn, maar naarmate je ervaring krijgt wordt het steeds gemakkelijker.

[Alain]

Precies wat ThomasG zegt. Probeer het probleem op te delen in kleinere problemen. Denk ook goed na hoe je een probleem oplost voordat je begint code te kloppen en doe soms een stapje terug als je erachter komt dat je verkeerde keuzes hebt gemaakt.

Ook is het vaak belangrijk om domeinkennis op te doen, maar dat zal voor een schoolopdracht misschien niet direct gelden.

[TRON]

@flugelisoke kan je aangeven waar je vooral op vastloopt? Kan je een opdracht wel uitwerken met pseudo-code? (niet echte code, maar een verhaaltje van hoe je iets oplost).

[Mugwump]

Allereerst valt alles tot op zekere hoogte wel te leren. De één zal meer aanleg hebben dan de ander, maar oefening baart niet voor niets kunst.

Zoals @TRON vraagt, om wat voor soort opdrachten gaat het?
Is het heel algoritmisch, is het wat meer logica waarbij je condities en iteraties moet toepassen of weer wat anders.

[sorted.bits]

Een deel is misschien 'aangeboren' inzicht, maar ik denk wel dat je jezelf er in kan verbeteren. Uiteindelijk is het een combinatie van een stukje talent, opleiding en oefening.

Wat al gezegd is, begrijp eerst het probleem goed en deel het op in stukken. Steeds kleiner en je kan een duidelijk plan maken om een stuk software te schrijven.

Daarnaast, oefenen, oefenen en oefenen. De meeste developers die ik ken (en waar ik mee werk), programmeren al jaren tot tientallen jaren. Mijn eerste programma's schreef ik toen ik een jaar of 8 was. (ow fuck, dat is bijna 32 jaar geleden). Natuurlijk niets spannends, maar oefening baart kunst.

[bwerg]

ThomasG schreef op dinsdag 30 april 2019 @ 20:05:
Programmeren is in feiten niets anders dan het probleem opdelen in kleine stukken

Alain schreef op dinsdag 30 april 2019 @ 20:47:
Probeer het probleem op te delen in kleinere problemen.

sorted.bits schreef op dinsdag 30 april 2019 @ 21:42:
Wat al gezegd is, begrijp eerst het probleem goed en deel het op in stukken.

Detail is dat je het wel op de juiste manier moet opdelen, anders heb je daar weinig aan. Het is niet alsof je 100 losse stukjes code kan schrijven, en dat als die 100 regels afzonderlijk werken, het geheel ook werkt. Om dat goed te doen heb je juist abstractievermogen nodig. De afzonderlijke stukjes code worden steeds gemakkelijker, maar het abstracte overzichtsplaatje wordt moeilijker.

[Matis]

Zoals al eerder genoemd, deel het vraagstuk op in losse deel-opdrachten.

Dat werkt overigens wel een stuk eenvoudiger als je weet welke functies een programmeertaal of framework biedt.
Je hoeft (bijna nooit) het wiel opnieuw uit te vinden, omdat heel veel oplossing van de deel-opdrachten al standaard in de programmeertaal of framework zitten.

Het "enige" dat een softwareontwikkelaar hoeft te doen is het aan elkaar knopen van die reeds bestaande stukken functionaliteit.
Ik ga nu wel heel kort door de bocht, maar ik zie softwareontwikkeling als een denksport die tot op zekere hoogte aan te leren valt.

Om je op weg te helpen: probeer ons eens uit te leggen (zonder code) wat de opdracht inhoudt en hoe jij deze denkt op te splitsen in deel-opdrachten.

90% van het werk van een softwareontwikkelaar is abstract denken in losse stukken functionaliteit. De overige 10% is het daadwerkelijk tikken van de regels code in de programmeertaal (naar keuze).

Wat je misschien zou helpen is het schrijven van (versimpelde) user stories/features in een pseudo (programmeer)taal zoals Gherkin.

[ Voor 17% gewijzigd door Matis op 01-05-2019 06:29 ]

[Douweegbertje]

Ik ben een aantal weken bezig nu

vs

Dit is enorm frustrerend en het doet me twijfelen aan mijn intelligentie.

Na een aantal weken inzet zou ik mij niet al te druk maken aan je intelligentie. Dat is een beetje snel en te voorbarig, sowieso; dat soort doemdenken heeft echt weinig nut.

Het maakt niet uit of je nu gaat programmeren of Franse les gaat geven, links of rechts om moet je hier gewoon energie in stoppen en dan zul je beetje bij beetje beter worden...


Puur om antwoord te geven op je exacte vraag, ja logisch nadenken zit er bij de 1 meer in dan de ander. Zo ben ik gewoon autistisch. Wellicht voor sommige een ernstig woordje, maar je hebt tegenwoordig volgens mij 1000 types er van. Bij mij houdt het concreet is dat ik eigenlijk alleen logisch kan nadenken.
Hoewel dit super leuk is voor wiskunde en uiteraard programmeren heeft het ook weer zijn nadelen.

Wat ik hiermee wil zeggen is dat het geen noodzaak is om keihard logisch te kunnen nadenken, in een bedrijf / team wil je diverse mensen hebben om elkaar aan te vullen. Het feit dat je capabel genoeg bent om na te denken over je huidige situatie en hier navraag over te doen zet je sowieso een paar stapje voor op menig persoon.

Ik zou gewoon lekker doorgaan en niet al te veel zorgen maken. Probeer er lol in te hebben en hier energie uit te halen om je steeds meer te verbeteren. Hoe leuker je het vind hoe makkelijker het is om erin bezig te blijven

Succes

[Metalfreak]

Mijn tip: papier! Ik weet het, een vies woord voor ICT-ers, maar als je het vaak in delen opschrijft en probeert uit te tekenen wat je wilt bereiken helpt dat enorm. Als je het tekent, haalt dat het abstracte ook een beetje eruit.

Maar goed, het echte abstracte programmeren wilde er bij mij ook nooit écht in (denk aan C en C++ ), dat heb ik maar geaccepteerd.

[flugelisoke]

Bedankt allemaal dat jullie zo behulpzaam zijn, super tof!

Soms heb ik misschien moeite met het écht door en door begrijpen van de vraag. Soms twijfel ik ook wat ik nou precies niet weet, voor mijn gevoel lijkt het dan alsof ik Chinese tekens moet gaan schrijven, wellicht is het probleem dat ik op dit moment de commands en volgordes nog niet helemaal beheers.

Ik wil dingen ook gelijk kunnen, wanneer er bij de opdracht easy staat, ben ik gefrustreerd dat ik er even niks uit krijg. Het wil niet zeggen dat ik geen een opdracht zelf kan maken, maar ik loop er wel vaak tegenaan. Aan de andere kant is dit nog maar het begin van de studie en ik weet ik simpelweg nog niet veel.

[flugelisoke]

Matis schreef op woensdag 1 mei 2019 @ 06:22:
Zoals al eerder genoemd, deel het vraagstuk op in losse deel-opdrachten.

Dat werkt overigens wel een stuk eenvoudiger als je weet welke functies een programmeertaal of framework biedt.
Je hoeft (bijna nooit) het wiel opnieuw uit te vinden, omdat heel veel oplossing van de deel-opdrachten al standaard in de programmeertaal of framework zitten.

Het "enige" dat een softwareontwikkelaar hoeft te doen is het aan elkaar knopen van die reeds bestaande stukken functionaliteit.
Ik ga nu wel heel kort door de bocht, maar ik zie softwareontwikkeling als een denksport die tot op zekere hoogte aan te leren valt.

Om je op weg te helpen: probeer ons eens uit te leggen (zonder code) wat de opdracht inhoudt en hoe jij deze denkt op te splitsen in deel-opdrachten.

90% van het werk van een softwareontwikkelaar is abstract denken in losse stukken functionaliteit. De overige 10% is het daadwerkelijk tikken van de regels code in de programmeertaal (naar keuze).

Wat je misschien zou helpen is het schrijven van (versimpelde) user stories/features in een pseudo (programmeer)taal zoals Gherkin.

Hey Matis!

Ik kom hier zsm even op terug zodat ik het meer in detail kan uitleggen. Het ding is dat ik deze opdracht eigenlijk zelf moet maken zonder het antwoord te weten, juist het zelf op zoek gaan naar de manieren is het doel.

Ik merk wel dat ik soms nog een beetje moeite heb om de oplossing zelf in het Nederlands te schrijven, laat staan vertalen naar Python.

[CurlyMo]

Toch moest ik wel gniffelen om het feit dat zo'n vraag wordt gesteld vanuit een Python context. Ik loop er vaak tegenaan dat programmeurs stellen expert te zijn in taal X. Ik zeg altijd dat ik een (programmeer)talenknobbel heb. Daarbij vind ik de vraag hoe goed ik in taal X ben ook helemaal niet relevant. Ja, ik kan stellen dat ik meer ervaring heb ik taal X, maar het gaat er mij veel meer om dat ik inzicht heb in bepaalde principes zoals OOP, parsers / lexers, design patterns enz. Dat zorgt ervoor dat ik uiteindelijk beter ga programmeren in een taal die ik nog niet ken, dan iemand die alleen maar die taal kent, maar het inzicht mist, zoals @MAX3400 eerlijk toegeeft.

Zo heb ik zat collega's gehad die 'expert' zeggen te zijn in python maar het principe van garbage collection en geheugenbeheer (wat essentieel is in C) niet kende (dat doet Python toch automatisch?), waardoor hun scripts regelmatig tegen geheugenproblemen aanliepen, waar ik nooit ergens last van had.

Oftewel, probeer je bij het aanleren van programmeren je niet blind te staren op de conventies specifiek voor die taal. Of dat nu Python of PHP of C of Java is. Ik ben bijvoorbeeld totaal geen fan van de Python PEP conventies. Juist omdat het zorgt voor code dat vooral voor Python mensen begrijpelijk is en niet voor mensen met een generieke talenknobbel zonder Python kennis. C dwingt je aan geheugenbeheer te doen waar dat in Python niet hoeft. Terwijl C vanuit zichzelf niks doet met bijv. threadpools. In PHP dwingt je nergens toe en dat is zowel een voordeel als nadeel, Java dwingt je weer in OOP te werken. Zolang je dat weet, dan kan je de principes van de taal op zijn waarde schatten en realiseer je tevens dat de wereld van programmeren en de principes erachter breder zijn dan dat.

En dan hebben we het alleen nog maar over imperatieve talen gehad en niet eens over functionele talen. Ik heb gemerkt dat sommige van mijn collega's het imperatieve denken totaal niet doorkregen en maar een kei waren in hun functionele taal. En andersom. Het kan dus ook zo zijn dat je misschien meer een functionele taal persoon bent. Wie weet

[servies]

CurlyMo schreef op woensdag 1 mei 2019 @ 08:45:
...

Een heel verhaal dat ik niet wil herhalen maar waar ik eigenlijk 10 duimpjes aan wil geven.

Het interesseert me tot op zekere hoogte niet met welke programmeertaal er gewerkt wordt *
Bedenk bij een probleem eens:
Hoe zou ik het zelf handmatig doen? Als je dan de stappen hebt opgeschreven, dan ben je al een heel eind op weg.

* Alles behalve Lisp... Ik word gek van het haakjes tellen...

[Luca]

Grappig, ik ben hier ook vaak tegenaan gelopen. Als iemand die graag de logica achter alles "moet" snappen en heel abstract denkt, heb ik de nodige hoofdpijnsessies gehad. Altijd de "maar waarom moet dat hier?"

Goede vriend en tevens enorm goede programmeur geeft mij altijd weer als tip dat ik de probleemstukken op moet delen in kleinere stukken, het meer moet proberen te ontleden en een klein stappenplan opschrijven. Ik wil dat *dit* en *dit* gedaan kan worden. Oké, en hoe ga ik dat bereiken? Door *dit* en *dit* te doen. En dat daadwerkelijk opschrijven, op ouderwets papier. Bullet points, dingen schetsen. Visualiseer het. Soms legde hij zijn probleemstuk gewoon uit aan mij, wat hij ging doen en hoe, puur zodat hij het voor zichzelf allemaal snapte.

Blijven herhalen en op een gegeven moment ga je een systeempje ontwikkelen. Maar vergeet ook niet dat niet iedereen er even goed in zal zijn, hoe graag je dat ook wil. Dat heb ik inmiddels ook al geaccepteerd. Ik ben een man van de talen, maar programmeren is echt hele andere koek.

[flugelisoke]

Danny.G schreef op woensdag 1 mei 2019 @ 09:01:
Grappig, ik ben hier ook vaak tegenaan gelopen. Als iemand die graag de logica achter alles "moet" snappen en heel abstract denkt, heb ik de nodige hoofdpijnsessies gehad. Altijd de "maar waarom moet dat hier?"

Goede vriend en tevens enorm goede programmeur geeft mij altijd weer als tip dat ik de probleemstukken op moet delen in kleinere stukken, het meer moet proberen te ontleden en een klein stappenplan opschrijven. Ik wil dat *dit* en *dit* gedaan kan worden. Oké, en hoe ga ik dat bereiken? Door *dit* en *dit* te doen. En dat daadwerkelijk opschrijven, op ouderwets papier. Bullet points, dingen schetsen. Visualiseer het. Soms legde hij zijn probleemstuk gewoon uit aan mij, wat hij ging doen en hoe, puur zodat hij het voor zichzelf allemaal snapte.

Blijven herhalen en op een gegeven moment ga je een systeempje ontwikkelen. Maar vergeet ook niet dat niet iedereen er even goed in zal zijn, hoe graag je dat ook wil. Dat heb ik inmiddels ook al geaccepteerd. Ik ben een man van de talen, maar programmeren is echt hele andere koek.

Je eerste alinea lijkt een quote van mezelf In het begin zat ik zelfs diep na te denken... "Ja maar waarom als ik print intik, waarom komt er dan tekst op het scherm"

Vaak zit ik ook bij loops na te denken... "Maar waarom doet hij precies dat als je dat keyword invult..."

[CurlyMo]

flugelisoke schreef op woensdag 1 mei 2019 @ 09:05:
[...]


Je eerste alinea lijkt een quote van mezelf In het begin zat ik zelfs diep na te denken... "Ja maar waarom als ik print intik, waarom komt er dan tekst op het scherm"

Als je zo gaat denken dan sta je op een gegeven moment in de mijn waar de waardevolle delfstoffen worden gedolven.

- Waarom komt er dan tekst op het scherm?
- Hoe werken drivers en in welke taal zijn die geschreven?
- Hoe werkt dan een LCD scherm en hoe een CRT?
- Hoe werkt dan de elektronica van zo'n scherm?
- Wat is een transistor?
- Hoe bouw je een transistor?
- Waar komen de materialen van een transistor vandaan?
[...]
- Wat zijn zwarte gaten en wat is de oerknal?

Ergens mag je best een scope aanbrengen in je interesses en nieuwsgierigheid. Dat print tekst op het scherm zet is daar één van

[bwerg]

flugelisoke schreef op woensdag 1 mei 2019 @ 08:39:
Soms heb ik misschien moeite met het écht door en door begrijpen van de vraag. Soms twijfel ik ook wat ik nou precies niet weet, voor mijn gevoel lijkt het dan alsof ik Chinese tekens moet gaan schrijven, wellicht is het probleem dat ik op dit moment de commands en volgordes nog niet helemaal beheers.

Dat zou ook heel goed kunnen. Zo kunnen beginnend programmeurs vaak ook nog niks met een debugger: of het juiste antwoord wordt geprint, of niet. En als dat niet zo is, dan staren ze beteuterd naar hun scherm en weten ze niet meer wat te doen. Uitzoeken waarom iets niet werkt is dan ook een belangrijke vaardigheid, maar dat wordt soms niet zo expliciet als doel gesteld in programmeeropdrachten. Hetzelfde geldt voor zoeken in libraries naar functies die je misschien kan gebruiken. Dan helpt het natuurlijk ook als je veel functies al eens gezien hebt, en dat duurt een tijd.

[CurlyMo]

bwerg schreef op woensdag 1 mei 2019 @ 09:17:
[...]

Dat zou ook heel goed kunnen. Zo kunnen beginnend programmeurs vaak ook nog niks met een debugger: of het juiste antwoord wordt geprint, of niet. En als dat niet zo is, dan staren ze beteuterd naar hun scherm en weten ze niet meer wat te doen.

Begin er niet over. Debuggen is zo'n enorm ondergeschoven kindje. Na het stap voor stap je probleem uitwerken het ook stap voor stap kunnen ontrafelen waarom het toch niet precies doet wat je had verwacht.

Daarbij is natuurlijk het verschil niet het juiste dingen op het scherm geprint krijgen en weten hoe überhaupt een print werkt. Dat eerste is zinvol, dat tweede niet zo.

[Mugwump]

CurlyMo schreef op woensdag 1 mei 2019 @ 08:45:
Toch moest ik wel gniffelen om het feit dat zo'n vraag wordt gesteld vanuit een Python context. Ik loop er vaak tegenaan dat programmeurs stellen expert te zijn in taal X. Ik zeg altijd dat ik een (programmeer)talenknobbel heb. Daarbij vind ik de vraag hoe goed ik in taal X ben ook helemaal niet relevant. Ja, ik kan stellen dat ik meer ervaring heb ik taal X, maar het gaat er mij veel meer om dat ik inzicht heb in bepaalde principes zoals OOP, parsers / lexers, design patterns enz. Dat zorgt ervoor dat ik uiteindelijk beter ga programmeren in een taal die ik nog niet ken, dan iemand die alleen maar die taal kent, maar het inzicht mist, zoals @MAX3400 eerlijk toegeeft.

Zo heb ik zat collega's gehad die 'expert' zeggen te zijn in python maar het principe van garbage collection en geheugenbeheer (wat essentieel is in C) niet kende (dat doet Python toch automatisch?), waardoor hun scripts regelmatig tegen geheugenproblemen aanliepen, waar ik nooit ergens last van had.

Oftewel, probeer je bij het aanleren van programmeren je niet blind te staren op de conventies specifiek voor die taal. Of dat nu Python of PHP of C of Java is. Ik ben bijvoorbeeld totaal geen fan van de Python PEP conventies. Juist omdat het zorgt voor code dat vooral voor Python mensen begrijpelijk is en niet voor mensen met een generieke talenknobbel zonder Python kennis. C dwingt je aan geheugenbeheer te doen waar dat in Python niet hoeft. Terwijl C vanuit zichzelf niks doet met bijv. threadpools. In PHP dwingt je nergens toe en dat is zowel een voordeel als nadeel, Java dwingt je weer in OOP te werken. Zolang je dat weet, dan kan je de principes van de taal op zijn waarde schatten en realiseer je tevens dat de wereld van programmeren en de principes erachter breder zijn dan dat.

Ik heb wel eens voor collega's die Python doen een soort van geschiedenislesje imperatieve / OO talen gedaan. Dan merk je toch wel dat er een aardig gat zit in denk- en werkwijze tussen de abstracte benadering van iemand met een WO TI achtergrond en de mensen die vooral in de 'hoe krijg ik X werkend in taal Y' stand zitten.

Kwam gisteren overigens nog weer een mooi voorbeeld tegen van de zeer beperkte mate waarin Java je dwingt OOP te werken. Stukje software met een servlet class waarin alle logica in één grote procedurele brei was verwerkt en wat pure data objectjes erbij. Gelukkig hebben we peers die je dwingen OO te werken.

En dan hebben we het alleen nog maar over imperatieve talen gehad en niet eens over functionele talen. Ik heb gemerkt dat sommige van mijn collega's het imperatieve denken totaal niet doorkregen en maar een kei waren in hun functionele taal. En andersom. Het kan dus ook zo zijn dat je misschien meer een functionele taal persoon bent. Wie weet

Of CLP, dat vond ik fantastische puzzeltjes op de uni. Wordt in de praktijk alleen zeer weinig gebruikt.

[flugelisoke]

bwerg schreef op woensdag 1 mei 2019 @ 09:17:
[...]

Dat zou ook heel goed kunnen. Zo kunnen beginnend programmeurs vaak ook nog niks met een debugger: of het juiste antwoord wordt geprint, of niet. En als dat niet zo is, dan staren ze beteuterd naar hun scherm en weten ze niet meer wat te doen. Uitzoeken waarom iets niet werkt is dan ook een belangrijke vaardigheid, maar dat wordt soms niet zo expliciet als doel gesteld in programmeeropdrachten. Hetzelfde geldt voor zoeken in libraries naar functies die je misschien kan gebruiken. Dan helpt het natuurlijk ook als je veel functies al eens gezien hebt, en dat duurt een tijd.

Ik kan bijvoorbeeld wanneer ik het antwoord c.q. de oplossing van het vraagstuk zie, goed onthouden welke commands er zijn gegeven. Dit is ook meteen het gevaar zei de docent. De vorige opdrachten tik ik vaak uit mijn hoofd uit omdat ik weet wat precies daar moet staan. Daarom raad hij me aan om juist niet naar de uitkomst te kijken en er zelf op te komen, dat is nog heuuuuuul lastig.

Soms wordt het dan letterlijk wazig als je naar je scherm zit te staren en komt er niks uit omdat ik het simpelweg niet weet, wellicht heb ik op dat moment nog niet de beschikking over de juiste informatie.

Anderzijds zou alles wat je moet doen wel in de hoofdstukken behandeld moeten zijn maar wellicht in een andere context waarbij het kwartje niet bij me valt.

[Tk55]

ThomasG schreef op dinsdag 30 april 2019 @ 20:05:
Wat ik zelf vaak merk als programmeurs niet weten waar ze moeten beginnen, is dat ze het probleem wat ze moeten gaan oplossen niet begrijpen, of in ieder geval niet goed genoeg begrijpen. Programmeren is in feiten niets anders dan het probleem opdelen in kleine stukken, en deze stap voor stap op te lossen; en daarmee het grote probleem te op lossen.

De eerste stap is dus het analyzeren van het probleem, en het vervolgens opdelen in kleinere problemen; en die zijn vaak ook weer op te delen in kleinere problemen. Bij het geheel weet je niet waar je moet beginnen, bij de kleinere problemen is het veel duidelijker hoe en wat. In het begin kan dat vrij lastig zijn, maar naarmate je ervaring krijgt wordt het steeds gemakkelijker.

Dit kan ik helemaal beamen.

Pak pen en papier, teken het probleem uit. Eigenlijk wil je het probleem in je hoofd al hebben opgelost, voordat je ook maar code gaat schrijven. Als je namelijk in de code duikt zonder fatsoenlijk plan, raak je de weg kwijt en zie je door de bomen het bos niet meer. Je hoeft namelijk niet na te denken over de code, de taal, de implementatiedetails. Enkel over de stappen die het probleem oplossen. Deze stappen naar code vertalen is vervolgens relatief gemakkelijk. Dit lijkt misschien minder productief, maar je komt vaak veel sneller tot een oplossing dan zonder eerst goed na te denken.

[ Voor 10% gewijzigd door Tk55 op 01-05-2019 09:28 ]

[Haan]

@TS om je een hart onder de riem te steken: ik ben zelf vrij laat begonnen met programmeren, ik zat al een aantal jaar op de universiteit (studie Economie) en ben toen programmeervakken (te beginnen bij 'Inleiding programmeren') gaan volgen om verder in die richting te kunnen ontwikkelen (mooie woordgrap in deze context ).
Dat ging in eerste instantie vrij beroerd, kan ook aan de docent en/of het boek gelegen dat we moesten gebruiken. In ieder geval had ik geen idee wat ik aan het doen was. Maar de tweede keer dat ik het vak volgde viel het kwartje opeens wel en scoorde ik zelfs een 10 voor het tentamen En inmiddels ben ik ruim 10 jaar aan het werk als programmeur.
Dus de moraal van het verhaal: het kan in het begin misschien moeilijk zijn, maar het kan ook helemaal goed komen!

[Stoelpoot]

Over wat voor problemen praten we hier trouwens? Gaat het om het wiskundige deel, of echt om de boolean-logica?

Verder sluit ik me ook aan bij de reacties dat je na een paar weken echt nog geen wereldwonderen hoeft te verwachten. Vaak heb je op dat niveau nog niet echt de kennis en ervaring om het brede geheel te zien. Daarbijkomend schrijf je als lerend ontwikkelaar vaak wat slechtere code, die dus lastiger te lezen is waardoor het lastig is het geheel te overzien. Als ik me nu indenk wat voor gedrochten ik heb geschreven tijdens m'n opleiding, bah.

Ook zoals anderen zeggen: Deel het werk op in blokken. Doe dit desnoods op papier (het belangrijkste gereedschap van een ontwikkelaar, zeg ik weleens ).

Tenslotte: Ga eens concreet advies en reviews vragen aan medeprogrammeurs. Als je een opdracht niet goed uitgewerkt krijgt, vraag aan een ander hoe diegene het uit zou werken. En als je een opdracht wel goed werkend hebt, vraag eens bij anderen na hoe die het aan zouden pakken. Dit kan trouwens ook best op Tweakers, mits je er wel eigen inzet voor toont en dus niet verwacht dat de opdracht voor je gemaakt wordt

[flugelisoke]

Matis schreef op woensdag 1 mei 2019 @ 06:22:
Zoals al eerder genoemd, deel het vraagstuk op in losse deel-opdrachten.

Dat werkt overigens wel een stuk eenvoudiger als je weet welke functies een programmeertaal of framework biedt.
Je hoeft (bijna nooit) het wiel opnieuw uit te vinden, omdat heel veel oplossing van de deel-opdrachten al standaard in de programmeertaal of framework zitten.

Het "enige" dat een softwareontwikkelaar hoeft te doen is het aan elkaar knopen van die reeds bestaande stukken functionaliteit.
Ik ga nu wel heel kort door de bocht, maar ik zie softwareontwikkeling als een denksport die tot op zekere hoogte aan te leren valt.

Om je op weg te helpen: probeer ons eens uit te leggen (zonder code) wat de opdracht inhoudt en hoe jij deze denkt op te splitsen in deel-opdrachten.

90% van het werk van een softwareontwikkelaar is abstract denken in losse stukken functionaliteit. De overige 10% is het daadwerkelijk tikken van de regels code in de programmeertaal (naar keuze).

Wat je misschien zou helpen is het schrijven van (versimpelde) user stories/features in een pseudo (programmeer)taal zoals Gherkin.

Als voorbeeld ben ik nu aan de volgende opdracht bezig, gisteren kon ik hem wel uitwerken met hulp maar dat ben ik vandaag weer kwijt.

De opdracht luidt alsvolgt:


Scenario
The continue statement is used to skip the current block and move ahead to the next iteration, without executing the statements inside the loop. The two statements can be used with both the while and for loops.

Your task is to design a vowel eater! Write a program with a for loop that utilizes the concept of conditional execution (if-elif-else), and makes use of the continue statement. Your program must:

ask the user to enter a word in lower-case letters;
use conditional execution and the continue statement to "eat" the vowels a, e, i, o, u from the inputted word;
print each letter to the screen (all consonants and the letter y) on a separate line.
Test your program with the data we've provided for you. Don't change the code in the editor.

Test data
Example input
python

Example output
p y t h n

Example input
snake

Example output
s n k

Example input
rhythm

Example output
r h y t h m


Het volgende heb ik voor mezelf op papier geschreven ( echt papier )


Programma schrijven met een for loop:

gebruik:

if
elif
else
continue

Filter de letters a,e,i,o,u eruit van het input woord, wat ik in dit geval "word" noem.

Print de woorden zonder de letters die hiervoor zijn genoemd.


Continue met een pijl naar a,e,i,o,u ( visueel )


Wat staat er als start gegeven in het scherm?

# prompt the user to enter a word:

# complete the for loop:
for letter in word:


Nu moet ik zelf weten wat ik precies moet invullen waardoor het programma geschreven wordt. Momenteel sta zit ik als een schaap naar het scherm te staren.

Ik wil het graag uitvinden zonder hints, maar ik probeer inzicht te krijgen in het feit waarom dat kwartje nog niet valt bij me.

Ook zou ik graag wat meer inzicht willen hoe ik er wel achter kan komen wat ik zou moeten invoeren.

[vj_slof]

Helemaal over een andere boeg gooien: jointje roken, paddo's eten of andere drugs (legaal of illegaal, whatever je ding is....)

Steve Jobs, Bill Gates, Elon Musk... just to name a few.

[ Voor 19% gewijzigd door vj_slof op 01-05-2019 12:38 ]

[Jaap-Jan]

flugelisoke schreef op woensdag 1 mei 2019 @ 12:27:
[...]
(..)
Ook zou ik graag wat meer inzicht willen hoe ik er wel achter kan komen wat ik zou moeten invoeren.

Eigenlijk is dit al een stappenplan:
1. ask the user to enter a word in lower-case letters;
2. use conditional execution and the continue statement to "eat" the vowels a, e, i, o, u from the inputted word;
3. print each letter to the screen (all consonants and the letter y) on a separate line.
4. Test your program with the data we've provided for you. Don't change the code in the editor.

Als je dit stap voor stap doet, heb je een werkend programma, simpel gezegd. En nu? Wat moet er nu gebeuren? Dat is wat je jezelf constant moet afvragen. Stap 1 bestaat zelf ook weer uit een aantal stappen. Kun je bedenken welke? En dan de hamvraag: kan ik die stap omzetten in code, of moet hij nog verder uitgewerkt worden?

[leverage010]

Scenario
The continue statement is used to skip the current block and move ahead to the next iteration, without executing the statements inside the loop. The two statements can be used with both the while and for loops. Your task is to design a vowel eater! Write a program with a for loop that utilizes the concept of conditional execution (if-elif-else), and makes use of the continue statement. Your program must:

- ask the user to enter a word in lower-case letters;
- use conditional execution and the continue statement to "eat" the vowels a, e, i, o, u from the inputted word;
-print each letter to the screen (all consonants and the letter y) on a separate line.
-Test your program with the data we've provided for you. Don't change the code in the editor.

Programma schrijven met een for loop:

gebruik:

if
elif
else
continue

Fragmentatie is je beste vriend. je breekt het vraagstuk op in stappen
1. Vraag een user om input
2. Sla deze input op in een variabele
ik zal op de een of andere manier over alle losse letters moeten gaan...zogezegd door het woorden heen "loopen"
3. schrijf een loop statement die door het woord heen gaat
kijk bij iedere letter naar welke letter hij is, en ALS het a, e, i, o of u is, moet ik hem niet outputten.

daar heb je dan in principe je stappenplan al.

in zijn primaire vorm, zal je bijna altijd terug komen op het "ALS" verhaal, omdat dingen moeten voldoen aan specifieke condities.

alle andere keywords en commands zijn er enkel om je leven makkelijker te maken, maar het fragmenteren van een taak in kleine stappen is je voornaamste skill.

[flugelisoke]

Inmiddels heb ik met lichte hulp een werkend programma gemaakt voor deze opdracht, maar nu heb ik een vraag.

Dit is het werkende programma:

word = input("Input a word: ")

# complete the for loop:
for letter in word:
if letter == "a":
continue
elif letter == "e":
continue
elif letter == "i":
continue
elif letter == "o":
continue
elif letter == "u":
continue
else:
print(letter)


Als ik kattenkont ( Ja ach, wat anders ) als invoer geef dan print hij idd kttnknt.

Maar als ik de code verander aan de onderkant met else:

word = input("Input a word: ")

# complete the for loop:
for letter in word:
if letter == "a":
continue
elif letter == "e":
continue
elif letter == "i":
continue
elif letter == "o":
continue
elif letter == "u":
continue

else:
print(letter)


En als ik dan kattenkont invoer.... Waarom print hij dan alleen de t?

nota: Else is dan geen onderdeel meer van die loop, maar dan alsnog vind ik het opmerkelijk dat t alleen de output is van die loop.

[ Voor 5% gewijzigd door flugelisoke op 01-05-2019 13:53 ]

[Aragnut]

flugelisoke schreef op woensdag 1 mei 2019 @ 13:50:
Inmiddels heb ik met lichte hulp een werkend programma gemaakt voor deze opdracht, maar nu heb ik een vraag.

Dit is het werkende programma:

word = input("Input a word: ")

# complete the for loop:
for letter in word:
if letter == "a":
continue
elif letter == "e":
continue
elif letter == "i":
continue
elif letter == "o":
continue
elif letter == "u":
continue
else:
print(letter)


Als ik kattenkont ( Ja ach, wat anders ) als invoer geef dan print hij idd kttnknt.

Maar als ik de code verander aan de onderkant met else:

word = input("Input a word: ")

# complete the for loop:
for letter in word:
if letter == "a":
continue
elif letter == "e":
continue
elif letter == "i":
continue
elif letter == "o":
continue
elif letter == "u":
continue

else:
print(letter)


En als ik dan kattenkont invoer.... Waarom print hij dan alleen de t?

Beetje fijne/vervelende van Python, je hebt geen haakjes om aan te geven wat binnen een loop zit, maar tabs (overigens kun je de code best in [ code ] tags sluiten zodat tabs behouden blijven)

Loop zelf eens doorheen en shrijf maar op wat de waardes van de variabel "letter" zijn.

TIP: bij het woord hondenbrok zal je de letter k krijgen aan het eind.

offtopic:
zo had ik een programma die na sorteren altijd netjes een lijst had met maar 1 item erin

[ Voor 3% gewijzigd door Aragnut op 01-05-2019 13:56 ]

[flugelisoke]

Aragnut schreef op woensdag 1 mei 2019 @ 13:53:
[...]


Beetje fijne/vervelende van Python, je hebt geen haakjes om aan te geven wat binnen een loop zit, maar tabs (overigens kun je de code best in [ code ] tags sluiten zodat tabs behouden blijven)

Loop zelf eens doorheen en shrijf maar op wat de waardes van de variabel "letter" zijn.

TIP: bij het woord hondenbrok zal je de letter k krijgen aan het eind.

Het volgende verwart me nog een beetje:

for letter in word:


Ik begrijp dat er met for een variabel wordt aangemaakt, het woord wat je na "for" typt is dus de nieuwe aangemaakte variabel.

Nu begrijp ik nog niet helemaal wat die variabel voor betekenis heeft ten opzichte van de input -> word.

Dus om op je opdracht terug te komen, loop er eens doorheen, begrijp ik denk ik het eerste nog niet helemaal zoals ik zou moeten

[leverage010]

flugelisoke schreef op woensdag 1 mei 2019 @ 13:56:
[...]


Het volgende verwart me nog een beetje:

for letter in word:


Ik begrijp dat er met for een variabel wordt aangemaakt, het woord wat je na "for" typt is dus de nieuwe aangemaakte variabel.

Nu begrijp ik nog niet helemaal wat die variabel voor betekenis heeft ten opzichte van de input -> word.

Dus om op je opdracht terug te komen, loop er eens doorheen, begrijp ik denk ik het eerste nog niet helemaal zoals ik zou moeten

for X in Y, is zogehete "syntax" sugar. het doet in principe hetzelfde als een normale for loop, enkel is je index variabele (X) een onderdeel van de collectie (Y).

stel je voor dat je een lijst hebt van strings, dan is Y de lijst, en X iedere loop een string uit die lijst
stel je hebt een dictionary, is Y de dictionary, en X een keyvaluepair uit die dictionary.

in feite is een string eigenlijk een lijst van karakters

[ Voor 3% gewijzigd door leverage010 op 01-05-2019 14:08 ]

[thimo1]

Een string kan je in Python ook benaderen alsof het is list is. Dat is ook wat er gebeurt als je er met een for loop doorheen bladert.

Kijk de volgende keer wanneer je iets niet helemaal begrijpt in de python documentatie:
https://docs.python.org/3/tutorial/index.html

Daar wordt alles erg duidelijk uitgelegd.

[ Voor 40% gewijzigd door thimo1 op 01-05-2019 14:19 . Reden: Link naar documentatie toegevoegd ]

[Mugwump]

flugelisoke schreef op woensdag 1 mei 2019 @ 13:56:
[...]


Het volgende verwart me nog een beetje:

for letter in word:


Ik begrijp dat er met for een variabel wordt aangemaakt, het woord wat je na "for" typt is dus de nieuwe aangemaakte variabel.

Nu begrijp ik nog niet helemaal wat die variabel voor betekenis heeft ten opzichte van de input -> word.

Dus om op je opdracht terug te komen, loop er eens doorheen, begrijp ik denk ik het eerste nog niet helemaal zoals ik zou moeten

Dat is niet helemaal volledig wat er gebeurt. For is een loop. 'for x in y' betekent: "herhaal deze code voor alle waarden x in y". Y kan een lijstje van dingen zijn of zoals in dit geval een 'woord' wat weer een lijstje van letters is.

Het verschil gedrag dat je hier ziet heeft betrekking op "deze code" in "Herhaal deze code". Ik vind Python voor beginners ook heel erg verwarrend omdat in Python inspringen effect heeft op de uitvoer van code. Als je in een wat meer van C afgeleide taal zoiets zou doen, dan krijg je:

code:

for (letter in word) {
  if(letter == 'a') {
    continue;
  }
  else {
    print(letter)
  }
}

Hier zie je door de haakjes duidelijk dat het hele stuk 'binnen de for loop' valt. Doe je daarentegen het volgende:

code:

for (letter in word) {
  if(letter == 'a') {
    continue;
  } 
}

else {
    print(letter)
}

Dan zie je duidelijk dat de else buiten de for loop valt (al mag zo'n geïsoleerde else vaak niet eens).

In Python gebruik je dus geen haakjes om aan te geven waar een for loop of een if statement begint en ophoudt, maar laat je de code een niveau dieper inspringen en aan het eind weer een niveau minder diep.

[Jaap-Jan]

offtopic:
Nooit geweten dat Python een for/else- loop had

[CurlyMo]

Jaap-Jan schreef op woensdag 1 mei 2019 @ 14:47:

offtopic:
Nooit geweten dat Python een for/else- loop had

Dit is precies wat ik bedoel. Wil je schrijven wat programmeurs in zijn algemeenheid snappen omdat het aansluit bij wat er in programmeerland gangbaar is, of wat alleen python programmeurs snappen. Python heeft de neiging dat laatste steeds meer te faciliteren. Ik ben er geen fan van.

[Gropah]

voor de mensen die ook zo verward naar 2x dezelfde code zaten te kijken, hierbij de eerste:

code:

word = input("Input a word: ")

# complete the for loop:
for letter in word:
    if letter == "a":
        continue
    elif letter == "e":
        continue
    elif letter == "i":
        continue
    elif letter == "o":
        continue
    elif letter == "u":
        continue
    else:
        print(letter)

en de tweede:

code:

word = input("Input a word: ")

# complete the for loop:
for letter in word:
    if letter == "a":
        continue
    elif letter == "e":
        continue
    elif letter == "i":
        continue
    elif letter == "o":
        continue
    elif letter == "u":
        continue
        
else:
    print(letter)

qua originele ts: het gros is hier als antwoord gegeven. Opdelen in problemen totdat je iets elementairs tegenkomt wat je uit kunt programmeren, vervolgens de delen aan elkaar zetten en voila. Maar dat lukt bijna nooit in 1x. Zeker niet in het begin. Iedereen ging door zo'n fase heen als waar jij nu in zit. Soms duurt dat lang, sommige zijn er met 2 dagen doorheen. Dat verschil is denk ik te verklaren met verschillende manieren van denken, waarbij de een makkelijker kan schakelen tussen het normale denkproces en het denkproces wat je nodig hebt bij programmeren.

[flugelisoke]

Gropah schreef op woensdag 1 mei 2019 @ 15:14:
voor de mensen die ook zo verward naar 2x dezelfde code zaten te kijken, hierbij de eerste:

code:

word = input("Input a word: ")

# complete the for loop:
for letter in word:
    if letter == "a":
        continue
    elif letter == "e":
        continue
    elif letter == "i":
        continue
    elif letter == "o":
        continue
    elif letter == "u":
        continue
    else:
        print(letter)

en de tweede:

code:

word = input("Input a word: ")

# complete the for loop:
for letter in word:
    if letter == "a":
        continue
    elif letter == "e":
        continue
    elif letter == "i":
        continue
    elif letter == "o":
        continue
    elif letter == "u":
        continue
        
else:
    print(letter)

qua originele ts: het gros is hier als antwoord gegeven. Opdelen in problemen totdat je iets elementairs tegenkomt wat je uit kunt programmeren, vervolgens de delen aan elkaar zetten en voila. Maar dat lukt bijna nooit in 1x. Zeker niet in het begin. Iedereen ging door zo'n fase heen als waar jij nu in zit. Soms duurt dat lang, sommige zijn er met 2 dagen doorheen. Dat verschil is denk ik te verklaren met verschillende manieren van denken, waarbij de een makkelijker kan schakelen tussen het normale denkproces en het denkproces wat je nodig hebt bij programmeren.

Misschien heel stom, maar zelfs bij het opdelen van problemen heb ik geen benul waar ik dan precies begin.

Wat is bijvoorbeeld het probleem, hoe schrijf ik het probleem op, wat schrijf ik dan precies op.. Daar zit dus een beetje mee.

[ Voor 3% gewijzigd door flugelisoke op 01-05-2019 15:17 ]

[leverage010]

flugelisoke schreef op woensdag 1 mei 2019 @ 15:16:
[...]


Misschien heel stom, maar zelfs bij het opdelen van problemen heb ik geen benul waar ik dan precies begin.

Wat is bijvoorbeeld het probleem, hoe schrijf ik het probleem op, wat schrijf ik dan precies op.. Daar zit dus een beetje mee.

als ik je de opdracht geef "bouw een houten hutje van 2 bij 2 meter met een puntig dak", waar begin je dan?
eerst kijk je of je de benodigheden hebt. dan kijk je welk proces je moet doorlopen om het tot een geheel te vormen.

Ik kan geen dak bouwen zonder muren
ik kan geen muren bouwen zonder fundering
fundering kan ik wel bouwen.
etc.

[Mugwump]

flugelisoke schreef op woensdag 1 mei 2019 @ 15:16:
[...]


Misschien heel stom, maar zelfs bij het opdelen van problemen heb ik geen benul waar ik dan precies begin.

Wat is bijvoorbeeld het probleem, hoe schrijf ik het probleem op, wat schrijf ik dan precies op.. Daar zit dus een beetje mee.

Het probleem is hier gewoon je opdracht. Vaak kun je in dit soort gevallen 'stapjes' vinden aan de hand van opsommingen. Je kunt ook kijken of je ergens herhaling (doe voor elke / iedere / enz) ziet of voorwaarden (indien / wanneer / als).

[XLord]

Zelf had ik tijdens mijn studie moeite met het vinden van een oplossing doordat ik vaak niet begreep wat ze nou wilde dat ik ging oplossen. En dan zit je te zoeken zonder dat je weet wat je nou eigenlijk zoekt.

Zodra ik ging werken had ik er eigenlijk geen last van, dus geef ook weer niet te snel op.

[CurlyMo]

XLord schreef op woensdag 1 mei 2019 @ 15:42:
Zelf had ik tijdens mijn studie moeite met het vinden van een oplossing doordat ik vaak niet begreep wat ze nou wilde dat ik ging oplossen. En dan zit je te zoeken zonder dat je weet wat je nou eigenlijk zoekt.

Zodra ik ging werken had ik er eigenlijk geen last van, dus geef ook weer niet te snel op.

Soms kan het ook zo zijn dat je denkt "Why the fuck willen ze dit met een continue statement oplossen", dan ben je misschien al te ver vooruit op de rest. Ook lastig inderdaad Dat had ik bijv. tijdens mijn opleiding. Opdracht: Ontwikkel een programma in pascal dat een poppetje uit een doolhof laat komen. Zoiets in ieder geval. Diezelfde avond had ik het antwoord gestuurd volgens een van de shortest path algoritmes. Stuurt de docent terug: "Je uitwerking klopt, maar hier stond 10 weken voor ". Toen had ik opeens vrij weinig om handen voor dat vak die 9 weken die volgde.

Ik vraag me dus inderdaad af waarom die continue nog los van het feit dat het goed is om te weten dat het bestaat. Niet om TS nog verder in de verwarring te brengen

Python:

word = input("Input a word: ")

# complete the for loop:
for letter in word:
    if letter in ["a", "e", "i", "o", "u"]:
        print(letter);

[BLACKfm]

Ik had een tijdje terug een familielid die een python kwestie had van school. Ik ben zelf wel redelijk bedreven in PHP, maar ik moest er haast een avondstudie van maken om een redelijk simpel vraagstuk (wat mij in PHP een stuk minder moeite had gekost) op te lossen.

Vanuit een aangeleverd tekstbestand (comma gescheiden gegevensbestand van GPS gegevens) moesten bepaalde gegevens (coordinaten) worden uitgefilterd van enkel bepaalde gegevens.
Je had voor het gemak 5 verschillende regels met informatie, en de gegevens die je wou hebben moest kon je halen uit regels die begonnen met een bepaald woord/code.

Ik kreeg het voor elkaar om een bestand in te lezen, de juiste regels te filteren en daarvan weer op het juiste punt de data te extraheren. Maar daar moest ik vervolgens weer een filtering in maken en vervolgens nog allemaal berekeningen mee doen... Dat was gewoon ondoenlijk voor mij.

Ik had wel een stappenplan uitgewerkt met wat ik moest doen

code:

# Lees een bestand in
  // Code
# Filter alleen de regels die je wilt zien
 // Code
# Filter uit die regel de informatie die je hebben wilt
 // Code
# Zet die gegevens in variabele
 // Code
# Ga met die gegevens berekeningen maken
 // Code
# Geef de uitkomsten hiervan goed weer
 // Code

En dat is dan globaal wat er moest gebeuren. En dan kende ik de taal nog niet eens, dus spelenderwijs werd die lijst eigenlijk heel erg uitgebreid.

Ik heb het idee dat je dan wel snel de basiscode onder de knie krijgt, als je aan het googlen slaat kom je veel basis regels tegen zoals

code:

Var1 = #antwoord_uit_filter1 # 4
Var2 = #antwoord_uit_filter2 # 2

// Berekening
Ant1 = Var1 * 0,25
Ant2 = Var2 * 0,5

Ant3 = Ant1 + Ant2

print(Ant3) # 2

Dit vind ik dan heel erg 'basic', maar laat wel duidelijk de stappen zien. Je weet (als je een beetje codetaal gegrijpt) wat wat doet.

Zou ik er van maken:

code:

print ((antwoord_uit_filter1 * 0,25) + (antwoord_uit_filter2 * 0,5)) # 2

Krijg je als het goed is hetzelfde antwoord (pin mij er niet op vast, ik heb python al weer ver achter mij gelaten...). De eerste optie is niet fout, maar als je die antwoorden (variabelen) later niet nodig hebt is het wel overbodige code.

En dan weet ik (denk ik te weten) wat bepaalde zaken doen. Het 'setten' van variabelen is een coding dingetje wat al heel bijzonder kan zijn en wat je daar allemaal mee kan (of moet) doen...


Ben verder ook van het weekend begonnen aan het programmeren van een Arduino nano clone... Hoeveel je daar mee kan k*tten om een simpel lampje te laten branden met een schakelaar. Al is dat niet zozeer een code kwestie (die veel weg heeft van PHP, wat ik prima begrijp), maar daar komt het hardware aspect ook nog eens bij kijken. Dan moet je weer op hele andere wijze met creatieve ideeën komen op coding gebied...

[ Voor 7% gewijzigd door BLACKfm op 01-05-2019 16:03 ]

[Mugwump]

CurlyMo schreef op woensdag 1 mei 2019 @ 15:52:
[...]

Soms kan het ook zo zijn dat je denkt "Why the fuck willen ze dit met een continue statement oplossen", dan ben je misschien al te ver vooruit op de rest. Ook lastig inderdaad Dat had ik bijv. tijdens mijn opleiding. Opdracht: Ontwikkel een programma in pascal dat een poppetje uit een doolhof laat komen. Zoiets in ieder geval. Diezelfde avond had ik het antwoord gestuurd volgens een van de shortest path algoritmes. Stuurt de docent terug: "Je uitwerking klopt, maar hier stond 10 weken voor ". Toen had ik opeens vrij weinig om handen voor dat vak die 9 weken die volgde.

Ik vraag me dus inderdaad af waarom die continue nog los van het feit dat het goed is om te weten dat het bestaat. Niet om TS nog verder in de verwarring te brengen

Python:

word = input("Input a word: ")

# complete the for loop:
for letter in word:
    if letter in ["a", "e", "i", "o", "u"]:
        print(letter);

Die doet juist het omgekeerde van wat er moet gebeuren.

[CurlyMo]

Mugwump schreef op woensdag 1 mei 2019 @ 16:11:
[...]


Die doet juist het omgekeerde van wat er moet gebeuren.

NOT

[flugelisoke]

Om even op een recente opdracht te komen:

Ik heb uiteindelijk de oplossing bekeken en nog begrijp ik hem niet helemaal eigenlijk. Ik betwijfel dan ook of ik er op dit moment überhaupt zelf achter was gekomen hoe het werkt.

Dit is de opdracht:

Scenario
Listen to our story: a boy and his father, a computer programmer, are playing with wooden blocks. They are building a pyramid. Their pyramid is a bit weird, as it is actually a pyramid-shaped wall - it's flat. The pyramid is stacked according to one simple principle: each lower layer contains one block more than the layer above.

The figure illustrates the rule used by the builders.




Your task is to write a program which reads the number of blocks the builders have, and outputs the height of the pyramid that can be built using these blocks.

Note: the height is measured by the number of fully completed layers - if the builders don't have a sufficient number of blocks and cannot complete the next layer, they finish their work immediately.

Test your code using the data we've provided.

Example input
6

Example output
Height of the pyramid: 3

Example input
20

Example output
Height of the pyramid: 5

Example input
1000

Example output
Height of the pyramid: 44

Example input
2

Example output
Height of the pyramid: 1


Dit is wat er al ingevuld staat:




Dit is de oplossing:




M.a.w. ik bezit momenteel niet de logica om te berekenen hoe die piramide is opgebouwd in Python taal of zo iets?

[ Voor 3% gewijzigd door flugelisoke op 01-05-2019 16:25 ]

[leverage010]

+= betekent tel het volgende bij de variabele op
-= betekent haal het volgende van de variabele af

x += 1
is hetzelfde als
x = x + 1

[Meekoh]

Wat is je vraag daarbij?
Opzich is het niet heel onlogisch. Je bouwt de piramide van boven naar onder. (inlayer is 1 want er moet minstens 1 blokje in een layer zitten) Dit is ook het deel wat het ook onlogisch kan maken, want meestal bouw je iets van onder naar boven, maar in dit geval is andersom makkelijker.
Zolang het aantal blokjes in een laag nog minder of gelijk is aan het aantal blokjes dat je op dat moment hebt, dan kun je nog blokjes plaatsen. Dus komt er een laag bij.
Bij iedere laag die je bouwt doe je de hoogte +1 (Dit is immers wat je moet rapporteren/uitpoepen), je laat het aantal blokjes afnemen met het aantal blokjes in een laag (want je hebt de laag immers geplaatst). Je blokjes voorraad neemt dus af. En als laatste moet je de volgende layer 1 blok meer laten zijn anders krijg je een toren ipv piramide.

edit: Wat velen ook zeggen en wat ik vroeger ook heb aangeleerd van collega devs, als je het niet snapt teken het uit. Knip desnoods vierkantjes uit en probeer zo de logica na te maken.

[ Voor 25% gewijzigd door Meekoh op 01-05-2019 16:41 ]

[flugelisoke]

leverage010 schreef op woensdag 1 mei 2019 @ 16:30:
+= betekent tel het volgende bij de variabele op
-= betekent haal het volgende van de variabele af

x += 1
is hetzelfde als
x = x + 1

De += weet ik gelukkig wel. Het is meer dat ik zelf de volgorde niet zie in de opdracht.

[leverage010]

flugelisoke schreef op woensdag 1 mei 2019 @ 16:36:
[...]


De += weet ik gelukkig wel. Het is meer dat ik zelf de volgorde niet zie in de opdracht.

Ken je de term "Rubber duck programming"? Dit is een methode om inzicht te krijgen in je code. Wat je in principe doet is 1 voor 1 over elke regel heen gaan om uitgebreid te vertellen wat er in die regel gebeurt.

voorbeeld:

1. number = 10
2.
3. while(number>8)
4. number -= 1
5.

in regel 1 declareert hij variabele "number", en zet de waarde daarvan naar 10
in regel 2 gebeurt niks
in regel 3, zegt hij dat hij een loop begint, en die draait zo lang number groter is dan 8
in regel 4, haalt hij 1 van number af
dan herhaalt hij weer naar 3
in regel 3 is number nu 9, en klopt de statement nog steeds dus gaan we verder in de loop
in regel 4 haalt hij 1 van number af
hij herhaalt weer
in regel 3 is number nu 8, en dus klopt de statement niet meer. we gaan verder
in regel 5 gebeurt er niks
we zijn klaar.

[Mugwump]

flugelisoke schreef op woensdag 1 mei 2019 @ 16:36:
[...]


De += weet ik gelukkig wel. Het is meer dat ik zelf de volgorde niet zie in de opdracht.

Als je kijkt naar je probleem hier dan is het 'Bepaal hoeveel lagen een pyramide als je X blokjes mag gebruiken'. Verder weet je dat elke laag 1 blokje meer bevat dan de laag erboven.
Als je zelf een blokkendoos zou pakken en je weet dat je ze zo moet neerleggen dat elke laag één blokje minder heeft dan de laag eronder, hoe zou je dan blokjes gaan leggen? Wat neem je als startpunt?

[flugelisoke]

Mugwump schreef op woensdag 1 mei 2019 @ 16:43:
[...]


Als je kijkt naar je probleem hier dan is het 'Bepaal hoeveel lagen een pyramide als je X blokjes mag gebruiken'. Verder weet je dat elke laag 1 blokje meer bevat dan de laag erboven.
Als je zelf een blokkendoos zou pakken en je weet dat je ze zo moet neerleggen dat elke laag één blokje minder heeft dan de laag eronder, hoe zou je dan blokjes gaan leggen? Wat neem je als startpunt?

Dan neem ik als startpunt het bovenste blokje van de pyramide en dan ga ik vervolgens zelf uit tellen hoeveel lagen ik kan maken met het aantal blokjes.

[Gropah]

flugelisoke schreef op woensdag 1 mei 2019 @ 16:24:
Om even op een recente opdracht te komen:

Ik heb uiteindelijk de oplossing bekeken en nog begrijp ik hem niet helemaal eigenlijk. Ik betwijfel dan ook of ik er op dit moment überhaupt zelf achter was gekomen hoe het werkt.

Dit is de opdracht:

Scenario
Listen to our story: a boy and his father, a computer programmer, are playing with wooden blocks. They are building a pyramid. Their pyramid is a bit weird, as it is actually a pyramid-shaped wall - it's flat. The pyramid is stacked according to one simple principle: each lower layer contains one block more than the layer above.

The figure illustrates the rule used by the builders.

[Afbeelding]


Your task is to write a program which reads the number of blocks the builders have, and outputs the height of the pyramid that can be built using these blocks.

Note: the height is measured by the number of fully completed layers - if the builders don't have a sufficient number of blocks and cannot complete the next layer, they finish their work immediately.

Test your code using the data we've provided.

Example input
6

Example output
Height of the pyramid: 3

Example input
20

Example output
Height of the pyramid: 5

Example input
1000

Example output
Height of the pyramid: 44

Example input
2

Example output
Height of the pyramid: 1


Dit is wat er al ingevuld staat:

[Afbeelding]


Dit is de oplossing:

[Afbeelding]


M.a.w. ik bezit momenteel niet de logica om te berekenen hoe die piramide is opgebouwd in Python taal of zo iets?

Met dit soort opdrachten ga ik vaak zelf met de hand aan de slag.

Ok, stel ik heb 6 blokjes, hoe ver kan ik komen. Eerste laag: 1 blok gebruikt, 2e laag: 2 extra gebruikt met 3 in totaal. 3e laag: 3 extra gebruikt met 6 in het totaal. Klaar!

Ok, wat voor ritme/regelmaat zit hier in? Wat kan ik zo snel ontdekken?

Je bouwt laag voor laag. Dus dat zal wel een for of while lus moeten worden. Weet ik precies wanneer ik moet stoppen? Nee, dan waarschijnlijk een while lus.

Ok, welke dingen zijn aan elkaar gekoppeld? zijn er dingen die elke ronde van een lus veranderen? Ja, de hoogte, het aantal stenen voor de laag en het aantal stenen gebruikt. Dan moeten die dus in de lus worden aangepast.

Vervolgens pak ik mijn eerdere handmatige berekening er bij. Hoe worden ze aangepast? Zit er een volgorde in? Hoogte gaat altijd 1 omhoog. Aantal stenen gaat met hoogte, na update, omlaag. Dus ik moet eerst de hoogte ophogen en dan het aantal stenen verlagen. En dit gaat door zolang als dat er meer blokken zijn dan dat de volgende laag groot is.

Ja, dat is een iets andere lus dan het gegeven antwoord, maar hetzelfde antwoord word wel bereikt.

[eric.1]

flugelisoke schreef op woensdag 1 mei 2019 @ 16:24:
The pyramid is stacked according to one simple principle: each lower layer contains one block more than the layer above.

Your task is to write a program which reads the number of blocks the builders have, and outputs the height of the pyramid that can be built using these blocks.

Note: the height is measured by the number of fully completed layers - if the builders don't have a sufficient number of blocks and cannot complete the next layer, they finish their work immediately.

M.a.w. ik bezit momenteel niet de logica om te berekenen hoe die piramide is opgebouwd in Python taal of zo iets?

De logica zit eigenlijk compleet verborgen in de opdracht. Je moet het er alleen uit weten te vissen .

Als je die uitwerking (of jouw poging) wilt debuggen, kun je alle variabelen printen - dan kan je volgen wat er gebeurt.

[Mugwump]

flugelisoke schreef op woensdag 1 mei 2019 @ 16:47:
[...]


Dan neem ik als startpunt het bovenste blokje van de pyramide en dan ga ik vervolgens zelf uit tellen hoeveel lagen ik kan maken met het aantal blokjes.

Precies, dus je begint met het leggen van 1 blokje. Daarna kun je het in nog wat kleinere stapjes doen. Wat doe je als je de bovenste laag hebt gelegd? Kijken of je nog genoeg blokjes hebt om een laag van 2 kan neerleggen. Kan dat, dan heb je twee laagjes, zo niet dan heb je je antwoord (maar 1 laagje). Dit herhaal je net zo lang tot je niet genoeg blokjes meer hebt.

Daar heb je eigenlijk al je stapjes.

[flugelisoke]

Mugwump schreef op woensdag 1 mei 2019 @ 16:59:
[...]


Precies, dus je begint met het leggen van 1 blokje. Daarna kun je het in nog wat kleinere stapjes doen. Wat doe je als je de bovenste laag hebt gelegd? Kijken of je nog genoeg blokjes hebt om een laag van 2 kan neerleggen. Kan dat, dan heb je twee laagjes, zo niet dan heb je je antwoord (maar 1 laagje). Dit herhaal je net zo lang tot je niet genoeg blokjes meer hebt.

Daar heb je eigenlijk al je stapjes.

Heel duidelijk en erg simpel vertaald, wat me vervolgens nog een beetje meer frustreert dat ik er niet eens zelf op ben gekomen

Is dat nou precies die vaardigheid die je kunt trainen door vaak met dit soort situaties om te gaan?

[ Voor 7% gewijzigd door flugelisoke op 01-05-2019 17:04 ]

[.oisyn]

vj_slof schreef op woensdag 1 mei 2019 @ 12:32:
Helemaal over een andere boeg gooien: jointje roken, paddo's eten of andere drugs (legaal of illegaal, whatever je ding is....)

Steve Jobs, Bill Gates, Elon Musk... just to name a few.

Wat een enorm slecht advies... Programmeren is logica, en dat is het eerste wat je verliest bij de meeste geestverruimende middelen. Dat de personen die je noemt recreatief drugs gebruiken of hebben gebruikt, impliceert nog niet dat ze daardoor zijn gekomen waar ze zijn.

[ Voor 13% gewijzigd door .oisyn op 01-05-2019 17:09 ]

[Mugwump]

flugelisoke schreef op woensdag 1 mei 2019 @ 17:03:
[...]


Heel duidelijk en erg simpel vertaald, wat me vervolgens nog een beetje meer frustreert dat ik er niet eens zelf op ben gekomen

Ach, zoals Johan Cruyff al zei: "Je gaat het pas zien als je het doorhebt".
Het is echt een kwestie van oefening baart kunst. Ik heb zelf een WO opleiding technische informatica gevolgd en inmiddels een jaar of 15 werkervaring dus dat is ook niet te vergelijken met jouw situatie.

[flugelisoke]

Mugwump schreef op woensdag 1 mei 2019 @ 17:10:
[...]


Ach, zoals Johan Cruyff al zei: "Je gaat het pas zien als je het doorhebt".
Het is echt een kwestie van oefening baart kunst. Ik heb zelf een WO opleiding technische informatica gevolgd en inmiddels een jaar of 15 werkervaring dus dat is ook niet te vergelijken met jouw situatie.

Ik ben nu 31 en ik doe dit nu voor het eerst ook, ik heb geen vooropleiding in die richting omdat ik heb gewerkt als taxichauffeur. Puur vanwege het feit dat ik vroeger geen bal om school gaf en daardoor geen fatsoenlijk diploma heb behaald ooit.

Nu juist, ben ik zeer leergierig.

Maar om een lang verhaal kort te maken, ik heb eigenlijk nooit wiskundig / probleemoplossend hoeven denken, wellicht is dat ook het ding waarom ik er nu wat meer moeite mee heb. Dat ik die vaardigheid eerst moet leren

Ik probeer het voor mezelf ook een beetje op een rijtje te zetten, want ik kan er niet precies de vinger op leggen waar ik nou exact moeilijkheden mee heb, dat ben ik zelf nog aan het uitvinden en zelfs dat kan soms erg lastig zijn.

[ Voor 11% gewijzigd door flugelisoke op 01-05-2019 17:15 ]

[Meekoh]

flugelisoke schreef op woensdag 1 mei 2019 @ 17:14:
[...]


Ik ben nu 31 en ik doe dit nu voor het eerst ook, ik heb geen vooropleiding in die richting omdat ik heb gewerkt als taxichauffeur. Puur vanwege het feit dat ik vroeger geen bal om school gaf en daardoor geen fatsoenlijk diploma heb behaald ooit.

Nu juist, ben ik zeer leergierig.

Maar om een lang verhaal kort te maken, ik heb eigenlijk nooit wiskundig / probleemoplossend hoeven denken, wellicht is dat ook het ding waarom ik er nu wat meer moeite mee heb. Dat ik die vaardigheid eerst moet leren

Als Taxi chauffeur moet je ook probleemoplossend denken.
Hoe kom ik van A naar B:
Is er file?
Nee dan snelweg.
Wel File, dan binnendoor.
etc.

Kook je weleens volgens een recept? Dat is in principe hetzelfde als de pythoncode.
IF water kookt, THEN doe de rijst erin.
WHILE resterende kooktijd niet gelijk aan 0 seconden/minuten THEN wacht totdat de wekker afgaat.
ELSE afgieten
etc,

[ Voor 12% gewijzigd door Meekoh op 01-05-2019 17:19 ]

[flugelisoke]

Meekoh schreef op woensdag 1 mei 2019 @ 17:17:
[...]

Als Taxi chauffeur moet je ook probleemoplossend denken.
Hoe kom ik van A naar B:
Is er file?
Nee dan snelweg.
Wel File, dan binnendoor.
etc.

In dat opzicht heb je gelijk, maar dat beperkt zich tot het basale. Zo zou je inderdaad een bezoek aan de supermarkt ook kunnen zien wanneer een product niet voorradig is, oh de kip is op... Dan kan ik geen kipsaté maken, dan zal ik op zoek moeten gaan naar een alternatief.

Dus in dat opzicht heb je volledig gelijk, maar dat zijn toch de basale daily probleempjes waar je eigenlijk niet over nadenkt.

[Freeaqingme]

flugelisoke schreef op woensdag 1 mei 2019 @ 17:19:
[...]


In dat opzicht heb je gelijk, maar dat beperkt zich tot het basale. Zo zou je inderdaad een bezoek aan de supermarkt ook kunnen zien wanneer een product niet voorradig is, oh de kip is op... Dan kan ik geen kipsaté maken, dan zal ik op zoek moeten gaan naar een alternatief.

Dus in dat opzicht heb je volledig gelijk, maar dat zijn toch de basale daily probleempjes waar je eigenlijk niet over nadenkt.

Maar, waarom zijn die dingen die je noemt basaal? Da's omdat je moeder je meenam naar de supermarkt toen je 2 jaar oud was, en je zo af en toe mocht helpen met 't bakken van koekjes.

Qua programmeren is 99% van de dingen die je doet ook een kwestie van 't stapelen van simpele blokjes totdat je een werkende combinatie hebt. Alleen, je moeder heeft je daar nooit mee geholpen vanaf je tweede, dus kost 't ff iets meer tijd om er in te komen. Daarna is 't als het een beetje meezit even basaal als boodschappen doen.

Edit: @.oisyn hieronder: Ik mis nog wat informatie in je vraag. Hoe groot is de lijst met elementen doorgaans, kunnen daar dubbele elementen in zitten, en kunnen er gaten in de reeks zitten of is deze aaneengesloten?

[ Voor 9% gewijzigd door Freeaqingme op 01-05-2019 17:42 ]

[.oisyn]

Zolang er geen enkele vorm van herhaling in zit kun je het ook nauwelijks programmeren noemen. Dan is het gewoon het afwerken van een script. En het is juist het vinden van patronen waar over het algemeen de "moeilijkheid" zit bij mensen die er niet echt aanleg voor hebben .

Een fundamenteel voorbeeld is het sorteren van een lijst met elementen. Hoe zou je dat doen, zonder voorkennis van sorteeralgoritmes en uiteraard zonder het gebruiken van de standaard sorteerfunctionaliteit in je programmeertaal?

Freeaqingme schreef op woensdag 1 mei 2019 @ 17:40:
Edit: @.oisyn hieronder: Ik mis nog wat informatie in je vraag. Hoe groot is de lijst met elementen doorgaans, kunnen daar dubbele elementen in zitten, en kunnen er gaten in de reeks zitten of is deze aaneengesloten?

Hiermee ben je de boel wel heel erg aan het concretizeren en is misschien ook wel tekenend voor de reden waarom je dit topic startte. Maar goed, tegenvraag: maken die dingen uit? Jij bent de TS helemaal niet

[ Voor 34% gewijzigd door .oisyn op 01-05-2019 17:58 ]

[Philip Ross]

In het geval van de pyramide heb je 2 opties om het probleem op te lossen. De eerste ben je intussen achter.

De tweede optie komt kijken als je naar extreem grote getallen gaat en een loop daar doorheen dus veel tijd gaat kosten.

Die optie is: Kan ik het probleem reduceren tot een wiskundige formule?

Het antwoord is ja, dat kan.

We noemen het aantal blokjes in de onderste laag B. (breedte)
Het aantel lagen noemen we H. (hoogte)

Bij deze pyramide zijn B en H altijd aan elkaar gelijk.

Het leuke aan pyramides is dat je door steeds 2 lagen te combineren je altijd een vast aantal blokjes krijgt. Namelijk de helft van de onderste laag + 1. Bij een oneven aantal lagen kan je alle lagen gelijk maken aan de breedte van de middelste laag en bij een even aantal lagen kan je de helft van het aantal lagen creeeren maar dan allemaal met de breedte van de onderste laag + 1.

Dan krijgen we dus altijd een situatie waarbij het aantel blokjes gelijk is aan 1/2 x H x (B+1) (even aantal lagen) of H x 1/2 x (B + 1). Beide formules zijn hetzelfde en sinds H en B ook gelijk zijn hou je het volgende over:

We noemen het aantal blokjes nu even N.

N = 1/2 x H x (H + 1) = 1/2 H² + 1/2 H.
Dit kunnen we reduceren tot 1/2 H² + 1/2 H - N = 0 wat we kunnen oplossen met de ABC formule Wikipedia: Wortelformule

Via die formule krijgen we 2 antwoorden (we nemen altijd de positieve) en ronden die naar beneden af omdat we gehele lagen willen (en dus halve lagen niet mee tellen).

Via deze weg heb je altijd in een beperkt aantal berekeningen gevonden hoeveel lagen je kan maken.

Nu is dit veel te ingewikkeld om voor een dergelijk kleine opdracht te doen maar wilde voor de volledigheid wel even wijzen op deze aanpak van problemen.

EDIT: Ik weet dat dit soort kwadratische formules oplossen niet altijd een correcte oplossing is maar ik wilde vooral het principe van reduceren tot een wiskundige formule uitleggen.

[ Voor 5% gewijzigd door Philip Ross op 01-05-2019 18:10 ]

[flugelisoke]

Ben nu een beetje aan het spelen met if, else.

Opzich begrijp ik die basis wel en heb zelf een simpel programmaatje gemaakt met als voorbeeld toeslag en inkomen. Nu heb ik geen benul van toeslagen, maar het is maar een voorbeeld..

jaarinkomen = int(input("Wat is uw jaarinkomen? "))

if jaarinkomen < 20000:
toeslag = 400
if jaarinkomen >= 20000:
toeslag = 200
if jaarinkomen >= 50000:
toeslag = 0


print("Uw toeslag per maand is",toeslag,"euro")

toeslag = toeslag * 0.20


if toeslag == 0:
print("U ontvangt geen toeslag, dus U hoeft geen belasting te betalen over het niet te ontvangen bedrag")

else:
print("U betaald op jaarlijkse basis",toeslag,"euro belasting over de toeslag")


Dat soort dingen kan ik dus al wel toepassen omdat ik dit uit het antwoord heb geleerd van een opgave die ik zelf eerst niet wist op te lossen.

[Reptile209]

flugelisoke schreef op woensdag 1 mei 2019 @ 18:03:
[...]
toeslag = toeslag * 0.20


if toeslag == 0:
print("U ontvangt geen toeslag, dus U hoeft geen belasting te betalen over het niet te ontvangen bedrag")

else:
print("U betaald op jaarlijkse basis",toeslag,"euro belasting over de toeslag")


Dat soort dingen kan ik dus al wel toepassen omdat ik dit uit het antwoord heb geleerd van een opgave die ik zelf eerst niet wist op te lossen.

Tip: variabelen zijn gratis (nu dan, vroegâh niet), dus gebruik ze. Als je een toeslag berekent en in variabele 'toeslag' zet, waarom maak je dan niet een nieuwe variabele voor het opslaan van de belasting? Dat is leesbaarder, en je kunt zelfs een zin afdrukken als: "Over een toeslag van 100 euro betaalt u 20 euro belasting.", want je hebt alle informatie nog! Dit itt je voorbeeld, waar je door de laatste berekening het bedrag van je toeslag kwijtraakt.

Dit soort dingen kunnen je misschien ook helpen om het proces in je hoofd te sturen.

[flugelisoke]

Reptile209 schreef op woensdag 1 mei 2019 @ 18:35:
[...]

Tip: variabelen zijn gratis (nu dan, vroegâh niet), dus gebruik ze. Als je een toeslag berekent en in variabele 'toeslag' zet, waarom maak je dan niet een nieuwe variabele voor het opslaan van de belasting? Dat is leesbaarder, en je kunt zelfs een zin afdrukken als: "Over een toeslag van 100 euro betaalt u 20 euro belasting.", want je hebt alle informatie nog! Dit itt je voorbeeld, waar je door de laatste berekening het bedrag van je toeslag kwijtraakt.

Dit soort dingen kunnen je misschien ook helpen om het proces in je hoofd te sturen.

Idd! Heb er meteen een beeld bij en kan het ook toepassen Zal eens het e.e.a. proberen!

[CurlyMo]

@flugelisoke

Een deel van het debugging leerproces is je code netjes opmaken. Niet alleen voor jezelf maar ook als je erover communiceert met anderen. Zet dus aub je code in code tags en repareer je vorige reacties om alsnog je code in code tags te zetten.

[proef]

Om nog maar eens Von Neuman's quote erbij te halen die mij geïnspireerd heeft (en programmeren is net wiskunde): "Young man, in mathematics you don't understand things. You just get used to them"

[eric.1]

flugelisoke schreef op woensdag 1 mei 2019 @ 18:03:
if jaarinkomen < 20000:
toeslag = 400
if jaarinkomen >= 20000:
toeslag = 200
if jaarinkomen >= 50000:
toeslag = 0

Niet echt handig om zo te doen:) als je 3e if waar is, blijft de 2e ook waar. Die toeslag wordt wel 0, maar eerst ga je volgens mij door die tweede IF-statement heen. Niet erg in dit voorbeeld maar als je wat spannendere dingen doet kan dat voor vreemde resultaten zorgen.

[ Voor 31% gewijzigd door eric.1 op 01-05-2019 22:19 ]

[Aragnut]

Op mn werk maak ik de nodige scripts om het mezelf makkelijker te maken. Vaak begint dit met uitzoeken hoe iets moet, dam realiseren dat ik tig keer bijna hetzelfde doe, dam uitschrijven wat ik nu precues doe en dan (het meeste werk): oplossen van syntax errors en lege waardes.

Van wat ik begrijp loop je er tegen aan om de discrete acties die nodig zijn voor het resultaat te definiëren/ontdekken.

Geen echt idee hoe je het traint, maar ik doe van nature juist acties door discrete stappen te onthouden eerst. Zoals van baan wisselen: discreet is dat spiegel binnen, spiegel buiten, over de schouder, knipperlicht en gaan. Om stapje moeilijker te maken: wat als er een auto naast je zit?

Mogelijk helpt het om eens alledaagse dingen die je doet te ontleden in stapjes, en opschrijven alsof je iemand moet uitleggen hoe je het doet.

Wellicht een leuke: schrijf stap voor stap uit wat je doet om van een melkbus met 10 tennisballen zo veel mogelijk door een gat in een plank te krijgen 2 meter verderop.

[Dets]

ThomasG schreef op dinsdag 30 april 2019 @ 20:05:
Wat ik zelf vaak merk als programmeurs niet weten waar ze moeten beginnen, is dat ze het probleem wat ze moeten gaan oplossen niet begrijpen, of in ieder geval niet goed genoeg begrijpen. Programmeren is in feiten niets anders dan het probleem opdelen in kleine stukken, en deze stap voor stap op te lossen; en daarmee het grote probleem te op lossen.

De eerste stap is dus het analyzeren van het probleem, en het vervolgens opdelen in kleinere problemen; en die zijn vaak ook weer op te delen in kleinere problemen. Bij het geheel weet je niet waar je moet beginnen, bij de kleinere problemen is het veel duidelijker hoe en wat. In het begin kan dat vrij lastig zijn, maar naarmate je ervaring krijgt wordt het steeds gemakkelijker.

Helemaal eens. Ik ben al veel te lang van school maar wat is er overgebleven van ontwerpen? Het probleem uitschrijven, analyseren, tekenen? Wie kent nog Nassi-Shneiderman, flowcharts, JSP, UML, ... Allemaal dingen die je helpen/dwingen het probleem op te breken. Ik teken nog steeds af en toe om duidelijk te krijgen wat er moet gebeuren, soms in powerpoint, soms in Visio, soms in een UML-tool, soms met een collega op een whiteboard. Het helpt enorm om het probleem op te breken en er losse puzzeltjes van te maken. In ieder geval begint programmeren meestal niet met het het openen van je favoriete editor voor het inkloppen van de code.

[CurlyMo]

Dets schreef op donderdag 2 mei 2019 @ 08:10:
[...]

Helemaal eens. Ik ben al veel te lang van school maar wat is er overgebleven van ontwerpen? Het probleem uitschrijven, analyseren, tekenen? Wie kent nog Nassi-Shneiderman, flowcharts, JSP, UML, ... Allemaal dingen die je helpen/dwingen het probleem op te breken. Ik teken nog steeds af en toe om duidelijk te krijgen wat er moet gebeuren, soms in powerpoint, soms in Visio, soms in een UML-tool, soms met een collega op een whiteboard. Het helpt enorm om het probleem op te breken en er losse puzzeltjes van te maken. In ieder geval begint programmeren meestal niet met het het openen van je favoriete editor voor het inkloppen van de code.

Genoeg plekken meegemaakt waar er belangrijke databases werden onderhouden, denk aan scope bankwezen, maar waar er geen ERD's werken gemaakt

[Ernemmer]

@flugelisoke waar doe je de opleiding? En is dit echt een Python opleiding of een algemene programmeer opleiding?

[flugelisoke]

Ernemmer schreef op donderdag 2 mei 2019 @ 08:24:
@flugelisoke waar doe je de opleiding? En is dit echt een Python opleiding of een algemene programmeer opleiding?

Het is echt een specifieke Python opleiding door een opleider die is gespecialiseerd in IT training / omscholing.

[Dets]

CurlyMo schreef op donderdag 2 mei 2019 @ 08:15:
[...]

Genoeg plekken meegemaakt waar er belangrijke databases werden onderhouden, denk aan scope bankwezen, maar waar er geen ERD's werken gemaakt

Wel herkenbaar en daar bovenop "er staat toch commentaar in de code"... om vervolgens onderstaande constructie tegen te komen:
if "het geval waarvoor ik de code moest maken" then
<Mijn code>
else
<Dit stuk code. Het is door mijn voorganger gemaakt, geen idee wat het precies doet maar het werkt.>
end if

[Mugwump]

Dets schreef op donderdag 2 mei 2019 @ 08:10:
[...]

Helemaal eens. Ik ben al veel te lang van school maar wat is er overgebleven van ontwerpen? Het probleem uitschrijven, analyseren, tekenen? Wie kent nog Nassi-Shneiderman, flowcharts, JSP, UML, ... Allemaal dingen die je helpen/dwingen het probleem op te breken. Ik teken nog steeds af en toe om duidelijk te krijgen wat er moet gebeuren, soms in powerpoint, soms in Visio, soms in een UML-tool, soms met een collega op een whiteboard. Het helpt enorm om het probleem op te breken en er losse puzzeltjes van te maken. In ieder geval begint programmeren meestal niet met het het openen van je favoriete editor voor het inkloppen van de code.

In veel projecten sta ik meer tijd voor een whiteboard dan dat ik achter een toetsenbord code zit te kloppen. Als we er dan eenmaal uit zijn even een fotootje en aan requirements / documentatie hangen.

[mark0172]

Wat mij het meeste heeft geholpen is het ontleden van opdrachten, zo ver mogelijk.Op het HBO kregen wij toetsen (zowel Java als Python) met als opdracht (bijvoorbeeld) programmeer een darts spelletje wat zichzelf uitspeelt met 2 spelers.

Dan ga je beginnen met de opdracht te ontleden, elk spel heeft 2 spelers, met elk 3 pijlen. de pijlen kunnen landen op 1 tot en met 20 en bullseye... ze kunnen dubbel, trippel, single of mis gooien.... en zo ga je steeds verder met het ontleden van de opdracht... Dit inzicht heeft mij veel geholpen bij verdere opdrachten en het maken van toetsen van deze vorm.

[DJMaze]

flugelisoke schreef op dinsdag 30 april 2019 @ 19:37:
Is logisch / abstract denken voor programmeren iets wat je standaard gewoon kan of niet.

Of is dit een eigenschap die je kunt aanleren?

Stap even uit de zone.

"Er zijn meerdere wegen naar Rome"...
- google maps
- routeplanner
- stratenboek
- compas
- gps
- vliegtuig

Je zal vast denken.. "ja, duh" want je kent ze!
Maar wat nou als je die niet kende, wat ging je dan doen?
- Informatie inwilligen?
- Staren naar je computer scherm met het gevoel "ik moet iets doen in Python!"
- op tweakers vragen "kan ik dit aanleren?"

Rome is een situatie die je kent, Python nog niet.
De vraag is: kan je Python net zo snel leren als de mogelijkheden naar Rome?

En dan vooral: kan je dit zelf "autodidactisch"?

Daarna begin je aan de Ikea kast...

[flugelisoke]

DJMaze schreef op donderdag 2 mei 2019 @ 15:27:
[...]

Stap even uit de zone.

"Er zijn meerdere wegen naar Rome"...
- google maps
- routeplanner
- stratenboek
- compas
- gps
- vliegtuig

Je zal vast denken.. "ja, duh" want je kent ze!
Maar wat nou als je die niet kende, wat ging je dan doen?
- Informatie inwilligen?
- Staren naar je computer scherm met het gevoel "ik moet iets doen in Python!"
- op tweakers vragen "kan ik dit aanleren?"

Rome is een situatie die je kent, Python nog niet.
De vraag is: kan je Python net zo snel leren als de mogelijkheden naar Rome?

En dan vooral: kan je dit zelf "autodidactisch"?

Daarna begin je aan de Ikea kast...

Hmm.. Interessante benadering! Die laat ik even inwerken

[leverage010]

Als ik eerlijk met je moet zijn was ik ook begonnen met python, en na een paar maanden met python bezig geweest te zijn en door ging met java stond ik op een dag op en opeens klikte alles. Dat is geen product van goed geluk of mijn "supergeweldige brein" ofzo...Dat was puur het product van gewenning. Continu jezelf confronteren met concepten die niet bekend zijn voor je, en je er in blijven verdiepen is hoe je abstracte kennis tot je neemt.

[flugelisoke]

leverage010 schreef op vrijdag 3 mei 2019 @ 11:20:
Als ik eerlijk met je moet zijn was ik ook begonnen met python, en na een paar maanden met python bezig geweest te zijn en door ging met java stond ik op een dag op en opeens klikte alles. Dat is geen product van goed geluk of mijn "supergeweldige brein" ofzo...Dat was puur het product van gewenning. Continu jezelf confronteren met concepten die niet bekend zijn voor je, en je er in blijven verdiepen is hoe je abstracte kennis tot je neemt.

Dat merk ik nu ook steeds meer wanneer ik hoofdstukken van het begin weer doorneem, dingen waarbij ik toen dacht dat ze misschien niet zo heel belangrijk waren, onbewust of niet... Vallen nu wel op z'n plek.


Om even terug te komen op de pyramide opdracht, ik heb de oplossing erbij gepakt om er van te leren maar het wil niet binnen komen.

Dit is de oplossing:

# Sample Solution

blocks = int(input("Enter the number of blocks: "))
height = 0
inlayer = 1
while inlayer <= blocks:
........height += 1
........blocks -= inlayer
........inlayer += 1

print("Height of the pyramid:",height)


Het dringt eigenlijk niet goed tot me door omdat ik het nog niet zie ondanks dat dit de oplossing is


Als ik op papier de loop doorloop dan komt het erg vreemd uit en klopt het niet, ik heb het volgende geschreven.


Startwaarde met 10 blokken wanneer ik de loop doorloop:

(Ieder cijfer na het streepje is de volgende loop)

block = 10 - 9 - 8 - 7 - 6 - 5 - 4 - 3 - 2 - 1 - 0
inlayer = 1 - 2 - 3 - 4 - 5 - 6 - 7 - 8 - 9 - 10 -11
height = 0 - 1 - 2 - 3 - 4 - 5 - 6 -7 - 8 - 9 - 10

[ Voor 38% gewijzigd door flugelisoke op 03-05-2019 15:31 ]

[Freeaqingme]

flugelisoke schreef op vrijdag 3 mei 2019 @ 13:46:
Als ik op papier de loop doorloop dan komt het erg vreemd uit en klopt het niet, ik heb het volgende geschreven.


Startwaarde met 10 blokken wanneer ik de loop doorloop:

(Ieder cijfer na het streepje is de volgende loop)

block = 10 - 9 - 8 - 7 - 6 - 5 - 4 - 3 - 2 - 1 - 0
inlayer = 1 - 2 - 3 - 4 - 5 - 6 - 7 - 8 - 9 - 10 -11
height = 0 - 1 - 2 - 3 - 4 - 5 - 6 -7 - 8 - 9 - 10

Als het programmeren eenmaal een beetje doorhebt, dan komt daar ook het debuggen bij kijken: je verwacht dat je code A doet, maar in werkelijkheid doet 't B. Waarom gaat dat zo?

Heel concreet kan je je afvragen of $inlayer continue 1 is, en of het dus klopt dat $block iedere keer maar met 1 af neemt.

[BLACKfm]

Ik weet niet of je de engelse taal machtig bent, maar je kunt variabelen natuurlijk ook een voor jezelf logische naam geven.

Of zet comments achter je code om voor jezelf duidelijk te maken wat elke regel nou precies doet.

Je 'uitwerking op papier' kan volgens mij ook niet, want de 'while' loopt door zolang de 'inlayer' kleiner is dan het aantal 'blocks'

Dan zou die dus hier moeten stoppen:

block = 10 - 9 - 8 - 7 - 6
inlayer = 1 - 2 - 3 - 4 - 5
height = 0 - 1 - 2 - 3 - 4

Want hierna is het aantal 'blocks' 5, maar de inlayer 6. Dan klopt de 'while' niet meer (want inlayer <= blocks) en gaat die verder met de code, het geven van de waarde van 'height'.

En zou die dus moeten aangeven dat de hoogte met 10 blokken 4 rijen moet zijn.

Als je het zo bekijkt is het heel logisch (vind ik )

[ Voor 13% gewijzigd door BLACKfm op 03-05-2019 15:54 ]

[flugelisoke]

BLACKfm schreef op vrijdag 3 mei 2019 @ 15:52:
Ik weet niet of je de engelse taal machtig bent, maar je kunt variabelen natuurlijk ook een voor jezelf logische naam geven.

Of zet comments achter je code om voor jezelf duidelijk te maken wat elke regel nou precies doet.

Je 'uitwerking op papier' kan volgens mij ook niet, want de 'while' loopt door zolang de 'inlayer' kleiner is dan het aantal 'blocks'

Dan zou die dus hier moeten stoppen:

block = 10 - 9 - 8 - 7 - 6
inlayer = 1 - 2 - 3 - 4 - 5
height = 0 - 1 - 2 - 3 - 4

Want hierna is het aantal 'blocks' 5, maar de inlayer 6. Dan klopt de 'while' niet meer (want inlayer <= blocks) en gaat die verder met de code, het geven van de waarde van 'height'.

En zou die dus moeten aangeven dat de hoogte met 10 blokken 4 rijen moet zijn.

Als je het zo bekijkt is het heel logisch (vind ik )

Oja natuurlijk.... inlayer <= blocks

[BLACKfm]

flugelisoke schreef op vrijdag 3 mei 2019 @ 15:56:
[...]
Oja natuurlijk.... inlayer <= blocks

. Vrij vertaald zegt die 'while' regel:

code:

zolang de 'inlayer' waarde kleiner is dan, of gelijk aan, de waarde van 'blocks'
   voer ik >deze< code uit

en zodra de 'zolang' niet meer klopt ga ik het antwoord geven van 'hoogte'

Nadeel van Python hierin vind ik persoonlijk dat je eigenlijk lastig kan zien wat nu bij het 'while' deel hoort.
Dat wordt enkel bepaald door de inspringing van de code die er onder staat blijkbaar.
Bij andere talen is dat (vind ik) een stuk duiderlijker.

[ Voor 29% gewijzigd door BLACKfm op 05-05-2019 12:56 ]

[Philip Ross]

BLACKfm schreef op vrijdag 3 mei 2019 @ 15:52:
Je 'uitwerking op papier' kan volgens mij ook niet, want de 'while' loopt door zolang de 'inlayer' kleiner is dan het aantal 'blocks'

Dan zou die dus hier moeten stoppen:

block = 10 - 9 - 8 - 7 - 6
inlayer = 1 - 2 - 3 - 4 - 5
height = 0 - 1 - 2 - 3 - 4

correct. Al zou blocks ook sneller af moeten nemen aangezien er steeds meer af gaan per stap:
block = 10 - 9 - 7 - 5 - 1
inlayer = 1 - 2 - 3 - 4 - 5
height = 0 - 1 - 2 - 3 - 4

Deze waardes zijn de waardes op het moment dat je de check doet of inlayer <= blocks

Antwoord is dus inderdaad 4 en in de laatste check is de voorwaarde niet meer waar en stopt het programma dus.

[CurlyMo]

@flugelisoke Leren betekent ook de goede tips van anderen integreren. Zoals ik eerder al aangaf code tags te gebruiken.

[BLACKfm]

Philip Ross schreef op vrijdag 3 mei 2019 @ 16:12:
[...]


correct. Al zou blocks ook sneller af moeten nemen aangezien er steeds meer af gaan per stap:
block = 10 - 9 - 7 - 5 - 1
inlayer = 1 - 2 - 3 - 4 - 5
height = 0 - 1 - 2 - 3 - 4

Moet dat dan niet:

block = 10 - 9 - 7 - 4 - 0
inlayer = 1 - 2 - 3 - 4 - 5
height = 0 - 1 - 2 - 3 - 4

Zijn? Maar dan klopt het nog steeds. <= is 'kleiner of gelijk aan'. Dus 4 is 'kleiner of gelijk aan' 4. Die klopt dan nog, 0 is kleiner dan 5 en geeft dan de waarde 'hoogte' van 4.

Bij de 4 / 4 / 3 stap wordt nog 1 maal de code uitgevoerd. Gaan er 4 blocks vanaf (0) komt er 1 inlayer bij (5) en krijgt de height er 1 bij (4). Vervolgens wordt de vergelijking weer gemaakt, blijkt inlayer (5) groter te zijn dan de blocks waarde (0) en wordt de onderliggende code van 'while' niet meer uitgevoerd.
De waarde van 'height' staat op dat moment op 4 en die wordt dan ook geprint.


Pfff. Ik heb gewoon een excel opgezet om deze berekening goed te kunnen visualiseren , al was dat dan weer meer omdat ik jouw uitkomsten niet kon plaatsen . Blijkt het soms toch weer lastiger te zijn dan het lijkt

[flugelisoke]

CurlyMo schreef op vrijdag 3 mei 2019 @ 19:20:
@flugelisoke Leren betekent ook de goede tips van anderen integreren. Zoals ik eerder al aangaf code tags te gebruiken.

Daar heb ik je even gemist

Ik zie het nu bij UBB codes!

[ Voor 5% gewijzigd door flugelisoke op 03-05-2019 20:34 ]

[CurlyMo]

flugelisoke schreef op vrijdag 3 mei 2019 @ 20:34:
[...]


Daar heb ik je even gemist

Ik zie het nu bij UBB codes!

Het is ook een goed idee om je oude reacties te verbeteren qua opmaak.

[Philip Ross]

BLACKfm schreef op vrijdag 3 mei 2019 @ 20:23:
[...]


Moet dat dan niet:

block = 10 - 9 - 7 - 4 - 0
inlayer = 1 - 2 - 3 - 4 - 5
height = 0 - 1 - 2 - 3 - 4

Zijn?

Je hebt gelijk, moet een typfoutje geweest zijn.

[CurlyMo]

Even vanaf mobiel en niet getest.

Volgens mij kan je nog veel simpeler zeggen:

Ik zie zojuist dat Python geen gangbare for loop syntax heeft, dus dit werkt niet in Python. Dan maar een C versie van gemaakt als voorbeeld.

C:

#include <stdio.h>

void main() {
        int blocks = 10;
        int height = 0;
        for(height=0;(blocks-height)>=0;height+=1, blocks-=height);
        printf("%d\n", height);
}

Scheelt weer een variabele.

Voor het idee dat meerdere wegen naar Rome leiden, afhankelijk van de mogelijkheden van je taal

[ Voor 82% gewijzigd door CurlyMo op 04-05-2019 10:43 ]

[ThomasG]

CurlyMo schreef op zaterdag 4 mei 2019 @ 07:36:
Even vanaf mobiel en niet getest.

Volgens mij kan je nog veel simpeler zeggen:

Ik zie zojuist dat Python geen gangbare for loop syntax heeft, dus dit werkt niet in Python. Dan maar een C versie van gemaakt als voorbeeld.

C:

#include <stdio.h>

void main() {
        int blocks = 10;
        int height = 0;
        for(height=0;(blocks-height)>=0;height+=1, blocks-=height);
        printf("%d\n", height);
}

Scheelt weer een variabele.

Voor het idee dat meerdere wegen naar Rome leiden, afhankelijk van de mogelijkheden van je taal

Ondanks dat je dit veel in oude C-code tegen komt, is het bad practice en dus helemaal niet handig om dit mensen aan te leren; vooral het beginnende programmeurs zijn. Het levert namelijk met moderne compilers geen performance winst op, maar heeft wel alle nadelen met betrekking tot de maintenance van de code. Je kunt niet in een oogopslag zien wanneer de for loopt stopt, en het ontbreken van een body is verwarrend. Het is dus beter om zulke dingen niet te doen.

[Matis]

ThomasG schreef op zaterdag 4 mei 2019 @ 13:54:
Ondanks dat je dit veel in oude C-code tegen komt, is het bad practice en dus helemaal niet handig om dit mensen aan te leren; vooral het beginnende programmeurs zijn. Het levert namelijk met moderne compilers geen performance winst op, maar heeft wel alle nadelen met betrekking tot de maintenance van de code. Je kunt niet in een oogopslag zien wanneer de for loopt stopt, en het ontbreken van een body is verwarrend. Het is dus beter om zulke dingen niet te doen.

Daar sluit ik me bij aan. Ik zie liever code met een extra variabele, dan one-liners die een berg aan commentaar nodig heeft om het te begrijpen.

Daarnaast is zo'n one-liner ook lastig(er) te debuggen door het gebrek aan regels code waar de debugger kan stoppen om zo een intermediate state van het systeem te bekijken.

Leuk om te zien hoe vindingrijk een programmeur kan zijn, maar mi. een zware bad-practice en not done binnen onze collega's.

[Raynman]

Ik vind die inlayer (en dan ook niet in_layer ) anders niet veel toevoegen behalve extra bookkeeping in de loop. Maar waarom er dan ineens weer C bij gehaald moet worden?

Python:

while height < blocks:
    height += 1
    blocks -= height

[CurlyMo]

Raynman schreef op zaterdag 4 mei 2019 @ 14:53:
Maar waarom er dan ineens weer C bij gehaald moet worden?

Omdat ik er pas later achter kwam dat zo'n for loop niet wordt ondersteund vanuit Python. Toen had ik mijn bericht zoals je las al getypt. En ik vond het wel zo netjes om een werkende voorbeeld af te leveren

ThomasG schreef op zaterdag 4 mei 2019 @ 13:54:
[...]
Ondanks dat je dit veel in oude C-code tegen komt, is het bad practice en dus helemaal niet handig om dit mensen aan te leren; vooral het beginnende programmeurs zijn.

Ik leer niemand wat aan. Wat wel goed is voor de beginnende programmeur om te beseffen is dat er meerdere wegen naar Rome zijn. Nog los van de wenselijkheid ervan.

Matis schreef op zaterdag 4 mei 2019 @ 14:20:
[...]
Leuk om te zien hoe vindingrijk een programmeur kan zijn, maar mi. een zware bad-practice en not done binnen onze collega's.

Allereerst zal ik die vindingrijkheid stimuleren om daarna beargumenteerd uit te leggen waarom ik dit liever niet in het team terug zie. Iemand moet eerst voor zichzelf leren denken alvorens geleerd wordt wat best-practices zijn.
.

[eric.1]

flugelisoke schreef op vrijdag 3 mei 2019 @ 13:46:
Dit is de oplossing:

# Sample Solution

blocks = int(input("Enter the number of blocks: "))
height = 0
inlayer = 1
while inlayer <= blocks:
........height += 1
........blocks -= inlayer
........inlayer += 1

print("Height of the pyramid:",height)

Zoals iemand al zei; vertaal de variabelen, wellicht wordt het dan al duidelijker.

Python:

mijn_stapel_blokken = int(input("Enter the number of blocks: "))
aantal_lagen = 0
benodigd_voor_volgende_laag = 1
while benodigd_voor_volgende_laag <= mijn_stapel_blokken: #dus ik heb genoeg blokken om een laag te maken
........aantal_lagen +1 #we kunnen een laag maken, dat doen we dus ook
........mijn_stapel_blokken = mijn_stapel_blokken - benodigd_voor_volgende_laag #we trekken de gebruikte blokken voor de "nieuwe" laag af van onze stapel beschikbare blokken
........benodigd_voor_volgende_laag = 1 meer dan deze toegevoegde laag

[Lethalis]

flugelisoke schreef op dinsdag 30 april 2019 @ 19:37:
Is logisch / abstract denken voor programmeren iets wat je standaard gewoon kan of niet.

Of is dit een eigenschap die je kunt aanleren?

Het is net zoals met wiskunde B op de middelbare school. Iedereen kan het leren, niet iedereen is er goed in.