Jan,
By default, I use DOUBLE for all decimal values unless I know for fact that the number will be relatively small such as unit price of gasoline which can be represented using 9.999 although if there is no administration change next November, I might need 99.999 which would still be covered by the REAL type. With the availability of inexpensive memory and storage and fast processors, the impact of using DOUBLE instead of REAL is in many cases negligible. Having worked with databases when memory and storage were prized and expensive, the old miser in me still wants to consider the best type for the data. For my particular application, I see no obvious downside of doing away with REAL and using DOUBLE in all cases. But then again, I am not storing millions of records where the data type could make big difference. Javier, Javier Valencia, PE O: 913-829-0888 H: 913-397-9605 C: 913-915-3137 From: [email protected] [mailto:[email protected]] On Behalf Of jan johansen Sent: Wednesday, March 07, 2012 10:52 AM To: RBASE-L Mailing List Subject: [RBASE-L] - Re: Strange Missing one hundredth in SUM variable Hmmm. I need to spend some time with this one. I had created some data storage with REAL that I was looking at changing to DOUBLE so I could represent measurement data captured better. We have some instrumentation capable of displaying 12345.7654321 But now that I look at that number, DOUBLE may still be the way to go because scientific notation really doesn't cover it. REAL · Holds real number amounts in the range of ±1E38 with six-digit accuracy · Real numbers with up to seven digits are displayed as decimal numbers; for example, 321.414 · Real numbers with more than seven digits are represented in scientific notation; for example, 9.8E32 -----Original Message----- From: "A. Razzak Memon" <[email protected]> To: [email protected] (RBASE-L Mailing List) Date: Wed, 07 Mar 2012 09:09:14 -0500 Subject: [RBASE-L] - Re: Strange Missing one hundredth in SUM variable At 05:41 AM 3/7/2012, Bo Franzén wrote: >3 : REAL vinkomst = SUM inkomst FROM plusgiro >4 : REAL vutgift = SUM utgift FROM plusgiro >5 : REAL vsaldo = (vinkomst + vutgift) > >The two first variables are shown with only one decimal, in spite of the >fact that there are two in the tables. So inkomst is shown as 362048.7 and >utgift as -290733.9. The correct figures in two digits are 362048.72 and >-290733.90 and it's obvious that R:BASE only shows one decimal in those two >first variables. The same can be said when Computing at the R> promt, while >the input is OK when opening the table. But the last variable above, >vsaldo, is (much to my surprise) given in two decimals: 71314.81, simply >reducing our money with one Swedish öre, since the correct sum is 71314.82. >That is indeed a petty amount, even compared with a US cent! Bo, When storing and performing calculations related to currency, your best option is to use the CURRENCY data type. Here's what you need to know the difference between REAL, DOUBLE, INTEGER, CURRENCY, NUMERIC, and BIGNUM data types. REAL · Holds real number amounts in the range of ±1E38 with six-digit accuracy · Real numbers with up to seven digits are displayed as decimal numbers; for example, 321.414 · Real numbers with more than seven digits are represented in scientific notation; for example, 9.8E32 · R:BASE reserves four bytes of internal storage space · REAL numbers are stored in a binary form; therefore, the displayed value may not be the actual stored value DOUBLE · Holds double-precision real numbers in the range ±1.7E308 with a precision of up to 15 digits · DOUBLE numbers longer than 15 digits are stored as scientific notation · R:BASE reserves eight bytes of internal storage · Because DOUBLE numbers are stored in a binary form, the displayed value may not be the stored value INTEGER · Holds whole numbers in the range of ±1,999,999,999 · Delimiters (such as commas) cannot be used in entry · R:BASE reserves four bytes of internal storage space · No length is needed CURRENCY · Holds monetary values of up to 23 digits represented in the currency format, established using SET CURRENCY · Dollar amounts are in the range ±$99,999,999,999,999.99 · Commas or the current delimiter can be used. If no decimal point is included, .00 is assumed · Data is stored as two long integer values, reserving four bytes of internal storage NUMERIC · Holds decimal numbers whose precision and scale can be set within the "Length" column · When specifying NUMERIC, specify a precision (the total number of digits) from 1 to 15 (default 9) and a scale (the number of decimal places) from zero to any positive integer up to the precision value (default 0) · R:BASE reserves a minimum of eight bytes of internal storage · NUMERIC numbers are stored as DOUBLE BIGNUM · Holds decimal numbers whose precision and scale can be set within the "Length" column · When specifying BIGNUM, specify a precision (the total number of digits) from 1 to 38 (default 18) and a scale (the number of decimal places) from zero to any positive integer up to the precision value (default 0) · R:BASE reserves a minimum of forty bytes of internal storage · BIGNUM numbers are stored as DECIMAL · Specific to R:BASE Turbo V-8, R:BASE eXtreme 9.1 (64), and R:BASE eXtreme 9.5 (64). Hope that helps! Very Best R:egards, Razzak.
