Capitolo sulla Programmazione Funzionale

[m1gwings]

Paragrafi da scrivere: (WIP: by @Furrrlo )

• [x] Definizione (by @francescogemma)
• [x] Interfacce funzionali (includendo quelle notevoli Function, ..., Predicate e spiegando il Comparator) (by @francescogemma )
  • [x] Aggiungere i nomi dei metodi dichiarati dalle interfacce funzionali (by @francescogemma , @Furrrlo )
• [x] Espressioni lambda (by @francescogemma)
• [x] Stream (il sottoparagrafo sul collector andrebbe arricchito ma è di secondaria importanza) (by @francescogemma)
  • [x] Collectors.toSet() (by @Furrrlo )
  • [x] reduce
  • [x] overloading di reduce che restituisce un optional (usaro nel TDE del 2022-02-07, esercizio 3, domanda b) (by @Furrrlo )
  • [x] min e max (secondari ma possono essere utili) (by @Furrrlo )
  • [x] mapToInt, average e sum per le IntStream (sono sulle slide a pag. 41, servono nel TDE del 2022-07-21, esercizio 4, domanda a) (by @Furrrlo )
  • [x] anyMatch (secondario ma può essere utile) (by @Furrrlo )
• [x] Optional (by @francescogemma)
• [x] Esercizio da tema d'esame (by @francescogemma)
• [x] Closures (di secondaria importanza) (by @Furrrlo )
• [ ] (Secondario) Method reference

[m1gwings]

Dovremmo cambiare sort in sorted nella lista di metodi definiti su una stream, dato che sort da quel che ho visto non è tra i metodi.

[Furrrlo]

Volendo potrei occuparmene io, però non ho esattamente seguito quello che ha fatto quindi potrei aggiungere roba che effettivamente non serve.

A me viene in mente:

• Collectors base come toList(), toCollection(supplier), join con overload che accettano separatore, prefisso e suffisso
• toArray()
• collettori più complessi come toMap(keyMapper, valueMapper), e groupingBy che ti permette di fare Map<K, Collection
• Stream di tipo primitivo, in particolare per gli int si può mappare a int con mapToInt() e poi chiamare operazioni di riduzione direttamente come sum(), avg(), etc
• oltre a anyMatch c'è anche noneMatch
• differenza tra l'operatore reduce e i Collectors (specifica di Java). Questo può essere utile in particolare perché tipo in JavaScript si usa reduce anche per creare collezioni, mentre in Java se non sbaglio (dovrei controllare) non puoi per come sono definite le signature di reduce
• metodi per creare comparatori più facilmente. In particolare dovrebbe esserci Comparators.comparing(Function<T, Comparable>) (e overload con primitivi) che facilita di molto il comparare oggetti per campi specifici già comparabili, e poi anche reverseOrder per cambiare l'ordine di uno già esistente

[m1gwings]

Mi sembrano tutte cose valide e che potrebbero essere utili! Magari per adesso ometterei i collettori più complessi e la differenza tra reduce e i Collectors, che possiamo lasciare in forse ed aggiungere alla fine se il cheatsheet non sarà già un papiro (dato che poi ce lo dobbiamo stampare). Il resto invece direi che effettivamente andrebbe aggiunto, magari dando priorità alle cose che possono essere utili più di frequente nei TDE, quindi se ti va, lavoraci pure! Intanto ti "aggiungo" tra quelli che stanno lavorando al capitolo.

[Furrrlo]

Domanda: nella sezione della reduce, viene detto https://github.com/m1gwings/ing-sw-cheatsheet/blob/1ff9b0a6412adaf2c6c4de89abc0ff3ff73cc141/programmazione-funzionale.md?plain=1#L196-L200

Questo non è propriamente sbagliato, ma da specifica il metodo non è obbligato a fare così, infatti in uno stream parallelizzabile è più probabile che faccia

0 + 30 -+
        +- 30 + 40 = 70  +
0 + 40 -+                | 
                         +--- 110 + 70 = 180
0 + 50 -+                | 
        +- 50 + 60 = 110 +
0 + 60 -+

e fino a qui tutto ok. Il caso il cui cambia è però quando viene specificata un'identità sbagliata:

1 + 30 -+
        +- 31 + 41 = 72  +
1 + 40 -+                | 
                         +--- 112 + 72 = 184 e non 181
1 + 50 -+                | 
        +- 51 + 61 = 112 +
1 + 60 -+

e qui si vede che non funziona, perché l'identità non è un semplice valore iniziale, ma deve essere l'identità della funzione passata nel senso matematico del termine.

Tra l'altro questa cosa ritorna anche nella collect, dove un collector alla fine è la factory di una collezione, un accumulatore che aggiunge un dato in una data collezione e una funzione che unisce due collezioni in una unica:

[] + 30 -+
         +- [30] + [40] = [30, 40]  +
[] + 40 -+                          | 
                                    +--- [30, 40] + [50, 60] = [30, 40, 50, 60]
[] + 50 -+                          | 
         +- [50] + [60] = [50, 60]  +
[] + 60 -+

e, come prima, se nella factory restituisci [1] al posto di [], avrai nella collezione finale anche [1, 1, 1, 1]

La domanda è: questa cosa è utile all'esame?

[m1gwings]

Grazie mille della correzione 👍🏼 , sinceramente non lo sapevo. Il comportamento che hai evindenziato si verifica solo quando si richiama parallel oppure no? Perché nel primo caso secondo me si può omettere dato che non credo venga richiesto di fare riduzioni parallelizzate e sicuramente è un po' più facile ragionare su come implementare la reduce nella versione semplificata spiegata nel cheatsheet. Magari potremmo specificare che vale solo se non si invoca parallel. Altrimenti, nel secondo caso, se il comportamento è sempre quello, allora va specificato, perché ragionando sulla versione semplificata si ottengono risultati sbagliati come hai mostrato.

[francescogemma]

Sì, il campo identità è effettivamente l'identità della funzione nella reduce, quindi quando si invoca parallel si usano le proprietà dell'identità per ottimizzare le operazioni, e questo porta ad errori se non si considera l'identità come tale. Tuttavia, nel caso in cui non dobbiamo usare parallel quel campo può essere considerato come il valore iniziale; sinceramente penso proprio che all'esame non richieda di usare gli stream paralleli (non li ho mai visti nei temi d'esame), infatti non ne ho neanche parlato nel capitolo.

[Furrrlo]

Il comportamento che hai evindenziato si verifica solo quando si richiama parallel oppure no?

Da specifica del metodo il comportamento si può verificare sempre, da implementazione di OpenJDK (e dal buon senso) avviene solo se parallelizzi lo stream (che se crei tu lo stream è una cosa che sai, se invece ti viene passato eg. per parametro non lo sai a priori).

Onestamente non credo serva, anche perché nelle reduce viene quasi sempre naturale specificare un'identità, quindi a meno che in un esame:

• chieda una riduzione in cui il valore iniziale non corrisponde all'identità (eg. devi fare sum() + 3)
• il prof sia particolarmente stronzo e decida di aderire strettamente alla specifica quando corregge

non credo serva metterlo

[m1gwings]

Ok, perfetto 👍🏼