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.
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 eac
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 will
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 ha
On 11/13/09 6:31 , "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
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
-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
iEYE
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 'int
-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 f
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
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 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 s
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 formatti
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 formatt
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 we
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 to
On Wed, Nov 11, 2009 at 10:07 AM, Peter Haworth 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, output formatting is
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 form
-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 n
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
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 '0.0'|
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 "$" si
22 matches
Mail list logo