Data Rounding

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Data Rounding

Tom McGoldrick
We occasionally need to have our data rounded in the .sav file to the nearest 10th.
 
We can use the format command, e.g. FORMAT Wkday (f1.0). to create an integer.  However, if we format the data to the nearest 10th the displayed data changes but the actual number stored and used for calculations includes all the decimal places.
 
We have workaround that involved multiplying everything by ten, creating an integer and then dividing everything by ten.
 
Clearly there must be an easier way.  I would appreciate any thoughts you have.
 
Tom

 

Tom McGoldrick
Director, Consulting Services
Questar - Know-How to Know More
2905 West Service Road
Eagan, MN  55121
[hidden email]
(651) 688 - 1979
www.questarweb.com





-----------------


This message (including any attachments) contains confidential
information intended for a specific individual and purpose,
and is protected by law.  If you are not the intended recipient,
you should delete this message and are hereby notified that any
disclosure,copying, or distribution of this message, or the taking
of any action based on it, is strictly prohibited.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Data Rounding

Raynald Levesque
Hi

I do not think there is an other way than multiplying by 10, round then
divide by 10.

But this is done in one line:

DATA LIST FREE /var1.
BEGIN DATA
1.21 1.25 1.333 2.79
END DATA.

COMPUTE OneDecimal=RND(var1*10)/10.
LIST var1 OneDecimal .

Regards

Raynald Levesque [hidden email]
Visit my SPSS site: http://www.spsstools.net


-----Original Message-----
From: SPSSX(r) Discussion [mailto:[hidden email]] On Behalf Of Tom
McGoldrick
Sent: June 21, 2006 5:40 PM
To: [hidden email]
Subject: Data Rounding

We occasionally need to have our data rounded in the .sav file to the
nearest 10th.

We can use the format command, e.g. FORMAT Wkday (f1.0). to create an
integer.  However, if we format the data to the nearest 10th the displayed
data changes but the actual number stored and used for calculations includes
all the decimal places.

We have workaround that involved multiplying everything by ten, creating an
integer and then dividing everything by ten.

Clearly there must be an easier way.  I would appreciate any thoughts you
have.

Tom



Tom McGoldrick
Director, Consulting Services
Questar - Know-How to Know More
2905 West Service Road
Eagan, MN  55121
[hidden email]
(651) 688 - 1979
www.questarweb.com





-----------------


This message (including any attachments) contains confidential information
intended for a specific individual and purpose, and is protected by law.  If
you are not the intended recipient, you should delete this message and are
hereby notified that any disclosure,copying, or distribution of this
message, or the taking of any action based on it, is strictly prohibited.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Data Rounding

Hector Maletta
In reply to this post by Tom McGoldrick
You can use the TRUNC or RND functions in COMPUTE, as in :
COMPUTE ROUNDVAR =RND(OLDVAR).
COMPUTE TRUNCVAR = TRUNC(OLDVAR).
Remember that SPSS always stores variable values with maximum allowable
precision (about 15 decimals), and that FORMAT only governs the visible
appearance of values in the data editor and in output. If you round or
truncate a variable, the internal value changes for good (all the decimals
are gone). You can also truncate or round to a certain number of decimals,
as in:
COMPUTE ROUND2VAR=RND (OLDVAR*100)/100.

Hector



-----Mensaje original-----
De: SPSSX(r) Discussion [mailto:[hidden email]] En nombre de Tom
McGoldrick
Enviado el: Wednesday, June 21, 2006 6:40 PM
Para: [hidden email]
Asunto: Data Rounding

We occasionally need to have our data rounded in the .sav file to the
nearest 10th.

We can use the format command, e.g. FORMAT Wkday (f1.0). to create an
integer.  However, if we format the data to the nearest 10th the displayed
data changes but the actual number stored and used for calculations includes
all the decimal places.

We have workaround that involved multiplying everything by ten, creating an
integer and then dividing everything by ten.

Clearly there must be an easier way.  I would appreciate any thoughts you
have.

Tom



Tom McGoldrick
Director, Consulting Services
Questar - Know-How to Know More
2905 West Service Road
Eagan, MN  55121
[hidden email]
(651) 688 - 1979
www.questarweb.com





-----------------


This message (including any attachments) contains confidential
information intended for a specific individual and purpose,
and is protected by law.  If you are not the intended recipient,
you should delete this message and are hereby notified that any
disclosure,copying, or distribution of this message, or the taking
of any action based on it, is strictly prohibited.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Data Rounding

Frank Milthorpe
In reply to this post by Tom McGoldrick
Ah!

One of my gripes about several packages including Excel. In Emme/2 my
favourite transport modelling package, there is the concept of negative
decimal places when formatting a number. We all understand what 0, 1, 2
and etc decimal places mean. The negative number of decimal places
indicates rounding in the opposite direction. For example -1 decimal
places results in numbers displayed with their value shown to the
nearest 10, for -2 decimal places the number is displayed with the value
rounded to the nearest 100. Note I am referring to the display of the
number, the underlying value is unaltered. I think the concept is
straightforward. I just wish more packages would implement it without
the need to duplicate / modify your data.

Cheers

Frank

>>>

Hector Maletta <[hidden email]>

You can use the TRUNC or RND functions in COMPUTE, as in :
COMPUTE ROUNDVAR =RND(OLDVAR).
COMPUTE TRUNCVAR = TRUNC(OLDVAR).
Remember that SPSS always stores variable values with maximum
allowable
precision (about 15 decimals), and that FORMAT only governs the
visible
appearance of values in the data editor and in output. If you round or
truncate a variable, the internal value changes for good (all the
decimals
are gone). You can also truncate or round to a certain number of
decimals,
as in:
COMPUTE ROUND2VAR=RND (OLDVAR*100)/100.

Hector



-----Mensaje original-----
De: SPSSX(r) Discussion [mailto:[hidden email]] En nombre de
Tom
McGoldrick
Enviado el: Wednesday, June 21, 2006 6:40 PM
Para: [hidden email]
Asunto: Data Rounding

We occasionally need to have our data rounded in the .sav file to the
nearest 10th.

We can use the format command, e.g. FORMAT Wkday (f1.0). to create an
integer.  However, if we format the data to the nearest 10th the
displayed
data changes but the actual number stored and used for calculations
includes
all the decimal places.

We have workaround that involved multiplying everything by ten,
creating an
integer and then dividing everything by ten.

Clearly there must be an easier way.  I would appreciate any thoughts
you
have.

Tom



Tom McGoldrick
Director, Consulting Services
Questar - Know-How to Know More
2905 West Service Road
Eagan, MN  55121
[hidden email]
(651) 688 - 1979
www.questarweb.com





--------------------------------------------------------------------------------
Frank Milthorpe
Senior Manager, Model Development
Transport and Population Data Centre
Department of Planning
Direct:   (02) 9206 8609
Phone:  (02) 9206 8611
Fax:      (02) 9206 8691
Street:    Level 7, Tower 2, 1 Lawson Square, Redfern NSW 2016
Mail:       GPO Box 39, Sydney NSW 2001
Email:     [hidden email]
Web:      www.tpdc.nsw.gov.au


-----------------------------------------------------
This message is intended for the addressee named and may contain confidential/privileged information. If you are not the intended recipient, please delete it and notify the sender.
Views expressed in this message are those of the individual sender, and are not necessarily the views of the Department.

You should scan any attached files for viruses.
-----------------------------------------------------
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Data Rounding

David Millar
In reply to this post by Tom McGoldrick
Tom

I had a problem previously when I wanted to compare two rounded/truncated*
variables.  Although the value for each variable might appear to be the same
(e.g. "1.45" or whatever) they were stored internally as slightly different
numbers.  When I used the formats command to see what was stored I'd start
to see differences at about the 16th place of decimals.  This could present
you with a problem if, for example, you want to select cases on the basis of
the truncated values that appear in SPSS.

Best wishes

David Millar
ERC
Dublin

*The problem occurred regardless of use of the rnd() or trunc() commands.


----- Original Message -----
From: "Tom McGoldrick" <[hidden email]>
Newsgroups: bit.listserv.spssx-l
To: <[hidden email]>
Sent: Wednesday, June 21, 2006 10:40 PM
Subject: Data Rounding


We occasionally need to have our data rounded in the .sav file to the
nearest 10th.

We can use the format command, e.g. FORMAT Wkday (f1.0). to create an
integer.  However, if we format the data to the nearest 10th the displayed
data changes but the actual number stored and used for calculations includes
all the decimal places.

We have workaround that involved multiplying everything by ten, creating an
integer and then dividing everything by ten.

Clearly there must be an easier way.  I would appreciate any thoughts you
have.

Tom



Tom McGoldrick
Director, Consulting Services
Questar - Know-How to Know More
2905 West Service Road
Eagan, MN  55121
[hidden email]
(651) 688 - 1979
www.questarweb.com





-----------------


This message (including any attachments) contains confidential
information intended for a specific individual and purpose,
and is protected by law.  If you are not the intended recipient,
you should delete this message and are hereby notified that any
disclosure,copying, or distribution of this message, or the taking
of any action based on it, is strictly prohibited.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Data Rounding

Kevin Gray-2
In reply to this post by Tom McGoldrick
Hi Tom

You may consider this method to be a little inelegant but I often
convert the numeric value to a string thereby capturing the displayed
value and then I convert the string back into a new numeric variable. It
has the advantage of retaining the original value should one need to
refer back to it.

String V2 (a11).
COMPUTE V2 = LTRIM(string(V1,F11.1)).
Numeric V3 (F11.1).
COMPUTE V3 = (number(V2,F11.1)).
EXECUTE.

DELETE VARIABLES V2.
EXECUTE .

(Where V1 is the original numeric value to x decimal places)

Kevin Gray
Sx3 Implementer
Network Housing Group
Olympic Office Centre
8 Fulton Road
Wembley
HA9 0NU
020 8782 4388
[hidden email]

-----Original Message-----
From: SPSSX(r) Discussion [mailto:[hidden email]] On Behalf Of
Tom McGoldrick
Sent: Wednesday 21 June 2006 22:40
To: [hidden email]
Subject: Data Rounding

We occasionally need to have our data rounded in the .sav file to the
nearest 10th.

We can use the format command, e.g. FORMAT Wkday (f1.0). to create an
integer.  However, if we format the data to the nearest 10th the
displayed data changes but the actual number stored and used for
calculations includes all the decimal places.

We have workaround that involved multiplying everything by ten, creating
an integer and then dividing everything by ten.

Clearly there must be an easier way.  I would appreciate any thoughts
you have.

Tom



Tom McGoldrick
Director, Consulting Services
Questar - Know-How to Know More
2905 West Service Road
Eagan, MN  55121
[hidden email]
(651) 688 - 1979
www.questarweb.com





-----------------


This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and is
protected by law.  If you are not the intended recipient, you should
delete this message and are hereby notified that any disclosure,copying,
or distribution of this message, or the taking of any action based on
it, is strictly prohibited.

________________________________________________________________________
This e-mail has been scanned for all viruses by Star. The service is
powered by MessageLabs. For more information on a proactive anti-virus
service working around the clock, around the globe, visit:
http://www.star.net.uk
________________________________________________________________________

_______________________________________________________________________

This message (including any attachments) is for the use of the intended recipient(s) only.  The message may contain information that is confidential, and if you have received this message in error we should be grateful if you would notify the sender immediately and then delete the complete email.  If you are not the intended recipient you should not use, disclose, copy or distribute this email.

Any opinion or advice contained anywhere in this message is that of the sender and is not intended to bind the Association or Network Housing Group Ltd in any way.  Neither can the sender accept any responsibility for any changes made to this email after it was sent.

This email has been scanned for viruses by Star Internet.  Nevertheless, the sender cannot accept any responsibility for any loss or damage caused by any software viruses transmitted with this email and we advise that you carry out your own virus checks on any attachments included in this message.

Information about delivering social housing through the Association and Network Housing Group is at
www. networkhg.org.uk
_______________________________________________________________________
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Data Rounding

Peck, Jon
In reply to this post by Tom McGoldrick
In effect, what you are asking for is close, thought not identical to, scientific notation, where you can specify the number of significant figures to be displayed and which is supported in SPSS.

Regards,
Jon Peck
SPSS

-----Original Message-----
From: SPSSX(r) Discussion [mailto:[hidden email]] On Behalf Of Frank Milthorpe
Sent: Thursday, June 22, 2006 12:47 AM
To: [hidden email]
Subject: Re: [SPSSX-L] Data Rounding

Ah!

One of my gripes about several packages including Excel. In Emme/2 my
favourite transport modelling package, there is the concept of negative
decimal places when formatting a number. We all understand what 0, 1, 2
and etc decimal places mean. The negative number of decimal places
indicates rounding in the opposite direction. For example -1 decimal
places results in numbers displayed with their value shown to the
nearest 10, for -2 decimal places the number is displayed with the value
rounded to the nearest 100. Note I am referring to the display of the
number, the underlying value is unaltered. I think the concept is
straightforward. I just wish more packages would implement it without
the need to duplicate / modify your data.

Cheers

Frank

>>>

Hector Maletta <[hidden email]>

You can use the TRUNC or RND functions in COMPUTE, as in :
COMPUTE ROUNDVAR =RND(OLDVAR).
COMPUTE TRUNCVAR = TRUNC(OLDVAR).
Remember that SPSS always stores variable values with maximum
allowable
precision (about 15 decimals), and that FORMAT only governs the
visible
appearance of values in the data editor and in output. If you round or
truncate a variable, the internal value changes for good (all the
decimals
are gone). You can also truncate or round to a certain number of
decimals,
as in:
COMPUTE ROUND2VAR=RND (OLDVAR*100)/100.

Hector



-----Mensaje original-----
De: SPSSX(r) Discussion [mailto:[hidden email]] En nombre de
Tom
McGoldrick
Enviado el: Wednesday, June 21, 2006 6:40 PM
Para: [hidden email]
Asunto: Data Rounding

We occasionally need to have our data rounded in the .sav file to the
nearest 10th.

We can use the format command, e.g. FORMAT Wkday (f1.0). to create an
integer.  However, if we format the data to the nearest 10th the
displayed
data changes but the actual number stored and used for calculations
includes
all the decimal places.

We have workaround that involved multiplying everything by ten,
creating an
integer and then dividing everything by ten.

Clearly there must be an easier way.  I would appreciate any thoughts
you
have.

Tom



Tom McGoldrick
Director, Consulting Services
Questar - Know-How to Know More
2905 West Service Road
Eagan, MN  55121
[hidden email]
(651) 688 - 1979
www.questarweb.com





--------------------------------------------------------------------------------
Frank Milthorpe
Senior Manager, Model Development
Transport and Population Data Centre
Department of Planning
Direct:   (02) 9206 8609
Phone:  (02) 9206 8611
Fax:      (02) 9206 8691
Street:    Level 7, Tower 2, 1 Lawson Square, Redfern NSW 2016
Mail:       GPO Box 39, Sydney NSW 2001
Email:     [hidden email]
Web:      www.tpdc.nsw.gov.au


-----------------------------------------------------
This message is intended for the addressee named and may contain confidential/privileged information. If you are not the intended recipient, please delete it and notify the sender.
Views expressed in this message are those of the individual sender, and are not necessarily the views of the Department.

You should scan any attached files for viruses.
-----------------------------------------------------
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Data Rounding

Richard Ristow
In reply to this post by David Millar
At 04:27 AM 6/22/2006, David Millar wrote:

>I had a problem previously when I wanted to compare two
>rounded/truncated* variables.  Although the value for each variable
>might appear to be the same (e.g. "1.45" or whatever) they were stored
>internally as slightly different numbers.  When I used the formats
>command to see what was stored I'd start to see differences at about
>the 16th place of decimals.  This could present you with a problem if,
>for example, you want to select cases on the basis of the truncated
>values that appear in SPSS.

Yes; this should be emphasized again and again.

Not all fractions can be represented exactly. (3/2)=1.5 is exact.
(4/3)=1.3333 is not exact, and it can't be made exact by adding any
(finite) number of digits.

Now, *which* fractions can be represented exactly, depends on the
number system. The one SPSS uses(*) isn't the standard decimal
numbering system, and doesn't have the same set of representable
fractions.

You can look at the details of the representation your system is using,
but it's not worth the trouble. Besides, the representation is *NOT*
part of the specifications of the system; it would be reasonable for
SPSS to switch to another high-precision standard, if that offered
practical advantages.

The safe rule is: <<There Is No Such Thing as an Exact Fraction>>. If a
number must have a certain value *exactly*, change the scale so that
value is an integer.

There may well be reasons for "having data rounded in the .sav file to
the nearest 10th," but be cautious: What does it benefit you? Does that
benefit depend on the numbers rounded values being exact?
......................
Demonstration: SPSS draft output

FORMATS INTEGER  (F05)
        /FRACTION (F10.3)
        /SCALE    (E08.1).
DATASET NAME McGoldrick.
NUMERIC DELTA    (E11.3).
COMPUTE DELTA = INTEGER - (FRACTION*SCALE).
FORMATS DELTA    (E11.3).
STRING  FLAG     (A03).
RECODE  DELTA
        (0    = '   ')
        (ELSE = '***') INTO FLAG.
LIST.

List
|-------------------------|------------------------|
|Output Created           |22-JUN-2006 16:09:23    |
|-------------------------|------------------------|
[McGoldrick]

Integer   Fraction    Scale       DELTA FLAG

      1        .010 1.0E+002  0.000E+000
      5        .050 1.0E+002  0.000E+000
      7        .070 1.0E+002 -8.882E-016 ***
      9        .090 1.0E+002  0.000E+000
     13        .130 1.0E+002  0.000E+000
     57        .570 1.0E+002  7.105E-015 ***
     91        .910 1.0E+002  0.000E+000
     13        .130 1.0E+002  0.000E+000
     57        .570 1.0E+002  7.105E-015 ***
     91        .910 1.0E+002  0.000E+000
    135       1.350 1.0E+002  0.000E+000
    579       5.790 1.0E+002  0.000E+000
    913       9.130 1.0E+002 -1.137E-013 ***
      1        .001 1.0E+003  0.000E+000
      5        .005 1.0E+003  0.000E+000
      7        .007 1.0E+003  0.000E+000
      9        .009 1.0E+003  0.000E+000
     13        .013 1.0E+003  0.000E+000
     57        .057 1.0E+003  0.000E+000
     91        .091 1.0E+003  0.000E+000
    135        .135 1.0E+003  0.000E+000
    579        .579 1.0E+003  0.000E+000
    913        .913 1.0E+003  0.000E+000
   1357       1.357 1.0E+003  0.000E+000
   5791       5.791 1.0E+003  0.000E+000
   9135       9.135 1.0E+003  0.000E+000

Number of cases read:  26    Number of cases listed:  26
......................
(*) SPSS for Windows uses 64-bit floating-point numbers following
standard IEEE 754. Likely enough for other platforms, too, but I don't
know for sure. SPSS uses IEEE 754 because it's a pretty good standard,
and most computers have hardware made to work with it. Most other
packages - SAS, I assume Excel, I believe Single and Double datatypes
in Access - also use it, for the same reasons.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Data Rounding

Boer, CPJ de
In reply to this post by Tom McGoldrick
As with comparing two real numbers, it was forbidden to us (back in 1980 while programming in Algol) to do that directly.

We were told to considder two real numbers equal if they 'were close enough together' or when 'their difference was small enough'.

Even now i often have a constant named epsilon with a value often of 0.000001.
I considder two real numbers equal when the absolute value of their difference is smaller than (or equal to) this epsilon.


Just my two cents ($0.020000004)

______________________
Ing. C.P.J. de Boer
EMGO, VUmc
afd. Datamanagement & Systeembeheer
BS-7 D-451
(020) 44 49828
In theorie is er geen verschil tussen theorie en praktijk. De praktijk is echter anders...

> -----Oorspronkelijk bericht-----
> Van: SPSSX(r) Discussion
> [mailto:[hidden email]]Namens Richard
> Ristow
> Verzonden: donderdag 22 juni 2006 19:40
> Aan: [hidden email]
> Onderwerp: Re: Data Rounding
>
>
> At 04:27 AM 6/22/2006, David Millar wrote:
>
> >I had a problem previously when I wanted to compare two
> >rounded/truncated* variables.  Although the value for each variable
> >might appear to be the same (e.g. "1.45" or whatever) they
> were stored
> >internally as slightly different numbers.  When I used the formats
> >command to see what was stored I'd start to see differences at about
> >the 16th place of decimals.  This could present you with a
> problem if,
> >for example, you want to select cases on the basis of the truncated
> >values that appear in SPSS.
>
> Yes; this should be emphasized again and again.
>
> Not all fractions can be represented exactly. (3/2)=1.5 is exact.
> (4/3)=1.3333 is not exact, and it can't be made exact by adding any
> (finite) number of digits.
>
> Now, *which* fractions can be represented exactly, depends on the
> number system. The one SPSS uses(*) isn't the standard decimal
> numbering system, and doesn't have the same set of representable
> fractions.
>
> You can look at the details of the representation your system
> is using,
> but it's not worth the trouble. Besides, the representation is *NOT*
> part of the specifications of the system; it would be reasonable for
> SPSS to switch to another high-precision standard, if that offered
> practical advantages.
>
> The safe rule is: <<There Is No Such Thing as an Exact
> Fraction>>. If a
> number must have a certain value *exactly*, change the scale so that
> value is an integer.
>
> There may well be reasons for "having data rounded in the .sav file to
> the nearest 10th," but be cautious: What does it benefit you?
> Does that
> benefit depend on the numbers rounded values being exact?
> ......................
> Demonstration: SPSS draft output
>
> FORMATS INTEGER  (F05)
>         /FRACTION (F10.3)
>         /SCALE    (E08.1).
> DATASET NAME McGoldrick.
> NUMERIC DELTA    (E11.3).
> COMPUTE DELTA = INTEGER - (FRACTION*SCALE).
> FORMATS DELTA    (E11.3).
> STRING  FLAG     (A03).
> RECODE  DELTA
>         (0    = '   ')
>         (ELSE = '***') INTO FLAG.
> LIST.
>
> List
> |-------------------------|------------------------|
> |Output Created           |22-JUN-2006 16:09:23    |
> |-------------------------|------------------------|
> [McGoldrick]
>
> Integer   Fraction    Scale       DELTA FLAG
>
>       1        .010 1.0E+002  0.000E+000
>       5        .050 1.0E+002  0.000E+000
>       7        .070 1.0E+002 -8.882E-016 ***
>       9        .090 1.0E+002  0.000E+000
>      13        .130 1.0E+002  0.000E+000
>      57        .570 1.0E+002  7.105E-015 ***
>      91        .910 1.0E+002  0.000E+000
>      13        .130 1.0E+002  0.000E+000
>      57        .570 1.0E+002  7.105E-015 ***
>      91        .910 1.0E+002  0.000E+000
>     135       1.350 1.0E+002  0.000E+000
>     579       5.790 1.0E+002  0.000E+000
>     913       9.130 1.0E+002 -1.137E-013 ***
>       1        .001 1.0E+003  0.000E+000
>       5        .005 1.0E+003  0.000E+000
>       7        .007 1.0E+003  0.000E+000
>       9        .009 1.0E+003  0.000E+000
>      13        .013 1.0E+003  0.000E+000
>      57        .057 1.0E+003  0.000E+000
>      91        .091 1.0E+003  0.000E+000
>     135        .135 1.0E+003  0.000E+000
>     579        .579 1.0E+003  0.000E+000
>     913        .913 1.0E+003  0.000E+000
>    1357       1.357 1.0E+003  0.000E+000
>    5791       5.791 1.0E+003  0.000E+000
>    9135       9.135 1.0E+003  0.000E+000
>
> Number of cases read:  26    Number of cases listed:  26
> ......................
> (*) SPSS for Windows uses 64-bit floating-point numbers following
> standard IEEE 754. Likely enough for other platforms, too, but I don't
> know for sure. SPSS uses IEEE 754 because it's a pretty good standard,
> and most computers have hardware made to work with it. Most other
> packages - SAS, I assume Excel, I believe Single and Double datatypes
> in Access - also use it, for the same reasons.
>
Loading...