On 11/13/09 6:31 , Dan Bishop danbisho...@gmail.com wrote:
Microsoft Excel has a similar problem. I ran into it back when I was
working in a credit union and tried to import a CSV file containing
credit card numbers. Wouldn't have noticed except that credit card
numbers are 16 digits long
On Thu, 12 Nov 2009, Dan Bishop wrote:
Microsoft Excel has a similar problem. I ran into it back when I was
working in a credit union and tried to import a CSV file containing credit
card numbers. Wouldn't have noticed except that credit card numbers are
16 digits long and double only has
Thanks for all the comments on this. Didn't realise there were so
many things to worry about when dealing with currency!
The system I'm developing is only dealing with US dollars right now
but I would hope it might make it's way into other countries at some
point. Even with dollars, I
On Fri, Nov 13, 2009 at 03:07:27AM +, Simon Slavin wrote:
On 13 Nov 2009, at 12:34am, Nicolas Williams wrote:
On Thu, Nov 12, 2009 at 11:40:23PM +, Simon Slavin wrote:
There's still some possibility for confusion, however: how many places
of decimals do you use for each currency
On 13 Nov 2009, at 4:40pm, Peter Haworth wrote:
That often give rise to some rounding issues. I do all the math using
however many decimal places are given to me and then round the total
to two decimal places, then calculate how much is owed to each band
member based on that total.
Thanks for all the advice on this. Just to be clear, I wasn't
referring to the accuracy of calculations when I compared the sqlite
date/time formatting capabilites to the lack of similar functionality
for currency, just the fact that there is a precedent for sqlite
providing output
That has always been my most effective last resort when attempting to do
business math with many databases and development environments.
Thanks for all the advice on this. Just to be clear, I wasn't
referring to the accuracy of calculations when I compared the sqlite
date/time formatting
On 12 Nov 2009, at 7:17pm, Peter Haworth wrote:
Just to be sure I get my calculations correct, the suggestion is that
all currency amounts should be stored in the database as whole numbers
in fields of type INTEGER. Calculations would be done using the whole
numbers and I'll need some
On Thu, Nov 12, 2009 at 11:40:23PM +, Simon Slavin wrote:
There's still some possibility for confusion, however: how many places
of decimals do you use for each currency ? As far as I know, no
currently traded currency uses more than two digits of precision.
On 13 Nov 2009, at 12:34am, Nicolas Williams wrote:
On Thu, Nov 12, 2009 at 11:40:23PM +, Simon Slavin wrote:
There's still some possibility for confusion, however: how many places
of decimals do you use for each currency ? As far as I know, no
currently traded currency uses more than
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Simon Slavin wrote:
Integers in all languages I'm aware of are not stored as mantissa/exponent,
they're stored as bits with complete precision.
There is one huge exception I found out the hard way recently: Javascript
stores all 'integers' as
On 13 Nov 2009, at 3:30am, Roger Binns wrote:
Simon Slavin wrote:
Integers in all languages I'm aware of are not stored as mantissa/exponent,
they're stored as bits with complete precision.
There is one huge exception I found out the hard way recently: Javascript
stores all 'integers'
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Simon Slavin wrote:
JavaScript doesn't have an integer type, just a number type:
You are agreeing with me :-)
Roger
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
Simon Slavin wrote:
On 13 Nov 2009, at 3:30am, Roger Binns wrote:
Simon Slavin wrote:
Integers in all languages I'm aware of are not stored as mantissa/exponent,
they're stored as bits with complete precision.
There is one huge exception I found out the hard way
Seems like I should handle the formatting in my application. Not sure
I agree that sqlite is not the place to do output formatting - it
provides lots of date and time formatting features so at least in that
area, output formatting is available.
Thanks also for the info re accuracy/REAL
On Wed, Nov 11, 2009 at 10:07 AM, Peter Haworth p...@mollysrevenge.com wrote:
Seems like I should handle the formatting in my application. Not sure
I agree that sqlite is not the place to do output formatting - it
provides lots of date and time formatting features so at least in that
area,
The best (safest?) way I have found to handle non scientific math is to
work strictly with integers and multiply and divide using ROUND/TRUNC as
required to gain the precision required. This includes way more than
SQLite situations as well. Borland (Code Gear) seem to be the only
developer
On 11 Nov 2009, at 4:51pm, Fred Williams wrote:
The best (safest?) way I have found to handle non scientific math is to
work strictly with integers and multiply and divide using ROUND/TRUNC as
required to gain the precision required. This includes way more than
SQLite situations as well.
I have a column defined with a type of FLOAT, which I believe is
treated as REAL by SQLite. When selecting that column, I would like
it to be returned with a leading $ sign and always have a decimal
point and two numbers after the decimal point. I can use
concatenation to get the $ sign
There's no way to force SQLite to return exactly 2 decimal places for
you. You have to do it in your application or if you really-really
need to do it in sql you can do it like this (assuming you need column
col from table tab):
select '$'||case
when length(col) = 1
then
On Tue, 10 Nov 2009, Peter Haworth wrote:
Is there a way to do this or should I plan on handling it within the
application?
Pete,
The latter. Display formatting is not part of SQL.
You might also consider using integer values for money because the math is
more accurate.
Rich
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Peter Haworth wrote:
I have a column defined with a type of FLOAT, which I believe is
treated as REAL by SQLite. When selecting that column, I would like
it to be returned with a leading $ sign and always have a decimal
point and two
22 matches
Mail list logo
