

In reply to this post by R devel mailing list
Not that it brings closure, but there's also
https://stat.ethz.ch/pipermail/rdevel/2017June/074462.htmlHenrik
On Sat, Aug 25, 2018, 06:40 Marc Schwartz via Rdevel < [hidden email]>
wrote:
> On Aug 25, 2018, at 9:26 AM, Hadley Wickham < [hidden email]> wrote:
> >
> > Hi all,
> >
> > Would someone mind pointing to me to the inspiration for the use of
> > the L suffix to mean "integer"? This is obviously hard to google for,
> > and the R language definition
> > ( https://cran.rproject.org/doc/manuals/rrelease/Rlang.html#Constants)
> > is silent.
> >
> > Hadley
>
>
> The link you have above, does reference the use of 'L', but not the
> derivation.
>
> There is a thread on RHelp from 2012 ("Difference between 10 and 10L"),
> where Prof. Ripley addresses the issue in response to Bill Dunlap and the
> OP:
>
> https://stat.ethz.ch/pipermail/rhelp/2012May/311771.html>
> In searching, I also found the following thread on SO:
>
>
> https://stackoverflow.com/questions/22191324/clarificationoflinr/22192378>
> which had a link to the RHelp thread above and others.
>
> Regards,
>
> Marc Schwartz
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/rdevel>
[[alternative HTML version deleted]]
______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/rdevel


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!
On Sat, Aug 25, 2018 at 6:50 AM Henrik Bengtsson < [hidden email]>
wrote:
> Not that it brings closure, but there's also
> https://stat.ethz.ch/pipermail/rdevel/2017June/074462.html>
> Henrik
>
> On Sat, Aug 25, 2018, 06:40 Marc Schwartz via Rdevel <
> [hidden email]>
> wrote:
>
> > On Aug 25, 2018, at 9:26 AM, Hadley Wickham < [hidden email]> wrote:
> > >
> > > Hi all,
> > >
> > > Would someone mind pointing to me to the inspiration for the use of
> > > the L suffix to mean "integer"? This is obviously hard to google for,
> > > and the R language definition
> > > (
> https://cran.rproject.org/doc/manuals/rrelease/Rlang.html#Constants)
> > > is silent.
> > >
> > > Hadley
> >
> >
> > The link you have above, does reference the use of 'L', but not the
> > derivation.
> >
> > There is a thread on RHelp from 2012 ("Difference between 10 and 10L"),
> > where Prof. Ripley addresses the issue in response to Bill Dunlap and the
> > OP:
> >
> > https://stat.ethz.ch/pipermail/rhelp/2012May/311771.html> >
> > In searching, I also found the following thread on SO:
> >
> >
> >
> https://stackoverflow.com/questions/22191324/clarificationoflinr/22192378> >
> > which had a link to the RHelp thread above and others.
> >
> > Regards,
> >
> > Marc Schwartz
> >
> > ______________________________________________
> > [hidden email] mailing list
> > https://stat.ethz.ch/mailman/listinfo/rdevel> >
>
> [[alternative HTML version deleted]]
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/rdevel>

http://carlboettiger.info [[alternative HTML version deleted]]
______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/rdevel


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

http://dirk.eddelbuettel.com  @eddelbuettel  [hidden email]
______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/rdevel


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.
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, M1B514
P.O. Box 19024
Seattle, WA 981091024
Email: [hidden email]
Phone: (206) 6675791
Fax: (206) 6671319
______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/rdevel


On 25 August 2018 at 13:49, 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.
The point I was trying to make in what you quote below is that the L may come
from a time when int and long int were in fact the same on most relevant
architectures. And it is hardly R's fault that C was allowed to change.
Also, it hardly matters given that R has precisely one integer type so I am
unsure where you see the confusion between long int and int.
 The fact that nowadays "int" and "long int" have the same size on most
 platforms is only anecdotal here.

 Just my 2 cents.
Are you sure?
R> Rcpp::evalCpp("sizeof(long int)")
[1] 8
R> Rcpp::evalCpp("sizeof(int)")
[1] 4
R>
Dirk
 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, M1B514
 P.O. Box 19024
 Seattle, WA 981091024

 Email: [hidden email]
 Phone: (206) 6675791
 Fax: (206) 6671319

http://dirk.eddelbuettel.com  @eddelbuettel  [hidden email]
______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/rdevel


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
>>
>
______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/rdevel


On 08/25/2018 02:23 PM, Dirk Eddelbuettel wrote:
>
> On 25 August 2018 at 13:49, 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.
>
> The point I was trying to make in what you quote below is that the L may come
> from a time when int and long int were in fact the same on most relevant
> architectures. And it is hardly R's fault that C was allowed to change.
>
> Also, it hardly matters given that R has precisely one integer type so I am
> unsure where you see the confusion between long int and int.
>
>  The fact that nowadays "int" and "long int" have the same size on most
>  platforms is only anecdotal here.
> 
>  Just my 2 cents.
>
> Are you sure?
>
> R> Rcpp::evalCpp("sizeof(long int)")
> [1] 8
> R> Rcpp::evalCpp("sizeof(int)")
> [1] 4
> R>
My bad, it's only the same on Windows. My point is that the discussion
about the size of int vs long int is only a distraction here. The
important bit is that 10L in R is represented by 10 in C, which is an
int, not by 10L, which is a long int. Could hardly be more confusing.
H.
>
> Dirk
>
>  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, M1B514
>  P.O. Box 19024
>  Seattle, WA 981091024
> 
>  Email: [hidden email]
>  Phone: (206) 6675791
>  Fax: (206) 6671319
>

Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1B514
P.O. Box 19024
Seattle, WA 981091024
Email: [hidden email]
Phone: (206) 6675791
Fax: (206) 6671319
______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/rdevel


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, M1B514
P.O. Box 19024
Seattle, WA 981091024
Email: [hidden email]
Phone: (206) 6675791
Fax: (206) 6671319
______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/rdevel


As long as we're on this point about not many users knowing about "L"
notation, I'm going bump my earlier suggestion that it be at least
mentioned in the `? integer` documentation page:
https://stat.ethz.ch/pipermail/rdevel/2018May/076203.htmlCheers,
Thomas
> From: Duncan Murdoch < [hidden email]>
> To: =?UTF8?B?SGVydsOpIFBhZ8Oocw==?= < [hidden email]>, Dirk
> Eddelbuettel < [hidden email]>, Carl Boettiger < [hidden email]>
> Subject: Re: [Rd] Where does L come from?
>
> 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
______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/rdevel


> 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 < [hidden email]>
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
>>>
>>>
>>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/rdevel>
[[alternative HTML version deleted]]
______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/rdevel


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 Rdevel <
[hidden email]> 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 < [hidden email]>
> 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
> >>>
> >>>
> >>
> > ______________________________________________
> > [hidden email] mailing list
> > https://stat.ethz.ch/mailman/listinfo/rdevel> >
>
> [[alternative HTML version deleted]]
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/rdevel>
[[alternative HTML version deleted]]
______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/rdevel


In reply to this post by R devel mailing list
Rich Calaway pointed out that S4 came out c. 199697, not 1991.
Bill Dunlap
TIBCO Software
wdunlap tibco.com
On Sun, Aug 26, 2018 at 8:30 PM, William Dunlap < [hidden email]> 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 < [hidden email]>
> 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
>>>>
>>>>
>>>
>> ______________________________________________
>> [hidden email] mailing list
>> https://stat.ethz.ch/mailman/listinfo/rdevel>>
>
>
[[alternative HTML version deleted]]
______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/rdevel

