[Python] Def opdracht, nummerlijst

[flugelisoke]

Ik heb een oefen opdracht ontvangen, maar ik vind hem nog lastig te begrijpen:

Opdracht:

code:

from typing import list
def twoSum(nums: 'list[int]', target: 'int') -> 'list[int]': 
#Your code here

Wanneer ik deze huidige code uitvoer, komt er een syntax error: Unexpected EOF while parsing. Nu is dit naar mijn idee te verklaren omdat er nog geen code is geschreven, maar ik ben wel nieuwsgierig waarom Python nou deze error code geeft.

Nu om terug te komen op de opdracht zelf:

- Ik begrijp dat de module typing wordt geïmporteerd, met als onderdeel list. Ik heb geen ervaring met deze module*

- Er wordt een functie gedefinieerd genaamd twoSum. Nu zie ik de parameter nums en target, maar ik zie nog niet hoe ik 'list[int]' moet verstaan, eveneens de target en -> 'list['int']


De opdracht als volgt is dat je schijnbaar een lijst met nummers krijgt (Ik zie geen lijst, maar een EOF error).
Uit die lijst moet je 2 nummers halen die het target getal vormen, je mag een nummer niet dubbel gebruiken.

Nu wil ik uiteraard graag zelf uitvinden hoe ik dat voor elkaar ga toveren, maar het gaat er mij om dat ik begrijp wat er nu in het begin gebeurt.

[RobIII]

flugelisoke schreef op vrijdag 30 augustus 2019 @ 13:10:
syntax error: Unexpected EOF while parsing

Omdat je functie geen code bevat (enkel een comment) (check). Je moet de functie nog implementeren (check); dat is nou net de opdracht.

[ Voor 21% gewijzigd door RobIII op 30-08-2019 13:17 ]

[Wolfboy]

Als dit letterlijk de code is die je gekregen hebt is de opdracht gewoon fout.

Het zou zo moeten zijn:

Python:

from typing import List


def twoSum(nums: List[int], target: int) -> List[int]:
    # Your code here
    ...

[DataGhost]

Ik kan me bijna niet voorstellen dat je een oefenopdracht uit het niets hebt ontvangen, zonder enige context, bij je studie fysiotherapie. Oftewel: wat is de context van de opdracht, wat is de lesstof die je gehad hebt, wat heeft je docent erover uitgelegd?

Wanneer ik deze huidige code uitvoer, komt er een syntax error: Unexpected EOF while parsing. Nu is dit naar mijn idee te verklaren omdat er nog geen code is geschreven,

Dat heb je dan wel goed bedacht.

maar ik ben wel nieuwsgierig waarom Python nou deze error code geeft.

Google anders even naar EOF als je niet weet wat dat betekent?

[flugelisoke]

Wolfboy schreef op vrijdag 30 augustus 2019 @ 13:19:


Als dit letterlijk de code is die je gekregen hebt is de opdracht gewoon fout.

Het zou zo moeten zijn:

Python:

from typing import List


def twoSum(nums: List[int], target: int) -> List[int]:
    # Your code here
    ...

Zo'n vermoeden begon ik dus te krijgen.....

[flugelisoke]

DataGhost schreef op vrijdag 30 augustus 2019 @ 13:19:
Ik kan me bijna niet voorstellen dat je een oefenopdracht uit het niets hebt ontvangen, zonder enige context, bij je studie fysiotherapie. Oftewel: wat is de context van de opdracht, wat is de lesstof die je gehad hebt, wat heeft je docent erover uitgelegd?


[...]

Dat heb je dan wel goed bedacht.


[...]

Google anders even naar EOF als je niet weet wat dat betekent?

Het volgende kopieer ik letterlijk wat ik heb ontvangen:

from typing import List def twoSum(nums: 'List[int]', target: 'int') -> 'List[int]': #Your code here


Je krijgt een lijst met nummers.Geef van deze lijst de van de twee cijfers terug die samen optellen tot de doel som.
Je mag ervan uitgaan dat er altijd maar ​één​ antwoord goed is. Je mag hetzelfde cijfer niet twee keer gebruiken.

Voorbeeld: twoSum(nums=[2,7,11,15], target=9) Antwoord: [2, 7] Want: nums[0] + nums[1] = 2+ 7 = 9


for cijfer in nums: print(cijfer)

[ Voor 3% gewijzigd door flugelisoke op 30-08-2019 13:26 ]

[RobIII]

flugelisoke schreef op vrijdag 30 augustus 2019 @ 13:10:
De opdracht als volgt is dat je schijnbaar een lijst met nummers krijgt (Ik zie geen lijst, maar een EOF error).

flugelisoke schreef op vrijdag 30 augustus 2019 @ 13:24:
Je krijgt een lijst met nummers.

Je begrijpt dit ⇧ verkeerd. "Je krijgt een lijst met nummers als input" voor je, nog te implementeren, functie. Niet als output.

Verder: Gebruik a.u.b. de wijzig-link (rechtsbovenaan je post) als je iets toe te voegen hebt; je topic herhaaldelijk omhoogschoppen is niet nodig en die melding staat er niet voor niets:

[ Voor 64% gewijzigd door RobIII op 30-08-2019 13:33 ]

[DataGhost]

Okee, maar wat zegt je lesstof erover? Daar is toch uitgelegd wat alles wat er nu al staat betekent, en daarmee zou je de rest moeten kunnen aanvullen? En anders zoek je er toch wat extra lesstof bij?

[flugelisoke]

DataGhost schreef op vrijdag 30 augustus 2019 @ 13:30:
Okee, maar wat zegt je lesstof erover? Daar is toch uitgelegd wat alles wat er nu al staat betekent, en daarmee zou je de rest moeten kunnen aanvullen? En anders zoek je er toch wat extra lesstof bij?

Er staan dingen in die nog niet in de lesstof zijn behandeld, zoals:

- het ' -> ' teken
- de manier waarop nums wordt aangesproken, (nums:list[int]
- target is ook niet in de lesstof behandeld

[Josk79]

code:

def twoSum(nums: List[int], target: int) -> List[int]

In deze regel staat dat argument 'nums' van de aanroep een List[int] moet zijn. Hettweede argument 'target' moet een int zijn. De returnwaarde van de functie twoSums moet ook List[int] zijn.

Dit verbiedt bijvoorbeeld deze aanroep:

code:

waarde = twoSums( 'appel', 123 )

want 'appel' is geen List[int].

Probeer nu zelf de code in de regels onder de definitie van twoSums in te vullen of speel vals en probeer eerst hard gecodeerd een waarde terug te geven bijv. [6, 6]. Als dat lukt kun je weer een stapje verder en uitpluizen hoe je door de lijst met getallen kan zoeken...

[ Voor 25% gewijzigd door Josk79 op 31-08-2019 10:05 ]

[flugelisoke]

Josk79 schreef op zaterdag 31 augustus 2019 @ 10:02:

code:

def twoSum(nums: List[int], target: int) -> List[int]

In deze regel staat dat argument 'nums' van de aanroep een List[int] moet zijn. Hettweede argument 'target' moet een int zijn. De returnwaarde van de functie twoSums moet ook List[int] zijn.

Dit verbiedt bijvoorbeeld deze aanroep:

code:

waarde = twoSums( 'appel', 123 )

want 'appel' is geen List[int].

Probeer nu zelf de code in de regels onder de definitie van twoSums in te vullen of speel vals en probeer eerst hard gecodeerd een waarde terug te geven bijv. [6, 6]. Als dat lukt kun je weer een stapje verder en uitpluizen hoe je door de lijst met getallen kan zoeken...

Het ding is, ik heb enigszins wel een idee in mijn hoofd hoe het ongeveer zou moeten.

Iets in de zin van:

Er is een lijst met nummers, het doel is om 9 te vormen met 2 aparte getallen uit die lijst.

Begin bij nummer 1, tel daarbij nummer 2 op, is dat 9? Return het. Is het hoger dan 9? Tel dan niet nummer 2 op, maar probeer nummer 3 erbij op te tellen enz.

Werkt het niet met nummer 1? Begin dan met nummer 2, tel daarbij nummer 3 op, is dat 9? Return.. enz enz enz.


Geef uiteindelijk de uitkomst terug van de match wat 9 maakt.

Mijn probleem is dat ik geen flauw benul heb hoe ik dit ga vertalen naar code Ik moet zeggen, ik heb er nog niet veel ervaring mee. Maar ook onbekende tekens helpen er niet aan mee en maken het voor mij verwarrend. Hier komt dan ook meteen mijn onzekerheid weer opspelen, de gedachte dat ik niet in staat ben om zelf oplossingen te verzinnen, erg frustrerend

[Josk79]

Je idee is goed! Ben je al bekend met for-loops? Kijk hier eens: https://treyhunner.com/20...p-with-indexes-in-python/

[flugelisoke]

Josk79 schreef op zaterdag 31 augustus 2019 @ 12:29:
Je idee is goed! Ben je al bekend met for-loops? Kijk hier eens: https://treyhunner.com/20...p-with-indexes-in-python/

Ik ben in principe al redelijk bekend met:

- for loops
- while loops
- functies maken
- modules importeren (basis)

Nu moet ik wel vermelden dat ik redelijk begrijp hoe loops werken, maar dat ik niet altijd weet hoe ik er geavanceerd mee om kan gaan, soms zie je loops in loops in loops en dat verwart me momenteel nog wel.

[Josk79]

Nou, vooruit een voorzetje:

code:

from typing import List

def twoSum(nums: List[int], target: int) -> List[int]:
    listGrootte = len(nums)
    for index1 in range(0, listGrootte):
        getal1 = nums[index1]
        getal2 = 666 # Dit moet je nog zelf oplossen met een tweede for-loop
        print("%d + %d = %d" % (getal1, getal2, getal1 + getal2))
        
twoSum(nums=[2,7,11,15], target=9)

Probeer deze code aan te passen zodat getal2 de volgende getallen in de list naloopt...
hint: range(index1, .......)

[flugelisoke]

Josk79 schreef op zaterdag 31 augustus 2019 @ 14:47:
Nou, vooruit een voorzetje:

code:

from typing import List

def twoSum(nums: List[int], target: int) -> List[int]:
    listGrootte = len(nums)
    for index1 in range(0, listGrootte):
        getal1 = nums[index1]
        getal2 = 666 # Dit moet je nog zelf oplossen met een tweede for-loop
        print("%d + %d = %d" % (getal1, getal2, getal1 + getal2))
        
twoSum(nums=[2,7,11,15], target=9)

Probeer deze code aan te passen zodat getal2 de volgende getallen in de list naloopt...
hint: range(index1, .......)

Tnx man, ik ga ermee aan de slag!

Wat heeft:

code:

from typing import List

eigenlijk voor nut? Ik zie dat twoSums om 2 parameters vraagt, die vervolgens ook worden gegeven in de vorm van een zelfgemaakte lijst. Dus wat doet die aanroep in het begin eigenlijk? Ik heb al even gegoogled maar ik word er niet wijzer van.

[DataGhost]

Haal die regel dan eens weg en kijk wat er gebeurt, zou ik zeggen...

[Morrar]

Die List is er alleen voor type hinting en kan eventueel weg als je geen type hinting wilt doen:

Python:

def twoSum(nums, target):
    ...

Overigens is die "Camel Case" functienaam niet helemaal PEP compliant, die zou eigenlijk snake case moeten zijn oftewel "two_sums".

Tot slot zijn de for-loops goed voor kleine lijsten, maar voor grote lijsten (> 500 getallen) wordt het al gauw traag. Een matrix oplossing met numpy werkt dan veel sneller:

Python:

import numpy as np


def two_sum(numbers, target):
    """Finds all combinations of numbers that sum up to target."""

    # Convert to matrix and compute sums
    num_mtx = np.array([numbers])
    prod_mtx = np.triu(num_mtx + num_mtx.T)

    # Find valid solutions
    valid = np.where(prod_mtx == target)
    
    # Return as tuples
    return [
        (numbers[idx1], numbers[idx2])
        for idx1, idx2 in zip(valid[0], valid[1])
    ]

[DataGhost]

Niet alleen is dit als met een atoombom een mug doodmaken, je kauwt nu een complete en over-engineered oplossing voor aan iemand die nog amper zelf een functie kan schrijven. Daar leert 'ie toch niks van? De bedoeling van zo'n opdracht is niet het "perfect", "supermooi" of "enterprise-y" implementeren van iets, de bedoeling is dat je kennis maakt met de verschillende constructs van een taal zodat je die later in echte opdrachten goed in kan zetten.

Bovendien krijg je hiermee puntenaftrek, want de output voldoet niet aan de specificatie, en je laat zien dat je niet de hele opdracht gelezen hebt "Je mag ervan uitgaan dat er altijd maar ​één​ antwoord goed is".

[ Voor 22% gewijzigd door DataGhost op 03-09-2019 10:25 ]

[RobIII]

Morrar schreef op dinsdag 3 september 2019 @ 09:58:

Wil je voortaan geen kant-en-klare code c.q. oplossing posten? Wat leert TS hier van? We hanteren hier in de Devschuur® het credo:

Give a man a fish and feed him for a day. Teach a man how to fish and feed him for a lifetime.

Je bedoeling is vast goed, maar hier wordt niemand beter van

[ Voor 10% gewijzigd door RobIII op 03-09-2019 10:43 ]

[Aetos]

@Morrar Kan je uitleggen waarom numpy in theorie per definitie sneller is in jouw implementatie?

Een oplossing met 2 iteratie constructies zonder op bounds te letten hoeft niet meer werk te verzetten dan de num_mtx + num_mtx.T en kan de helft sparen door op bounds te letten.


Mogelijkerwijs is er een manier te verzinnen om de nummers gesorteerd te gebruiken en dan aan beide zijden af te eten en daarmee eerder te stoppen.

sorteren: nlogn
eenmalig over alle elementen itereren.: n

Hm. Misschien een theoretisch optimalere oplossing dan 1/2 n^2?

[DroogKloot]

Dit kan gewoon in O(N) tijd dmv een hashtable, maar met complexiteit hoeft de TS zich nog niet mee bezig te houden lijkt me.

[Morrar]

Rustig maar mensen; die oplossing van mij gaat de TS natuurlijk niet inleveren, dat was ook niet het punt. Sowieso stond de oplossing er al in pseudo code.

Maar wellicht wel leuk voor de TS om te zien hoe het ook zou kunnen en als introductie met numpy; toch wel een package dat handig is om te kennen voor zo'n beetje alles met wiskunde in Python.

Waarom numpy veel sneller is; veel redenen, maar o.a. omdat pure Python gewoon best wel traag is vergeleken met C / Fortran (= numpy). Daarnaast vallen matrix operaties enorm simpel te paralleliseren. Kortom, zodra je met serieuze data gaat werken wil je alles zsm uit Python en in numpy o.i.d. duwen (al zal de TS zich daar inderdaad nog niet druk over hoeven maken).

De sorteer optie is ook wel interessant, kun je de search space aardig verkleinen. Alleen kun je dan ook niet voldoen aan "de eerste" oplossing.

@Gomez12 Poeh beetje zuur, neem nog een koffie Van docenten die net zo rigide denken als jij kreeg ik altijd graag een onvoldoende...

[ Voor 29% gewijzigd door Morrar op 03-09-2019 14:20 ]

[Gomez12]

Morrar schreef op dinsdag 3 september 2019 @ 13:05:
Rustig maar mensen; die oplossing van mij gaat de TS natuurlijk niet inleveren, dat was ook niet het punt. Sowieso stond de oplossing er al in pseudo code.

Maar wellicht wel leuk voor de TS om te zien hoe het ook zou kunnen en als introductie met numpy; toch wel een package dat handig is om te kennen voor zo'n beetje alles met wiskunde in Python.

Ik hoop dat de TS niet jouw "oplossing" gaat inleveren, want dat zou hem als het kon waarschijnlijk een negatief cijfer opleveren.

A : Je coding style is verkeerd, leuk dat jij snakecase wilt hanteren, maar als er Camel Case gegeven wordt dan moet je Camel Case opleveren.
B: Je antwoord is simpelweg niet wat er gevraagd wordt
C: Je introduceert onnodige extra complexiteit en dependencys met numpy
D: Vanwege C heb je nu ook dingen geintroduceerd die TS helemaal niet meer kan uitleggen.
E: Je hele method aanroep is anders dan spec

Oftewel in een serieuze omgeving als je niet gisteren begonnen bent dan zou je een serieuze uitbrander krijgen voor dit flierefluit werk waar niemand iets mee kan en wat enkel tijdverspilling is.

Morrar schreef op dinsdag 3 september 2019 @ 13:05:
@Gomez12 Poeh beetje zuur, neem nog een koffie Van docenten die net zo rigide denken als jij kreeg ik altijd graag een onvoldoende...

Ik bekijk het niet vanuit docenten oogpunt, maar puur uit zakelijk oogpunt waar je in een team werkt en er gewoon afspraken zijn waaraan men zich moet houden etc.

Als ik aan een collega vraag om een method te schrijven die x als aanroep heeft en y als output, dan heb ik niks aan een method die een totaal andere aanroep heeft en een ander resultaat oplevert.

Doe dit soort grappen te vaak en je kan simpelweg je boeltje pakken omdat er met jou niet valt samen te werken.

[ Voor 23% gewijzigd door Gomez12 op 03-09-2019 14:36 ]

[Morrar]

Om op je punten terug te komen:

A. Nee de naam is niet PEP8 compliant en dus geen goed geformatteerde code. De docent heeft het fout...

B. Alleen de eerste oplossing teruggeven is eenvoudig te implementeren. Het is echter een extreem arbitraire requirement (want afhankelijk van input). Een oplossing met sort zou bijvoorbeeld ook niet kunnen.

C. Oh nee pip install numpy Python draait op het package eco-systeem...

D. Zoals gezegd de oplossing is "ter leering ende vermaeck", niet zozeer voor de TS om in te leveren. Dat mag niet van RobIII en daarom heb ik uiteraard geen versies met loopjes gepost...

E. Voor de Python interpreter zijn ze identiek, die negeert de type hinting compleet. Het is alleen een hint voor andere programmeurs en het verneukt je backwards compatibiliteit... Oh en wellicht kun je er nog wat unit tests mee automatiseren, maar dat lijkt me niet in de scope van dit topic...

Als dit mijn team zou zijn, zou ik het gesprek aangaan over deze punten... Maar zo wel weer genoeg gediscussieerd, heeft de TS niet zoveel aan.

Persoonlijk zou ik TS aanraden om eens www.codecademy.com/python erbij te pakken.

[ Voor 10% gewijzigd door Morrar op 03-09-2019 15:05 ]

[DataGhost]

Morrar schreef op dinsdag 3 september 2019 @ 14:51:
Om op je punten terug te komen:

A. Nee de naam is niet PEP8 compliant en dus geen goed geformatteerde code. De docent heeft het fout...

Zolang het geen syntaxfout is gaat de codeerstandaard van hetgene je aangeleverd krijgt voor. Zeker in een team als er afspraken zijn. PEP8 is ook maar een richtlijn, en dan nog specifiek voor code die in de standard library komt, dus het zegt niks over code die je zelf schrijft. Ik vind het ook een behoorlijk achterlijke richtlijn, maar dat is mijn mening. Gelukkig is 'ie optioneel.

C. Oh nee pip install numpy Python draait op het package eco-systeem...

Het gaat om een simpele oefenopdracht. Verder is het een ongelofelijk geval premature optimization, en het maakt het behoorlijk onleesbaar of moeilijk te begrijpen wat de code nou precies doet.

D. Zoals gezegd de oplossing is "ter leering ende vermaeck", niet zozeer voor de TS om in te leveren. Dat mag niet van RobIII en daarom heb ik uiteraard geen versies met loopjes gepost...

Wat heeft een totale beginner daar dan aan? Leert 'ie daar iets van? Denk je dat hij binnen 2 jaar zo ver is dat 'ie zelf een dergelijke oplossing uit zou kunnen poepen? Tegen die tijd is 'ie het allang weer vergeten. Eigenlijk nu al, wat je niet begrijpt blijft ook niet hangen.

E. Voor de Python interpreter zijn ze identiek, die negeert de type hinting compleet. Het is alleen een hint voor andere programmeurs en het verneukt je backwards compatibiliteit... Oh en wellicht kun je er nog wat unit tests mee automatiseren, maar dat lijkt me niet in de scope van dit topic...

Wederom, het is de aangeleverde coding standard die het voorschrijft, en ik vind het persoonlijk ook behoorlijk bijdragen aan makkelijker begrip van de code, het is direct duidelijk wat voor argumenten verwacht worden, en het is ook nog eens te checken met een linter waardoor je direct kan zien waar je verkeerde types gebruikt. En backwards compatibiliteit met wat? Python 3.4 is al EOL, en 2.7 had dat al jaren moeten zijn. Hoe dan ook mag je uitgaan van Python 3 en diens syntax, en daar is geen enkele versie meer van waar geen type hinting in zit.

[flugelisoke]

Inmiddels ben ik tot de oplossing gekomen, eerst heb ik beschreven in het Nederlands wat ik denk wat er moet gebeuren. Het vertalen van Nederlands naar coderen is een best klusje als beginner omdat je wel een en ander van de tools af weet, maar nog niet goed weet hoe en waar je ze precies gebruikt.

Nu heb ik vandaag wat meer geleerd over een loop in een loop en daarmee ook de oplossing gemaakt:

code:

def twoSum(nums,target):
    for i in nums:
        for y in nums:
            if i == y:
                continue
            elif i + y == target:
                return [i,y]
            

print(twoSum([2,15,1,7],9))

[Josk79]

Goed gedaan! Wel nog een kleine instinker:

print(twoSum([2,2,1,7],4))

Hier gaat 'ie de mist in.

[Brilsmurfffje]

Dit is ook een erg bekende interview vraag. Met deze oplossing die je nu hebt kan je nog bedenken voor jezelf hoe dit sneller kan. Schrijf wat het programma doet ui op papier en probeer het aantal dubbele stappen te beperken

Mocht je dit soort problemen leuk vinden en wil je er meer mee oefenen, kijk dan eens op Projecteuler.net

[Wolfboy]

DataGhost schreef op dinsdag 3 september 2019 @ 15:21:
[...]

Zolang het geen syntaxfout is gaat de codeerstandaard van hetgene je aangeleverd krijgt voor. Zeker in een team als er afspraken zijn. PEP8 is ook maar een richtlijn, en dan nog specifiek voor code die in de standard library komt, dus het zegt niks over code die je zelf schrijft. Ik vind het ook een behoorlijk achterlijke richtlijn, maar dat is mijn mening. Gelukkig is 'ie optioneel.

PEP8 is misschien alleen een richtlijn, maar het is wel de de facto standaard in Python en daarmee een goede basis om aan te houden.

Zoals veel projecten en projectteams doen kan je natuurlijk prima aanpassingen maken zoals 120 karakter regel limieten in plaats van 80, maar dat maakt de basis niet nutteloos.

Uit interesse, wat vindt je achterlijk aan PEP8? Persoonlijk vind ik het een prima richtlijn met sommige delen misschien een beetje nitpicky. Naar mijn mening gaat PEP8 voornamelijk om leesbaarheid, iets wat altijd hoog in het vaandel van Python staat.

flugelisoke schreef op dinsdag 3 september 2019 @ 23:12:
Inmiddels ben ik tot de oplossing gekomen, eerst heb ik beschreven in het Nederlands wat ik denk wat er moet gebeuren. Het vertalen van Nederlands naar coderen is een best klusje als beginner omdat je wel een en ander van de tools af weet, maar nog niet goed weet hoe en waar je ze precies gebruikt.

Nu heb ik vandaag wat meer geleerd over een loop in een loop en daarmee ook de oplossing gemaakt:

code:

def twoSum(nums,target):
    for i in nums:
        for y in nums:
            if i == y:
                continue
            elif i + y == target:
                return [i,y]
            

print(twoSum([2,15,1,7],9))

Klein beetje nitpicken hier. Als conventie gebruik je meestal ofwel de loop variabelen "i", "j" (en eventueel "k" als je er 3 nodig hebt). Of de variabelen "x", "y" en "z".

Zoals @Josk79 al aangeeft ga je nu de fout in doordat je de waarden (en niet de index) aan het vergelijken bent. Kijk eens naar dit voorbeeldje om een betere oplossing te bouwen:

Python:

some_list = [7, 8, 9]

for i, x in enumerate(some_list):
    print(i, x)

[ Voor 36% gewijzigd door Wolfboy op 04-09-2019 04:24 ]

[DataGhost]

Wolfboy schreef op woensdag 4 september 2019 @ 04:20:
[...]
Uit interesse, wat vindt je achterlijk aan PEP8? Persoonlijk vind ik het een prima richtlijn met sommige delen misschien een beetje nitpicky. Naar mijn mening gaat PEP8 voornamelijk om leesbaarheid, iets wat altijd hoog in het vaandel van Python staat.

Mijn verwoording was een beetje enthousiast. Hetgene waar ik het meeste over val is het geforceerde gebruik van spaties over tabs met de (IMO) falende argumentatie die daarachter zit. Daar kan ik heel passioneel over worden maar die discussie wil ik hier niet gaan volgen De regellengte is ook een dingetje inderdaad, en de naamgeving van functienamen en variabelen is ook een persoonlijk dingetje, omdat ik vanuit andere talen natuurlijk iets anders gewend ben. Dan is mijn code maar niet helemaal pythonic (zolang ik zelf de standaard mag dicteren), leesbaar hou ik het wel.

@flugelisoke: fijn dat je werkende code hebt weten te schrijven! Maar er zit inderdaad nog een foutje in. Naast de aangedragen oplossing van @Wolfboy met enumerate, kan je ook kijken naar het gebruik van range in je for-loop (for i in range(...)), daarmee kan je ook je check op "hetzelfde getal" overbodig maken als je goed nadenkt. Probeer ze allebei te maken als oefening Ik kan zo nog een paar andere manieren verzinnen maar die zijn wat minder elegant.

En inderdaad, een goeie conventie is om i, j (en k) te gebruiken voor loop-indices en x, y, z (of andere letters/namen) voor waarden. Je bent natuurlijk altijd helemaal vrij in je keuze, maar i, j (en k) hebben vrijwel universeel (in zo ongeveer elke taal dus) de de facto-betekenis van loop-index, vandaar dat het mixen van die twee voor onduidelijkheid kan zorgen.

[flugelisoke]

Bedankt allemaal voor jullie feedback!!

Ik heb nog eens naar de code gekeken en ik heb de tip van @Wolfboy meegenomen. Ik ben eens wat gaan youtuben over enumerate ( leuk om wat nieuwe inzichten te krijgen op hoe je dingen oplost trouwens! )

En vervolgens ben ik tot de nieuwe code gekomen, of hij helemaal goed is, ik weet het niet, maar het is een alternatieve oplossing:

code:

def twoSum(nums,target):
    for i, j in enumerate(nums):
        for k, l in enumerate(nums):
            if j + k == target:
                return[j,k]


print(twoSum([2,15,1,7],9))

Ook heb ik de tip van de loop variabelen meegenomen, je hebt inderdaad gelijk, dat is iets waar ik niet eerder over heb nagedacht


Ik heb zojuist zelf een fout ontdekt in de code, wanneer ik 18 invoer als target, geeft de code als uitkomst [15,3]

Ik denk dat dit te verklaren is omdat hij de index positie 3 pakt om tot de som te komen, wanneer ik 19 invoer geeft hij een None en betekent het dat de index out of range is naar mijn idee.

Is het zo dat met enumerate de hele output gebruikt wordt i.p.v enkel de waarde? Ik heb verder nog geen ervaring met enumerate.

[ Voor 22% gewijzigd door flugelisoke op 04-09-2019 10:14 ]

[DataGhost]

Voordat je lukraak een voor jou onbekende functie gaat gebruiken is het gebruikelijk om de documentatie ervan te lezen. Je ziet dan waarom @Wolfboy "i,x" gebruikte in plaats van "i.j". Voer anders ook even het code-voorbeeldje wat hij heeft gepost uit en kijk wat daar uit komt. Het maakt Python zelf niks uit hoe je je variabelen noemt, maar het maakt het voor jouzelf een stuk makkelijker om te bekijken wat er precies gebeurt. Je hebt verderop namelijk een kritieke denkfout gemaakt die ervoor zorgt dat je uitkomst met 18 fout is, en die ervoor zorgt dat de uitkomst van jouw code [7,2] is in plaats van [2,7]. Laten we het erop houden dat het toeval is dat je code uiteindelijk een bijna-goede uitkomst geeft

Je vorige oplossing gaf trouwens correct "None" als uitkomst van print(twoSum([2,15,1,7],4)). Je nieuwe oplossing geeft dan [2,2], wat volgens de opdracht niet hoort te kunnen.

[ Voor 4% gewijzigd door DataGhost op 04-09-2019 10:49 ]

[flugelisoke]

DataGhost schreef op woensdag 4 september 2019 @ 10:46:
Voordat je lukraak een voor jou onbekende functie gaat gebruiken is het gebruikelijk om de documentatie ervan te lezen. Je ziet dan waarom @Wolfboy "i,x" gebruikte in plaats van "i.j". Voer anders ook even het code-voorbeeldje wat hij heeft gepost uit en kijk wat daar uit komt. Het maakt Python zelf niks uit hoe je je variabelen noemt, maar het maakt het voor jouzelf een stuk makkelijker om te bekijken wat er precies gebeurt. Je hebt verderop namelijk een kritieke denkfout gemaakt die ervoor zorgt dat je uitkomst met 18 fout is, en die ervoor zorgt dat de uitkomst van jouw code [7,2] is in plaats van [2,7]. Laten we het erop houden dat het toeval is dat je code uiteindelijk een bijna-goede uitkomst geeft

Je vorige oplossing gaf trouwens correct "None" als uitkomst van print(twoSum([2,15,1,7],4)). Je nieuwe oplossing geeft dan [2,2], wat volgens de opdracht niet hoort te kunnen.

Poeh, nu zie ik het! Het moet j + l zijn, want inderdaad, nu gaat de code een waarde en een positie optellen

Wat suf, zulke fouten zijn snel gemaakt denk ik

Door de correctie van j + l geeft de code nu wel een correct antwoord, alsmede een None wanneer je een foutieve invoer geeft.

code:

def twoSum(nums,target):
    for i, j in enumerate(nums):
        for k, l in enumerate(nums):
            if j == l:
                continue
            if j + l == target:
                return[j,l]


print(twoSum([2,15,1,7],16))

[ Voor 19% gewijzigd door flugelisoke op 04-09-2019 11:03 ]

[DataGhost]

Ja, maar als je i,x en j,y had gebruikt was (en is) het veel duidelijker. Je weet dan dat i (afgeleid van het woord "index") en j "altijd" posities aangeven, en x en y zijn de waarden. De suggestie van @Josk79 "print(twoSum([2,2,1,7],4))" geeft nu namelijk nog steeds None bij jou in plaats van [2, 2].

[ Voor 5% gewijzigd door DataGhost op 04-09-2019 11:08 ]

[Gomez12]

flugelisoke schreef op woensdag 4 september 2019 @ 10:58:
[...]
Wat suf, zulke fouten zijn snel gemaakt denk ik

Omdat je niet de eerste bent die hier tegenaan loopt heb je dus codingstandaarden.

En daarom is de post van Morrar ook zo fout, die gooit de opgegeven codingstandaard weg en mikt er wat hij lekker vind werken eroverheen.

Zolang iedereen binnen het project / bedrijf / opdracht met dezelfde codingstandaarden werkt (bijv i,j zijn loop-variabelen) dan zijn die fouten niet meer zo gemaakt. Want iedereen herkent i,j als loop-variabelen.
Het gaat pas fout als iemand een andere codingstandaard erdoorheen gaat gooien waarbij hij x,y als loop-variabelen gaat gebruiken...

[Wolfboy]

DataGhost schreef op woensdag 4 september 2019 @ 08:08:
[...]

Mijn verwoording was een beetje enthousiast. Hetgene waar ik het meeste over val is het geforceerde gebruik van spaties over tabs met de (IMO) falende argumentatie die daarachter zit. Daar kan ik heel passioneel over worden maar die discussie wil ik hier niet gaan volgen

Traditioneel was ik ook altijd groot aanhanger van tabs in plaats van spaties (eenvoudiger in te stellen in editors enzo) maar sinds het web tijdperk heeft het wel wat nadelen (probeer binnen deze reply box maar een tab toe te voegen). Inmiddels is het grotendeels toch onbelangrijk, iedere fatsoenlijke editor kan je het gewoon instellen dus effectief scheelt het niet meer.

De regellengte is ook een dingetje inderdaad, en de naamgeving van functienamen en variabelen is ook een persoonlijk dingetje, omdat ik vanuit andere talen natuurlijk iets anders gewend ben. Dan is mijn code maar niet helemaal pythonic (zolang ik zelf de standaard mag dicteren), leesbaar hou ik het wel.

Het belangrijkste argument voor naamgeving van classes, functies en variabelen is consistentie. Ook al is Python daar zelf ook niet 100% consistent in helaas.

Naar mijn weten forceert PEP8 overigens geen standaard daarin en is het vooral consistentie boven alles. Maar dat is inderdaad vooral een smaak verhaal, het is maar net wat je gewend bent (i.e. werk je normaal veel in Java of veel in C++).

Overigens... dat de PEP8 style guide geen expliciete voorschrijvingen doet kwa naamgevingen zegt niet dat linting tools dat niet toch forceren

flugelisoke schreef op woensdag 4 september 2019 @ 10:58:
Poeh, nu zie ik het! Het moet j + l zijn, want inderdaad, nu gaat de code een waarde en een positie optellen

Wat suf, zulke fouten zijn snel gemaakt denk ik

Door de correctie van j + l geeft de code nu wel een correct antwoord, alsmede een None wanneer je een foutieve invoer geeft.

code:

def twoSum(nums,target):
    for i, j in enumerate(nums):
        for k, l in enumerate(nums):
            if j == l:
                continue
            if j + l == target:
                return[j,l]


print(twoSum([2,15,1,7],16))

En daarom zijn consistente naamgevingen belangrijk

De i, j en k zijn voor iteraties zoals bijvoorbeeld bij for loops die meestal zo lopen: [0, 1, 2, 3, 4, ...]. Beginnend bij 0 dus
De x, y en z zijn voor de daadwerkelijke waarden en kunnen dus alles zijn.

Begin eens met deze versie:

Python:

def twoSum(nums,target):
    for i, x in enumerate(nums):
        for j, y in enumerate(nums):
            ...

[ Voor 25% gewijzigd door Wolfboy op 04-09-2019 13:12 ]

[flugelisoke]

@Wolfboy Dat maakt het inderdaad wel overzichtelijker waar je mee bezig bent.

Even los van deze specifieke opdracht.

Zijn er bepaalde 'tactieken' om problemen op te lossen, hoe moet ik het zien? Is het zo dat je in de meeste gevallen aan een aantal gereedschappen als een loop en if else vaak voldoende hebt om te starten?

Ik merk dat ik het vaak nog lastig vind met het "waar begin ik toch en met wat".

[Wolfboy]

Het woordt dat je zoekt is "algoritme". Voor ieder probleem zijn er wel meerdere algoritmes te bedenken maar het belangrijkste is dat je eerst zelf gaat bedenken hoe je tot een oplossing kan komen.

Stel je hebt een lijst van getallen, hoe zou je met de hand het grootste getal gaan zoeken in deze lijst?
Waarschijnlijk ga je dan 1 voor 1 alle getallen af en kijk je bij ieder getal of het groter is dan wat je eerst als grootste getal had. In programmeertaal is het "1 voor 1 alle getallen af" dus een loop. Kijken of iets groter of kleiner is een if statement. En het onthouden van het grootste getal het opslaan in een variabele.

In Python zou dat er zo uit kunnen zien:

Python:

largest_number = 0
list_of_numbers = [1, 5, 3, 2, 9, 8, 5, 6]

for x in list_of_numbers:
    if x > largest_number:
        largest_number = x

print('The largest number was:', largest_number)