Newsgroup: it.cultura.linguistica.italiano
Titolo: Separazione migliaia nei numeri

Qualcuno sa come si dividono le cifre delle migliaia in italiano 
corretto, nei numeri?
A me sembra di ricordare che il puntino di separazione vada messo in 
alto, ovviamente cosa impossibile con un computer. Insomma 
millecentocinquanta sarebbe: 1°150 (perdonate l'uso del circolino) e non 
1.150. Vaneggio? Qualcuno si ricorda questa cosa?
Ciaoooo
-- 
Togli le maiuscole dall'indirizzo email, per rispondere
Il vantaggio di essere intelligente è che si può sempre fare 
l'imbecille, mentre il contrario è del tutto impossibile. (W.A.) 

corretto, nei numeri?
le norme per la scrittura dei numeri (in campo scientifico) non sono solo
italiane, ma internazionali  e sono stabilite dall'ISO
esse prevedono che i gruppi di tre cifre siano separati da uno spazio
(quindi niente punti, ne' sopra ne' sotto)
saluti cari
A.L.


(italiano di Svizzera). Il separatore delle migliaia è il campo
"Grouping Separator", nella sezione "Number Elements".
Ciao.
Marco

 (quindi niente punti, ne' sopra ne' sotto)
    Norma saggia, qualora si scriva in un ambiente internazionale, giacché
in certi Paesi s'usa il puntino, in altri la virgola, ed occorre evitare
confusioni. Ciò nondimeno, restando in àmbito nostrano, giacché s'usano i
puntini, che, nella scrittura a mano, sono piú chiari dello spazio vuoto ed
impediscono che vi si interpoli abusivamente un'ulteriore cifra, la domanda
originaria mi pare sensata.
    Io metterei il puntino in altro, sia perché cosí m'hanno insegnato, sia
perché è piú razionale: la scrittura alfabetica latina attribuisce maggiore
importanza alla metà superiore delle lettere che a quella inferiore. Se
provi a coprire la metà inferiore di una riga, riesci a leggere lo stesso,
se copri quella superiore, non ce la fai. Ergo, l'occhio, specie leggendo in
fretta, si sofferma di piú in alto (ecco perché accenti e diacritici,
sovente, si mettono in alto e non in basso), e quindi, per semplificare al
massimo l'elaborazione cerebrale dello scritto, opterei per il puntino alto.
Scrivendo al computer, come giustamente osservi, mi vedo costretto a
ricorrere al puntino basso, che di conseguenza, ahimè, compare anche in
tutti gli stampati delle mie prestazioni occasionali (sono un libero
professionista).
    Ciao,
            Nicola
--
Multa non quia difficilia sunt non audemus, sed quia non audemus sunt
difficilia (Seneca).
[it, en, ru, es, (fr, pt, la, zh, ar)]

1.150. Vaneggio? Qualcuno si ricorda questa cosa?
Effettivamente in italiano si scriveva così.
In Unicode dovrebbe corrispondere al carattere 729 (02D9 in
esadecimale)
Credo che oggi le norme editoriali prescrivano di separare le
migliaia, oltre le quattro cifre, con uno spazio:
1234
12 345
--
Maurizio Pistone - Torino
                strenua nos exercet inertia  Hor.
 
scri...@mauriziopistone.it
 
http://www.mauriziopistone.it
 
http://www.lacabalesta.it

 12 345
Solo oltre le quattro cifre? Un bel macello, dal punto di vista
informatico. Ben pochi sistemi operativi sarebbero in grado,
attualmente, di mettere in pratica una simile separazione
condizionale.
Per quanto riguarda lo spazio da usare, Unicode ha un carattere
apposito: l'8199 (esadecimale 2007), che è uno spazio non secabile
(cioè il computer non andrà mai a capo fra il "12" e il "345") della
stessa larghezza delle cifre arabe.
Senza Unicode, si può usare il 160 (esadecimale A0), che è sempre uno
spazio non secabile, ma della larghezza dello spazio normale.
Ciao.
Marco

 Questo genere di convenzioni sono piuttosto variabili [...]
In un caso come questo, un accordo a senso è tollerabile o è un errore?
Insomma: da uno a cento, quanto mi devo vergognare di quello che ho scritto?
Ciao.
Marco

 Marco

 stessa larghezza delle cifre arabe.
Perché mai dovrei usare uno spazio largo quanto una cifra?
Esteticamente sta meglio lo spazio normale proprio perché più stretto.
-- 
____________________________________
Giancarlo Pillan  -  Ivrea  -  Italy
____________________________________

 professionista).
C'è l'apostrofo-virgoletta-apice che può svolgere egregiamente la
funzione di "separatore delle migliaia da mettere in alto". Con il
vantaggio di occupare meno spazio del carattere spazio.


 Esteticamente sta meglio lo spazio normale proprio perché più stretto.
Boh. So che Unicode ha questo spazio speciale ("FIGURE SPACE"),
pensato proprio per questo uso. Bisogna vedere se, nella pratica,
qualcuno lo usa veramente.
Una ragione potrebbe essere che, all'interno del testo "giustificato"
(allineato cioè sia a sinistra che a destra), la larghezza dello
spazio è variabile. Su una linea di testo che ha poche parole, i due
pezzi del numero potrebbero trovarsi talmente distanti da sembrare due
numeri separati ("12    345").
Ciao.
Marco

 numeri separati ("12    345").
Motivazione respinta: se desidero incolonnare dei numeri dovrň
necessariamente allinearmi a destra. In ogni caso, motiverebbe solo la
caratteristica "unificante" non quella di "minor larghezza" cui mi
riferivo.


 riferivo.
In questo caso non parlavo di una tabella di numeri (generata magari
automaticamente) ma di un numero all'interno di una frase,  battuto
manualmente, tipo: "Il terremoto causò 12 345 vittime nella sola
capitale". Se fra i due pezzi del numero c'è un normale spazio
"elastico", potrebbe succedere che venga mostrato con una larghezza
eccessiva, quando il testo è "giustificato".
Questa è la ragione per cui in Unicode hanno messo questo "FIGURE
SPACE". Poi, ognuno è libero di utilizzarlo o meno (e la mia
impressione è che, in pratica, non lo usi nessuno).
Ma, come al solito, siamo terribilmente off-topic! Peccato che non
esista un newsgroup italiano dedicato a questo tema
dell'internazionalizzazione del software. Chissà se la materia sarebbe
on-topic su <it.comp.accessibilita>?
Ciao.
Marco

 lunghezza del numero.
Lo puoi fare solo se usi applicazioni ben fatte.
Non mi risulta che in Cina e Giappone si raggruppi a quattro.
So solo che si "dicono" a "decimigliaia".


GCPillan wrote:
 > Esempio di SW di buona qualità, come quello realizzato dalle ditte
 > dove ho lavorato io, ovvero che non prende la facile scorciatoia di
 > utilizzare info provenienti dal sistema operativo:
 >
 > Meeting at 2:00 pm on May 9th, 2002. Incontro alle 14:00 del 9 maggio
 > 2002.
La questione se usare o meno il "locale" non è così banale da potersi
esaurire in un giudizio di buona o cattiva qualità. Il problema èè che
ci troviamo di fronte a due esigenze contrapposte e non armonizzabili.
Da una parte la necessità per un utente di un sistema di leggere
determinate informazioni in un formato a lui/lei comprensibile in quanto
conforme alle regole alle quali è abituato/a.
Dall'altra quella di mantenere l'originalità dell'informazione così come
è stata scritta dall'autore per evitare che modifiche di formato ne
alterino il contenuto.
Un esempio: la data. Supponiamo che in un contratto americano si faccia
riferimento ad una certa improrogabile scadenza: 05/04/2002. Ovviamente
è il 4 maggio. Supponiamo che io riceva il documento in un sistema
italiano e che la data in questione venga trasformata in 04.05.2002. Io
so che ci siamo messi d'accordo su maggio -- la conversione per me è
corretta e conforme agli accordi -- per cui stampo il documento e firmo.
Quindi mando via posta ordinaria il tutto. Dall'altra parte mi bloccano
il contratto. Per loro 04.05.2002 è il 5 aprile.
L'unica soluzione sarebbe se ogni informazione "localizzabile" venisse
corredata di una metainformazione relativa al formato, visualizzabile a 
richiesta. Non solo: in fase di stampa il formato dovrebbe essere 
automaticamente segnalato tramite una opportuna nota a piè di pagina.
Altro caso: €20.000 sono ventimila euro o venti euro? Per un inglese 
sono venti euro con la segnalazione dei millesimi, come richiesto in 
certe operazioni bancarie. Per noi sono ventimila senza riporto dei 
centesimi, come si scrive spesso in documenti non formali. Inoltre, 
anche se nell'Unione usiamo quasi tutti gli euro, abbiamo comunque modi 
diversi di scrivere i valori in valuta: €20.00, 20,00€, €20¢00, €20- e 
così via. Sugli assegni, poi, si scrive €20/00.
E non abbiamo analizzato i "locale" arabi, giapponesi, cinesi e via 
dicendo. La stessa punteggiatura può essere "localizzata". Ad esempio 
noi tendiamo a mettere i segni di interpunzione a fine frase fuori dalle 
virgolette, gli americani li mettono dentro:
Gianni disse: "Che bella giornata!".
John said: "What a glorious day!"
Maria rispose: "Non lo so".
Mary replied: "I do not know."
Insomma, secondo gli standrd NLS leggere il "locale" è buona 
programmazione, codificare in modo fisso il formato no. Ma entrambe le 
soluzioni non risolvono il problema: culture diverse rappresentano le 
stesse informazioni in modo differente, e questo può essere sempre e 
comunque fonte di equivoci.
IMHO
Dario de Judicibus

on-topic su <it.comp.accessibilita>?
Per restare nel subgruppo cultura, un'idea sarebbe
it.cultura.cybersocieta
-- 
Bye
      Vitt

 Vero, ho appena provato. Ma sembra piů un'eccezione che la regola.
Ah, capisco: č come la cesta di mele gialle che ne contiene
ben tre gialle ed eccezionalmente sette rosse...
Altre "eccezioni" alla regola per cui Word utilizza le impostazioni
internazionali sono:
1) Inserisci Data e ora
2) Visualizza numeri in tabella
3) Risultato funzioni matematiche 
   (mentre l'interpretazione segue la "regola")
4) Sostituzione virgoletta-apice tra le migliaia
5) chissŕ quante altre situazioni...
Spiego meglio la (3)...
Scrivo due numeri all'italiana.
Sotto metto la somma in automatico.
La somma viene corretta.
Salvo il documento. 
Ipotizzo una spedizione: imposto USA in Windows.
Riapro il documento: č inalterato. Bene!
Modifico leggermente un importo, conservandone il formato.
Aggiorno la somma: viene sbagliata!
Motivo? Il nuovo numero viene interpretato secondo il formato USA anche
se č scritto all'italiana (ovvero viene considerato mille volte piů
piccolo) e la somma viene lasciata nel formato italiano originale. Come
dicevo, i tentativi di prendere la scorciatoia dei parametri esterni
sono soggette spesso a malfunzionamenti piů o meno evidenti.
Fortunatamente questo errore capita in Word che non č propriamente un
foglio di calcolo. Excel si difende un po' meglio.


 comunque fonte di equivoci.
Non c'è alcun problema se ti attieni sempre ed esclusivamente alle 
convenzioni relative alla lingua di stesura del documento.


 [...]
Non sgolarti a criticare Word, ché io non ho certo intenzione di
difendelo. E men che meno ho intenzione di difendere Excel, che odio
ricambiato.
Quanto alle incongruenze e alle deficienze dei sistemi di locale sui
vari sistemi operativi, non credere che non le conosca.
Oltre ai paradossi sulle date citati da te e da Dario de Judicibus,
trovo che la cosa piů pazzesca sia il trattamento degli ammontari
valutari: se scrivo "L.1000" (mille lire = 0,52 euro) e cambio la
"locale", mi potrei ritrovare con "US$ 1000.00" (mille dollari)! Come
se i simboli "L." e "US$" fossero semplici "preferenze" stilistiche!
Nel mio ambiente, queste cose ci costringono a "incapsulare" i servizi
di i18n forniti dai sistemi operativi, in modo da poter rimpiazzare
ciň che non funziona con meccanismi sostitutivi.
Ma questo, a mio avviso, non significa che la parametrizzazione
internazionale sia in sé una cosa sbagliato. Se non vogliamo una
americanizzazione forzata, queste cose servono.
Perché la cosa produca piů benefici che danni, perň, bisogna che
questi strumenti siano progettati con intelligenza. Per esempio, il
sottosistema di localizzazione multipiattaforma di ICU
(
http://oss.software.ibm.com/cgi-bin/icu/lx
) č un punto d'inizio non
da buttare.
Bisogna anche che questi strumenti siano usati con un po' di sale in
zucca. Per esempio, trovo deleterio che si "internazionalizzino" i
dati interni a un programma: č bene che una data, per esempio, abbia
sempre internamente un formato normalizzato semplice, tipo "20020513".
Solo al momento della presentazione all'utente si utilizzeranno
formati piů complicati, come "13 maggio 2002".
Ciao.
Marco