Peter Dalgaard wrote: > Stefan Evert wrote: > >> >> ... am I the only one who thinks that the integer 7 is something >> entirely different from the real number 7.0? (The latter most likely >> being an equivalence class of sequences of rational numbers, but that >> depends on your axiomatisation of real numbers.) Integers can be >> embedded in the set of real numbers, but that doesn't make them the >> same mathematically. >> >> > Several people have tried to make that point (or something very > similar), but it doesn't seem to take. > > It might get clearer if taken one step up: is.double(-1+0i) is not true > either, even though the real line is cleanly embedded in complex space, > -1+0i is not the same as -1. For instance, you can take the square root > of the former but not the latter. >
you see, there seems to be a confusion of *numbers* and their *representations*. but of course the integer 7 is *the same* number as the real number 1.0, even if we refer to it using two different representations. the literal '7' might, in some system, cause the compiler/interpreter to use an integer representation of the number 7, and to use a floating point representation of the number 7 in some other system. these two representations differ, as do those for -1 and -1+0i; but just as the real number 7.0 happens to be an integer, so does the complex number -1+0i happen to be a real number. and, of course, you can take a square root of -1, that's what you do when you square-root -1+0i, only that the result is not a member of the set of real numbers. the fact that you may not be able to apply, in a computer language, sqrt to -1, is a consequence of a particular implementation; there's no problem, in principle, in having a system where sqrt(-1) is allowable even if the literal '-1' corresponds to an integer or floating point representation rather than one for complex numbers. just try it with systems such as octave, matlab, mathematica, sage, etc. in the last one, for example sqrt(int(-1)) is perfectly legal, and returns what's expected. *you* can't you take square root of the *integer* 2, can you? "is.double(-1+0i) is not true either, even though the real line is cleanly embedded in complex space," apparently, but it's an *implementation* choice, not a property of the (both real and complex) number -1+0i. the r function is.double returns false for -1+0i, but it's not because the number -1+0i is not real, but because the literal '-1+0i' makes r represent the number using a specific representation scheme. if you try to prove that r must work the way it does by showing how it works, it's painfully circular, and void. the problem was, and is, that is.integer refers to the *representation*, not the *value* (which should, arguably, be clear from the man page), and this seems to be counterintuitive to some of the users. > With integers it is less clear that there is a difference in R, but it > has been mentioned that you can get overflows from adding and multipying > integers which you dont get with reals. In other programming languages, > division of integers is integer division and many a fledgling C > programmer has found the hard way that (2/3)*x is different from 2*x/3. > and this, again, is an *implementation* matter, not a property of numbers. again, in languages that allow the user to think mathematics rather than registers and processors, (2/3)*x == 2*x/3 would rather evaluate to true, even though these are *computer* languages used to specify *computations*. all this trolling, again, to argue that it's far from obvious that is.integer(7) evaluates to FALSE, even if this might be a reasonable choice from some point of view. > >> So the original complaint should really have said that is.integer() >> doesn't do what a naive user (i.e. someone without a background in >> computer science or maths) might expect it to do. :-) >> well, 'naive' should mean 'not familiar with r' rather than 'not understanding the nature of computation'. you can have good background in maths and cs, and still expect that a language like r behaves differently. there's really no point in offending people that get confused by r's details. vQ ______________________________________________ R-help@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
