[Rd] Why no .Machine$sizeof.double?
Earl F. Glynn
efg at stowers-institute.org
Tue Oct 18 23:55:10 CEST 2005
"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
More information about the R-devel
mailing list