Newsgroup: it.comp.os.linux.development
Titolo: Infomedia traditrice (FUD)

Il FUD colpisce ancora. Il FUD contagia anche Infomedia che fino ad ottobre del
1999 diceva che Linux e l'Open Source erano la salvezza del mondo. Ho comprato
Computer Programming perchè avevo visto che il focus era su Linux, ho trovato
dentro un dossier sul pinguino scritto da Dino Esposito, un ottimo
programmatore ma purtroppo servo di M$. E' stato davvero imparziale l'articolo,
considerando che Esposito ha sempre proclamato la superiorità di Winzoz in
tutti i campi fingendosi imparziale. Citando dati sulle performance presi da
fonti filo-M$, parlando con programmatori che dichiaravano che "Windows NT è
instabile per colpa dei driver di periferica che non vanno", precisando che
"non so quanti drivers abbia Linux ma di sicuro ne ha meno, quindi è + stabile
per questo". Affermazioni sicuramente campate in aria, che dimostrano l'essenza
del FUD. Cioè spararle grosse senza cognizione di causa. Inoltre ancora certa
gente non capisce perchè sia meglio l'Open Source, il bazaar, rispetto alla
cattedrale. I soldi uno li fa anche con l'Open Source e in modo meno sleale.
Secondo me è schifoso vedere società che si scontrano a suon di monopoli e
tecnologie proprietarie ed unilaterali, invece con l'Open Source ci sarebbero
standard ed ognuno avrebbe la possibilità di modificare il codice. Il FUD
termina con la spiegazione che Linux è bello, affidabile, e stabile ma non
esiste supporto tecnico, non esistono giochi, non esiste Visual Basic, GNOME e
KDE sono grezzi etc... Che KDE non sia affatto innovativo, ma sia piuttosto un
clone della GUI di MacOS e Winzoz è vero. Forse quei programmatori intervistati
e lo stesso Esposito non conoscono GNOME 1.2 che fa la gioia di chi vuole avere
un bel desktop, forse nonm sanno tutto il lavoro dietro a GNOME 2.0, forse non
conoscono i giochi per Linux (Quake2/3 e altri come Civilization).
E' una vergogna.....
-- 
Pier Luigi Fiorini 
http://www.fiorinisoft.n3.net/

 E' una vergogna.....
già
-- 
Non c'è più forza nella normalità: c'è solo monotonia.

 già
Quello che mi fa arrabbiare è che il dossier lo ha scritto uno che usa le
tecnologie (?) M$, uno piu' parziale di lui non lo potevano trovare...


 
http://www.gnome.org/gb
NOOOOO!!!!!!!!!


 wrote in message
news:05O75.11986$2s6.1...@news.infostrada.it...
[snip]
Computer Programming e` sempre stato molto Windows-oriented, ed Esposito
e` un noto sostenitore del mondo Windows. Se pero` ad esempio prendiamo
Dev, credo che sia l'unica rivista italiana Linux-oriented con una certa
tiratura... certo non possono parlare *solo* di Linux, perche` sarebbe
un suicidio commerciale (ricordo che stiamo parlando dell'Italia).
P.S. Puoi darmi una rinfrescata sul significato di "FUD"? In passato mi
sono beccato piu` volte anche io questo epiteto, ma non ricordo piu`
cosa significhi. :)
---
Bye! Lorenzo Lutti
http://www.geocities.com/SiliconValley/Peaks/6258/

 significhi. :)
FUD (fear uncertain dubt, lasciando perdere il fatto che avrò scritto male...)
paura, incertezza, dubbi. E' una tecnica particolarmente usata da M$ e soci,
siccome costoro non sanno competere lealmente sfornando tecnologie vere,
inventano cacchiate come falsi test (magari confronto di performance tra un pc
i486 con gnu/linux e un pc i586 75MHz con wincaz 95, senza ovviamente dirlo) Si
finisce anche col negare l'evidenza sfruttando la fama che un prodotto aveva
nelle versioni meno recenti. Basti pensare che a volte si parla del fatto che
il kernel di linux va ricompilato al cambio di hardware. Cio' era vero tanto
tempo fa (ricordiamo che 1 anno informatico sono 3 anni uomo o giù di li, qui
si parla di 6 anni informatici fa circa) quando i moduli non esistevano. Oggi
quasi tutte le distro offrono un kernel con tanti moduli, basta caricarli o
scaricarli a proprio piacimento. Se poi un Microservo ha paura ad usare la
console, ca$$i suoi. La GUI piace a tutti, io uso GNOME, ma ancora oggi
solitamente le operazioni sui files le faccio in console con cp, mv o altri
comandi perchè sono più comodi. E continuerò anche quando ci sarà Nautilus.


 NOOOOO!!!!!!!!!
Pensa che uno degli obiettivi č proprio la compatibilitą con Visual Bug.


 tecnologie (?) M$, uno piu' parziale di lui non lo potevano trovare...
Dipende se lo pagano o meno...
E' noto che M$ in un modo o nell'altro foraggia le riviste con pubblicita'
se scrivono bene di loro (ma anche altri lo fanno in effetti)
bye
Gianluca.
-- 
Home Page                	Contro i brevetti sw     Boicotta Microsoft
www.infinito.it/utenti/chewbe
 
no-patents.prosa.it/
 
www.boycott-ms.org/
 
"If we have to file a thousand lawsuits a day, we'll do it.
It's less expensive than losing CONTROL of YOUR creative works."
---Jack Valenti, President and CEO, Motion Picture Association of America


Sono completamente d'accordo su tutto quello che hai detto.
Cmq ti faccio notare che CP fino a 2 anni fa non parlava di Linux, e
che chi adesso ne parla male (?) allora avrebbe detto "Linux non
esiste ... " o qlcosa di simile.
Qualcosa si muove, anche nell'ambiente dei fedelissimi M$.
Nello stesso articolo cmq lo stesso autore invita a inviargli critiche
o precisazioni. Probabilmente sa di non sapere (o di sapere poco su
Linux). Mi sembra l'atteggiamento di una persona non chiusa, o non
completamente chiusa, su ambienti a lui alieni.
Ciao
Fausto


Di questo gliene do atto, non č certamente chiuso al 100%. Se qualcuno con
maggiore esperienza informatica di me gli inviasse critiche costruttive...
Credo a: 
espo...@infomedia.it
 Cmq hai ragione qualcosa si sta muovendo,
speriamo che nel giro di poco tempo Linuz venga considerato un OS (magari nel
tempo anche il miglior OS, o meglio quello piů scalabile, performante, stabile
e + adatto alle esigenze della maggior parte della gente)
E' per questo che cerco di aiutare come posso il progetto GNOME....


 Pensa che uno degli obiettivi è proprio la compatibilità con Visual Bug.
penso che metterò nel cron un'entrata  per purificare ogni giorno il mio
pc da libGnomeBasic, per essere sicuro che anche se un giorno la dovessi
installare poi se ne andrebbe.


cosa significhi. :)
Fear, Uncertainty, Doubt.
man FUD, FUD-HOWTO e FUD-Reply-HOWTO sono la' fuori :-)
Leonardo
".signature": bad command or file name

 completamente chiusa, su ambienti a lui alieni.
No, e' il comportamento sbagliato. Se non sai, _prima_ di scrivere
l'articolo ti informi, _poi_ lo scrivi.
bye
Gianluca


 installare poi se ne andrebbe.
Mmh ottima idea :-))


 
http://www.geocities.com/SiliconValley/Peaks/6258/
più che Windows-oriented direi Microsoft-oriented. A riprova di quanto
dico, all'interno della rivista prodotti per lo stesso Windows di Case in
competizione con la M$ trovano poco o nessuno spazio.  Il Delphi della
Borland/Imprise, praticamente ignorato, ne è un eclatante esempio.
Figuriamoci se si sognano di parlar bene di Linux....
Ciao

 Figuriamoci se si sognano di parlar bene di Linux.... Ciao
No ma la pubblicità di Inprise/Borland io l'ho sempre vista, anche se poca. I
casi sono 2: o Inprise non spende tanto (non credo sia giusta) o il grande (e
bastardo) fratello (cioè M$) c'entra L'ignoranza di certi (pseudo) tecnici fa
davvero schifo. Tempo fa, quando purtroppo usavo Win (ero vittima del FUD
perchè credevo che Linux fosse rimasto come nella serie 1.0, invece c'era già
la 2.0 con tante innovazioni) facevo dei programmi con Delphi quindi ho fatto
una litigata su linux nel newsgroup di Marco Cantù. Beh sono tornato dopo
qualche mese nel newsgroup, dopo aver provato linux per tutto il tempo, e ho
detto che corel fa schifo. Hanno fatto un prodotto con una licenza non chiara
(credo anche che certi programmi non possano essere distribuiti, ma non vorrei
sbagliare), etc, etc. Loro mi hanno risposto che è come Windows e quindi è
bella!!!!! Ah ahah ahahahahaha Che risate...... E' molto meglio una distro come
Debian che è sicura, non va in crash ogni 3 secondi (si come winzozz) che una
facile come corel, semiproprietaria, entri come root senza password, va in
crash, si basa su qt! Il succo è questo: Cantù (che si crede un grandissimo
programmatore, ma come persona fa schifo perchè è arrogante) non sapeva un
ca$$o di Linux (bastava fargli domande) e di Corel e si permetteva di parlare


-- 
Dopo questo intervento credo che non mi rivolgerete più la parola :-(
Perchè tanto accanimento contro questo progetto? Un'ambiente di sviluppo RAD è
una delle poche cose che manca a Linux e sarebbe non poco utile. Intanto
consentirebbe ai programmatori non esperti di passare in modo più soft a Linux,
lasciandogli il tempo di imparare gradualmente. L'incontro con gcc e librerie
varie è stato quasi un trauma, da cui non sono ancora uscito. Mi spiego:
programmo per hobby, e in Win/Dos ho imparato (credo) molto bene VB e Pascal.
Conosco un poco di C++ ma con Linux non sono ancora riuscito a fare niente,
anche perchè non sono ancora riuscito a trovare un po di documentazione adatta
(continuo a rimpiangere gli help on line di Turbo Pascal, Turbo C++ e VC++ :-( )
E poi non è detto GnomeBasic debba essere per forza fatto male, solo perchè è
compatibile con VB. Ripeto, credo che questo incoraggerà molti appassionati
(come sono io) a passare a Linux: e non mi sembra una brutta cosa...
ciao ANto


Cos'è Nautilus?


 */

 (come sono io) a passare a Linux: e non mi sembra una brutta cosa...
Io non ti ammazzo sicuro, anche se la pensiamo diversamente! Ho sempre adorato
i RAD ma se li usi non sai nulla di come funzionano realmente le cose e se ti
trovi in panne che fai? Imparare le glibc, gdb, gcc, make e altri è
fondamentale!! Se uno non sa queste cose elementari è meglio che non programmi
affatto. Capisco la necessità per gli utenti desktop di un desktop environemnt
(PS: pubblicità, il migliore è GNOME :-)) anche a me piace sollazzarmi con le
icone colorate e le stupide finestrelle fluttuanti, ma se si vuole programmare
bisogna sapere. Anche se si programma per hobby, anche io faccio qualche
programmillo in C per hobby, non sono un programmatore professionista ed
esperto però le basi (gcc, gdb etc...) le conosco e chiunque le deve conoscere!
L'informatica significa informazione automatica, qundi che infomratica c'è se
non c'è conoscenza? E ricorda che l'informatica non è (solo) la GUI all'ultima
moda.


agosto/settembre e sostituirą gnome midnight commander su gnome 2.0!
Ma solo per la gui?
-- 
Ci sentiamo  |  Remigio Zedda
             |  
remi...@tiscalinet.it
ciao Remigio |                    kernel 2.2.13 su Slack 7.0

 non c'è conoscenza?
Guarda che in quel caso con "informazione" non si intende cio` che
conosce il programmatore. :-)



Credo che ci siamo capiti male. La penso esattamente come te, solo che con un
RAD il passaggio sarebbe più graduale. Concordo il giudizio su GNOME :-)
Anto


 *
 *       Powered by
 *  OpenOS GNU/Linux v0.1
 *     (Linux v2.2.16)
 */

 software e` scritto usando il VB qualche ragione ci sara`...
Sotto windows probabile ... fortunatamente non sotto linux, dove in
genere le cose si tende a farle con dei linguaggi veri, affrontando lo
sforzo necessario per impararli.
Tenderei a chiudere qui la solita diatriba RAD/nonRAD, difficile che una
delle due parti cambi idea; gli argomenti sono sempre gli stessi e alla
quarta o quinta volta vengono a noia, comunque se proprio volete
continuarla almeno cambiate il subject, che Infomedia traditrice non mi
pare adatto.
Ciao
-- 
Simone Piccardi
Microsoft is NOT the answer. Microsoft is the Question.
The answer is: "NO!"

 programmatori per Linux.
C'e' glade. Non e' proprio tipo VB ma e' interessante.


 almeno cambiate il subject, che Infomedia traditrice non mi pare adatto.
Già è una diatriba irrisolvibile, possiamo però fare un thread a parte...


 vicini al vero problema).
Beh, pero' l'idea dietro VB non e' male. Le poche volte che mi trovo a scrivere
programmi con gtk, la maggior parte del tempo parte per fare la gui del 
programma, avere un qualcosa che consente di disegnarle in maniera
facile ed intuitiva (l'_unico_ vantaggio del VB) non e' male.


 delle due parti cambi idea;
Non voglio far cambiare idea a nessuno. Mi sono limitato a far notare un
fatto che mi sembrava poco contestabile, ossia che un buon RAD sotto
Linux causerebbe un boom del numero di programmatori. Se anche fossero
"programmatori di serie B", potrebbero sempre crescere; e comunque anche
se anche non crescessero promuoverebbero Linux indirettamente.
P.S. Questo non mi sembra un thread OT, a patto di non scivolare sui
soliti tormentoni "chi usa i RAD e` un lamer" oppure "il VB non e` un
linguaggio di programmazione"... continuo a trovare interessante il
discorso "RAD sotto Linux". Se non vi piacciono non usateli, e` una
vostra scelta; ma arrivereste a ostacolarne la diffusione? Denigrando i
potenziali "utenti" lo state facendo.


 vicini al vero problema).
Che sarebbe?
Secondo me il vero problema e` sempre quello di non sfondare i costi.
Quello che usi per risolvere il problema (incluso il sistema operativo,
ovviamente) e` soltanto una conseguenza, non un vincolo. Se invece
stiamo parlando di una fantomatica "Arte della Programmazione" o di alti
ideali, allora e` un altro discorso. In particolare, e` un discorso che
non mi interessa.


Cos'è Nautilus?
nautilus sarà un giorno il nuovo filemanager di GNOME, dagli screenshot
sembra eccezionale, e io ci conto molto, visto che quello attuale
e una merda a dir poco.
poi con la concorrenza feroce del KDE qualcosa di buono in questo senso mancava.
ho letto che dalla versione 2.0 sara compatibile con l'HTML 4.0, i CSS,
e i plugin per il netscape.

pare adatto.
il RAD va bene anche sotto linux, purche il linguaggio sia il C/C++,
le librerie necessarie all'interfaccia e gli header file siano open source
e che il tutto sia basato sui tool GNU in modo da garantire una facile
compilazione su altri sistemi che non abbiano l'ambiente RAD installato.

facile ed intuitiva (l'_unico_ vantaggio del VB) non e' male.
be pero di rad anche se non avanzati come delphi ce ne sono,
parti 
www.gtk.org
 e cerca...


Lo so, lo so. E' che non faccio piu' programmi in gtk per il momento.


facile ed intuitiva (l'_unico_ vantaggio del VB) non e' male.
Glade.
(C, C++, Ada...)
-- 
 (o-  | Un OS per domarli, Un OS per trovarli,
 //\  | Un OS per ghermirli e nel buio incatenarli
 V_/_ | 
http://pinguin.linuxave.net
 r.salmaso(at)
flashnet.it

"ma per ordinare 200.000 record, non si puo' usare il bubble-sort ?"
La tecnica che ho visto io per ordinare i records e' la seguente (so una
ricca sega di VB, io, quindi abbiate pazienza).
	a) Si apre un controllo Listbox
	b) Si caricano le righe di testo nelle opzioni
	c) Si da': Listbox.sticazzi.options.sorted = YES
	d) Si rileggono le opzioni.
Tadah. E si rileggono ordinate.
Ora, provateci con 64K di dati, e osservate stupiti e increduli l'OS che
parte alla scoperta delle sorgenti del Nilo (e, no: non le trova).


 parte alla scoperta delle sorgenti del Nilo (e, no: non le trova).
Ma questo dipende dall'algoritmo che viene utilizzato per il sorting,
non certo dal modo in cui tu chiedi che ti venga fatto il sorting.
Ciao,
Fabio Alemagna

 wrote in message
| Ora, provateci con 64K di dati, e osservate stupiti e increduli l'OS che
| parte alla scoperta delle sorgenti del Nilo (e, no: non le trova).
Non e' per difendere M$, ma basta freezare l'update della list-box... come
va fatto col gtk.






Ho il sospetto che ci siano sistemi piu' efficienti per ordinare 200.000 record,
che so, un bel algoritmo con tempo lineare (Radix sort)... Anche se in effetti non
ho idea dell'algoritmo che usa il controllo in oggetto, ma non credo che sia 
uno di quelli in tempo lineare, ma potrei sbagliarmi, quindi niente insulti ;-). 


 niente insulti ;-).
Il codice inerente il controllo listbox spiegato non è un algoritmo ;-)


 mi interessa.
Linux è un OS diverso da Windows, un RAD potrebbe anche essere tollerato ma
deve essere fatto in un certo modo. Esiste Glade, che viene usato moltissimo,
poi con libglade è possibile creare la gui a runtime senza scrivere tanto
codice... Cmq un buon RAD non sarà mai Kylix (Delphi per Linux) o GNOME
Basic... Bisognerebbe realizzare qualcosa che sia adatto a Linux e che nasconda
il meno possibile al programmatore tutto ciò che fa! E soprattutto deve usare i
tool GNU come automake, autoconf, gcc, make, gdb e magari gnome-debug.


 
www.gtk.org
 e cerca...
Glade è uno di questo, cioè non è un RAD tradizionale ma solo un GUI builder
però è interessante,, cito anche libglade. 
http://glade.pn.org/
Quello che serve a GNU/Linux è un buon IDE per GNOME (dato che è l'unico
desktop veramente free per tutti i linguaggio di programmazione (dato che
EGCS/GCC li supportano quasi tutti), simile all'organizzazione della finestra
di Visual C++, che è uno dei pochi punti a suo favore.


 di Visual C++, che è uno dei pochi punti a suo favore.
C'e' gia' Glade che e'molto meglio di Visual C++/MFC (Credimi...)
Ciao
--
Mandoch

 Pier Luigi Fiorini 
http://www.fiorinisoft.n3.net/
Approvo :-)

 gnome-debug.
perfetto!!!!!
-- 
Non c'č piů forza nella normalitŕ, c'č solo monotonia.

 wrote in message
G9_a5.6989
| Guarda che ho usato sia VB che Delphi, soprattutto Delphi ma ti posso
giurare
| che VB č un software idiota che permette di fare sotware molto semplici.
Si
| possono fare al massimo dei gestionali, per realizzare un buon programma
e
| complesso bisgna usare un vero linguaggio di programmazione. VB si basa
sul
| basic che non č un linguaggio di programmazione, serve solo ad imparare e
ad
| introdursi nella programmazione.
Peccato che il 90% dei software richiesti siano gestionali...
In questo modo si e' creato un mercato di programmatori VB, spesso gli
unici in una Software House, che pensano di avere per le mani il top del
top, ma poi s'inchiodano davanti alle definizioni delle API nelle
librerie...
(comunque col VB si fanno anche dei bei programmini per il controllo del
costo di connessione, dai... :-)

 Il codice inerente il controllo listbox spiegato non è un algoritmo ;-)
Zi, ma il controllo un algoritmo di ordinamento lo dovra' utilizzare, se 
ordina i dati...


 se anche non crescessero promuoverebbero Linux indirettamente.
Dicevo solo che le argomentazioni pro/contro RAD sono sempre le stesse,
e quel che dici me lo conferma in pieno. Dopo la quarta volta che vedi
di queste discussioni ti annoi un po', e per questo, almeno per quel che
mi rigurda, la pianto qui.
Ciao
-- 
Simone Piccardi
Microsoft is NOT the answer. Microsoft is the Question.
The answer is: "NO!"

 basic che non č un linguaggio di programmazione
Motiva questa affermazione apparentemente errata. Il basic e` dotato di
tutti i costrutti fondamentali dei linguaggi di programmazione
strutturati; il basic *e`* un linguaggio di programmazione procedurale,
mediocre quanto vuoi, ma lo e`.


non certo dal modo in cui tu chiedi che ti venga fatto il sorting.
No, no. Dipende dal fatto che il listbox aveva un buffer statico di 64K.
E, a giudicare dai disastrosi risultati, non controllava di averlo forse
sfondato :-)
Comunque nulla di che: il server che va giu', un dump di un centinaio di
mega, cose cosi'.


va fatto col gtk.
Scusa, doveva esserci scritto: "Provate con PIU' di 64K di dati".
L'update non so cosa faccia, ma dubito eviti il Blue Screen of Death che
compariva immancabilmente 8-D
(E' anche vero che io gli spedivo dentro i codici ABI e CAB per tutte le
banche d'Italia 8-D )


 wrote in message
|
| Scusa, doveva esserci scritto: "Provate con PIU' di 64K di dati".
| L'update non so cosa faccia, ma dubito eviti il Blue Screen of Death che
| compariva immancabilmente 8-D
Avevo da kualke parte un codice dimostrativo di number crunching che
trovava alcuni milioni di numeri, data mem e HD sufficienti, proprio in VB.
mi sembra il 4 o il 5.
il problema e' che andava prima chiamata la
int InitStorage( int nItems, UINT nBytes );
If successful, the maximum number of items that the list box can store
before a memory reallocation is needed, otherwise LB_ERRSPACE, meaning not
enough memory is available.
che comunque su win95 1^ v. non permetteva di forare i 32K elementi, ma su
NT, e' sempre stato solo questione di limiti di mem.


 RAD il passaggio sarebbe più graduale. Concordo il giudizio su GNOME :-)
Ah allora avevo frainteso :-)


> C'e' gia' Glade che e'molto meglio di Visual C++/MFC (Credimi...)
Oppure Lazarus per chi usava Delphi!
www.lazarus.freepascal.org
www.freepascal.org


 e`.
Aggiungerei interpretato. Cmq Linux e Windows sono diversi, se uno vuole Linux
si deve adattare, altrimenti usa Windows in tutto e per tutto.


 tutto.
Adattarsi a cosa?


Lo so, lo so. E' che non faccio piu' programmi in gtk per il momento.
il fatto č che gtk per ora č il toolkit per X piů avanzato in assoluto,
quindi vedi un po' tu, ma non gtk based c'č poco.

 Adattarsi a cosa?
all'approccio linuxiano


 uno di quelli in tempo lineare, ma potrei sbagliarmi, quindi niente
insulti ;-).
Algoritmi di ordinamento a complessità lineare ??????!!!!!!!!!!!!!
Mi puoi dire di più in merito, credo che potresti vincere un nobel.
Manuele.


Non credo, visto che sono gia' stati inventati.
Quando non esegui ordinamenti per confronti, allora il limite inferiore
 ---n lg n--- viene a cadere, e quindi, dato che quello e' il limite
inferiore (dimostrato) per gli algoritmi per confronti, puoi avere tempi lineari.
Counting Sort ad esempio ha tempo k=O(n) che e' lineare su n.
Altri algoritmi con tempi medi lineari sono il Radix sort o il Bucket Sort
(i tempi medi sono generalmente quelli considerati per valutare un algortimo quando
non hai idea di come sara' l'input. Se invece sai come e' l'input, le valutazioni
da fare sono altre)
Se ti interessa di piu' l'argomento (o vuoi controllare le mie affermazioni)
dai un'occhiata a 
"Introduzione agli algoritmi Vol 1" (titolo originale "Introduction to Algorithms")
di T.H. Cormen, C.E. Leiserson e R.L. Rivest


 Counting Sort ad esempio ha tempo k=O(n) che e' lineare su n.
Vi credo, anche se mi sembra molto strano... Non mi potreste dire su cosa si
basano questi algoritmi? (Voi dite che non si basano su confronti...)
Qual'è l'idea di base di tali algoritmi?
GRAZIE
Daniele.

Vai Daniele spacca giů tutto!!


E' sembrato strano pure a me la prima volta che l'ho sentito...
Dunque, i normali algoritmi di ordinamento confrontano in maniera piu' o meno
furba gli elementi. C'e' pero' un'altra classe di algoritmi che, usando tecniche 
diverse, non ha bisogno di fare confronti. 
Il Counting Sort ad esempio si basa sull'idea di contare, per ogni elemento x,
quanti elementi minori ci sono, e poi mettere x direttamente nella posizione 
giusta. Altri algoritmi usano altre tecniche o fanno altre supposizioni sui
dati di input, ma in ogni caso non eseguono confronti tra gli elementi, ma 
ha la necessita' di sapere quanti elementi ci sono (cosa non difficile 
da trovare in effetti).
In codice potrebbe essere una cosa simile:
for 1 to k
	C[i] = 0
for j = 1 to lenght[A]
	C[A[j]]++
for i = 2 to k
	C[i] = C[i] + C[i-1]
for j = lenght[A] downto 1
	B[C[Aj]]] = A[j]
	C[A[j]]--  
(scopiazzato dal libro dell'altro post)
Come vedi fa 4 cicli e nessun confronto...
Hanno i loro vantaggi e svantaggi (il radix sort ad esempio consente
di ordinare 1.000.000 di numeri a 64 bit in 4 passate, ma ciuccia un
sacco di ram). 
I dettagli li trovi sul libro di cui avevo postato il titolo comunque.


	C[A[j]]--  
!!
Caspita, e' proprio vero che non bisogna mai dare niente per scontato.
Mi chiedo se con un altro piccolo sforzo, non si riuscira' a trovare
la parola giusta e dire ... abbacatrabba! :-))
ciao Michele

 C[A[j]]--
OK, non è per fare il polemico a tutti i costi... ma se io ti dessi un
vettore di double da ordinare...
Sì, va bene, hai ragione: i double hanno pur sempre una rappresentazione
"discreta" in memoria, perciò con mooooooooolta RAM ce la puoi fare. Però
non è un tipo di ordinamento che vale in tutte le condizioni, come
bubblesort, quicksort and so on... Anzi, a dire la verità algoritmi di
questo tipo sono d'uso piuttosto limitato, dal punto di vista pratico.
Quand'è che puoi realmente permetterti di avere un vettore di dimensioni
pari alla cardinalità dell'insieme che vuoi ordinare? Es.: i programmatori C
hanno la cattiva abitudine di usare gli "int" sempre e comunque. Sarebbe
buona abitudine usare anche char, unsigned int, etc...
Quindi: la cardinalità di un "int" è... eheh... sapevo che ci sareste
cascati!!!! Siamo in linux su processori a 32 bit: quanto fa?! Fa circa
4.300.000.000 (e non circa 65.000 come pensano tutti quelli che provengono
dal DOS!!).
A noi interessa la cardinalità e non il valore max che è circa 2.000.000.000
Bene, ora sappiamo che ci serve un vettore lungo 4.300.000.000. Ma un
vettore di cosa? Beh, il caso peggiore richiede un tipo che consenta di
contenere almeno la lunghezza del vettore iniziale. Supponiamo di essere
fortunati e avere almeno un vettore iniziale corto, così da poter usare dei
char (ma i programmatori C userebbero sicuramente degli int = 4 byte!!!!).
In totale ti servono 4.300.000.000 byte.
Tu li hai sul tuo PC?
Daniele.

 Tu li hai sul tuo PC?
Sei fuori strada. Il caso peggiore dovrebbe essere (dovrebbe perche' non 
l'ho mai testato) il caso in cui hai un vettore di 100 elementi, con il
minimo 1 e il massimo 4.233.323.328
Altrimenti ci sono metodi per ridurre la necessita' di memoria.
In ogni caso, tieni presente che per ordinare simili quantita' di dati ci
sono altri tipi di approcci.
La scelta dell'algoritmo da utilizzare varia anche in base alla quantita'
di dati che ti aspetti di ricevere. Se sai che non avrai mai piu' di un
100 di dati, puoi usare anche un bubble-sort e la cosa funziona lo stesso
bene. Se pero' ti aspetti di avere un array di 2.000.000 di int, allora 
forse devi studiare qualche altro sistema per ordinare i dati. Quello che 
ho riportato, non e' neppure l'unico algoritmo in tempo lineare che esiste,
non e' detto che sia il migliore o il piu' adatto.
Un esempio che puo' farti capire quanto sia importante la scelta dell'algoritmo
giusto e' questo (estratto sempre dal solito libro)
A[1.000.000] -> Array da ordinare.
hai due macchine: un supercalcolatore ed un PC sfigato.
Sul supercalcolatore usi:
	Insertion Sort ottimizzato al massimo -> 2n^2 operazioni
	100.000.000 di operazioni al secondo
Sul PC usi
	merge sort non ottimizzato -> 50nlg(n) operazioni
	1.000.000 operazioni al secondo.
Ecco i risultati:
Supercalcolatore: (2*(10^6)^2)  /  (10^8)  = 20000 sec = 5.56 ore
                      |               |
                  istruzioni      istr/sec
                      |               |
PC:               (50*10lg10^6) /  (10^6)  = 1000 sec = 16.67 minuti
Se tu usassi sul PC un algoritmo lineare avresti (spannometricamente e 
molto in eccesso)
                  (100*n) / (10^6) = 100 sec = 1.67 minuti
(non ne sono sicuro al 100% pero' dovrei ripassare un po')
Sicuramente pero' non e' questo l'unico parametro da considerare, ma anche
la RAM, i tipi di dati e cosi' via (questo ad esempio non ordina stringhe).
(chiedo venia per le eventuali stupidate scritte, ma e' un po' che non prendo in 
mano sta roba)
bye
Gianluca


A noi interessa la cardinalità e non il valore max che è circa
2.000.000.000
Avrei proprio detto il contrario...
Saluti,
    Mardy
P.S. Gli int in Linux potrebbero anche essere > 32 bit.

 dal DOS!!).
Char                  1 byte         8 bit
Signed Char           1 byte         8 bit
Unsigned Char         1 byte         8 bit
Short                 2 byte        16 bit
Int                   4 byte        32 bit <--- :-O
Long                  4 byte        32 bit
Unsigned Short        2 byte        16 bit
Unsigned              4 byte        32 bit
Unsigned Long         4 byte        32 bit
Float                 4 byte        32 bit
Double                8 byte        64 bit
Long Double          12 byte        96 bit
Compilato ed eseguito su Intel Pentium 133
gcc version 2.95.2 19991024 (release)
...ovviamente sotto DOS.
--
 Ciao, Bianco.
 Reply to 
luca....@tiscalinet.it

 mano sta roba)
GRAZIE per la pazienza!
Daniele.

> C[A[j]]--
DP> OK, non è per fare il polemico a tutti i costi... ma se io ti dessi un
DP> vettore di double da ordinare...
infatti gli algoritmi di ordinamento lineari di solito si possono
usare solo sotto certe ipotesi, in questo caso che i numeri da
ordinare siano interi e che ci sia (e sia noto) un limite superiore
al valore che tali numeri possono assumere (ok, a parte quello banale
di MAXINT :)). Altrimenti tutti userebbero solo gli algoritmi lineari
e i nostri cari amici quicksort e compagnia bella potrebbero andare
in pensione :)
-- 
ciao,
Claudio

 GRAZIE per la pazienza!
Oh, di niente.
bye
Gianluca
-- 


 Avrei proprio detto il contrario...
Infatti mi interessa di piu' il valore max e minimo piu' che la cardinalita'
dell'insieme.


 caso accada, ma e' un problema comune a tutti gli algoritmi.
Con la versione randomized di quicksort non e' detto che accada, e' anzi 
improbabile.
-- 
Riverenti Saluti,
                  Mahatios ap Ganadhor                           
########################################################################
# - #193 IHGGER                                                        #
# - Illuminante Apostolo e Maestro del                                 #
#   Leale Ordine della Cavalleria et Stregoneria Italica (LOCSI)       #
# - Webmaster-master del PBEM di C&S 
http://gioco.net/fantasy/aquileia
 #
# - CoWebMaster del (futuro) sito del LOCSI, 
http://gilda.it/locsi
     #
########################################################################

 improbabile.
Osservazione acuta e corretta. Con il quicksort randomizzato ti metti al
sicuro perche' non capita mai il caso _peggiore_ ma continui ad avere
comunque un tempo di n (log n), che su insiemi molto grandi porta a 
valori notevoli. 
Per contro gli algoritmi non basati su confronti, e quindi in tempo lineare,
abbattono comunque questo limite, anche nel caso peggiore, quindi sono 
piu' adatti ad ordinare grossi volumi di dati o grosse strutture di dati
con piu' chiavi.
Mi ripeto, quicksort, come tutti gli altri algorimi, non va bene sempre e
comunque: in alcuni casi va bene ed in altri no, dipende anche dalla politica
che usi per le risorse. Se ti va bene sprecare un po' di ram e avere un processo
di ordinamento molto veloce usi un algoritmo, se invece hai problemi di ram 
ma non ti interessa avere il processore occupato per molto, e' un altro 
discorso. 


 processore occupato per molto, e' un altro  discorso.
