Riesumare thread così vecchi è, in genere, una pessima idea.
Inoltre la richiesta non ha particolare attinenza con la teoria dei linguaggi e dei metodi formali: ciò di cui si parla è invece una applicazione della IA, in realtà situata in un territorio di sovrapposizione tra sistemi per la produzione di regole (motori inferenziali) e le classiche reti neurali artificiali ANN.

Software come Holsys sono comunque letteralmente unici nel loro genere: a meno che tale approccio non esploda improvvisamente in una nuova moda accademica (come è già successo, ad esempio, alle reti di apprendimento bayesiane "con rinforzo"), difficilmente c'è da attendersi di vederne dei cloni, gratuiti o magari anche opensource. A fortiori, è difficile pensare di trovare chi si sia sobbarcato lo sforzo di elaborare una interfaccia GUI user-friendly per un tale software: siamo a livelli enormemente lontani dalla sofisticazione ed evoluzione di storici sistemi constrained e rule-based come Ilog (CPLEX per i più giovani), Chip ed Eclipse.

Per i testi, non mi limito a proporre due o tre titoli: il mio consiglio è quello di orientarsi sulla famiglia di testi sul (visual) C# della O'Reilly e sulla serie "Step by step" di Microsoft Press. Naturalmente in questo settore è opportuno fare riferimento ad una versione corrente del framework e del linguaggio, il che restringe il campo editoriale alle uscite degli ultimi due/tre anni.

I "programmatori" PHP sono molto richiesti e poco pagati, proprio perché l'eccessiva semplificazione e destrutturazione del linguaggio abbassa in modo rilevante le barriere d'ingresso, escludendo la necessità di una solida piattaforma logica e informazionale. Ne consegue un rapido turnover di personale con background inconsistente, e conseguente produzione di codice-spazzatura che affligge la maggior parte della codebase PHP esistente - aiutata, invero, dalla totale mancanza di progettazione del linguaggio, che nella più tipica delle parabole ingegneristiche discendenti ha implementato solo ieri, e in modo comunque incoerente, features che altri linguaggi della medesima generazione presentano nativamente fin dalle versioni beta.   


Sulla filosofia, al di là delle simpatiche punzecchiature goliardiche, cuicumque suis. Personalmente, come logico trovo assolutamente naturale la contiguità con gli analitici e una stretta parentela con Husserl e Kant. Come lettore dilettante della storia delle idee, riconosco che i continentali hanno continuato a puntare il dito su problemi che gli analitici hanno escluso dal novero filosofico, per la mancanza di strumenti razionali atti non solo a risolverli, ma perfino a descriverli.
Oggi il contrasto è in gran parte superato, secondo una vasta maggioranza (a me sfugge comunque come potrei comporre Heidegger con Quine, per dire... sia pure facendo perno attorno ad Husserl) ma rimane il problema di come definire la filosofia, se disciplina formale dei fondamenti (come ancor oggi fa Franca d'Agostini) o "qualcos'altro" di un po' meno occidentale.

Ammetto che il motto "primum vivere, deinde philosophare" abbia una sua ragionevolezza, ma la domanda è: perché, con tutte le dozzine di linguaggi eccellenti che esistono, andare a pescare proprio quella schifezza ignobile di php? Dal punto di vista filosofico sarebbe come dedicare una vita a studiare gli scritti filosofici di padre Marino Mersenne, o forse di qualcuno ancor più insignificante a fronte di Platone, Kant, o della filosofia analitica tutta.

Se vuoi davvero imparare a programmare in cambio di vil danaro, appropriati innanzi tutto di un framework (ad esempio, dotnet) e impara almeno una terna di linguaggi: Python, C#, e magari in seguito F# per orientarti su un paradigma non banale.


PS: Comunque oggi i filosofi trovano lavori interessanti assai più facilmente dei programmatori web: vedi ad esempio Francesco Berto o Luciano Floridi. Certo, se mi diventi una specie di Rorty o un seguace di Guattari e Deleuze, oltre a non rivolgerti più la parola (purtroppo sono allergico ai continentali in ogni grado di parentela...), temo che di lavoro ne troverai veramente poco... 

Per fortuna esistono i forum e gli esperti, che sanno fornire un orientamento definitivo nel vasto universo della IT.
Il tuo viaggio di mille leghe inizia allacciandosi i calzari... cioè con lo studio dell'architettura del calcolatore e le istruzioni atomiche a livello di Assembly x86. Al secondo posto, un ottimo libro per sophomore è lo Sprankle "Problem solving and programming concepts", che ti insegna la logica della programmazione PRIMA di parlare di linguaggi di programmazione. Per il resto, su questo sito abbiamo bibliografie tematiche realmente complete e aggiornate su una moltitudine di argomenti...

Innanzi tutto, fai un bel respiro profondo. Inspira, trattieni, espira contando ogni volta fino a cinque prima di passare alla fase successiva. E ricordati di non prendere mai decisioni importanti a stomaco vuoto...

Ricordati sempre che programmare è un'arte, mentre quello che ti fanno fare nella tua azienda, nel migliore dei casi, è come mettere un Raffaello Sanzio o uno Jan Vermeer a comporre gli identikit di spacciatori e rubagalline per la questura.

Se vuoi davvero imparare a programmare, esiste una sola via, impervia e tortuosa, ma è l'unica che porta al successo. Tutte le scorciatoie (e tutti i linguaggi impuri) portano invece all'inferno dei cattivi programmatori. Devi solo avere la capacità di concentrazione necessaria a scindere il particolare ambito lavorativo dalla vera informatica.

Per superare i tuoi problemi di motivazione e concentrazione, devi inoltre privilegiare i testi americani per sophomore e junior years, in pratica quelli per il bachelor e in qualche caso anche per il college: hanno il dono della chiarezza, una notevole ridondanza espositiva e un metodo di lavoro "baby steps" per piccoli obiettivi semplificati e molto focalizzati. Una volta apprese le basi in quel modo, potrai affrontare testi più seri, che rendano conto della reale dimensione e complessità degli argomenti trattati.

Benvenuto. L'argomento è decisamente una FAQ ed è stato affrontato ormai un'infinità numerabile di volte. Questo post, ad esempio, è un ottimo punto di partenza...

Assolutamente NO.

In linguaggio C il programmatore è obbligato a conoscere a compile time il tipo, ovvero in ultima analisi la dimensione, di qualsiasi variabile o aggregato di variabili. Punto e basta. Non esistono eccezioni a questa regola, come non ne esistono in Assembly. Nella manciatina di casi in cui, pur potendola e dovendola conoscere, è necessario produrre codice che deve fingere di ignorare tale informazione (vedremo casi del genere in calce al presente post), si deve comunque procedere lavorando per byte, ovvero per unità atomiche rispetto all'architettura fisica (parola di memoria e ampiezza di registro).
Tipi dinamici, cast evoluti, tipi "variant" come in Clipper e quant'altro... sono appannaggio esclusivo dei linguaggi di alto livello, peraltro tipicamente non imperativi.

Il tipo void, oggetto di sesquipedali incomprensioni anche da parte di programmatori provenienti da altri linguaggi, che pure hanno pratica di linguaggio C da molti anni, è un tipo di transizione, una discontinuità logica nel sistema dei tipi, in sostanza una singolarità. Viene usato principalmente nel passaggio di parametri a funzioni, e più in generale quando si tratta di emulare strettamente l'Assembly in quel minimo di programmazione con tipi di dato generici consentita dalla "rozzezza" (= vicinanza all'HW)  di tali linguaggi. La sua unicità è sancita dalla regola stessa che ne definisce le caratteristiche: è sempre possibile convertire qualsiasi altro tipo standard in void e da void. Si tratta, come è spesso il caso con il linguaggio C, di una regola eccessivamente blanda, che consente abusi di ogni genere e non aiuta ad inquadrare le vere ragioni che hanno condotto all'introduzione di tale tipo, e che ne dovrebbero parimenti sempre guidare l'uso.


Esempio assolutamente a portata di mano, che però pare sistematicamente sfuggire quasi a tutti: i puntatori void sono indispensabili in funzioni di libreria che gestiscono sorting e searching su array generici, come la lfind() o la qsort(), e storicamente sono stati introdotti nel linguaggio unicamente per far fronte a situazioni simili. Studiare bene e comprendere l'implementazione di tali funzioni (i sorgenti delle varie librerie di runtime e standard del C si trovano ormai in bundle con le buste di patatine, in tutte le salse) significa, in buona sostanza, sapere tutto ciò che il programmatore quadratico medio deve sapere sull'identificatore void del linguaggio C - e, aggiungerei, anche sulla correlazione con l'operatore sizeof(), che va studiato e compreso altrettanto bene al medesimo tempo.


In relazione alla questione degli algoritmi generalizzati, e quindi del corretto uso di void, recentissimamente ho dovuto proporre un codice del genere in un altro forum, che - per i soliti motivi scolastici - illustra una buona implementazione generica di un pessimo algoritmo.

Il codice fa riferimento ad uno dei rarissimi tutorial sensati che trattano l'argomento in modo accettabilmente chiaro e progressivo, sebbene alcune scelte stilistiche risultino ampiamente migliorabili (come appunto fa l'esempiuccio appena pubblicato).

Infatti, per contrappasso dantesco andrebbero messi a copiare i listati esadecimali dalle riviste anni '80, immettendo ciascun singolo valore in un rudimentale programmatore di EPROM, che richiede la pressione di un pulsante ENTER dopo ogni digitazione sul tastierino esadecimale (e siete già fortunati, i primissimi progetti DIY avevano solo un dip switch per i dati) per far avanzare "automaticamente" il banco di contatori TTL che gestisce le linee di indirizzo.
Salvo poi scoprire, alla terza o quarta pagina, che era saltata l'impaginazione e mancava l'ultima parte del listato, pubblicata come errata corrige (forse) il mese successivo. Solo così si può diventare Veri Programmatori... been there, done that. 

L'aggeggio si chiama Arduino, in effetti: non hai sbagliato grafia, il fatto è che siamo nauseati al solo sentirlo rammentare, perché è diventato un terribile tormentone... come "l'amarissimo che fa benissimo" o "l'uomo in ammollo", o le canzonette estive, la zumba, lo spritz, i balli sudamericani di gruppo, eccetera.
Tutti parlano di Arduino, anche se poi pochissimi sanno davvero cosa sia. Come tutte le mode, si spera che passi presto. Per Diana! Sembra che sia l'unico sistema di sviluppo esistente con un linguaggio HLL incorporato, per i non addetti ai lavori!!!
Per giunta lo si vede impiegato anche in applicazioni PC-related del tutto inutili, laddove invece la classica scheda parallela, seriale, USB con una manciata di I/O e zero firmware residente andrebbe non bene, ma benissimo.

Veramente, con questo Arduino non se ne può più... perfino le più diffuse riviste amatoriali superstiti nel mondo del DIY elettronico l'hanno impalmato come se fosse la panacea di tutti i mali: ma per il sottoscritto, dopo un quarto di secolo di professione nel mondo dell'elettronica (e quasi sette lustri da amatore), resta un mistero il perché dozzine e dozzine di altri progetti amatoriali, accademici e low cost (per non parlare di quelli dei produttori primari) di simile impronta, sovente nettamente migliori qualitativamente, mai abbiano incontrato tutta questa fortuna presso i profani e non.


Al di là di questo, prova a spulciare i cataloghi di Nuova Elettronica: ricordo che tempo fa avevano proposto proprio un cronometro per autopiste e simili, con ingressi di controllo derivati appunto da una fotocoppia lineare (barriera IR). Sicuramente poi troverai qualcuno che ti assembla il kit ad un prezzo ragionevole.

Ritengo che codesto genere di apparati sia in commercio da decenni sotto forma di sottosistema completo per atletica leggera e altri sport affini, con barriere infrarosse già pronte, incorporate in paletti metallici o plastici. Non dico che si trovino da Decathlon o Sportland, ma poco ci manca. Probabilmente nei modelli più economici manca solo l'interfaccia al computer, o esiste come opzione sotto forma di seriale RS232 (più modernamente, USB). Informati presso qualche rivenditore, per farti un'idea.

Inoltre, barriere infrarosse in kit con uscite impulsive monostabili a 5/12V e portate comprese tra i 2 e i 10 metri sono sicuramente presenti nei cataloghi di tutti i principali costruttori di kit: Nuova Elettronica, GPE, Futura Elettronica, Velleman, etc. - alla voce "Sistemi di allarme" o "Antinfortunistica", di norma.


PS: Il prossimo che scrive "arduino" verrà crocefisso in sala mensa... 

"Per colpa di qualcuno, non si fa credito a nessuno"

"Si fa credito solo ai novantenni se accompagnati da ambedue i genitori"

Pas de quoi, mon ami...
Sono proprio questi i thread che rendono questi forum unici, irripetibili, insostituibili.



Se vuoi sapere tutto sulle pizze sessagesimali, leggi questo thread e soprattutto questo.

Ovviamente sì. Dato un intero strettamente positivo v, vogliamo determinare il naturale n in modo tale che T(n), ossia il numero triangolare n-esimo, sia non maggiore di v.

L'espressione chiusa che lega n e l'n-simo numero triangolare è arcinota:



Si tratta dunque di risolvere la seguente banalissima disequazione di secondo grado, in una variabile naturale:



Ovvero, dopo ovvi passaggi algebrici:



In sostanza, saltando direttamente alle conclusioni, abbiamo quindi:



Nonostante la presenza della radice quadrata, si tratta comunque di una banale formuletta, calcolabile in O(1). Occorre solo prestare un minimo di attenzione all'implementazione... Divertente infatti, dal punto di vista computazionale, è notare che il delta di questa semplice equazioncina di secondo grado è sempre dispari: quando è un quadrato perfetto anche la sua radice quadrata, intera, è necessariamente dispari, il che rende sicuramente pari e intero il risultato finale - senza bisogno dell'operatore floor.

Coraggio, Rob: il diavolo non è così brutto come lo si dipinge. E poi sono solo matrici quadrate, il che è una notevole semplificazione...

Limitiamoci alla semimatrice triangolare superiore sinistra, il resto è banale per simmetria.

Quanti elementi ci sono in ogni (anti)diagonale? 1, 2, 3, ... N-2, N-1, N. Ricorda qualcosa questa ovvia sequenza? Certo che sì! Gauss, la somma dei primi N naturali, e ovviamente i numeri triangolari. Sfruttando la meravigliosa proprietà che la somma delle coordinate è costante per ciascuna antidiagonale, e la individua univocamente (rivedi questa discussione), noi sappiamo che, per ogni antidiagonale ad_n+1, il numero di elementi precedenti non è altro che l'n-simo numero triangolare. Quindi, ad esempio, se mi posiziono all'inizio della antidiagonale 5 + 1, avrò già riempito le T₅ = 15 caselle alla sua sinistra e so inoltre che tale antidiagonale avrà 6 elementi.

Da qui si può sviluppare facilmente una formuletta, usando al limite un reverse lookup su un array dei primi 2N-1 numeri triangolari per aiutarsi. Dato infatti il valore v, la sua collocazione è funzione del numero triangolare immediatamente inferiore o uguale T_n, dove l'indice n individua univocamente l'antidiagonale cui appartiene e la differenza v - T_n ci dà l'offset di tale numero rispetto all'inizio dell'antidiagonale. Da qui è decisamente banale ricavare R e C in funzione di v.

Prendiamo ad esempio una matrice 10x10. Si abbia v = 18. Il nostro T_n < 18 è T₅ = 15 e quindi n = 5. Il numero appartiene alla sesta antidiagonale, che ha quindi origine in (R₀, C₀) ossia (6,0) usando la convenzione del C, ed ha in questo caso offset pari a v - T_n +1 = 18 -15 +1 = 2, da cui R = R₀ - Ofs = 6 - 2 = 4, C = C₀ + Ofs = 0 + 2 = 2, quindi R = 4 e C = 2, dove i segni algebrici tengono ovviamente conto del fatto che lavoriamo per antidiagonali, unidirezionalmente per R decrescente e C crescente. Ma è puerile gestire casi diversi.

01	03	06	10	15	21
02	05	09	14	20
04	08	13	19
07	12	18
11	17
16

1) "stdio.h" non è una libreria, bensì uno header file. Esso descrive i prototipi di talune funzioni di libreria, nonché strutture dati, variabili globali e quant'altro necessario alla corretta integrazione nel sorgente della funzionalità delle libreria.

2) Lo "standard del linguaggio" è oggetto, da troppo tempo e per motivi spesso ignobili (es. "il mio compilatore preferito è più standard del tuo"), di fraintendimenti marchiani.
Lo standard è un documento che definisce un insieme minimo di caratteristiche del linguaggio, guidando quindi la progettazione e implementazione di compilatori in modo tale, ad esempio, da facilitare anche il lavoro (comunque improbo) di "porting" da una piattaforma ad un'altra, o in subordine da un compilatore ad un altro. Tutto ciò non interessa che una risicata minoranza di programmatori, e di fatto ha influenza quasi unicamente sul lavoro di chi, come il sottoscritto, sviluppa cross compilatori, librerie matematiche, e altri tools per i programmatori.
Alcune tipologie di sorgenti, segnatamente nel mondo unix-like GNU, godono della fama di essere compilabili su un numero spropositato di piattaforme: ma alternativamente, lo fanno sacrificando in modo spesso inaccettabile le prestazioni, oppure confrontandosi realmente con le idiosincrasie di una miriade di compilatori (tipicamente dello stesso GCC, che ha più incarnazioni di qualche divinità indù) e quindi trasformando il sorgente in una assurda jungla di #ifdef, #ifndef e altra paccottiglia che di fatto maschera la presenza di più sorgenti in uno, con poco o punto codice realmente in comune. Tale è la situazione, la "portabilità" in linguaggio C è solo una chimera.
Peraltro i due più recenti standard, C'99 e C'11, sono stati snobbati dalla vasta maggioranza dei produttori, a causa di notevoli incongruenze interne e conflitti con una codebase enorme già sviluppata all'epoca della loro concezione (in particolare vale per C'99).

3) Lo sviluppatore C quadratico medio può ignorare perfino l'esistenza dello standard, e deve fare riferimento solo e unicamente ai manuali del compilatore e allo standard di codifica imposto dall'Azienda e spesso congegnato in modo da rispondere a specifiche normative (es. MISRA/C 2012). Il linguaggio C, al contrario di quasi ogni altro linguaggio, non è in alcun modo univoco ed ha innumerevoli estensioni, più o meno tante quanti sono i relativi compilatori (e in pratica non esiste piattaforma hardware, anche superproprietaria purché minimamente diffusa, per la quale non sia previsto un cross-compilatore, un compilatore nativo o almeno un interprete C).