L’Apocalisse del lavoro (che non arriva mai)…

Ci sono discussioni che sembrano scoppiare all’improvviso, come temporali estivi: rumorose, piene di lampi, ma raramente illuminate a giorno. Una di queste riguarda il lavoro e l’intelligenza artificiale.
Ogni settimana arriva un nuovo titolo: l’AI cancellerà milioni di posti, gli algoritmi prenderanno il posto degli umani, la fine del lavoro è vicina. Titoli perfetti per circolare sui social, molto meno per capire davvero cosa stia accadendo.
Se però si ha la pazienza di abbassare il volume e guardare meglio i numeri — che sono meno rumorosi ma più affidabili — la storia appare meno apocalittica e molto più complessa.
Prendiamo un caso recente: una grande azienda tecnologica annuncia licenziamenti massicci e li collega all’intelligenza artificiale. Il titolo corre veloce: AI sostituisce migliaia di lavoratori. Ma se si scava un poco sotto la superficie si scopre spesso che le cause sono altre: espansioni eccessive durante gli anni del boom tecnologico, pressioni degli investitori, riorganizzazioni interne. L’intelligenza artificiale diventa così una spiegazione semplice per una decisione molto più prosaica: ridurre i costi. È una narrazione comoda. Anche elegante, in un certo senso. Dire “stiamo tagliando perché abbiamo assunto troppo” è poco romantico. Dire “lo fa l’AI” è molto più moderno.
Eppure la storia dell’innovazione racconta qualcosa di più sobrio.
Negli ultimi quarant’anni ogni ondata tecnologica — automazione industriale, informatica diffusa, robotica — è stata accompagnata da profezie simili. Sempre lo stesso scenario: macchine sempre più intelligenti, lavoro umano sempre più inutile.
Poi, quasi sempre, succede un’altra cosa. Il lavoro non scompare. Cambia forma.
Quando si guardano con calma gli studi che analizzano decenni di trasformazioni tecnologiche nelle economie avanzate, emerge un quadro curioso: la tecnologia tende sì a sostituire alcune mansioni, soprattutto quelle più ripetitive, ma allo stesso tempo ne crea altre. Non sempre nello stesso luogo, non sempre nello stesso momento, ma comunque nuove. È un movimento più simile a una migrazione che a un’estinzione.
Questo non significa che il cambiamento sia indolore. Non lo è mai stato.
Chi svolge lavori più routinari o possiede competenze facilmente automatizzabili paga spesso il prezzo più alto delle trasformazioni tecnologiche. Ma da qui a immaginare un futuro senza lavoro ce ne corre parecchio. Anzi, alcune evidenze recenti raccontano qualcosa di ancora più curioso.
Nel settore dove l’intelligenza artificiale sembra più potente — lo sviluppo software — diversi esperimenti controllati mostrano risultati meno lineari di quanto si pensi. Gli strumenti generativi aiutano in alcune attività e rallentano in altre; i programmatori meno esperti ne beneficiano di più, mentre quelli molto esperti talvolta diventano perfino più lenti. E quasi tutti, indipendentemente dai risultati reali, sono convinti di essere diventati molto più produttivi.
Una piccola lezione di psicologia tecnologica: non sempre percepiamo bene cosa ci rende davvero più efficienti.
Perfino chi costruisce questi strumenti racconta una realtà più sfumata delle promesse pubblicitarie. L’intelligenza artificiale aiuta, certo, ma richiede supervisione continua, correzioni, verifiche. Più che sostituire il lavoro umano, spesso lo trasforma in qualcosa di diverso: meno esecutivo, più di controllo e interpretazione. In altre parole, il futuro assomiglia meno a un Armageddon e più a un grande cantiere.
Il problema allora non è tanto l’intelligenza artificiale, quanto il modo in cui ne parliamo. Le narrazioni apocalittiche sono affascinanti: vendono articoli, attirano attenzione, semplificano una realtà intricata. Ma hanno un effetto collaterale curioso. Spostano la discussione dalle domande importanti a quelle spettacolari. Non come cambieranno le competenze. Non quali politiche di formazione serviranno. Non come accompagnare chi rischia di restare indietro. Ma semplicemente: quanti lavori spariranno. È una domanda rumorosa, ma povera. Forse la questione più interessante è un’altra.
Gli strumenti di intelligenza artificiale sono potenti, sì. Ma funzionano soprattutto come amplificatori di ciò che gli chiediamo. Cambia il risultato, a volte radicalmente, semplicemente cambiando la domanda. È una proprietà tecnica dei modelli linguistici, ma anche una piccola metafora culturale. La tecnologia non è uno specchio neutro del futuro: è uno specchio delle nostre aspettative. Se la guardiamo con paura, ci restituirà paura. Se la osserviamo con metodo, potrà restituirci conoscenza.
Il punto non è dunque decidere se l’intelligenza artificiale porterà la fine del lavoro. Il punto è capire con pazienza, dati alla mano, cosa sta davvero cambiando.
Il progresso tecnologico non ha mai avuto il gusto dell’apocalisse. Ha sempre preferito qualcosa di molto più umano: il disordine lento delle trasformazioni. E forse, prima o poi, impareremo che tra una profezia e un’analisi scientifica c’è la stessa differenza che passa tra una cartomante e un laboratorio. Solo che la cartomante parla più forte.

Il diritto di dire: “non lo so (ancora)”

C’è una domanda che arriva sempre con quella gentilezza un po’ ingannevole delle cose semplici: “ci spieghi come funziona, davvero, questa roba qui?”. È una richiesta legittima. Anzi: è la richiesta più sana del mondo. Perché sotto, se la ascolti bene, non chiede la magia. Chiede il motore. Chiede la vite nascosta, il perché del rumore, il punto esatto in cui la macchina smette di essere “wow” e diventa “ah, quindi”.
Solo che, a volte, la risposta più onesta non è una spiegazione. È un rifiuto. Non per snobismo. Non per posa. Ma per un principio che oggi sembra quasi controculturale: la competenza non è un’opinione ben presentata. È una cosa rodata. È una cosa che si è sporcata le mani. Ci sono ambiti in cui puoi permetterti di capire “in teoria”. E altri in cui la teoria, se non ci hai litigato in pratica, ti illude. Ti fa credere di essere vicino, mentre sei solo bravo a stare in superficie. È come leggere un manuale di meccanica e poi pretendere di fare il docente di motori. O studiare i sistemi operativi, sapere le parole giuste, ricordare i nomi importanti, e scoprire — nel momento in cui provi a costruirne uno — che tra “capisco” e “so fare” c’è un oceano. Un oceano fatto di dettagli noiosi, bug infami, compromessi, limiti fisici, scelte che nessun libro ti dice come si prendono. Quella è la parte artigianale della conoscenza: non brilla, ma regge. E con le AI generative, oggi, questo oceano è diventato anche un temporale. Perché non siamo più nell’epoca in cui potevi seguire l’evoluzione con la calma di chi mette un piede dopo l’altro: un paper ogni tanto, una tecnologia che si sedimenta, un filone che ti dà il tempo di diventare “di casa”. A un certo punto la corrente accelera: modelli nuovi, architetture, varianti, ottimizzazioni, dataset, trucchi di training, allineamenti, pipeline che sembrano città intere. E la letteratura cresce con una rapidità che spesso non è profondità, è rumore. Troppa carta, troppo inchiostro, troppa voglia di essere “il prossimo”. E tu, se vuoi restare tecnico sul serio, devi scegliere: o ti ci chiudi dentro e lavori, o resti fuori e osservi.
In mezzo non si può. In mezzo si diventa pericolosi.
Perché il problema non è “sbagliare qualche dettaglio”. Il problema è che solo chi è davvero esperto sa quali dettagli sono dettagli e quali sono colonne portanti. Solo chi ha costruito sa cosa si può semplificare senza tradire, e cosa invece, se lo tagli, fa crollare tutto. È un bagno di umiltà, sì. Ma è anche igiene mentale. È la differenza tra divulgare e improvvisare. E allora forse ha senso accettare un ruolo più semplice e più onesto: quello dell’utente consapevole. Di chi usa lo strumento, lo mette alla prova, ne guarda gli effetti, e decide di parlare non del “come è fatto dentro” (che richiede mani e anni), ma di cosa fa a noi. A come cambia il nostro modo di leggere, di scrivere, di studiare, di ricordare. A come sposta la linea tra fatica e scorciatoia, tra comprensione e riassunto, tra pensiero e imitazione del pensiero. E qui si apre una strada bellissima: non quella dei tutorial tecnici travestiti da certezze, ma quella delle domande buone. Quelle che non danno l’illusione di aver capito tutto, ma ti costringono a capire meglio te stesso. Magari tornando, ogni tanto, ai classici. Non per nostalgia — la nostalgia è spesso una scusa elegante — ma perché alcune intelligenze del passato avevano una dote rara: sapevano guardare i cambiamenti senza esserne ubriacate. Sapevano mettere ordine nelle parole, prima ancora che nelle cose. E forse oggi, con tutte queste macchine che parlano, la cosa più urgente non è farle parlare meglio. È imparare di nuovo a capire quando stiamo parlando noi. E quando no. E se la risposta a “spiegaci come funziona” è “no”, non è una resa. È una forma di rispetto: per l’argomento, per chi lo padroneggia davvero, e per chi ascolta. Che meritava, semplicemente, la verità più pulita di tutte: non lo so abbastanza da spiegartelo bene. Ma so abbastanza da non mentirti.

Il secondo Commodore 64: perché Linux è ancora un giocattolo per adulti

Ci sono generazioni che si riconoscono da un rumore.
La mia, per esempio, la riconosci dal suono secco di un tasto “RUN/STOP”, dal gracchiare di un registratore a cassette, da quella riga blu con scritto “READY.” che ti guardava come una sfida più che come un messaggio di cortesia. Prima di avere “i computer”, abbiamo avuto il computer-giocattolo. Che non era un giocattolo nel senso di plastica colorata, ma nel senso serio del termine: un oggetto che ti chiede di essere toccato, smontato, travisato, forzato oltre il manuale d’uso. Il Commodore 64, il TI-99/4A, quegli 8 bit lì. Accendevi, e non c’era la schermata delle app. C’era un prompt. Non «che cosa vuoi fare», ma: «cosa sai dire». Non ti offriva programmi, ti offriva linguaggio.
Poi sono arrivati gli anni “seri”. MS-DOS, i primi PC “per il lavoro”, i software di contabilità, i word processor. Il computer cominciava a parlare la lingua delle fatture, non più quella dei sogni. Non ti chiedeva più di inventare: ti chiedeva di compilare. Uscivi dall’infanzia dell’informatica e entravi nell’età adulta: solida, utile, assolutamente necessaria. Anche un po’ noiosa. In mezzo, un passaggio quasi invisibile: da una macchina che ti invitava a programmare, a una macchina che ti invitava a consumare software. E poi, da qualche parte tra la fine dei ’90 e i primi anni Duemila, è arrivato quel coso strano che era troppo complicato per il grande pubblico e troppo “giocattolo” per l’industria: Linux. Io continuo a pensarci come al “secondo Commodore 64”. Non perché graficamente gli assomigliasse — anzi, spesso non assomigliava a niente di presentabile — ma per il ruolo che ha avuto. Linux non si installava perché “serviva per lavorare”. Per quello c’erano già i sistemi “seri”: Unix commerciale, Windows NT, le cose con le licenze, le brochure patinate e il supporto tecnico a pagamento. Linux lo installavi per vedere cosa c’era sotto il cofano. Per scoprire che faccia ha davvero un sistema operativo quando smetti di guardarlo dall’icona “Risorse del computer” e cominci a parlarci in shell. Era un sistema complicato, pieno di spigoli, spesso ostile. Ma era tuo.
Il gioco non era trovare la “killer app”. Il gioco era il sistema operativo stesso: far riconoscere una scheda di rete, ricompilare il kernel, capire perché quel demone non partiva al boot. Il divertimento era «capire». E questa, per quella generazione, somigliava moltissimo alla felicità.
Col tempo, però, ti accorgi che Linux non era solo quell’esercizio di stile di un ragazzo finlandese geniale. Era una specie di collante che teneva insieme decenni di storia Unix: pezzi di codice nati nelle università, negli AT&T Bell Labs, nei corridoi di Berkeley; strumenti scritti da gente che voleva solo un compilatore decente, un editor migliore, una shell più potente. Quando parlavi di “Linux”, in realtà stavi parlando di un mosaico: il kernel, i tool GNU, il codice di derivazione BSD, linguaggi buttati lì da ricercatori curiosi e rimasti perché “funzionavano”. Era, tecnicamente, un minestrone. Ma di quelli buoni, quelli che vengono da giorni e giorni di ingredienti aggiunti, di pentola che sobbolle, di assaggi e correzioni di sale. Mentre altrove si costruivano cattedrali eleganti e coerenti, con linee di codice scolpite come colonne ioniche, il mondo Linux cresceva come crescono i mercati rionali: disordinato, rumoroso, pieno di roba che non sai neanche bene da dove arrivi, ma nel complesso vivo, potentissimo. E la verità bruta è che ha vinto quello. Ha vinto il minestrone. Non perché fosse più bello, ma perché era più aperto, più rapido, più disposto a sporcarsi le mani. Mentre certi sistemi si prendevano il tempo di essere perfetti, Linux si prendeva il rischio di essere usabile, portabile, adattabile. Smetteva di chiedersi “sono puro?” e cominciava a chiedersi “giro qui? giro là? posso stare anche su quell’architettura?”. E così, quasi per accumulo, da giocattolo per smanettoni è diventato il pavimento su cui appoggiava i piedi mezza Internet. LAMP non è mai stato uno slogan particolarmente poetico, ma ha raccontato una rivoluzione: Linux, Apache, MySQL, PHP. Start-up che nascevano su server che nessuno aveva pagato in licenze, studenti che montavano siti in cameretta usando software che nessun consiglio di amministrazione aveva scelto per loro.
Quando una tecnologia smette di essere “divertente” e diventa “infrastruttura”, succede una cosa strana: vince, ma si mimetizza. Oggi Linux è dappertutto e quasi mai si vede. Sta dietro a router, server, telefoni, televisori, auto, perfino lavatrici. È passato dal feticcio dell’hacker alla condizione atmosferica: è “l’aria di fondo” dell’informatica contemporanea. Ed è proprio lì che un po’ di magia si perde. Perché quando qualcosa diventa indispensabile, smette di sembrare interessante.
I ragazzi di oggi non vedono più il prompt come un invito all’avventura: vedono l’icona della rete che non va, il wifi che cade, il login che non si ricorda la password. Vedono il lato “sistemista” del gioco, non quello esplorativo. L’idea che si possa installare un sistema operativo “solo per vedere come funziona” sembra quasi una stramberia da adulti nostalgici. E forse, in parte, lo è. Ma è una stramberia che mi piacerebbe rivendicare con orgoglio.
Penso che servirebbe tornare a parlare di Linux — e, più in generale, dei sistemi aperti — con un po’ di hype. Non l’hype da keynote con i droni sul palco e le parole “magico”, “incredibile”, “mai visto prima” ripetute come un mantra. Un hype onesto, artigianale: quello negli occhi di chi ti racconta una cosa che ha provato, che conosce, che gli è costata ore di sbattimenti ma gli ha lasciato addosso la sensazione precisa di aver capito qualcosa in più del mondo.
Ogni tanto capita di incontrare persone che, quando parlano di hardware, di driver, di kernel, si illuminano. Non fanno divulgazione per mestiere, non vendono corsi: stanno semplicemente condividendo una gioia, una mania, un pezzo di identità. In quei momenti ti ricordi perché avevi acceso il primo computer non per mandare una mail, ma per vedere cosa succedeva se scrivevi 10 PRINT "CIAO" e poi 20 GOTO 10. E allora ti viene questa idea un po’ assurda: comprarti un portatile non perché ti serve, ma perché vuoi appartenerci di nuovo. Non un ultrabook perfetto per la produttività, non il mostro da gaming con i LED ovunque. Un laptop onesto, smontabile, su cui installare una distribuzione solo per il gusto di vedere cosa va, cosa non va, cosa devi piegare, che incantesimi bisogna recitare per far riconoscere la GPU o far andare lo standby. Non ti serve per lavorare: per quello hai già la macchina solida, ottimizzata, senza sorprese.
Ti serve per giocare sul serio. Per fare quello che facevi a dodici anni, ma con la consapevolezza di adesso: aprire un terminale, tirare giù un sorgente, leggere un man, perdersi in una configurazione, rompere qualcosa e doverlo sistemare. Non perché sia “utile”, non perché ci farai soldi, ma perché credi ancora che dietro quei processi, quei log, quei file in /etc si nasconda una lingua che vale la pena di imparare.
Forse questo, oggi, è il vero gesto controcorrente: usare una macchina potente non per produrre di più, ma per capire di più. E magari, nel farlo, farti vedere da qualcuno più giovane di te. Un figlio, uno studente, un ragazzo che pensa che il computer sia solo la scatola dove girano social e videogiochi. Fargli vedere che esiste un livello in più, sotto i menù e sopra l’hardware, dove le cose non si scaricano soltanto: si costruiscono. Non so se basterà a cambiare qualcosa. Ma so che, per una certa generazione, Linux è stato davvero il secondo Commodore 64. E che forse è arrivato il momento di trattarlo di nuovo così: non come una presenza scontata, ma come un invito.
Accendi, appare il prompt, lampeggia un cursore.
Ti chiede, ancora una volta: non “cosa devi fare”.
Ma: “cosa vuoi imparare a dire”.

Il Problema 10 del Project Euler…

Il Problema 10 del Project Euler, che richiede di calcolare la somma di tutti i numeri primi inferiori a due milioni, offre una finestra affascinante nel mondo della matematica e dell’informatica. I numeri primi, da sempre al centro della teoria dei numeri, trovano applicazioni in diversi campi, dalla crittografia all’analisi numerica. Il problema, apparentemente semplice, cela sfide computazionali non trascurabili, soprattutto considerando la grandezza del numero limite, due milioni. Qui di seguito un codice in Python che prova a risolvere il problema:

# Il codice che segue risolve il problema 10 del Project Euler:
# https://projecteuler.net/problem=10

# La somma dei primi 10 numeri primi è 2 + 3 + 5 + 7 = 17.
# Trova la somma di tutti i numeri primi minori di due milioni.


def is_prime(n):
# Funzione che restituisce True se il numero n è primo, False altrimenti
# (utilizza il teorema di Fermat)

    if n <= 1:
        return False
    for i in range(2, int(n**0.5) + 1):
        if n % i == 0:
            return False
    return True

def sum_of_primes_below(n):
# Funzione che restituisce la somma di tutti i numeri primi minori di n
    primes_sum = 0
    for i in range(2, n):
        if is_prime(i):
            primes_sum += i
    return primes_sum

result = sum_of_primes_below(2000000)
print(result)

Il codice Python proposto per affrontare questa sfida si compone di due funzioni principali: is_prime(n) per determinare se un numero è primo, e sum_of_primes_below(n) per calcolare la somma di tutti i primi inferiori a un dato numero n. La funzione is_prime(n) utilizza un approccio basato sul teorema di Fermat, che prevede di testare i divisori di un numero da 2 fino alla sua radice quadrata. Questo metodo è efficace e corretto, ma quando si tratta di numeri molto grandi, come nel nostro caso, la sua efficienza diventa un fattore critico. Ogni numero viene testato individualmente per la primalità, un processo che diventa progressivamente più lento man mano che n cresce.

L’approccio di sum_of_primes_below(n) segue una logica diretta: iterare su tutti i numeri da 2 fino a n-1, sommando quelli che risultano primi. Anche qui, la semplicità del metodo porta con sé questioni di efficienza, specialmente data la grandezza del numero limite.

In un’ottica di ottimizzazione, sarebbe consigliabile esplorare algoritmi più efficienti come il crivello di Eratostene o il crivello di Atkin, noti per la loro capacità di ridurre drasticamente il numero di operazioni necessarie identificando e scartando i multipli di numeri già riconosciuti come non primi. Questi metodi non solo accelerano il processo di identificazione dei numeri primi ma sono anche più scalabili quando si lavora con intervalli numerici estesi.

Il problema, dunque, sebbene intrinsecamente matematico, ha profonde implicazioni in ambito informatico, specialmente nell’ottimizzazione algoritmica. La ricerca della soluzione non solo offre una dimostrazione dell’applicazione pratica dei numeri primi ma sottolinea anche l’importanza di considerare l’efficienza computazionale, soprattutto quando si affrontano problemi su larga scala. Questa sfida rappresenta un esempio eccellente di come problemi teorici possano essere trasformati in applicazioni pratiche, fornendo opportunità per l’esplorazione e l’innovazione nel campo dell’ingegneria e dell’informatica.

Rediscovering Aesthetics of Yesteryears with smplotlib: A Bridge to SuperMongo Styling in Modern Data Visualization

In a domain where the phrase “a picture is worth a thousand words” rings particularly true, the journey of data visualization has witnessed a metamorphosis from simplistic graphs to today’s highly interactive and dynamic plots. Amidst this evolution, the quaint charm and professional allure of old-school styling inherent in figures from erstwhile technical papers have garnered a unique reverence. It’s this vintage aesthetic that smplotlib, a Python library, strives to emulate, providing a bridge to the venerable SuperMongo (SM) aesthetics in the modern realm of Python-based data plotting.

Installation:

pip install smplotlib

Let’s delve into the utilization of smplotlib with a hands-on example. Though it’s important to note that smplotlib appears to be a personalized or auxiliary library, the following example demonstrates how one might structure a complex plot using matplotlib, and it’s here where smplotlib could potentially be integrated to imbue the plot with a vintage aesthetic, assuming smplotlib provides such styling functionalities.

import matplotlib.pyplot as plt
import numpy as np
import smplotlib  # Assuming smplotlib provides styling functionalities

# Generate some data
x = np.linspace(0, 10, 100)
y1 = np.sin(x)
y2 = np.cos(x)
y3 = np.tan(x)

# Create the plot
fig, ax = plt.subplots()

# Plot the functions
ax.plot(x, y1, label='sin(x)')
ax.plot(x, y2, label='cos(x)')
ax.plot(x, y3, label='tan(x)')

# Add labels and legend
ax.set_xlabel('X-axis Label')
ax.set_ylabel('Y-axis Label')
ax.set_title('Trigonometric Functions')
ax.legend()

# Set axis limits for better visualization
ax.set_ylim([-10, 10])

# Assuming smplotlib provides a function called style_plot (this is a made-up function, as smplotlib's actual usage is not clear)
# smplotlib.style_plot(ax)  

# Show the plot
plt.show()

In the code snippet above:

  1. We utilize numpy to generate a series of x values and calculate y values for sine, cosine, and tangent functions.
  2. We employ plt.subplots() to create a figure and axis for plotting.
  3. The ax.plot() method is used to plot each function, specifying a label for each that will be used in the legend.
  4. Labels for the axes, a title for the plot, and a legend indicating which line corresponds to which function are added using ax.set_xlabel(), ax.set_ylabel(), ax.set_title(), and ax.legend() respectively.
  5. ax.set_ylim() is used to limit the Y-axis to a range that makes the graph readable, as the tangent function has vertical asymptotes that would otherwise “zoom out” the graph.
  6. A hypothetical smplotlib.style_plot(ax) function is invoked to style the plot, assuming such a function exists in smplotlib.

This piece of code illustrates how one can create a more complex plot and incorporate labels using Matplotlib. It’s a placeholder where smplotlib could potentially be utilized to apply vintage styling, aligning with the aesthetic of old-school technical papers.

smplotlib encapsulates more than just a stylistic add-on; it’s a homage to the timeless essence of clarity and precision that were the hallmarks of figures in bygone eras. The ability to recreate such an aesthetic in today’s fast-evolving visualization landscape not only pays homage to the past but also provides a stylistic choice that stands out amidst modernist designs.

This library is an open-source initiative, hosted on GitHub, welcoming contributions from anyone resonating with the cause of preserving the classical styling in contemporary data storytelling.

In an academic and professional world that’s continually chasing the ‘new’, smplotlib offers a quaint respite, taking one back to the roots where simplicity and elegance were the narrators of data tales.

Visualizing the Möbius Strip in Python…

The formulation of the Möbius strip involves a parameterization in terms of two variables: \theta, which is an angle that varies from 0 to 2 \pi, and w, which is a distance from the centerline of the strip and varies between -1 and 1.

Given these parameters, the (x, y, z) coordinates for points on the Möbius strip can be determined using the following equations:

import numpy as np
import matplotlib.pyplot as plt

# Create a Möbius strip
theta = np.linspace(0, 2 * np.pi, 100)
w = np.linspace(-1, 1, 20)
theta, w = np.meshgrid(theta, w)
phi = 0.5 * theta
r = 1 + w * np.cos(phi)
x = np.cos(theta) * r
y = np.sin(theta) * r
z = w * np.sin(phi)

# Plot the Möbius strip
fig = plt.figure()
ax = fig.add_subplot(111, projection='3d')
ax.plot_surface(x, y, z, edgecolor='k', color='c')
ax.view_init(50, 30)  # Adjust view angle for better visualization
ax.set_title('Möbius Strip in 3D')
plt.show()

Visualization Strategy:

  1. Parameter Space Definition: We begin by defining our parameter space for θ and w. The variable θ spans the entire 360-degree range of the strip, while w varies between -1 and 1 to account for the width of the strip.
  2. Meshgrid Creation: Using NumPy’s meshgrid function, we create a grid of points in the (θ, w) parameter space. Each combination of (θ, w) corresponds to a unique point on the Möbius strip.
  3. Position Calculation: For every combination of (θ, w), we compute the x, y, and z coordinates using the above equations.
  4. 3D Plotting: Using Matplotlib’s 3D plotting capabilities, we then plot the computed (x, y, z) coordinates as a surface. The edgecolor is set to ‘k’ (black) to distinguish between individual segments on the strip, and color is set to ‘c’ (cyan) for the surface color.
  5. View Angle Adjustment: The line ax.view_init(50, 30) adjusts the view angle of the 3D plot, making it easier to perceive the Möbius strip’s twist.

unico confine: la fantasia…

L’esperienza di generare immagini attraverso l’intelligenza artificiale è come avere a disposizione un intero mondo di possibilità creative, pronto a prendere forma secondo i propri desideri. Basta chiudere gli occhi e in un attimo ecco schiudersi scenari mai visti, figure e luci che danzano nell’immaginazione. Poi, affidandosi alla magia di poche parole sapientemente intrecciate, quel mondo interiore prende vita sulla pagina. Ogni frase dipinge un nuovo dettaglio, ogni aggettivo modifica luce e profondità. Le parole creano ombre e volumi con la precisione di un artigiano. Si resta incantati nel vedere quelle visioni trasformarsi in realtà, emergendo linea dopo linea dal foglio prima bianco. È un’esperienza che spinge al limite la creatività, portandola dove non avrebbe mai osato. L’unico confine è la fantasia di chi scrive. Si prova l’ebbrezza di plasmare mondi sconosciuti con la semplice forza dell’immaginazione. Ogni scena che prende forma è una sorpresa. Ogni dettaglio aggiunto apre nuovi sentieri da esplorare. È un viaggio che regala continue scoperte. Basta chiudere gli occhi e immaginare, fiduciosi che le parole sapranno dare vita ai sogni.

Introduzione al web scraping: tecniche e strumenti per l’estrazione di dati

Web scraping is a technique that allows extracting and processing large amounts of unstructured data from the web through automated scripts that analyze the HTML structure of pages to identify and acquire the desired information; it allows quickly obtaining large amounts of online data for research, monitoring and data analytics, for example by extracting all prices and descriptions from an e-commerce site; the core Python libraries for scraping are Requests to download page content, BeautifulSoup to analyze HTML, and Selenium to handle dynamic pages with JavaScript; with BeautifulSoup it is possible to navigate the HTML as a tree of objects, searching and finding elements through tags, id, class and attributes; for scraping sites with multiple pages, loops can be used that visit each URL in automatic sequence; by adopting best practices with these tools it is possible to create effective, scalable and automated scraping scripts to extract and process large volumes of unstructured data for research, monitoring and data analytics purposes.


Il web scraping è una tecnica fondamentale per raccogliere ed elaborare grandi quantità di dati dal web. In questo articolo analizzeremo in dettaglio i concetti chiave, le migliori pratiche e gli strumenti necessari per iniziare a fare web scraping in modo efficace.

Cos’è il web scraping

Il web scraping consiste nell’estrarre e raccogliere dati da pagine web tramite script automatizzati. Funziona analizzando la struttura HTML delle pagine per identificare e acquisire le informazioni desiderate.

Il principale vantaggio dello scraping è la possibilità di ottenere velocemente un grande volume di dati non strutturati da fonti online per scopi di ricerca, monitoraggio, data analytics. Ad esempio, è possibile estrarre tutti i prezzi e le descrizioni da un e-commerce per analizzarne le dinamiche nel tempo.

Preparazione dell’ambiente

Per iniziare a fare web scraping in Python, è necessario installare alcune librerie fondamentali:

  • Requests: permette di scaricare il contenuto HTML delle pagine web
  • Beautiful Soup: analizza l’HTML e permette di estrarre facilmente dati selezionati
  • Selenium: per interagire con pagine web dinamiche che richiedono l’esecuzione di codice JavaScript

Si possono installare tramite il comando pip:

pip install requests beautifulsoup4 selenium

Scraping di base con Requests e BeautifulSoup

Importiamo le librerie necessarie:

import requests 
from bs4 import BeautifulSoup

Scarichiamo il contenuto HTML di una pagina con Requests:

url = 'https://example.com'
response = requests.get(url)

Analizziamolo con BeautifulSoup per estrarre il titolo e i paragrafi:

soup = BeautifulSoup(response.text, 'html.parser')
title = soup.title.text 
paragraphs = soup.find_all('p')

E scriviamo i dati estratti su file CSV per un’ulteriore elaborazione:

import csv
with open('output.csv', 'w') as file:
    writer = csv.writer(file)
    writer.writerow([title])
    for p in paragraphs:
        writer.writerow([p.text])

Navigazione nella struttura HTML

BeautifulSoup mette a disposizione una serie di metodi per scorrere ed esplorare l’HTML come albero ad oggetti:

  • find() ricerca il primo elemento corrispondente
  • find_all() restituisce tutti gli elementi corrispondenti

Ad esempio, per estrarre tutti i link di una pagina:

links = soup.find_all('a')
for link in links:
   print(link['href'])

È possibile ricercare elementi tramite id, classe o altri attributi per individuare precisamente i dati desiderati.

Scraping di pagine JavaScript dinamiche

Molti siti web moderni utilizzano JavaScript per generare contenuti e pagine dinamicamente. In questi casi, è necessario Selenium, che consente di controllare un browser web per interagire pienamente con le pagine.

Ad esempio, per caricare una pagina dinamica e cliccare su un pulsante prima di scaricarne il contenuto:

from selenium import webdriver
driver = webdriver.Chrome()
driver.get(url)
button = driver.find_element_by_id('load-more')
button.click()
html = driver.page_source
soup = BeautifulSoup(html)

Gestione di pagine multiple

Per scaricare dati da siti web con più pagine, è possibile realizzare script che visitano ogni URL utilizzando cicli e paginazione automatica.

Ad esempio, per estrarre prodotti da un e-commerce con più pagine:

import requests
from bs4 import BeautifulSoup
base_url = 'https://example.com/products?page='
final_page = 10
for x in range(1, final_page+1):
    print(f'Page {x}')
    url = base_url + str(x)
    
    response = requests.get(url)
    soup = BeautifulSoup(response.text)
    
    products = soup.find_all('div', class_='product')
    
    for product in products:
         name = product.find('h2').text
         print(name)

Come abbiamo visto, il web scraping è una tecnica potente che permette di ottenere ed elaborare grandi moli di dati non strutturati da fonti online. Requisiti fondamentali sono librerie come Requests, BeautifulSoup e Selenium, che consentono di automatizzare il processo di estrazione dati anche da pagine web complesse e dinamiche. Adottando le migliori pratiche illustrate e una strategia strutturata, è possibile realizzare script di scraping efficaci e scalabili per progetti di data analytics, monitoraggio, ricerca e altro ancora.

SymPy: Un Viaggio nella Matematica Simbolica con Python – Dal Calcolo Basico alle Applicazioni Avanzate…

SymPy è una libreria open-source di Python dedicata alla matematica simbolica, che permette la manipolazione algebrica di espressioni matematiche senza approssimazioni numeriche. A differenza di altri sistemi di calcolo numerico, SymPy rappresenta i numeri come simboli, consentendo calcoli esatti. Ad esempio, la divisione di 1 per 3 è rappresentata come una frazione 1/3, piuttosto che come un numero decimale approssimato. Utilizzando SymPy, è possibile svolgere operazioni di base come la semplificazione, l’espansione e la fattorizzazione di espressioni matematiche. Ad esempio, per espandere un prodotto notevole si può scrivere:

SymPy è anche in grado di risolvere equazioni algebriche, differenziali e integrali. Per esempio, può risolvere un’equazione differenziale ordinaria del primo ordine:

Inoltre, SymPy offre strumenti avanzati per la geometria, la teoria dei numeri, la combinatoria e molto altro, rendendolo adatto a vari campi scientifici. Con le sue funzionalità per la manipolazione di matrici, è possibile anche lavorare con l’algebra lineare, come nell’esempio seguente:

SymPy è altamente estensibile e personalizzabile, permettendo agli utenti di definire funzioni simboliche personalizzate, creare nuovi tipi di oggetti e interfacciarsi con altre librerie scientifiche di Python. Con un’ampia documentazione e una comunità attiva, SymPy è un potente strumento sia per chi si avvicina alla matematica simbolica per la prima volta, sia per ricercatori e professionisti che necessitano di calcoli simbolici avanzati e precisi.

:wq!

https://twitter.com/vimlinks/status/1687833458104508416?s=46&t=CtqLErAyfPWDldFpeVn91g