"informatica *senza* matematica"
vincenzo
volevo sapere se qualcuno aveva seguito il 3d "Informatica senza matematica"
su it.istruzione.universita e che opinione si era fatto.
vincenzo
--------------------------------
Inviato via http://arianna.libero.it/usenet/
Kiuhnm
> Ciao,
> volevo sapere se qualcuno aveva seguito il 3d "Informatica senza
> matematica" su it.istruzione.universita e che opinione si era fatto.
L'Informatico deve conoscere la Matematica.
Mi sembra più che ovvio.
I matematici che si specializzano in certi settori (per es. Teoria dei
Numeri - Crittografia) non hanno studiato comunque anche altre branche della
Matematica?
E allora perché l'Informatico che si specializza per es. in algoritmi di
sorting non dovrebbe comunque conoscere l'Informatica generale e quindi
anche la Matematica?
Inoltre ritengo che gli informatici debbano anche saper programmare
(qualcuno l'aveva messo in dubbio) in quanto un informatico deve sapere
utilizzare gli strumenti che ha disposizione.
I discorsi "ma a me non serve" non contano. Qui si sta parlando di
"Informatico" nella sua accezione più generale.
Kiuhnm
Giorgio Pastore
vincenzo wrote:
> Ciao,
> volevo sapere se qualcuno aveva seguito il 3d "Informatica senza matematica"
> su it.istruzione.universita e che opinione si era fatto.
Con l' eccezione di pochissimi interventi, discussione da Bar Sport.
Che senso ha accalorarsi se ci vogliano o no esami di matematica ad
informatica se non si chiarisce prima *quale* informatica e *quale*
matematica? L' unica cosa interessante, secondo me, e' che e'
evidenziato un problema diffuso di impostazione didattica della
matematica che si fa in molti corsi di laurea in informatica.
Giorgio
vincenzo
>L' unica cosa interessante, secondo me, e' che e'
> evidenziato un problema diffuso di impostazione didattica della
> matematica che si fa in molti corsi di laurea in informatica.
che intendi in particolare? che tipo di impostazione ti senti di criticare?
ciao
v
/* frank */
> volevo sapere se qualcuno aveva seguito il 3d "Informatica senza matematica"
Informatica senza matematica e' impossibile da fare.
Tanto per dirne una: il modello ricorsivo che e' alla base
della programmazione e che si dimostra, si applica, proprio
dimostrando, conoscendo, benissimo il principio di induzione
matematica.
Sys
scritto:
>Ciao,
>volevo sapere se qualcuno aveva seguito il 3d "Informatica senza matematica"
>su it.istruzione.universita e che opinione si era fatto.
Il mio professore di Informatica delle Superiori (ora studio
Informatica alla Statale di Milano) diceva sempre: "L'informatica è
l'intonaco, la matematica il muro, gratti via l'informatica e ci trovi
la matematica!". Corollario: "L'intonaco non si regge in piedi senza
il muro!".
Secondo me la matematica per l'informatico e' fondamentale, anche se
noto che molti, ma proprio molti, studenti di informatica si
domandano: "ma io voglio imparare a programmare bene, cosa me ne frega
di saper calcolare le sommatorie o gli integrali o il calcolo delle
complessità?!".
Ciao
O'blivion
> Inoltre ritengo che gli informatici debbano anche saper programmare
> (qualcuno l'aveva messo in dubbio) in quanto un informatico deve sapere
> utilizzare gli strumenti che ha disposizione.
eccomi!
tu ancora non mi hai risposto a questo: Shannon per te non è un
informatico ?
ciao
Kiuhnm
> tu ancora non mi hai risposto a questo: Shannon per te non è un
> informatico ?
Ti rispondo facendoti notare che algoritmo = circuiti.
Shannon è stato uno dei più grandi protagonisti nella storia
dell'Informatica.
Shannon nel 1950 pubblicò addirittura un articolo dove parlava della
programmazione del computer per giocare a scacchi. Se questo non è saper
programmare...
Kiuhnm
O'blivion
interessante questo, non lo sapevo.
Ora supponi che Shannon non sapesse
programmare, dato tutto il contributo che ha dato alla scienza
dell'informazione (molta gente non sa che la crittografia intesa come
scienza l'ha praticamente inventata lui, che pure era un ingegnere), tu
non lo definiresti un informatico ?
In ogni caso quello che voglio dire io è che non è che un informatico
può non saper programmare, ma solo che una persona può essere un grande
informatico pur essendo un mediocre programmatore.
Il punto è che un
grande informatico, per la forma mentis che ormai ha assunto, per il modo
di ragionare sviluppato, sa implicitamente programmare. Se gli si insegna
un linguaggio egli è in grado di impararlo in breve tempo e di
applicarlo.
Questo però non significa che un grande informatico debba essere un
grande programmatore.
ciao
Kiuhnm
> Ora supponi che Shannon non sapesse
> programmare, dato tutto il contributo che ha dato alla scienza
> dell'informazione (molta gente non sa che la crittografia intesa come
> scienza l'ha praticamente inventata lui, che pure era un ingegnere),
> tu non lo definiresti un informatico ?
Non un informatico completo. E comunque mi riferisco all'Informatico di
*oggi*. Sessant'anni fa erano in pochi quelli che potevano mettere le mani
su un "calcolatore"!
Ti sentiresti di chiamare Matematico un esperto di Analisi che non sa
niente, ma proprio niente di Geometria?
Se sě, allora partiamo da premesse diverse e abbiamo ragione entrambi, dal
nostro punto di vista.
> In ogni caso quello che voglio dire io č che non č che un informatico
> puň non saper programmare, ma solo che una persona puň essere un
> grande informatico pur essendo un mediocre programmatore.
> Il punto č che un
> grande informatico, per la forma mentis che ormai ha assunto, per il
> modo di ragionare sviluppato, sa implicitamente programmare. Se gli
> si insegna un linguaggio egli č in grado di impararlo in breve tempo
> e di applicarlo.
Un momento. Per me una persona che sa scrivere uno pseudo codice sa
programmare.
Per anni e anni mi sono concentrato sullo studio degli algoritmi e mi sono
limitato all'asm, al C e al C++ (quest'ultimo lo uso senza tante
diavolerie), mentre altri programmatori conoscono 1000 linguaggi, hanno
esperienza nell'uso di 1000 librerie commerciali e non, e non sanno
implementare neanche un quicksort o un albero binario autobilanciante.
Io mi ritengo "piů informatico" di loro, pur conoscendo solo 3 linguaggi. Il
linguaggio č un dettaglio, diceva uno dei miei professori, ciň che conta č
l'algoritmo.
Kiuhnm
vincenzo
> Secondo me la matematica per l'informatico e' fondamentale, anche se
> noto che molti, ma proprio molti, studenti di informatica si
> domandano: "ma io voglio imparare a programmare bene, cosa me ne frega
> di saper calcolare le sommatorie o gli integrali o il calcolo delle
> complessità?!".
Sono d'accordo, specie sull'osservazione...e come fare a invertire questa
"pericolosa" tendenza?
Marco
> Un momento. Per me una persona che sa scrivere uno pseudo codice sa
> programmare.
> Per anni e anni mi sono concentrato sullo studio degli algoritmi e mi sono
> limitato all'asm, al C e al C++ (quest'ultimo lo uso senza tante
> diavolerie), mentre altri programmatori conoscono 1000 linguaggi, hanno
> esperienza nell'uso di 1000 librerie commerciali e non, e non sanno
> implementare neanche un quicksort o un albero binario autobilanciante.
> Il linguaggio è un dettaglio, diceva uno dei miei professori, ciò che
> conta è l'algoritmo.
>
> Kiuhnm
Probabilmente alla fine siete daccordo entrambi. Forse c'è stata un po' di
incomprensione sull'uso dei termini. Kiuhnm intente programmazione come
progetto, verifica e implementazione di algoritmi. In questo caso
l'informatico deve sapere programmare. Tuttavia nel parlare comune per
programmazione si intende conoscenza di un linguaggio. Insomma per molti
più librerie conosci e più trucchi di un linguaggio conosci più sei un
bravo programmatore e quindi (sbagliando) un bravo informatico.
Secondo me l'informatica è composta dalle seguenti discipline
Computabilità -> esiste un algoritmo per risolevere questo problema?
Complessità -> quanto è difficile questo problema?
Progetto e analisi di algoritmi -> esiste un algoritmo _efficiente_ per
risolvere questo problema?
Linguaggi -> semantica e sintassi dei linguaggi
Purtroppo spesso non si dà importanza a questi aspetti e ti tormentano con
corsi di programmazione I e II dove ti insegnano il C e il C++ e nei
progetti di laboratorio l'algoritmi più difficile che implementi è la
scansione sequenziale di una lista ordinata.
ciao
Marco
Marco
> Secondo me la matematica per l'informatico e' fondamentale, anche se
> noto che molti, ma proprio molti, studenti di informatica si
> domandano: "ma io voglio imparare a programmare bene, cosa me ne frega
> di saper calcolare le sommatorie o gli integrali o il calcolo delle
> complessità?!".
>
Bella immagine quella dell'intonaco e il muro!
In effetti molti si iscrivono ad informatica sperando di imparare a
programmare oppure ad usare Word. In entrambi i casi sbagliano. Il problema
è la disinformazione, ovunque si parla di corsi di informatica quando si fa
riferimento ad un ciclo di lezioni su Office organizzate dalla parrocchia.
Ma anche i capi delle facoltà di informatica alla fine cercheranno di
soddisfare questi poveri studenti dalle idee confuse. Infatti la pressione
delle aziende è forte, a loro servono programmatori, non esseri umani che
conoscono la computabilità. Questo è triste. Ne parlavo anche sul mio sito,
http://emptyset.altervista.org (post, IO odio informatica) i commenti che
trovate sono stati scritti da studenti di informatica... loro vogliono
programmare e mi sembra di essere un po' la pecora nera.
ciao!
Elio Fabri
> ...
> Secondo me l'informatica è composta dalle seguenti discipline
>
> Computabilità -> esiste un algoritmo per risolevere questo problema?
> Complessità -> quanto è difficile questo problema?
> Progetto e analisi di algoritmi -> esiste un algoritmo _efficiente_
> per risolvere questo problema?
> Linguaggi -> semantica e sintassi dei linguaggi
O se vogliamo, che sei un informatico che piu' teorico non si puo' :)
------------------------------
Elio Fabri
Dip. di Fisica - Univ. di Pisa
------------------------------
Elio Fabri
> Shannon nel 1950 pubblicò addirittura un articolo dove parlava della
> programmazione del computer per giocare a scacchi. Se questo non è saper
> programmare...
O'blivion ha scritto:
> Ora supponi che Shannon non sapesse programmare, dato tutto il
> contributo che ha dato alla scienza dell'informazione (molta gente non
> sa che la crittografia intesa come scienza l'ha praticamente inventata
> lui, che pure era un ingegnere), tu non lo definiresti un informatico?
Kiuhnm ha scritto:
> Non un informatico completo. E comunque mi riferisco all'Informatico
> di *oggi*. Sessant'anni fa erano in pochi quelli che potevano mettere
> le mani su un "calcolatore"!
Beh, sessant'anni fa (quasi) io c'ero: ho cominciato a occuparmi di
calcolatori giusto 50 anni fa...
L'articolo di Shannon del 1950 (intitolato proprio "Programming
Computers for Playing Chess") non l'ho letto, ma a quel tempo non si
poteva "programmare" un computer come si fa non dico oggi, ma anche 30
anni fa.
Nel 1950 i computer erano pochissimi, tutti diversi tra loro, e non
esistevano i linguaggi di programmazione, ma solo il "linguaggio
macchina" o come volete chiamarlo. Il FORTRAN e' nato nel 1957, il
LISP nel 1960.
Percio' in quell'articolo ci sara' stata solo una discussione molto
generale (magari me lo vado a leggere: e' sul "Philosphical
Magazine"...)
Tanto meno esisteva l'informatica: neppure la parola...
Ovviamente il lavoro di Shannon del 1948, che ha praticamente fondato
la teoria dell'informazione, e' stato una delle radici da cui si e'
sviluppata l'informatica; ma discutere se Shannon fosse un informatico
e' storicamente insensato.
> Il linguaggio è un dettaglio, diceva uno dei miei professori, ciò che
> conta è l'algoritmo.
Possiedo un libro intitolato: "Algorithms + Data Structures = Programs".
Sentito nominare? :)
------------------------------
Elio Fabri
Dip. di Fisica - Univ. di Pisa
------------------------------
From
Marco
In effetti, ci sarebbero gli "ambienti", i sistemi operativi e le
architetture (fisiche). Forse qualcos'altro, ma volevo solo evidenziare
quelle discipline che ritengo "caratterizzanti". Secondo me tutto si può
ricondurre (o ridurre!) a queste sopra.
Ho il libro Algorithms+DataStructure=Programs... è ben fatto, perchè è uno
dei pochi libri che insegna a programmare non facendo esempi stupidi! Ma io
preferisco il Cormen-Rivest!
ciao
Marco
Elio Fabri
> ...
> Secondo me l'informatica è composta dalle seguenti discipline
>
> Computabilità -> esiste un algoritmo per risolevere questo problema?
> Complessità -> quanto è difficile questo problema?
> Progetto e analisi di algoritmi -> esiste un algoritmo _efficiente_
> per risolvere questo problema?
> Linguaggi -> semantica e sintassi dei linguaggi
Jilani KHALDI
>Sentito nominare? :)
// jilani
Kiuhnm
> Ho il libro Algorithms+DataStructure=Programs... è ben fatto, perchè
> è uno dei pochi libri che insegna a programmare non facendo esempi
> stupidi! Ma io preferisco il Cormen-Rivest!
Stai parlando di libri introduttivi.
Ho scoperto da tempo che le cose è meglio studiarsele direttamente dalla
fonte. Esistono splendidi siti come http://citeseer.ist.psu.edu/cs nei quali
è possibile trovare di tutto.
Ogni tanto si scoprono sorprendenti algoritmi che non trovi su nessun libro
semplicemente perché poco conosciuti.
Kiuhnm
Kiuhnm
> Possiedo un libro intitolato: "Algorithms + Data Structures =
> Programs". Sentito nominare? :)
Ti dice niente l'inventore di quello schifosissimo linguaggio chiamato
Pascal?
Se non ricordo male, quel libro č suo.
Anzi, lo vado a prendere...
Eccolo qui: Niklaus Wirth, creatore del Pascal. CVD.
E' ben fatto, ma copre pochi argomenti. Niente di avanzato insomma.
Per es. se non ricordo male non parla di SkipList, SkipTree, Alberi di tipo
AB (Relaxed Multi-Way Tree), Alberi Red Black, Alberi BB (semplicissimi e
molto efficienti), non presenta i metodi di ordinamento O(n) come il
QuickSort-5, il Bucket Sort, il Radix Sort, ecc.... Di cose che ritengo
*fondamentali* ne mancano, perņ, per essere un libro introduttivo (diciamo
per TAMC al primo anno di Scienze dell'Informazione) č pił che accettabile.
Kiuhnm
Kiuhnm
> Possiedo un libro intitolato: "Algorithms + Data Structures =
> Programs". Sentito nominare? :)
Vedo che spesso rispondi a post che riguardano problemi relativi a spline,
superfici e "grafica" in generale (se non ricordo male). Hai mai avuto
l'occasione di leggere il libro "Computer Graphics: Principles & Practice"?
Un vero gioiello. L'ho intravisto mentre cercavo quello di Wirth.
Kiuhnm
Marco
Qualche cosa ho cercato anch'io da quelle parti!
Si lo so, sono libri introduttivi, pensa un po' te, sono al quarto (in
settembre) anno di informatica ed ho fatto solo introduzioni ed altre cose
che reputo inutili! E' triste... sob sob...
Di algoritmi che ho fatto? Qualche cosa del rivest anche se non tutto.
Di complessità ho fatto P, NP, coNP, visto di sfuggita PSPACE, per conto mio
RP, coRP, BPP, coBPP... ma per tutto il resto ci vorrebbe un secondo corso
di complessità... ahimè!
Di computabilità, qualche misera funzione ricorsiva....
e poi? bho... ah si C, C++, Java, UML, Pascal... che palle!
ciao
Marco
Kiuhnm
> Si lo so, sono libri introduttivi, pensa un po' te, sono al quarto (in
> settembre) anno di informatica ed ho fatto solo introduzioni ed altre
> cose che reputo inutili! E' triste... sob sob...
Sono molto interessanti anche i libri di Knuth.
Diciamo pure che sono dei veri mattoni...
"The Art Of Computer Programming" vol 1, 2, .....
Comunque è inutile studiare proprio tutti gli algoritmi conosciuti. E'
meglio avere una visione d'insieme e poi approfondire quando necessario.
Vi siete occupati di problemi di sincronizzazione? Lock-free, Wait-free,
CAS, CASN, Cas, ecc...?
Kiuhnm
Marco
> Marco wrote:
>> Si lo so, sono libri introduttivi, pensa un po' te, sono al quarto (in
>> settembre) anno di informatica ed ho fatto solo introduzioni ed altre
>> cose che reputo inutili! E' triste... sob sob...
>
> Sono molto interessanti anche i libri di Knuth.
> Diciamo pure che sono dei veri mattoni...
> "The Art Of Computer Programming" vol 1, 2, .....
>
L'ho visto ma preferisco Rivest.
> Comunque è inutile studiare proprio tutti gli algoritmi conosciuti.
Questo si!
> E'
> meglio avere una visione d'insieme e poi approfondire quando necessario.
> Vi siete occupati di problemi di sincronizzazione? Lock-free, Wait-free,
> CAS, CASN, Cas, ecc...?
>
qualcosa si, ma poco, tipo il problema dei filosofi a cena ed altri che non
ricordo...
> Kiuhnm
ciao
Marco
Giovanni
> Elio Fabri wrote:
>> Possiedo un libro intitolato: "Algorithms + Data Structures =
>> Programs". Sentito nominare? :)
>
> Ti dice niente l'inventore di quello schifosissimo linguaggio chiamato
> Pascal?
CUT
Per quanto riguarda scopi didattici il Pascal è il migliore in assoluto,
infatti praticamente tutti quelli che hanno studiato programmazione, hanno
cominciato con quello :-)
> Kiuhnm
--
# ICQ 84624356
Kiuhnm
> Per quanto riguarda scopi didattici il Pascal è il migliore in
> assoluto, infatti praticamente tutti quelli che hanno studiato
> programmazione, hanno cominciato con quello :-)
Come primo linguaggio consiglio l'assembly, questo incompreso.
(assembly != linguaggio macchina)
Dall'asm è facile passare al C e non si corre più il rischio di fare casini
assurdi con array e puntatori.
Da qui si può passare a Java, Python, C++, C#, ecc...
Consiglio il C perché è un linguaggio di medio livello.
Kiuhnm
Elio Fabri
> In effetti, ci sarebbero gli "ambienti", i sistemi operativi e le
> architetture (fisiche). Forse qualcos'altro, ma volevo solo
> evidenziare quelle discipline che ritengo "caratterizzanti". Secondo
> me tutto si può ricondurre (o ridurre!) a queste sopra.
la pensi come quei fisici teorici che dicono "tutta la chimica si puo'
ridurre all'eq. di Schroedinger, o alla peggio a quella di Dirac".
Ecco perche' ti avevo definito "teorico" ;-)
Kiuhnm ha scritto:
> Ti dice niente l'inventore di quello schifosissimo linguaggio chiamato
> Pascal?
> Se non ricordo male, quel libro è suo.
> Anzi, lo vado a prendere...
> Eccolo qui: Niklaus Wirth, creatore del Pascal. CVD.
Certo che e' suo!
Premetto che avevo solo voluto fare una battuta, in risposta alla
tua citazione sulla relazione fra algoritmni e programmi.
Ma forse tu non sai che il Pascal e' nato come linguaggio "didattico",
appunto per scrivere quel libro; non era inteso da Wirth come un
linguaggio in cui programmare realmente.
Poi e' venuta la Borland col TurboPascal e l'ha fatto diventare una
cosa anche utilizzabile in pratica.
Poi in Italia c'e' stato il PNI, quasi 20 anni fa, che ha imposto il
Pascal come unico linguaggio di programmazione nella scuola secondaria
(dove si continua a usare, per cosi' dire...).
Cosa alla quale non ero favorevole, perche' ho sempre sostenuto la
necessita' di un approccio a piu' facce alla programmazione, e perche'
non condividevo l'idea di ridurre l'informatica ad algoritmi e
programmazione.
Ma siccome quella era la legge, e dato che a quel tempo lavoravo per
l'introduzione dei computer nellinsegnamento (a modo mio) e' stato
proprio in quell'occasione che ho imparato il Pascal, che poi a me nn
sembra cosi' schifoso.
> Come primo linguaggio consiglio l'assembly, questo incompreso.
> (assembly != linguaggio macchina)
Aspetta, fammi capire...
D'accordo che assembly non e' ling. machina, pero' ci sono tanti
assembly quanti processori: quindi che vuol dire "studiare l'assembly"?
Io in tenpi lontani ne ho usati almeno tre: 6502, Z80, 8086; piu' di
recente 80C52 (se ricordo bene la sigla).
Oppure pensi a un assembly fittizio, come il MIX di Knuth?
Ma non ci mettiamo a parlare di linguaggi, perche' sai bene quello che
succede :)
Elio Fabri
> Vedo che spesso rispondi a post che riguardano problemi relativi a
> spline, superfici e "grafica" in generale (se non ricordo male). Hai
> mai avuto l'occasione di leggere il libro "Computer Graphics:
> Principles & Practice"?
> Un vero gioiello. L'ho intravisto mentre cercavo quello di Wirth.
Per quanto posso ricordare, ho risposto a una domanda sulle splines
cubiche, perche' e' una tecnica che mi e' capitato di usare
programmando PostScript.
Ma in materia di grafica, come di qualsiasi altro argomento
informatico, sono sostanzialmente un dilettante, per dipiu'
handicappato dall'aver cominciato a lavorarci troppo tempo fa, quando
gran parte di quello che si sa oggi non esisteva.
Per cui ho studiato qua e la', a pezzi e bocconi, quando una cosa mi
serviva o m'interessava, senza nessuna sistematicita'.
Il libro che citi non lo conosco (mentre per es. ho i tre volumi di
Knuth, nonche' tutto il TeXbook :) )
Marco
Ad esempio come descriveresti l'informatica? quali "materie" la
caratterizzano?
Marco
Enrico Franchi
> Consiglio il C perché è un linguaggio di medio livello.
dipende anche dal corso di studi che uno deve fare.
Non sottovalutiamo il Python, come linguaggio didattico.
--
RiK0
Non credo negli schemi non vincenti.
Elio Fabri
> Ad esempio come descriveresti l'informatica? quali "materie" la
> caratterizzano?
Perche' dovrei saperlo fare per l'informatica?
Dal punto di vista pratico, didattico o organizzativo, e' chiaro che
ci sono sempre materie "di confine", piu' o meno teoriche, piu' o meno
applicative, che puoi o no includere nell'informatica, nella
matematica, nell'ingegneria, perfino nella fisica...
Per es. nei tuoi elenchi non hai incluso le reti ne' l'elaborazione
delle immagini.
Mi diresti che sono materie applicative?
Mica tanto: in entrambi i casi intervengono concetti teorici nuovi,
che non puoi ricondurre facilmente al tuo schema.
Marco
> Marco ha scritto:
>> Ad esempio come descriveresti l'informatica? quali "materie" la
>> caratterizzano?
> Io non saprei definire la metematica, e neppure la fisica...
> Perche' dovrei saperlo fare per l'informatica?
>
Volevo solo un'opinione, sapere quello che pensano gli altri, come ad
esempio un fisico vede l'Informatica. Frequento il quarto anno di
informatica, ma sono abbastanza deluso. Informatica fa parte di Scienze e
mi sarei aspettato più scienza, ma invece non è stato così. Nn si può
nemmeno paragonare informatica a matematica o a fisica in quanto a
"scienza". Chissà...
> Dal punto di vista pratico, didattico o organizzativo, e' chiaro che
> ci sono sempre materie "di confine", piu' o meno teoriche, piu' o meno
> applicative, che puoi o no includere nell'informatica, nella
> matematica, nell'ingegneria, perfino nella fisica...
>
> Per es. nei tuoi elenchi non hai incluso le reti ne' l'elaborazione
> delle immagini.
> Mi diresti che sono materie applicative?
> Mica tanto: in entrambi i casi intervengono concetti teorici nuovi,
> che non puoi ricondurre facilmente al tuo schema.
>
giusto le reti, le ho lasciate, lapsus... il corso di reti che ho fatto è
stato talmente inutile (nn per il corso in sè ma per il docente) che mi
sono dimenticato che esistesse. Reti in informatica dovrebbe essere diverso
da reti fatto da ing.telecomunicazioni, nel senso che si danno maggior
rilievo a diversi argomenti. Ad esempio telecomunicazioni si occupa di più
della trasmissione dei segnali, l'informatica invece degli algoritmi di
routing (è un esempio) e della loro complessità (ritorna l'algoritmica!).
Ingegneri e informatici però devono conoscere tutti gli aspetti, anche
quelli dell'altra parte anche se in modo meno approffondito. Ma reti non lo
vedrei caratterizzate, ma un corso "interdisciplinare" per completare le
conoscenze dell'informatico che deve avere una cultura generale un po' più
vasta dei soli insiemi ricorsivamente enumerabili. Nn so se mi sono
spiegato.
Idem credo per elaborazioni delle immagini.
>
> ------------------------------
> Elio Fabri
> Dip. di Fisica - Univ. di Pisa
> ------------------------------
ciao
Marco
Elio Fabri
> Volevo solo un'opinione, sapere quello che pensano gli altri, come ad
> esempio un fisico vede l'Informatica. Frequento il quarto anno di
> informatica, ma sono abbastanza deluso. Informatica fa parte di
> Scienze e mi sarei aspettato più scienza, ma invece non è stato così.
> Nn si può nemmeno paragonare informatica a matematica o a fisica in
> quanto a "scienza". Chissà...
piu' lo stesso termine non e' in uso generale: come saprai e'
un'invenzione francese. In USA non usa (scusa il bisticcio :-) )
La giovane eta' fa si' che non possa ancora esserci una tradizione
didattica filtrata e consolidata.
So che a Pisa (dove il corso di laurea e' nato, grazie all'esperienza
CEP) aveva un indirizzo fortemente teorico; ma non so se sia rimasto
cosi'. In altre sedi puo' anche essere molto diverso.
A Pisa c'e' anche ingegneria informatica.
> Reti in informatica dovrebbe essere diverso da reti fatto da
> ing.telecomunicazioni, nel senso che si danno maggior rilievo a
> diversi argomenti. Ad esempio telecomunicazioni si occupa di più della
> trasmissione dei segnali, l'informatica invece degli algoritmi di
> routing (è un esempio) e della loro complessità (ritorna
> l'algoritmica!).
La ragione per cui ti ho citato le reti e' che fanno intervenire un
elemento nuovo: il tempo.
Non e' l'unico caso, s'intende; ma comunque gli algoritmi debbono
farei i conti con processi _asincroni_, che si svolgono ciascuno
secondo il proprio tempo.
Da cui i problemi di priorita', conflitti e compagnia bella.
> Idem credo per elaborazioni delle immagini.
Immagini significa inevitabilmente tener conto dell'utente.
Non ha senso parlare di elab. d'immagini in astratto,
perche' un'immagine finisce sempre per dover essere vista da occhi
umani (o meglio, da un sistema nervoso umano).
Non si tratta solo di un aspetto applicativo: occorre porsi problemi
diversi, per es. che cos'e' il colore _percepito_
Per non parlare delle immagini in movimento...
Kiuhnm
> D'accordo che assembly non e' ling. machina, pero' ci sono tanti
> assembly quanti processori: quindi che vuol dire "studiare
> l'assembly"? Io in tenpi lontani ne ho usati almeno tre: 6502, Z80,
> 8086; piu' di recente 80C52 (se ricordo bene la sigla).
>
> Oppure pensi a un assembly fittizio, come il MIX di Knuth?
Va bene qualsiasi assembly relativo a CPU Risc e Cisc (purché non minimale).
Gli "ultimi asm" sono interessanti per quanto riguarda il "modo protetto" (o
analogo) e i sistemi di protezione in generale.
Preferisco partire dall'assembly in modo che lo studente apprezzi e capisca
"realmente" (sperimentandolo sulla propria pelle) i vantaggi derivanti
dall'uso di linguaggi di medio-alto livello e non dia tutto per scontato.
Dove posso, cerco sempre di ripercorrere la storia. Conoscendo l'assembly
(nel senso di Linguaggio di Basso Livello) si può capire concretamente cosa
accade all'interno di un sistema operativo, lo si può analizzare, ecc...
Non conoscere l'assembly significa avere le mani legate e utilizzare i
computer come scatole nere (o almeno "più nere" di quanto lo sono in
realtà).
> Ma non ci mettiamo a parlare di linguaggi, perche' sai bene quello che
> succede :)
Per carità!
Kiuhnm
rez
>Preferisco partire dall'assembly in modo che lo studente apprezzi e capisca
Cavoli, insegni l'assembly! :-))
E a chi, ai fantasmi, visto che col baco del 2000 avevano
dovuto richiamare i pensionati.
Cmq.. ehm.. me lo manderesti in email il sorgente per
generare numeri casuali?
[ovvio: se ce l'hai gia` fatto neh]
--
Ciao, | Attenzione! campo "Reply-To:" alterato |
Remigio Zedda | posta: ti.ilacsit@zoigimer <-- dx/sn ;^) |
-- GNU/Linux 2.4.25 su Slackware 9.1
Kiuhnm
> Cmq.. ehm.. me lo manderesti in email il sorgente per
> generare numeri casuali?
> [ovvio: se ce l'hai gia` fatto neh]
Sono stato via sei giorni e ho saltato molti post...a cosa ti riferisci?
Numeri casuali???
Esistono molti algoritmi e li trovi un po' ovunque. Ne trovi su Numerical
Recipes (se ti fidi :-) ), Knuth, ecc...
Il più semplice è questo:
unsigned rseed = 1;
void srand32(unsigned seed)
{
rseed = seed;
}
unsigned rand32()
{
rseed = 1664525*rseed + 1013904223;
return rseed;
}
double rand32()
{
return (double)rand32() / (double)0xffffffff;
}
Questo sfrutta una semplicissima cong. lineare ed è utile quando la velocità
è tutto e non ti servono proprietà particolari, altrimenti usa algo. più
avanzati oppure addirittura algo. crittografici.
Kiuhnm
Kiuhnm
> dipende anche dal corso di studi che uno deve fare.
> Non sottovalutiamo il Python, come linguaggio didattico.
Per me non esistono linguaggi didattici, ma soltanto modi più o meno
intelligenti di presentare le cose.
Il percorso asm->C->... è forse il più lungo, ma è anche il più completo,
secondo me.
Non tutti hanno il tempo e sentono la necessità di compierlo, quindi partono
subito programmando in alto livello usando questi cosiddetti linguaggi
didattici, ma in un corso completo e avanzato di programmazione consiglio
quanto ho detto.
Non pretendo di avere ragione: è soltanto il mio punto di vista.
Kiuhnm
rez
>Il piů semplice č questo:
>unsigned rseed = 1;
Ma no.. cercavo la pappa scodellata in assembly:)
Enrico Franchi
> Per me non esistono linguaggi didattici, ma soltanto modi più o meno
> intelligenti di presentare le cose.
Chiaramente non esiste un 'linguaggio didattico'. Ma esiste un
linguaggio adatto ad essere presentato come primo linguaggio.
> Il percorso asm->C->... è forse il più lungo, ma è anche il più completo,
> secondo me.
Io per esempio lo trovo fuorviante. Specie per l'Assembly. Il C sono
convinto che tanto ad uno prima o poi serva, al limite anche per leggere
degli esempi in giro. Quindi anche farlo come primo linguaggio... solo
che poi ci si fanno idee sbagliate in testa, per il fatto che se di C si
parla si parla di ANSI C, e in ANSI C certe cose non sono volutamente
possibili (ovvero, non sono parte dell'ANSI C, ma ci si appoggia a
librerie dell'OS e/o esterne. Librerie che in parte non servono per
imparare, ma d'altra parte permettono subito di provare quello che si e`
imparato in un contesto un po' piu` 'reale').
Sull'ASM non sono minimamente d'accordo perche` e` (volutamente)
fuori-standard. A seconda della macchina che hai, chiaramente rischia di
cambiare ASM (mica puoi pretendere che tutti usino un Intel/Amd... io il
primo PC x86 lo ho preso pochi anni fa, prima sempre altro -- e peraltro
tutt'ora uso di piu` altro).
Non solo. Pur programmando senza grossi problemi ASM in ambiente *nix
(cosa che mi serve talvolta per ottimizzare qualche routine
'aritmetica', per esempio -- e generalmente poi rendendomi conto che un
buon compilatore fa meglio di me e di ogni altra persona di mia
conoscenza, specie contando la media di processori leggermente diversi
eppur 'compatibili'), ASM in ambiente DOS - Windows non lo voglio
nemmeno vedere.
Per me una cosa tipo INT 21 significa non avere sotto un sistema
operativo (che ha una ben determinata funzione... se chiamo diretto un
INT qualcosa non va... INT 80 passando il controllo al kernel, molto
meglio).
Inoltre tende a portare fuori strada da quella che e` realmente la
programmazione. Per esempio in un corso di matematica FORTRAN e MATLAB
possono benissimo fare il loro lavoro (anche se insisto, con il Python
si vola... ci sono dei bellissimi moduli, e sono pure liberi e
multipiattaforma).
Ma al di la di questo programmare significa formalizzare idee e scrivere
un programma di computer adatto a svolgere un compito. L'ASM in questo
senso e` dispersivo.
Kiuhnm
[...]
> Non solo. Pur programmando senza grossi problemi ASM in ambiente *nix
> (cosa che mi serve talvolta per ottimizzare qualche routine
> 'aritmetica', per esempio -- e generalmente poi rendendomi conto che
> un buon compilatore fa meglio di me e di ogni altra persona di mia
> conoscenza, specie contando la media di processori leggermente diversi
> eppur 'compatibili'), ASM in ambiente DOS - Windows non lo voglio
> nemmeno vedere.
Per tutti questi motivi, considero altamente istruttivo partire dall'asm.
> Per me una cosa tipo INT 21 significa non avere sotto un sistema
> operativo (che ha una ben determinata funzione... se chiamo diretto un
> INT qualcosa non va... INT 80 passando il controllo al kernel, molto
> meglio).
La chiamata a un INT 21h presuppone un sistema operativo.
Se la CPU sul quale gira l'OS mette a disposizione una tale istruzione è
bene utilizzarla.
La troppa virtualizzazione e indirezione porta all'inefficienza.
Nessun OS nasconde completamente l'hardware (fortunatamente).
> Inoltre tende a portare fuori strada da quella che e` realmente la
> programmazione. Per esempio in un corso di matematica FORTRAN e MATLAB
> possono benissimo fare il loro lavoro (anche se insisto, con il Python
> si vola... ci sono dei bellissimi moduli, e sono pure liberi e
> multipiattaforma).
La programmazione *reale* è fatta anche di queste cose, quindi dire che
porta fuori strada da quella che è realmente la programmazione è veramente
un controsenso.
> Ma al di la di questo programmare significa formalizzare idee e
> scrivere un programma di computer adatto a svolgere un compito. L'ASM
> in questo senso e` dispersivo.
E quindi altamente didattico.
Kiuhnm
Enrico Franchi
> Per tutti questi motivi, considero altamente istruttivo partire dall'asm.
No, aggiungere confusione non significa preparare meglio.
Tanto piu` perche` nel mondo reale ASM e` in via di rapido abbandono. I
processori sono in genere troppo complessi affinche` un umano possa
ottimizzare meglio di un compilatore, e poi come ho gia` scritto variano
molto internamente, per cui un'ottimizzazione su uno, potrebbe
peggiorare sull'altro. Il compilatore invece ci mette una manciata di
secondi a generare nuovo codice quando io gli ho detto quello che deve
fare in C / C++.
> La chiamata a un INT 21h presuppone un sistema operativo.
che non faccia il suo dovere. e non lo dico io, lo dice Tanenbaum (ma
qui si va OT).
> Se la CPU sul quale gira l'OS mette a disposizione una tale istruzione è
> bene utilizzarla.
Distingui. Non e` che e` bene usarla o non e` bene usarla. Non e` bene
fare interrupt hardware da un programma che gira in userland (e non
dovrebbe nemmeno essere permesso).
> La troppa virtualizzazione e indirezione porta all'inefficienza.
Eppure gli OS *nix sono ben piu` performanti. E la programmazione si fa
tramite syscalls. non chiamando gli interrupt hardware.
> Nessun OS nasconde completamente l'hardware (fortunatamente).
Dipende cosa intendi per completamente.
> La programmazione *reale* è fatta anche di queste cose, quindi dire che
> porta fuori strada da quella che è realmente la programmazione è veramente
> un controsenso.
Non hai quotato di quali cose intendevi fosse fatta. Immagino di quanto
ho detto sopra.
E comunque:
1) non ritengo che la programmazione reale debba essere fatta di tali
cose (bisogna vedere quali, ho citato diverse cose, alcune
effettivamente fanno parte del bagaglio del programmatore 'di strada',
altre no).
2) ammesso e non concesso che lo sia, prima ti insegno ad andare in
bicicletta sul parco sottocasa, non ti sbatto direttamente in
tangenziale. Inutile aggiungere all'inesperienza problemi estranei.
Di solito si aggiunge un fattore di difficolta` alla volta.
Dopo di che se tu devi fare che so io, scrivere un metodo di
linearizzazione (compito peraltro banale)... lo fai in ASM? e poi quale
ASM? 486? Pentium? PPC? SPARC? pseudo-assembly alla Knuth? Quali
estensioni usi? e su PPC lo usi l'Altivec?
> E quindi altamente didattico.
hai un notevole gusto per il paradosso.
Kiuhnm
> No, aggiungere confusione non significa preparare meglio.
> Tanto piu` perche` nel mondo reale ASM e` in via di rapido abbandono.
> I processori sono in genere troppo complessi affinche` un umano possa
> ottimizzare meglio di un compilatore, e poi come ho gia` scritto
> variano molto internamente, per cui un'ottimizzazione su uno, potrebbe
> peggiorare sull'altro. Il compilatore invece ci mette una manciata di
> secondi a generare nuovo codice quando io gli ho detto quello che deve
> fare in C / C++.
E' inutile che continuiamo questa discussione. Non ci capiamo e non siamo
d'accordo su molte cose.
Partire dai linguaggi di alto livello è come studiare la Matematica partendo
dai risultati, cosa normalissima per molti (non si fa così anche nelle
Università?), ma non per me.
Kiuhnm
Enrico Franchi
> Partire dai linguaggi di alto livello è come studiare la Matematica partendo
> dai risultati, cosa normalissima per molti (non si fa così anche nelle
> Università?), ma non per me.
Purtroppo matematica e informatica sono cose 'simili' 'legate'. In
particolare hanno un sottoinsieme comune.
La programmazione e` un po' altro, nel senso che il paragone regge poco.
Xelloss dal portatile
> Partire dai linguaggi di alto livello è come studiare la Matematica
> partendo dai risultati, cosa normalissima per molti (non si fa così
> anche nelle Università?), ma non per me.
Certamente un po' di assembly fa parte delle basi della programmazione.
Però da un punto di vista didattico è molto più efficace cominciare da
linguaggi di alto livello, magari funzionali. Con l'assembly si rischia di
assumere un sacco di cattive abitudini di programmazione. In un primo
corso di programmazione non insegnerei mai l'assembly, in un secondo corso
magari sì.
Saluti.
--
\/ wirix...@libero.it ICQ UIN: 3233084
/\ e l l o s s (per rispondermi in privato, elimina il DEMONE)
darko
> Certamente un po' di assembly fa parte delle basi della programmazione.
> Però da un punto di vista didattico è molto più efficace cominciare da
> linguaggi di alto livello, magari funzionali. Con l'assembly si rischia di
> assumere un sacco di cattive abitudini di programmazione. In un primo
> corso di programmazione non insegnerei mai l'assembly, in un secondo corso
> magari sì.
io in un primo corso di programmazione non insegnerei mai un linguaggio,
in un secondo corso magari si'. e puo' essere l'assembly, il java o il lisp.
darko
--
"Cosa sono i milioni, quando in cambio ti danno le scarpe ?"
http://www.autistici.org/darko
Kiuhnm
> Con l'assembly si rischia di assumere un sacco di cattive abitudini
> di programmazione. In un primo corso di programmazione non insegnerei
> mai l'assembly, in un secondo corso magari sì.
Cattive abitudini?
Gli esseri umani non vanno "programmati", ma vanno condotti lungo un
percorso personale di studio.
Cattive abitudini nascondono lacune e/o concetti poco chiari.
La programmazione non è un'attività istintiva e conoscere l'asm aiuta a
capire con molta più profondità i linguaggi di alto livello.
Si potrebbe fare il parallelo con il latino e l'italiano. Sono due lingue
diverse quindi è un errore usare costruzioni latine in italiano, però la
conoscenza del latino è tutt'altro che controproducente
(per es. il latino mi ricorda che "conoscienza" è sbagliato perché il
termine italiano non deriva da "scio", ma da "cognosco").
Kiuhnm
Xelloss dal portatile
> Cattive abitudini?
> Gli esseri umani non vanno "programmati", ma vanno condotti lungo un
> percorso personale di studio.
> Cattive abitudini nascondono lacune e/o concetti poco chiari.
> La programmazione non è un'attività istintiva e conoscere l'asm aiuta a
> capire con molta più profondità i linguaggi di alto livello.
Credo che ciò che può essere stato vero per te non lo sia
necessariamente per gli altri. Certo, anche a me piace sapere "come
funziona", quindi non posso fare a meno di conoscere un po' di assembly;
tuttavia esistono modi più efficaci per insegnare l'utilizzo delle
strutture dati e degli strumenti che danno potenza espressiva a un
linguaggio, ossia ricorsione e strutture di controllo.
Quando si comincia a programmare in un qualunque linguaggio imperativo (di
solito dei linguaggi funzionali non si sospetta neanche l'esistenza),
capita a tutti di esagerare con i goto, che sappiamo essere
controproducenti dal punto di vista dell'ingegneria del software e inutili
dal punto di vista dell'espressività. Tanto più un linguaggio ostacola
l'uso dei goto, tanto più è indicato per l'apprendimento della
programmazione. In assembly, ogni salto è un goto e le chiamate di
funzione sono solamente convenzioni.
> Si potrebbe fare il parallelo con il latino e l'italiano. Sono due lingue
> diverse quindi è un errore usare costruzioni latine in italiano, però la
> conoscenza del latino è tutt'altro che controproducente
Sì. Ma il latino non si impara in prima elementare.
Kiuhnm
[...]
> Quando si comincia a programmare in un qualunque linguaggio
> imperativo (di solito dei linguaggi funzionali non si sospetta
> neanche l'esistenza), capita a tutti di esagerare con i goto, che
> sappiamo essere controproducenti dal punto di vista dell'ingegneria
> del software e inutili dal punto di vista dell'espressività. Tanto
> più un linguaggio ostacola l'uso dei goto, tanto più è indicato per
> l'apprendimento della programmazione. In assembly, ogni salto è un
> goto e le chiamate di funzione sono solamente convenzioni.
Per me l'aspetto didattico è proprio questo.
L'asm non pone limiti (o quasi) quindi ognuno può implementare un software
nei modi più strani possibili.
E' anche vero che esistono vari modi di insegnare l'asm. Esiste l'asm allo
stato brado e l'asm ben strutturato.
Per un esempio di quest'ultimo esiste il libro di Randall (solo per x86, se
non sbaglio).
Dopo un po' che si usa l'asm, s'inizia a sentire la necessità di strutturare
il proprio codice in quanto è facile perdere la testa.
Le Macro sono piuttosto potenti e permettono d'implementare tutti i
principali costrutti per il controllo del flusso (condizionali, iterativi e
incondizionati).
In seguito si sostituiscono le Macro con le parole chiave rese disponibili
dagli assemblatori più evoluti.
Gli algoritmi complessi vengono implementati tramite l'uso di chiamate a
funzioni, infatti in asm è difficile gestire funzioni lunghe come quelle
scritte con linguaggi di alto livello.
Come vedi anche in asm esiste la "buona programmazione". Quando si studiano
le funzioni, si apprendono i concetti di stack, heap, variabili locali,
globali, statiche, ecc... (anche qui si usano le Macro).
Tutte queste cose appaiono estremamente limpide se spiegate in asm (chiedi
al 99% dei programmatori di linguaggi di alto livello come pensano che certe
"funzionalità" siano state implementate e preparati a impallidire).
L'asm portato a questi livelli è veramente molto simile ai linguaggi di
medio livello come il C, ma mantiene una corrispondenza 1-1 con la maggior
parte delle istruzioni della CPU.
Quando si passa al linguaggio C (o a un altro linguaggio di medio livello)
non si può fare a meno di ricollegare tutto quanto è stato studiato in
precedenza con i nuovi costrutti che in realtà ricordano tutti alla
perfezione quelli creati con le Macro.
Studiare l'asm non è inutile perché, dato che le CPU sono tutte simili ed
equivalenti, si è in grado di valutare più facilmente se un algoritmo
(specialmente se non prettamente numerico) è efficiente, se la memoria è
organizzata in modo intelligente, e così via...
Non dimentichiamoci che nel calcolo della complessità a livello teorico le
costanti non contano e si guardano gli ordini, ma nella realtà contano non
poco!
Per es. un programma di riconoscimento vocale troppo lento è inutile. Se
l'algoritmo è molto efficiente, ma l'implementazione è pessima, il risultato
è ugualmente disastroso.
Quello che non pochi ignorano è che il codice può essere notevolmente
ottimizzato agendo direttamente sul codice sorgente che hanno scritto. Dato
che i metodi generici di ottimizzazione adottati da tutti i compilatori sono
molto simili, è possibile aiutarli organizzando il codice in determinati
modi.
Anche qui, conoscere l'asm aiuta moltissimo e non è vero che si perde
portabilità o che ottimizzare il codice è inutile. Esistono metodi di
ottimizzazione che non pregiudicano la portabilità e funzionano praticamente
ovunque.
Ritengo che sia poco educativo partire da un linguaggio di alto livello
perché è difficile capire in modo *intuitivo* i vari concetti e per me
l'*intuito* è tutto.
Prima le cose vanno capite intuitivamente e poi definite e dimostrate
rigorosamente. I concetti capiti intuitivamente te li ricordi finché vivi,
invece gli aridi teoremi possono essere dimenticati dopo pochi anni che non
si usano.
Per es. in Calcolo Numerico vengono sbattute in faccia agli studenti formule
che vengono chissà da dove oppure vengono presentate particolari matrici
senza dire da dove vengono. Magari sono state "inventate/scoperte per caso",
ma spesso l'autore stava cercando qualcosa e partire dal risultato senza
sapere niente di come ci si è arrivati rende il tutto molto arido.
>> Si potrebbe fare il parallelo con il latino e l'italiano. Sono due
>> lingue diverse quindi è un errore usare costruzioni latine in
>> italiano, però la conoscenza del latino è tutt'altro che
>> controproducente
>
> Sì. Ma il latino non si impara in prima elementare.
Neanche l'italiano :-)))
Kiuhnm
Xelloss dal portatile
> Per me l'aspetto didattico è proprio questo.
> L'asm non pone limiti (o quasi) quindi ognuno può implementare un software
> nei modi più strani possibili.
L'esperienza dice che rispettare le convenzioni dell'asm è tutt'altro che
banale anche per chi non è al primo corso di programmazione.
> Come vedi anche in asm esiste la "buona programmazione".
Certo che sì, ma non sei per nulla costretto ad usarla.
> Studiare l'asm non è inutile
Nessuno l'ha mai sostenuto. Solo che non è utile studiarlo come primo
linguaggio. Un primo corso di programmazione dovrebbe basarsi sulla
ricorsione e l'utilizzo delle strutture dati. Tutto il resto può venire
dopo: prima di imparare a fare meglio (ottimizzando il codice) bisogna
imparare a fare e basta.
Enrico Franchi
> Nessuno l'ha mai sostenuto. Solo che non è utile studiarlo come primo
> linguaggio. Un primo corso di programmazione dovrebbe basarsi sulla
> ricorsione e l'utilizzo delle strutture dati. Tutto il resto può venire
> dopo: prima di imparare a fare meglio (ottimizzando il codice) bisogna
> imparare a fare e basta.
Sostanzialmente sono d'accordo.
C'era una famosa massima sull'ottimizzazione precoce... ;)
Enrico Franchi
> Per es. in Calcolo Numerico vengono sbattute in faccia agli studenti formule
> che vengono chissà da dove oppure vengono presentate particolari matrici
> senza dire da dove vengono.
A voi magari. A noi hanno dimostrato tutto. Pezzetto per pezzetto.
Fai Ingegneria, Matematica o altro?
Kiuhnm
> Kiuhnm <kiuhnm_...@invalid.it> wrote:
>
>> Per es. in Calcolo Numerico vengono sbattute in faccia agli studenti
>> formule che vengono chissà da dove oppure vengono presentate
>> particolari matrici senza dire da dove vengono.
>
> A voi magari. A noi hanno dimostrato tutto. Pezzetto per pezzetto.
> Fai Ingegneria, Matematica o altro?
Cosa c'entrano le dimostrazioni???
Se ti presento una formula lunghissima e te la dimostro sei soddisfatto?
Kiuhnm
Enrico Franchi
> Cosa c'entrano le dimostrazioni???
Nel senso che costruisci le cose e dimostri che hanno un senso.
> Se ti presento una formula lunghissima e te la dimostro sei soddisfatto?
Dipende. Chiaramente se non me la dimostri devo avere un esame molto
sotto e avere molto poco tempo per fidarmi sulla parola. :)
Kiuhnm
>> Se ti presento una formula lunghissima e te la dimostro sei
>> soddisfatto?
>
> Dipende. Chiaramente se non me la dimostri devo avere un esame molto
> sotto e avere molto poco tempo per fidarmi sulla parola. :)
Allora mi spiego meglio. Calcolo Numerico può considerarsi Matematica
applicata e prende in prestito metodi da vare branche della stessa. Per
questo motivo, spesso ci si ritrova ad utilizzare metodi specifici senza
sapere che esiste un'intera famiglia di tali metodi. Per capire alla
perfezione un metodo è utile partire dal più semplice della stessa famiglia
e arrivarci passo passo.
Kiuhnm
Enrico Franchi
> Per capire alla
> perfezione un metodo č utile partire dal piů semplice della stessa famiglia
> e arrivarci passo passo.
appunto... e su questo siamo parecchio d'accordo.
obsidian
devo dire che l'ho trovata un ottima soluzione per insegnare a chi non deve
studiare informatica nella vita, perchè ti permette di apprendere i concetti
senza preoccuparti troppo della sintassi (e lo stesso si potrebbe dire per
visual basic che però ha altri diversi difetti).
Il c++ ti permette una via di mezzo, capisci come interfacciarti al sistema
operativo, capisci cosa devi includere e cosa no, e apprendi il concetto di
oggetti, cosa che ormai non è possibile non sapere.
L'assembler, che penso bisognerebbe distinguere tra assembler su macchina
ideale (dove di solito si impara) e su macchina reale (dove ti devi
preoccupare di cosa puoi leggere, quando, dove, etc...) non è un bel
linguaggio da imparare e non avendo direttamente strutture ti porta a
trovare un sistema per tutto, ma se uno ti dice di far finta che quello sia
un ciclo con un goto: messo ad un certo punto e il flag messo in quel modo e
ti devi preoccupare dello stack e di tutto il resto, il concetto di ciclo
quando lo capisci? e che utilità pratica ha doversi preoccupare di flag,
stack e quant'altro? se è anche vero che l'assembler ti permette di
ottimizzare, quanti programmi vale la pena ottimizzare in assembler?
l'ottimizzazione di questo tipo ha un costo abbastanza alto, ed è raro (a
mio parere) che valga la pena per chi acquista il prodotto pagarla.
Poi sono sicuro che c'è qualcosa che va solo in assembler, come magari le
sim dei cellulari o qualche altra cosa molto di base.
La domanda rimane sempre, a cosa ti serve studiare un linguaggio? a
programmare, a lavorare, a capire? poi scegli...
per curiosità dico che studio ing inf (primo anno c++, secondo anno
assembler ideale (poco), terzo anno assembler reale (sempre poco), ma nel
frattempo fai le reti e i calcolatori, altrimenti non avrebbe senso)
"darko" <da...@spam.org> ha scritto nel messaggio
news:4104...@x-privat.org...