Bo,

Just make sure the variable on the form has the currency type also and you will 
be in good shape.

Dennis McGrath
Software Developer
QMI Security Solutions
1661 Glenlake Ave
Itasca IL 60143
630-980-8461
[email protected]
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Bo Franzén
Sent: Thursday, March 08, 2012 4:20 AM
To: RBASE-L Mailing List
Subject: [RBASE-L] - Re: Strange Missing one hundredth in SUM variable

Hello again,

And thanks for all advice and interesting information!

This is not a big problem for my chess club but it's always satisfactory
to understand why; that goes for even the pettiest error. I've had some fun
experimenting with DOUBLE resulting in 46727.71875 for the first variable
(instead of 46727.72), 71314.818 (instead of the earlier 71314.81) for the
last variable, while the negative variable for the column utgift disappears
altogether with the exception of a negative sign [-]. 

When changing columns and form-variables to CURRENCY there follows some
problems as a dollar sign in front of all variable SUMs. I followed an old
piece of advice Gunnar Ekblad once gave me and put in a space instead of $
in R>SET Format SYMBOL and that worked well. Now two of the variables, the
positive ones, appear perfect: 362,048.72 and 71,314.82. The difference
between those two SUM-variables is obviously -290,733.90 as well as it's
the correct SUM of the column utgift. So my last problem is to get this
negative SUM to be shown as a variable in my form.

Bo Franzén
Department of Economic History
Stockholm University



On Wed, 7 Mar 2012 11:33:25 -0600, "Javier Valencia"
<[email protected]> wrote:
> 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.

--- RBASE-L
================================================
TO POST A MESSAGE TO ALL MEMBERS:
Send a plain text email to [email protected]

(Don't use any of these words as your Subject:
INTRO, SUBSCRIBE, UNSUBSCRIBE, SEARCH,
REMOVE, SUSPEND, RESUME, DIGEST, RESEND, HELP)
================================================
TO SEE MESSAGE POSTING GUIDELINES:
Send a plain text email to [email protected]
In the message SUBJECT, put just one word: INTRO
================================================
TO UNSUBSCRIBE: 
Send a plain text email to [email protected]
In the message SUBJECT, put just one word: UNSUBSCRIBE
================================================
TO SEARCH ARCHIVES:
Send a plain text email to [email protected]
In the message SUBJECT, put just one word: SEARCH-n
(where n is the number of days). In the message body, 
place any 
text to search for.
================================================


Reply via email to