On 25/08/2018 4:49 PM, Herv? Pag?s wrote:> The choice of the L suffix in R to mean "R integer type", which > is mapped to the "int" type at the C level, and NOT to the "long int" > type, is really unfortunate as it seems to be misleading and confusing > a lot of people.Can you provide any evidence of that (e.g. a link to a message from one of these people)? I think a lot of people don't really know about the L suffix, but that's different from being confused or misleaded by it. And if you make a criticism like that, it would really be fair to suggest what R should have done instead. I can't think of anything better, given that "i" was already taken, and that the lack of a decimal place had historically not been significant. Using "I" *would* have been confusing (3i versus 3I being very different). Deciding that 3 suddenly became an integer value different from 3. would have led to lots of inefficient conversions (since stats mainly deals with floating point values). Duncan Murdoch> > The fact that nowadays "int" and "long int" have the same size on most > platforms is only anecdotal here. > > Just my 2 cents. > > H. > > On 08/25/2018 10:01 AM, Dirk Eddelbuettel wrote: >> >> On 25 August 2018 at 09:28, Carl Boettiger wrote: >> | I always thought it meant "Long" (I'm assuming R's integers are long >> | integers in C sense (iirrc one can declare 'long x', and it being common to >> | refer to integers as "longs" in the same way we use "doubles" to mean >> | double precision floating point). But pure speculation on my part, so I'm >> | curious! >> >> It does per my copy (dated 1990 !!) of the 2nd ed of Kernighan & Ritchie. It >> explicitly mentions (sec 2.2) that 'int' may be 16 or 32 bits, and 'long' is >> 32 bit; and (in sec 2.3) introduces the I, U, and L labels for constants. So >> "back then when" 32 bit was indeed long. And as R uses 32 bit integers ... >> >> (It is all murky because the size is an implementation detail and later >> "essentially everybody" moved to 32 bit integers and 64 bit longs as the 64 >> bit architectures became prevalent. Which is why when it matters one should >> really use more explicit types like int32_t or int64_t.) >> >> Dirk >> >
On 08/25/2018 04:33 PM, Duncan Murdoch wrote:> On 25/08/2018 4:49 PM, Herv? Pag?s wrote: >> The choice of the L suffix in R to mean "R integer type", which >> is mapped to the "int" type at the C level, and NOT to the "long int" >> type, is really unfortunate as it seems to be misleading and confusing >> a lot of people.I don't have stats about this so I take back the "lot".> Can you provide any evidence of that (e.g. a link to a message from one > of these people)?? I think a lot of people don't really know about the L > suffix, but that's different from being confused or misleaded by it. > > And if you make a criticism like that, it would really be fair to > suggest what R should have done instead.? I can't think of anything > better, given that "i" was already taken, and that the lack of a decimal > place had historically not been significant.? Using "I" *would* have > been confusing (3i versus 3I being very different).? Deciding that 3 > suddenly became an integer value different from 3. would have led to > lots of inefficient conversions (since stats mainly deals with floating > point values).Maybe 10N, or 10n? I'm not convinced that 10I would have been confusing but the I can easily be mistaken for a 1. H.> > Duncan Murdoch > > >> >> The fact that nowadays "int" and "long int" have the same size on most >> platforms is only anecdotal here. >> >> Just my 2 cents. >> >> H. >> >> On 08/25/2018 10:01 AM, Dirk Eddelbuettel wrote: >>> >>> On 25 August 2018 at 09:28, Carl Boettiger wrote: >>> | I always thought it meant "Long" (I'm assuming R's integers are long >>> | integers in C sense (iirrc one can declare 'long x', and it being >>> common to >>> | refer to integers as "longs"? in the same way we use "doubles" to mean >>> | double precision floating point).? But pure speculation on my part, >>> so I'm >>> | curious! >>> >>> It does per my copy (dated 1990 !!) of the 2nd ed of Kernighan & >>> Ritchie.? It >>> explicitly mentions (sec 2.2) that 'int' may be 16 or 32 bits, and >>> 'long' is >>> 32 bit; and (in sec 2.3) introduces the I, U, and L labels for >>> constants.? So >>> "back then when" 32 bit was indeed long.? And as R uses 32 bit >>> integers ... >>> >>> (It is all murky because the size is an implementation detail and later >>> "essentially everybody" moved to 32 bit integers and 64 bit longs as >>> the 64 >>> bit architectures became prevalent.? Which is why when it matters one >>> should >>> really use more explicit types like int32_t or int64_t.) >>> >>> Dirk >>> >> >-- Herv? Pag?s Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpages at fredhutch.org Phone: (206) 667-5791 Fax: (206) 667-1319
> the lack of a decimal place had historically not been significantVersion 4 of S (c. 1991) and versions of S+ based on it treated a sequence of digits without a decimal point as integer. Bill Dunlap TIBCO Software wdunlap tibco.com On Sat, Aug 25, 2018 at 4:33 PM, Duncan Murdoch <murdoch.duncan at gmail.com> wrote:> On 25/08/2018 4:49 PM, Herv? Pag?s wrote: > >> The choice of the L suffix in R to mean "R integer type", which >> is mapped to the "int" type at the C level, and NOT to the "long int" >> type, is really unfortunate as it seems to be misleading and confusing >> a lot of people. >> > > Can you provide any evidence of that (e.g. a link to a message from one of > these people)? I think a lot of people don't really know about the L > suffix, but that's different from being confused or misleaded by it. > > And if you make a criticism like that, it would really be fair to suggest > what R should have done instead. I can't think of anything better, given > that "i" was already taken, and that the lack of a decimal place had > historically not been significant. Using "I" *would* have been confusing > (3i versus 3I being very different). Deciding that 3 suddenly became an > integer value different from 3. would have led to lots of inefficient > conversions (since stats mainly deals with floating point values). > > Duncan Murdoch > > > >> The fact that nowadays "int" and "long int" have the same size on most >> platforms is only anecdotal here. >> >> Just my 2 cents. >> >> H. >> >> On 08/25/2018 10:01 AM, Dirk Eddelbuettel wrote: >> >>> >>> On 25 August 2018 at 09:28, Carl Boettiger wrote: >>> | I always thought it meant "Long" (I'm assuming R's integers are long >>> | integers in C sense (iirrc one can declare 'long x', and it being >>> common to >>> | refer to integers as "longs" in the same way we use "doubles" to mean >>> | double precision floating point). But pure speculation on my part, so >>> I'm >>> | curious! >>> >>> It does per my copy (dated 1990 !!) of the 2nd ed of Kernighan & >>> Ritchie. It >>> explicitly mentions (sec 2.2) that 'int' may be 16 or 32 bits, and >>> 'long' is >>> 32 bit; and (in sec 2.3) introduces the I, U, and L labels for >>> constants. So >>> "back then when" 32 bit was indeed long. And as R uses 32 bit integers >>> ... >>> >>> (It is all murky because the size is an implementation detail and later >>> "essentially everybody" moved to 32 bit integers and 64 bit longs as the >>> 64 >>> bit architectures became prevalent. Which is why when it matters one >>> should >>> really use more explicit types like int32_t or int64_t.) >>> >>> Dirk >>> >>> >> > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel >[[alternative HTML version deleted]]
most likely L comes from Michel or Obelisk. http://img.izing.ml/MARSHALL.html = why you are making Mars colonization (and space) "just a game" http://img.izing.ml/IT.html = why i could care less. ? On Sun, Aug 26, 2018 at 11:30 PM, William Dunlap via R-devel < r-devel at r-project.org> wrote:> > the lack of a decimal place had historically not been significant > > Version 4 of S (c. 1991) and versions of S+ based on it treated a sequence > of digits without a decimal point as integer. > > Bill Dunlap > TIBCO Software > wdunlap tibco.com > > On Sat, Aug 25, 2018 at 4:33 PM, Duncan Murdoch <murdoch.duncan at gmail.com> > wrote: > > > On 25/08/2018 4:49 PM, Herv? Pag?s wrote: > > > >> The choice of the L suffix in R to mean "R integer type", which > >> is mapped to the "int" type at the C level, and NOT to the "long int" > >> type, is really unfortunate as it seems to be misleading and confusing > >> a lot of people. > >> > > > > Can you provide any evidence of that (e.g. a link to a message from one > of > > these people)? I think a lot of people don't really know about the L > > suffix, but that's different from being confused or misleaded by it. > > > > And if you make a criticism like that, it would really be fair to suggest > > what R should have done instead. I can't think of anything better, given > > that "i" was already taken, and that the lack of a decimal place had > > historically not been significant. Using "I" *would* have been confusing > > (3i versus 3I being very different). Deciding that 3 suddenly became an > > integer value different from 3. would have led to lots of inefficient > > conversions (since stats mainly deals with floating point values). > > > > Duncan Murdoch > > > > > > > >> The fact that nowadays "int" and "long int" have the same size on most > >> platforms is only anecdotal here. > >> > >> Just my 2 cents. > >> > >> H. > >> > >> On 08/25/2018 10:01 AM, Dirk Eddelbuettel wrote: > >> > >>> > >>> On 25 August 2018 at 09:28, Carl Boettiger wrote: > >>> | I always thought it meant "Long" (I'm assuming R's integers are long > >>> | integers in C sense (iirrc one can declare 'long x', and it being > >>> common to > >>> | refer to integers as "longs" in the same way we use "doubles" to > mean > >>> | double precision floating point). But pure speculation on my part, > so > >>> I'm > >>> | curious! > >>> > >>> It does per my copy (dated 1990 !!) of the 2nd ed of Kernighan & > >>> Ritchie. It > >>> explicitly mentions (sec 2.2) that 'int' may be 16 or 32 bits, and > >>> 'long' is > >>> 32 bit; and (in sec 2.3) introduces the I, U, and L labels for > >>> constants. So > >>> "back then when" 32 bit was indeed long. And as R uses 32 bit integers > >>> ... > >>> > >>> (It is all murky because the size is an implementation detail and later > >>> "essentially everybody" moved to 32 bit integers and 64 bit longs as > the > >>> 64 > >>> bit architectures became prevalent. Which is why when it matters one > >>> should > >>> really use more explicit types like int32_t or int64_t.) > >>> > >>> Dirk > >>> > >>> > >> > > ______________________________________________ > > R-devel at r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > [[alternative HTML version deleted]] > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel >[[alternative HTML version deleted]]
Rich Calaway pointed out that S4 came out c. 1996-97, not 1991. Bill Dunlap TIBCO Software wdunlap tibco.com On Sun, Aug 26, 2018 at 8:30 PM, William Dunlap <wdunlap at tibco.com> wrote:> > the lack of a decimal place had historically not been significant > > Version 4 of S (c. 1991) and versions of S+ based on it treated a sequence > of digits without a decimal point as integer. > > Bill Dunlap > TIBCO Software > wdunlap tibco.com > > On Sat, Aug 25, 2018 at 4:33 PM, Duncan Murdoch <murdoch.duncan at gmail.com> > wrote: > >> On 25/08/2018 4:49 PM, Herv? Pag?s wrote: >> >>> The choice of the L suffix in R to mean "R integer type", which >>> is mapped to the "int" type at the C level, and NOT to the "long int" >>> type, is really unfortunate as it seems to be misleading and confusing >>> a lot of people. >>> >> >> Can you provide any evidence of that (e.g. a link to a message from one >> of these people)? I think a lot of people don't really know about the L >> suffix, but that's different from being confused or misleaded by it. >> >> And if you make a criticism like that, it would really be fair to suggest >> what R should have done instead. I can't think of anything better, given >> that "i" was already taken, and that the lack of a decimal place had >> historically not been significant. Using "I" *would* have been confusing >> (3i versus 3I being very different). Deciding that 3 suddenly became an >> integer value different from 3. would have led to lots of inefficient >> conversions (since stats mainly deals with floating point values). >> >> Duncan Murdoch >> >> >> >>> The fact that nowadays "int" and "long int" have the same size on most >>> platforms is only anecdotal here. >>> >>> Just my 2 cents. >>> >>> H. >>> >>> On 08/25/2018 10:01 AM, Dirk Eddelbuettel wrote: >>> >>>> >>>> On 25 August 2018 at 09:28, Carl Boettiger wrote: >>>> | I always thought it meant "Long" (I'm assuming R's integers are long >>>> | integers in C sense (iirrc one can declare 'long x', and it being >>>> common to >>>> | refer to integers as "longs" in the same way we use "doubles" to mean >>>> | double precision floating point). But pure speculation on my part, >>>> so I'm >>>> | curious! >>>> >>>> It does per my copy (dated 1990 !!) of the 2nd ed of Kernighan & >>>> Ritchie. It >>>> explicitly mentions (sec 2.2) that 'int' may be 16 or 32 bits, and >>>> 'long' is >>>> 32 bit; and (in sec 2.3) introduces the I, U, and L labels for >>>> constants. So >>>> "back then when" 32 bit was indeed long. And as R uses 32 bit integers >>>> ... >>>> >>>> (It is all murky because the size is an implementation detail and later >>>> "essentially everybody" moved to 32 bit integers and 64 bit longs as >>>> the 64 >>>> bit architectures became prevalent. Which is why when it matters one >>>> should >>>> really use more explicit types like int32_t or int64_t.) >>>> >>>> Dirk >>>> >>>> >>> >> ______________________________________________ >> R-devel at r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > >[[alternative HTML version deleted]]