Why no .Machine$sizeof.double?

Whis is there a .Machine$sizeof.longdouble but no .Machine$sizeof.double?

sizeof(double) is always 8 and sizeof(int) is always 4, because R requires 
the IEEE/IEC standard arithmetic types.  R will not compile with any other 
sizes.

 	-thomas

"Thomas Lumley" <tlumley at u.washington.edu> wrote in message
news:Pine.LNX.4.63a.0510181039440.30016 at homer24.u.washington.edu...

On Tue, 18 Oct 2005, Earl F. Glynn wrote:

Whis is there a .Machine$sizeof.longdouble but no

.Machine$sizeof.double?

sizeof(double) is always 8 and sizeof(int) is always 4, because R requires
the IEEE/IEC standard arithmetic types.  R will not compile with any other
sizes.

But it's a common, recommended software engineering practice to define
mnemonic, named constants.

If I were to see code like .Machine$sizeof.double * N.COL * N.ROW, I know
that's the number of bytes in a matrix of doubles. If I see code that is 8 *
N.COL * N.ROW, I can guess what "8" means, but I could guess wrong.  I wrote
code that looks just like this today because I couldn't find the defined
constant.  Will someone else reading my code automatically know what the "8"
means?

The use of  literal constants should be discouraged.  I encourage more to
study Section 12.7 "Named Constants" in the book "Code Complete 2" (see
http://www.cc2e.com/).  At some point the R community should become more
receptive to named constant to make R code more readable and easier to
maintain.  But for now, I guess I still have a minority opinion on this
matter in the R community.

efg

"Thomas Lumley" <tlumley at u.washington.edu> wrote in message
news:Pine.LNX.4.63a.0510181039440.30016 at homer24.u.washington.edu...

On Tue, 18 Oct 2005, Earl F. Glynn wrote:

Whis is there a .Machine$sizeof.longdouble but no

.Machine$sizeof.double?

sizeof(double) is always 8 and sizeof(int) is always 4, because R requires
the IEEE/IEC standard arithmetic types.  R will not compile with any other
sizes.

But it's a common, recommended software engineering practice to define
mnemonic, named constants.

If I were to see code like .Machine$sizeof.double * N.COL * N.ROW, I know
that's the number of bytes in a matrix of doubles. If I see code that is 8 *
N.COL * N.ROW, I can guess what "8" means, but I could guess wrong.  I wrote
code that looks just like this today because I couldn't find the defined
constant.  Will someone else reading my code automatically know what the "8"
means?

But why would you ever want to write either .Machine$sizeof.double * N.COL 
* N.ROW or 8 * N.COL * N.ROW?

If you are doing memory allocation in R then numeric() automatically 
allocates things of the correct size. If you are doing memory allocation 
in C then you should use sizeof(double) or, even better, sizeof(*yourpointer).
In both cases, the language has the facility to let you work in the 
correct units without explicit constants, named or unnamed.

You would have a stronger case for arguing that there should be typedefs
in C so that you didn't need to remember that R's numeric type is double 
(rather than, er, float?)and its integer type is int (rather than long)
  and in fact we do provide
  typedef int Sint;
in R.h.

 	-thomas

"Thomas Lumley" <tlumley at u.washington.edu> wrote in message
news:Pine.LNX.4.63a.0510181332090.30016 at homer24.u.washington.edu...

But why would you ever want to write either .Machine$sizeof.double * N.COL
* N.ROW or 8 * N.COL * N.ROW?

To troubleshoot a problem a post doc is having with a large matrix.  I was
trying to understand the size of the numbers in the matrix and the extra
overhead reported as part of object.size().

Often code fragments from "toy" examples and tests later find their way into
other problems over time, so I find it useful to write code that can be
easily understood if I look at it months or years later.

The disciplined use of named constants actually saves time in the long run.
I've spent years of my life reverse engineering code in several languages
(once on a medical device seized by a federal marshal  we were legally
ordered to reverse engineer the software under FDA scrutiny with none of the
original developers available).  I've seen enough "bad" code I like to
encourage good software engineering practices.

Can you find useful information from Google about "8"?

You would have a stronger case for arguing that there should be typedefs
in C so that you didn't need to remember that R's numeric type is double
(rather than, er, float?)and its integer type is int (rather than long)

I was taught in software engineering and programming classes over 25 years
ago that it was a good idea to NEVER use literal constants. I don't think
that practice has changed in the software engineering world.

Many times I've had to lookup the meaning of R literal constants, especially
with R graphics parameters.  Just what does "1" or "2" mean, especially when
it's context sensitive?  Good mnemonics and named constants convey more
meaning, make code easier to read (and learn) and make it more maintainable.

Statisticians might be dismayed when someone applies a wrong statistical
test.  Likewise, computer folks should be concerned when good programming
practices are not followed.

efg