Why no .Machine$sizeof.double?
"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