Topic: Ordinamento lessicografico stringa tramite funzione ricorsiva  (Letto 1516 volte)

0 Utenti e 1 Visitatore stanno visualizzando questo topic.

Offline RicPol

  • python sapiens sapiens
  • ******
  • Post: 2.939
  • Punti reputazione: 9
    • Mostra profilo
Re:Ordinamento lessicografico stringa tramite funzione ricorsiva
« Risposta #15 il: Marzo 13, 2018, 20:53 »
Uhm, sì nel frattempo ho notato anch'io che questo voleva essere più un "esercizio sulle funzioni (probabilmente) ricorsive" che non un "esercizio sul sorting". E con un adeguato reframing concettuale, posso farcelo stare. Mi fa ancora storcere un po' il naso, trovo che farlo con le liste e gli interi sia comunque meglio.
Ma certamente non siamo al livello di quello che faceva fare comparazioni esatte con i float.

Poi, capisco e accetto tutto il tuo discorso pratico sul panorama della didattica dell'informatica come scienza che non esiste, e dei docenti di informatica come personale che spesso non esiste (nel senso, non ha la didattica nel contratto).
Io però non parlo mai di problemi reali e scenari reali. Parlo sempre solo di didattica e qualità della didattica in senso astratto. Che se vuoi è un po' spocchioso, ci sta. Ma secondo me è anche necessario perché se ci limitiamo sempre a constatare che il panorama è quello che è, nessuno si prenderà mai il compito di dire che l'imperatore è nudo, cioè che alla fine della giornata la qualità della didattica è *comunque* scarsa. Poi, che cosa si possa fare concretamente, questo è un altro discorso. Magari avrei delle idee, magari a parlarne potrebbero venire delle idee. Ma nel frattempo non possiamo continuare a buttare nel tritacarne soldi pubblici e studenti e docenti, e sperare che per caso salti fuori la ricetta per le polpette.

In tutto questo, poi, va anche detto che gli esercizi sono notoriamente un aspetto molto difficile della didattica. La costruzione di un percorso di apprendimento è difficile, ma gli esercizi sono ancora più difficili perché (in teoria) sono il momento in cui affronti quello che "ancora non sai" ma sempre restando nei confini del terreno in cui puoi cavartela con "quello che già sai". E quindi bisogna bilanciare la tensione tra sapere e non-sapere. Lo stesso esercizio, formulato nello stesso modo, può essere un errore didattico in un certo momento e una genialata in un altro momento.
Il problema è che tu *vuoi* che gli allievi si perdano nel bosco, *ma* allo stesso tempo vuoi anche che non vadano a perdersi in direzioni troppo diverse da dove li vuoi mandare. Questo è sottile: se si perdono in direzioni troppo diverse, stai sprecando tempo: da un lato gli studenti non si interrogano (e quindi rafforzano la loro conoscenza) sulle cose che dovrebbero imparare in quel momento; dall'altro, annaspano in acque dove non hanno abbastanza appigli. Infine, probabilmente acquisiscono pattern sbagliati che poi è difficile individuare e correggere.
Attenzione, ripeto: questo è sottile. Se tu dai un esercizio sull'argomento A (le funzioni, passare argomenti e aspettarsi valori di ritorno... funzioni che chiamano altre funzioni... funzioni ricorsive... quelle cose lì) che però inavvertitamente porta nelle acque sconosciute dell'argomento B (i float... l'I/O... va a sapere), poi sicuramente tu puoi "approfittare" dello sbandamento per metterti ad affrontare l'argomento B. Ma è il modo sbagliato di affrontare l'argomento B (a meno che tu non abbia calcolato genialmente proprio tutto). Lo stai affrontando fuori tempo, lo stai prendendo magari dal verso più scomodo, eccetera. Infine, è vero che nella vita di tutti i giorni capita sempre di annaspare in acque profonde e imparare dagli errori. Ma appunto, questa è la *vita*, non la *didattica*. Se stai facendo didattica, hai la pretesa di insegnare in modo più efficiente di quanto farebbe la vita (compresi gli apprendistati artigianali, l'imparare dai propri errori, l'imparare dagli errori degli altri, il farsi da soli i propri percorsi... tutte cose utili, per carità - ma nella vita, appunto).
Se io preparo un esercizio sulle funzioni e mi accorgo, testandolo, che è pesantemente dipendente dalle bizzarrie dei float (nel senso che è facile che gli studenti si perdano lungo questa strada), certamente mi chiederò se non ci sia un buon momento per fare una lezione sui float. E magari degli esercizi sui float. Magari una lezione a partire da un esercizio. Tutto buono, per carità. Ma nel frattempo, però, *modifico* il mio esercizio sulle funzioni in modo che i miei studenti si concentrino su quello che voglio. Così l'esercizio diventa troppo arido e astratto? Di nuovo, è colpa mia: devo complessificare l'esercizio, ma *restando* nell'area che mi interessa.
Fare buoni esercizi è un'arte.

Parentesi necessaria: poi tutto questo non c'entra niente con lo studente bravo che fa esperimenti per conto suo, allarga lo sguardo, si perde e si inciampa e impara. Questo va incoraggiato e premiato, si capisce. Ma "l'esercizio" standard non è il terreno per questo tipo di esplorazioni.

Offline 🌞

  • python unicellularis
  • *
  • Post: 7
  • Punti reputazione: 0
    • Mostra profilo
Re:Ordinamento lessicografico stringa tramite funzione ricorsiva
« Risposta #16 il: Marzo 13, 2018, 23:39 »
Certo. Io non ho letto il capitolo di horstman. Pero' ancora una volta... alla fine e' un esercizio sulla ricorsione. Ti aiuta a capire la ricorsione? Mi verrebbe da dire di si.
A quel punto ti sono anche probabilmente state introdotte le stringhe qualche capitolo prima e mi verrebbe da dire che (spero) ci sia una nota che ti dice che le stringhe sono immutabili (per forza, in realta') e che usare + e' controindicato.
Sì, per la precisione qui e qui dice che le stringhe sono immutabili.
Non sapevo che usare + fosse controindicato.
Ho visto che in vari topic spieghi che concatenare stringhe con il + è O(n^2), cioè forse il caso peggiore del tempo di esecuzione di un algoritmo, ma non sono sicuro di cosa significhi.
L'analisi delle prestazioni di un algoritmo viene trattata nell'ultimo capitolo del libro, quindi non posso ancora capire queste cose.
Horstmann, finora, ha detto solamente che utilizzando l'operatore + si possono concatenare più stringhe per formare una stringa più lunga.
La funzione ''.join dovrebbe essere il modo migliore per farlo, ma  penso si utilizzi con le liste, e non le ho ancora studiate.
Appena trovo il tempo, devo mettermi a studiare anche computer science.  ;)
« Ultima modifica: Marzo 14, 2018, 18:57 da 🌞 »

Offline riko

  • python deus
  • *
  • moderatore
  • Post: 7.453
  • Punti reputazione: 12
    • Mostra profilo
    • RiK0 Tech Temple
Re:Ordinamento lessicografico stringa tramite funzione ricorsiva
« Risposta #17 il: Marzo 15, 2018, 12:13 »
Uhm, sì nel frattempo ho notato anch'io che questo voleva essere più un "esercizio sulle funzioni (probabilmente) ricorsive" che non un "esercizio sul sorting". E con un adeguato reframing concettuale, posso farcelo stare. Mi fa ancora storcere un po' il naso, trovo che farlo con le liste e gli interi sia comunque meglio.

Massi'...

Citazione
Poi, capisco e accetto tutto il tuo discorso pratico sul panorama della didattica dell'informatica come scienza che non esiste, e dei docenti di informatica come personale che spesso non esiste (nel senso, non ha la didattica nel contratto).

Non e' che i "professori di informatica" non ce lo hanno. E' cosi' che funziona l'universita' (in Italia, ma in realta' anche in tanti altri paesi... alcuni hanno un modello un po' diverso, che porta altri problemi).

Citazione
Io però non parlo mai di problemi reali e scenari reali. Parlo sempre solo di didattica e qualità della didattica in senso astratto. Che se vuoi è un po' spocchioso, ci sta. Ma secondo me è anche necessario perché se ci limitiamo sempre a constatare che il panorama è quello che è, nessuno si prenderà mai il compito di dire che l'imperatore è nudo, cioè che alla fine della giornata la qualità della didattica è *comunque* scarsa. Poi, che cosa si possa fare concretamente, questo è un altro discorso. Magari avrei delle idee, magari a parlarne potrebbero venire delle idee. Ma nel frattempo non possiamo continuare a buttare nel tritacarne soldi pubblici e studenti e docenti, e sperare che per caso salti fuori la ricetta per le polpette.

Scusa, i discorsi astratti sono tempo perso. Davvero. Funziona meglio concentrarsi su cose che si possono risolvere e cominciare da li. Fai esperienza. Poi fai un piano un po' piu' ambizioso e cosi' via.
La qualita' della didattica e' scarsa? E' come dire che la qualita' del software e della carpenteria sono scarse. E' tutto vero. Solo che e' inutilmente punitivo nei confronti di chi scarso non e'.

E' molto facile pontificare dal proprio salotto: bisognerebbe provare un po' a farle le cose. Nel senso, non te la prendere. Ma bisognerebbe anche provare a cambiare le cose "essendoci dentro". Parlare di come "andrebbero fatte le cose" ha un utilita' limitata. Forse si sarebbe meno astratti e molto piu' utile per risolvere gli stessi problemi per cui si sta tuonando.

Ma poi *davvero* il problema e' che la qualita' di programmazione I e' scarsa? A me verrebbe da dire (lo ho anche visto fare) di *toglierla* e assumere che la gente lo sappia fare. In effetti e' quello che ho visto fare in diversi corsi di eccellenza.
Siccome e' molto piu' facile formare eccellenze se si e' filtrato in entrata il peso morto, tanto vale. Voglio dire... a te a lettere mica ti hanno insegnato a scrivere come alle elementari. A me a matematica mica mi hanno fatto le tabelline. No?
Ma tutte cose astratte alla fine. Il punto e' che si parla di un non-problema.

Sinceramente trovo piu' grave quando si insegnano cose che sembravano essere una buona idea 20 anni fa. Problema relativo alla completa disconnessione che in molti atenei (fortunatamente non in tutti) si ha con la pratica. Tanto per dire.

Ma insomma.. parliamo parliamo: io davvero non conosco nessuna disciplina che riesce a formare gente davvero brava a partire da materiale di scarto. Forse dovremmo renderci conto che fare l'universita' non e' obbligatorio e fare un'universita' per gente che vuole davvero una marcia in piu'. E offrire diversa formazione per chi ha obiettivi diversi. Anche perche' non e' particolarmente chiaro cosa dovrebbe fare l'universita' (cioe' a parte renderti magicamente in grado di fare tutto). Vogliamo un'universita' teorica che ti da il framework generale e ti prepara per l'accademia? Poi non ci lamentiamo che gli studenti non sono pronti per il mondo del lavoro. Trasformiamo l'universita' in qualcosa di professionalizzante che ti rende in grado di inserirti facilmente? E poi ci lamentiamo che i laureati non hanno abbastanza capacita' di astrazione. Ah, vogliamo entrambi? Ok, allora dobbiamo aumentare il carico di lavoro. Ma poi perdiamo studenti. Etc etc etc.

O forse stiamo risolvendo un non-problema, perche' alla fine dei conti i nostri studenti se la cavano piuttosto bene nel mondo. Non e' ideale? Certo.
Sprechiamo potenziale? Forse. O forse no. Forse mandiamo fuori gente "brava" proprio perche' il metodo e' imperfetto. Paesi con didattica curata magari poi hanno studenti che si accartocciano quando li tiriamo nel mondo reale. Non so... non ho dati. E parlare senza dati va bene solo al bar alla quarta malvasia fra un porco e un carico a perdere giocando a briscola.

Citazione
In tutto questo, poi, va anche detto che gli esercizi sono notoriamente un aspetto molto difficile della didattica. La costruzione di un percorso di apprendimento è difficile, ma gli esercizi sono ancora più difficili perché (in teoria) sono il momento in cui affronti quello che "ancora non sai" ma sempre restando nei confini del terreno in cui puoi cavartela con "quello che già sai". E quindi bisogna bilanciare la tensione tra sapere e non-sapere. Lo stesso esercizio, formulato nello stesso modo, può essere un errore didattico in un certo momento e una genialata in un altro momento.
Il problema è che tu *vuoi* che gli allievi si perdano nel bosco, *ma* allo stesso tempo vuoi anche che non vadano a perdersi in direzioni troppo diverse da dove li vuoi mandare. Questo è sottile: se si perdono in direzioni troppo diverse, stai sprecando tempo: da un lato gli studenti non si interrogano (e quindi rafforzano la loro conoscenza) sulle cose che dovrebbero imparare in quel momento; dall'altro, annaspano in acque dove non hanno abbastanza appigli. Infine, probabilmente acquisiscono pattern sbagliati che poi è difficile individuare e correggere.
Attenzione, ripeto: questo è sottile. Se tu dai un esercizio sull'argomento A (le funzioni, passare argomenti e aspettarsi valori di ritorno... funzioni che chiamano altre funzioni... funzioni ricorsive... quelle cose lì) che però inavvertitamente porta nelle acque sconosciute dell'argomento B (i float... l'I/O... va a sapere), poi sicuramente tu puoi "approfittare" dello sbandamento per metterti ad affrontare l'argomento B. Ma è il modo sbagliato di affrontare l'argomento B (a meno che tu non abbia calcolato genialmente proprio tutto). Lo stai affrontando fuori tempo, lo stai prendendo magari dal verso più scomodo, eccetera. Infine, è vero che nella vita di tutti i giorni capita sempre di annaspare in acque profonde e imparare dagli errori. Ma appunto, questa è la *vita*, non la *didattica*. Se stai facendo didattica, hai la pretesa di insegnare in modo più efficiente di quanto farebbe la vita (compresi gli apprendistati artigianali, l'imparare dai propri errori, l'imparare dagli errori degli altri, il farsi da soli i propri percorsi... tutte cose utili, per carità - ma nella vita, appunto).

E il problema e' che non si puo' "insegnare a programmare". Non davvero. Si puo' *guidare* qualcuno. Certo. Ma bisogna scrivere decina di migliaia di righe di codice *e* avere qualcuno (bravo) che fa codereview e da suggerimenti. E questo non e' il ruolo di un docente. Non lo e' perche' non si puo' fare durare il corso di "programmazione I" per cinque anni (anche perche' poi non si hanno abbastanza problemi da risolvere via codice per scrivere quelle righe).

Quindi forse a Programmazione I basta dare i fondamenti a quelli che non hanno mai pensato che programmare fosse divertente e poi hanno deciso di fare informatica. Che nella mia testa vuole dire che dovrebbe essere un corso di cui si possa fare opt-out con un pre-esame. Ma vabbe'.

Citazione
Se io preparo un esercizio sulle funzioni e mi accorgo, testandolo, che è pesantemente dipendente dalle bizzarrie dei float (nel senso che è facile che gli studenti si perdano lungo questa strada), certamente mi chiederò se non ci sia un buon momento per fare una lezione sui float. E magari degli esercizi sui float. Magari una lezione a partire da un esercizio. Tutto buono, per carità. Ma nel frattempo, però, *modifico* il mio esercizio sulle funzioni in modo che i miei studenti si concentrino su quello che voglio. Così l'esercizio diventa troppo arido e astratto? Di nuovo, è colpa mia: devo complessificare l'esercizio, ma *restando* nell'area che mi interessa.
Fare buoni esercizi è un'arte.

Si, certo. Solo che non devi preparare un esercizio. Ne devi preparare centinaia. E devi fare anche altro.