Newsgroup: it.comp.www.php
Titolo: Inserire nel decimale .00

il valore nel campo del DB è 925.000
$Imponibile é 925.000
con questa funzione
function CalcolaIVA($Imponibile) {
        $totale = $Imponibile * (20 / 100) ;
  return $totale;
}
visualizzo 185
come modifico la visualizzazione di 925.000 in 925.00
e
come visualizzo il valore dato dalla funzione in 185.00 ??


wrote:
function CalcolaIVA($imponibile)
{
	return number_format($imponibile*0.2, 2, '.', '');
}
Leonardo
-- 
Enough, enough!  But, stranger, ere we part,
Glancing farewell to each nefarious bier,
This warning would I beg you take to heart:
There is an end to e'en the worst career!

 come visualizzo il valore dato dalla funzione in 185.00 ??
http://php.net/manual/en/function.number-format.php
Se la precisione dei decimali è di vitale importanza (e mi pare di
capire di si) considera le funzioni bc*
http://it.php.net/manual/en/function.bcscale.php

 il valore nel campo del DB è 925.000
[..]
Scusa, ma ... IMHO usare i float per degli importi è FOLLE.
Usa gli interi, esprimi tutto in centesimi (o millesimi) di Euro.
Ciò detto, converti in euro e formatta con number_format in
VISUALIZZAZIONE.
ciao, f.

 Usa gli interi, esprimi tutto in centesimi (o millesimi) di Euro.
+1
Usare gli interi sempre quando possibile.
Ciao,
luigi
-- 
/
+--[Luigi Rosa]--
\
I could prove God statistically.
    --George Gallup

 Usare gli interi sempre quando possibile.
Yep ;)
Aggiungo che in ANNI di sviluppo di applicativi e database, posso
tranquillamente affermare che l'uso dei float è una perfetta *rarità*
nel mondo reale.
Non è che ogni volta che hai un decimale hai un float.
I float servono quando vuoi rappresentare valori in virgola *MOBILE*,
ovvero roba tipo 2, 1,5656, o pi greco NELLA STESSA VARIABILE.
Per il resto, quando la precisione che si richiede è *FISSA* (= n
decimali fissi, come nel caso degli importi), usare i float è
assolutamente da pazzi. Lo considero un errore grave di progettazione.
Commettendolo escono fuori (ad esempio) quei bei gestionali che "a
volte" "in alcuni casi" danno risultati imprevedibili. Che non è quello
che vuoi.
Se solo sorge il dubbio, vuol dire che il float non serve.
ciao, f.

 nel mondo reale.
Anche perche', alla fine, a livello applicativo hai quasi sempre una
formattazione tipo "tot cifre per l'intero, virgola, tot cifre per i decimali" o
comunque una limitazione nei decimali che puo' essere comunque normalizzata con
un intero.
Ciao,
luigi
-- 
/
+--[Luigi Rosa]--
\
Computers make excellent and efficient servants,
but I have no wish to serve under them.
Captain, a starship also runs on loyalty to one man.
And nothing can replace it or him.
    --Spock, "The Ultimate Computer"

Scusa, ma ... IMHO usare i float per degli importi è FOLLE.
Il modo raccomandato è usare il tipo DECIMAL, o, dove disponibile, il
tipo CURRENCY.
In subordine, il tipo FLOAT va bene per importi "di tutti i giorni" -
diciamo inferiori al miliardo.
Il tipo intero espone a grossi problemi con i decimali (e questo gia'
se devi calcolare percentuali dell'ordine del 20%; se ti tocca il 15%
o il 30%, o peggio ancora il 17%... brrr).
La soluzione "Rube Goldberg" con gli interi prevede di scalarli, come
del resto fa già il tipo DECIMAL, ma facendolo a mano e in piu' punti
- a me pare la cronaca di un disastro annunciato.
Il tutto poi per...? Risparmiare due microsecondi di sort, o due byte
a colonna in un database? Questo sì, che ha poco senso.


 - a me pare la cronaca di un disastro annunciato.
No se l'accesso ai dati lo fai direttamente in ogni punto del programma. QUELLO
e' un disastro annunciato.
Quasi sempre hai una funzione di mediazione o normalizzazione dei dati che, per
esempio li sanifica prima di passarli a SQL, li sanifica prima di passarli ai
form, li sanifica dopo averli presi dai form, eccetera. Il tutto fatto
centralmente, non disseminato per il programma.
Basta aggiungere a quella funzione la capacita' di leggere e scrivere anche i
dati "decimali".
Il giorno in cui cambiano le regole, cambia l'engine o viene aggiornato devi
solo cambiare l'algoritmo della funzione e il tuo programma non se ne accorge
nemmeno.
Ciao,
luigi
-- 
/
+--[Luigi Rosa]--
\
You cannot propel yourself forward by patting yourself on the back.

 30%, o peggio ancora il 17%... brrr).
Il problema, quando tratti valuta, e` che la legislazione ha regole 
"umane" e non informatiche.
Quindi il 17% di 20.25 non e` 3.4425, ma 3.44, anche se poi devi sommarlo 
con altre cifre. Semplicemente devi perdere pezzi per strada e scordarti 
la precisione.
Ma soprattutto quando hai 3.4449999999999 non devi arrotondare a 3.45, ma 
a 3.44, mentre con 3.4450 devi arrotondare a 3.45, perche` conta solo la 
terza cifra decimale (tranne rarissimi casi), e spesso con la 
rappresentazione FP sei fregato causa arrotondamento interno. :)
Gestirli come interi e` una vera rottura, ma in alcuni casi e` l'unica 
soluzione.
Bye.

centralmente, non disseminato per il programma.
Questo pero' non ti aiuta granche' se i dati fanno "anda e rianda" piu'
volte dal sistema al database. Ogni volta si verifica un arrotondamento
o troncamento per tenere il dato "pulito" nel database, e in certi casi
gli errori si sommano anche parecchio.


In subordine, non accettare il lavoro.
(Visto che "in subordine" significa che non sia accettabile impiegare gli
strumenti adatti a fare il lavoro per bene, costringendo a workaround che
- IMLimitedExperience - finiscono per costare piu' tempo, fatica e denaro
di quanto sarebbe costato dotarsi degli strumenti adatti in primo luogo).
===
On a side note, il tipo CURRENCY non si comporta come uno si aspetterebbe
"sempre e comunque", dipendendo a volte da impostazioni varie. Sybase per
esempio equivale a NUMERIC(...,4).
Una tabella che può tornare comoda:
http://www.carlprothman.net/Default.aspx?tabid=97
Il tipo FLOAT ha come grossa limitazione la sostanziale impossibilita' di
effettuare SELECT basate sulla corrispondenza esatta (il vecchio discorso
della "precisione di macchina"), che a volte puo' essere richiesta.


 gli errori si sommano anche parecchio.
Oddio, e quando mai fai "anda e rianda" dal db di dati che stai elaborando?!
In ogni modo, nel caso di numeri periodici o irrazionali qualsiasi sistema di
codifica dei numeri deve introdurre degli "errori". Per questo ci sono delle
precise regole finanziarie per gli arrotondamenti che ti permettono di
utilizzare gli interi.
Del resto, ci sono banche e grosse istituzioni che utilizzando programmi in
COBOL o RPG, che tagliano come un'ascia sui numeri e nessuno si e' mai lamentato.
Ciao,
luigi
-- 
/
+--[Luigi Rosa]--
\
Hackers do it with fewer instructions.

utilizzare gli interi.
Mi fanno giustamente notare in email che NUMERIC e INTEGER sono a
tutti gli effetti matematici la medesima cosa.
Per qualche motivo, attribuivo proprietà magiche al tipo NUMERIC.


 assolutamente da pazzi.
La soluzione però non è l'uso degli interi ma del datatype
NUMERIC(precision, scale).
http://www.techrepublic.com/article/sql-basics-number-data-types/1051673

 dato che non aggiunge ASSOLUTAMENTE NULLA ?
Aggiunge, aggiunge, perchè con int(8) rendi i dati illeggibili da
chiunque non conosca le tue convenzioni.
E' come se tu memorizzassi tutte le date come varchar(6): se io mi trovo
un "101112" come faccio a interpretarla senza sapere che formato usi?
Stamattina mi sono arrivati dei risultati di analisi chimiche nel
formato che piace a te: i parametri che conoscevo già sono riuscito a
interpretarli, ma per un parametro nuovo ho dovuto chiedere perchè non
avevo idea se 999 volesse dire in realtà 9D99, 99D9, 0D999, ...

dato che non aggiunge ASSOLUTAMENTE NULLA ?
Non proprio, due cose (non essenziali, d'accordo) le aggiunge:
1. Risparmia di usare in proprio la divisione per 100 o 1000
2. In output ti da' in automatico i decimali


...però questa volta non concordo molto.
Be', stiamo discutendo dei gusti, eh. Matematicamente dentro la roba
è quella: che sia NUMERIC o INTEGER. Anche come spazio di storage mi
sa che non ci siano differenze significative.
In genere io non mi occupo della logica di display, e sicché tendo a
far fare il più possibile al backend... se hai una logica di display
più importante, mi torna, che tu possa far fare lo scaling a lei.
In genere però, io cerco di mantenere il formato dei dati congruente
con il suo significato, diciamo, "semantico": le valute sono in euro
o dollari, non in centesimi.
Comunque, qui stiamo senz'altro in zona "de gustibus" :-D


 Comunque, qui stiamo senz'altro in zona "de gustibus" :-D
Quoto, ma aggiungo due considerazioni (che ovviamente si contraddicono 
;-) ):
- se la velocità degli elaboratori viene calcolata in FLOPS un motivo ci 
sarà;
- in campo finanziario e contabile i floating sono in genere 
sconsigliati (tanto che è stato proposto uno standard, IEEE 754, per ora 
implementato in pochi linguaggi).

 sarà;
I FLOPS sono roba nuova. Prima di loro c'erano i MIPS (million 
instructions per second). :P
Bye.

 instructions per second). :P
Più che altro vengono usati alternativamente, a seconda del tipo di 
record che i "big" vogliono battere ;-)
A parte le battute la cosa ha anche senso: se devo fare un computer per 
simulazioni climatiche (esempio a caso) avrò bisogno di potenza in 
virgola mobile, per un computer più "generalista" meglio i MIPS.

 dovuti ai limiti del sistema :)
Si ma i problemi sarebbero altri.
Tipo: Mi devi pi greco euro, e li voglio TUTTI. ;-P
ciao, f.

 Be', stiamo discutendo dei gusti, eh.
[..]
Si abbastanza, mi pare di capire che siamo entrambi dell'idea che si
tratti di un insieme discreto e come tale vada gestito ... il resto
tutto sommato son finezze.
Ricordo in università quando studiai le rappresentazioni floating point:
una volta visto *come* venivano trattate, fui assalito DAL TERRORE circa
il loro utilizzo (IEEE 754 fa - per certi versi - venire i brividi).
Del resto, alla fine, un *REGISTRO* rappresenta sempre e comunque un
insieme di stati FINITI.
In realtà, la pericolosità sta proprio lì ... ti SEMBRA di poter gestire
numeri reali ... forse esagero ma se non hai almeno una volta nella vita
compreso *perfettamente* quel buffo insieme pseudo-reale (al punto da
poter scrivere con carta e penna la rappresentazione interna dato un
numero ... è meglio che non li usi. ;)
ciao, f.

 Tipo: Mi devi pi greco euro, e li voglio TUTTI. ;-P
LOL :-)
Ok, però prima mi devi dare una definizione matematica di "euro". ;-)

 Tipo: Mi devi pi greco euro, e li voglio TUTTI. ;-P
:) :) :)
Solo dopo che Achille avra' raggiunto la tartaruga!
Ciao,
luigi
-- 
/
+--[Luigi Rosa]--
\
Nature, to be commanded, must be obeyed.
    --Francis Bacon

 Solo dopo che Achille avra' raggiunto la tartaruga!
ahaha ;)
O anche "te li darò quando mi dirai esattamente dov'e' e dove sta
andando quel bischero di heisenberg" ;)
ciao, f.

 Tipo: Mi devi pi greco euro, e li voglio TUTTI. ;-P
... che poi perchè accada basta accordarsi con un imbianchino per tot
euro per ogni metro di staccionata dipinta, avendo un giardino circolare
... ;)
ciao, f.

numero ... è meglio che non li usi. ;)
Tanto tempo fa, scrissi un programma che usava una variabile float. Poi,
il "creeping featurism" rese quella variabile uno stato... nel senso che
poteva avere valori sopra o sotto una certa soglia.
Dato che gli incrementi erano fissi, il primo avviso sarebbe stato - per
forza - il momento in cui quella variabile avesse assunto ESATTAMENTE il
valore della soglia.
Non penso di dover aggiungere altro, se non che mi ci volle una giornata
a capire che era quello il test che non funzionava. Anche i breakpoint a
valle vedevano che lim aveva quello che _PAREVA_ il valore critico.
Da allora, o forse da un po' prima o dopo, scrivo cose come
	if (test)
	{
		jdebug("test passato");
		...
	}
	else
	{
+++		jdebug("test fallito");
		...


che l'esempio che citi non ha alcun senso (mettere date in un varchar)
tu finora hai lavorato solo su db progettati dopo il 2000 vero? mai
avuto a che fare con un db in utilizzo dal 1980 vero? perche' sai
all'epoca le date (se eri fortunato) venivano registrati in formato
numerico nella versione aaaammgg, ma solo se sei fortunato, altrimenti
anche char o varchar (perche si portavano appresso i separatori di
data) 

 data) 
Ma ... che c'entra ?
Sto parlando di quelle che ritengo essere buone tecniche di
*progettazione* (oggi).
Se è per questo esistono anche DB progettati malissimo ben dopo il 2000,
e pur capitando di doverci per forza lavorare senza poterli
riprogettare, non è una buona ragione per venir qua a sostenere che
memorizzare date nei varchar sia una buona cosa.
Anche perchè ti voglio vedere poi quando devi effettuarci delle
*operazioni* lato DB ...
ciao, f.

*operazioni* lato DB ...
quello credimi e' l'ultimo problema, come hai detto altrove e' un
problema di comprensione delle logiche interne di un sistema, una
volta assunte quelle, si procede alquanto tranquillamente... 

 volta assunte quelle, si procede alquanto tranquillamente... 
Mi permetto di dissentire sul "tranquillamente". Se non usi i datatype
corretti devi effettuare continuamente conversioni e anche le operazioni
piů banali diventano delle bombe a orologeria:
SQL> select min(to_date(crapdate,'yyyy-mm-dd')),
max(to_date(crapdate,'yyyy-dd-mm')) from mydata;
                                                        *
ERROR at line 1:
ORA-01841: (full) year must be between -4713 and +9999, and not be 0
Questo perchč su 42 milioni di righe corrette ce n'č una con
crapdate='paperoga'.
No datatypes, no party.
	Y.

max(to_date(crapdate,'yyyy-dd-mm')) from mydata;
avrei fatto un controllo (tramite apposita funzione) se c'erano sempre
scritti dei "numeri" dentro individuando il crapdate="paperoga" e
segnalando la cosa prima della funzione sql, se devi operare su un db
dove c'e' un campo formato char (ma vale anche per i tipi numerici)
che pero' rappresenta una data e decidi di usare quelle funzioni mi
sembra il minimo, perche' al di la' delle rassicurazioni del cliente,
ti ci puoi trovare veramente di tutto.
Ripeto, entrare in sintonia (e pararsi il sedere).

 fatto, prima di fare
Aggiungerei che tutti i database NoSQL e/o quelli che usano formati 
file-based (tipo HDF5) di solito neanche hanno il concetto di datatype.
Vista la loro sempre maggiore diffusione, in particolar modo in ambienti 
critici, evidentemente l'uso di formati/tipi arbitrari/personalizzati 
non č cosě drammatico.
Personalmente č anche la mia opinione, tanto che ultimamente ad esempio 
salvo le date come stringhe(8), evitando di pormi anticipatamente 
vincoli se le poi le dovrň archiviare su RDBMS, su NoSQL o su 
entrambi... :-)

 No datatypes, no party.
Considerato che siamo in un ng dedicato a un linguaggio dinamicamente e 
debolmente tipizzato la tua affermazione sembra quasi ironica... ;-)

 debolmente tipizzato la tua affermazione sembra quasi ironica... ;-)
Un conto sono i dati, un altro è il linguaggio di programmazione che usi
per elaborarli. Ho già avuto a che fare in passato con "database
debolmente tipizzati" e ti assicuro che preferirei andare a giocare a
moscacieca in tangenziale piuttosto che averci a che fare di nuovo.
YMMV. Il mondo è bello perchè è vario.

 entrambi... :-)
Io uso sempre e comunque un intero (timestamp unix a 64bit) per le date. 
Almeno posso farci dei conti. :)
Ho abbandonato il tipo date quando MySQL ha iniziato a spararmi fuori i 
dati in formato diverso in base al locale della macchina...
Bye.

 dati in formato diverso in base al locale della macchina...
Cambia DBMS.
	Y.

 PostgreSQL tutta la vita. Anzi tutte le vite. ;)
Gia` fatto, ma ho ancora un centinaio di siti che non e` che posso 
riscrivere se il cliente non paga per farlo.
Rimango comunque fedele al timestamp. :)
Bye.

 moscacieca in tangenziale piuttosto che averci a che fare di nuovo.
Ovviamente la mia era una battuta e anch'io, tendenzialmente, preferisco 
lavorare con strutture rigorose e formalmente ben definite.
Però va anche detto che due delle strutture dati che più si usano, file 
system e web (inteso come interfaccia basata su XML), sono basate su 
dati non tipizzati.

 dati in formato diverso in base al locale della macchina...
Sorvoliamo sul discorso MySQL ;-)

 concettualmente dovrebbe essere uguale.
MongoDB (quello che conosco meglio tra i due, ma CouchDB e` simile) e` 
si` dinamically typed, ma non significa che sia typeless.
Schemaless nel senso che non hai colonne predefinite, puoi metterci 
quello che vuoi.
Ma il bello e` che ha un motore javascript interno, e i dati sono JSON, 
quindi puoi usare una "cella" col suo tipo, che, per le date, e` proprio 
il tipo Date di JS, con relative funzioni di manipolazione.
Puoi fare, per esempio (anche se poco efficiente):
db.collezione.find({ $where: "this.data_pubblicazione <= new Date()"});
 
(sperando di non aver scritto js-castronerie).
Bye.

 (sperando di non aver scritto js-castronerie).
Il codice js mi sembra corretto però se noti gli fai elaborare un 
"this.": nel db è stato salvato un generico oggetto, al quale è stato 
associato un attributo. Attributo che essendo scritto in JS può 
contenere anche valori di tipo diverso da Date.
Idem per l'oggetto: nello stesso contenitore (che tu hai indicativamente 
chiamato "collezione") possono essere inseriti valori diversi dall'oggetto.
Ad esempio una cosa del tipo:
db.collezione.put('ci sto bene');
funziona senza problemi.
Fidati che ho provato per bene ;-)
Anche se qui mi forse mi son spiegato un po' sinteticamente... :-|
Va poi detto che il mio era un discorso generale: ci sono dozzine di 
motori di storage di tipo key/value con un comportamento ancora più 
permissivo.
Solo per ribadire che forse la tipizzazione "molto elastica" di cui si 
parlava non è così deleteria :-)

 parlava non è così deleteria :-)
No, anzi. Io la trovo eccezionale.
Bye.

 No, anzi. Io la trovo eccezionale.
Appunto, mi sa che la pensiamo allo stesso modo e stiamo discutendo del 
sesso degli angeli :D

 sesso degli angeli :D
Mi sa di si`, ma era solo per chiarire anche agli altri. :)
Bye.

 e` un DB SQL. :)
In effetti ero incerto su quale categoria applicargli... ;-)
Anche perché è una scelta che hanno sempre difeso a spada tratta, 
all'inizio per motivi di compattezza del codice, poi sempre più per 
motivi di dinamicità.
Lo metterei tra i database "SQL" solo perché, tautologicamente, usa SQL 
come linguaggio di interrogazione :-D