Re: [Rd] type.convert and doubles
On Tue, Apr 29, 2014 at 10:41:19AM +0200, Martin Maechler wrote: > > > > on Tue, 29 Apr 2014 08:25:41 + writes: > > > [...snip...] > > Martin Maecher wrote: > > >> > I have now committed svn rev 65507 --- to R-devel only for now --- > >> > the above: exact = NA is the default > >> > and it means "warning + FALSE". > >> > > >> > Interestingly, I currently get 5 identical warnings for one > >> > simple call, so there seems clearly room for optimization, > > BTW, the above was an implicit RFC and for code proposals by > really good C programmers... > > > >> > and that is one main reason for this reason to not yet be migrated > >> > to 'R 3.1.0 patched'. > > > Peter Dalgaard wrote: > >> I actually think that the default should be the old behaviour. No > warning, just potentially lose digits. If this gets a user in trouble, _then_ > turn on the check for lost digits. > > > +1 > > (yes please, people chime in ... once, you can also give "-1") +1 from me as well. Warning about loss of precision seems ok to me as well, perhaps that could be phased in in the future. Generally, I'd also suggest that conditions for implicit conversion to the factor class should be progressively restricted, rather than extended. This is because I've seen too many budding / not overly type-aware R programmers running into trouble due to some variable ending up containing a factor where they didn't anticipate that. You can only hope they don't "figure out" to "fix this" by using as.numeric in this case... Best regards, Jan > > IMO "read.table" and friends are convenience functions with somewhat of > a "do what I mean" flavour, and as such their default should be to work > conveniently for most cases. We typically ignore loss of precision in all > sorts of numeric operations without warning. Those who do really care about > that 21st digit in 'read.table' could always use 'colClasses'. With a > 'digitloss' argument (but shouldn't it be column-specific? if not, is it > really needed?) > > Note that the current implementation of read.table() and friends > only use type.convert() at all when there are *no* colClasses at > all, and I think we really should not change that principled > behavior ! > > > they can get what they need more easily, but the evidence seems to be that > > this is a rare case. > > > Mark Bravington > > CSIRO > > Hobart > > Australia > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- +- Jan T. Kim ---+ | email: jtt...@gmail.com| | WWW: http://www.jtkim.dreamhosters.com/ | *-=< hierarchical systems are for files, not for humans >=-* __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] SUGGESTION: Force install.packages() to use ASCII encoding when parse():ing code?
On Fri, Dec 12, 2014 at 06:01:22AM -0500, Duncan Murdoch wrote:
> On 12/12/2014, 4:12 AM, Bj??rn-Helge Mevik wrote:
> > Duncan Murdoch writes:
> >
> >> users of other languages may want to have messages and variable names
> >> in their native language, and ASCII might not be enough for that.
> >
> > Allowing for messages in non-ASCII encodings would probably be a good
> > idea, but I think allowing non-ASCII variable names is dangerous.
>
> Dangerous in what way?
>
> I agree that CRAN probably shouldn't accept packages like that, at least
> for exported symbols: packages there should run anywhere. But I
> suspect that the majority of R packages are for private use, and will
> never be sent to CRAN. Do you know any reason that non-ASCII names
> would be dangerous for those?
>
> Duncan Murdoch
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
I'm would perhaps not go as far as calling them dangerous, but non-ASCII
characters in code are a mixed blessing which personally I'd opt to not
have, on balance. Being German I can understand that people may want
umlauted characters in their variable names, but where this catches on,
it's just a matter of time that people get characters into their code that
are different but indistinguishable in the font they use (I've seen this
with \H{o} rather than a \"{o}), and mega-personmonths are wasted puzzling
over tracking down these problems.
While many packages are used in-house at least initially, making a
package is a step towards releasing it, so I'd anticipate that having
an option to support weeding out any potentially troublesome identifiers
has the potential to do some good.
Best regards, Jan
--
+- Jan T. Kim ---+
| email: jtt...@gmail.com|
| WWW: http://www.jtkim.dreamhosters.com/ |
*-=< hierarchical systems are for files, not for humans >=-*
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] SUGGESTION: Force install.packages() to use ASCII encoding when parse():ing code?
On Fri, Dec 12, 2014 at 04:58:52PM +, Barry Rowlingson wrote:
> On Fri, Dec 12, 2014 at 12:34 PM, Jan Kim wrote:
>
> > it's just a matter of time that people get characters into their code that
> > are different but indistinguishable in the font they use (I've seen this
> > with \H{o} rather than a \"{o}), and mega-personmonths are wasted puzzling
> > over tracking down these problems.
>
> Then R should ban variable names from having 'l', 'i', '1', '0' and
> 'O' in them!
well -- I can live with 'i', but if I came across code using variable names
i, \'{\i}, \`{\i} and also \i, \u{\i}, \r{\i}, \d{\i} etc. I'd consider that
dangerous to my sanity (especially if they're all used in the same piece of
code)... ;-)
More seriously, as I (literally) see it, the problems of confusing l / I / 1
or O / 0 etc. are reasonably solvable by using a decent font (e.g. Deja Vu,
Source Code Pro), but ensuring distinctness of glyphs in the same way
won't scale to character sets the size of Unicode.
Best regards, Jan
> Barry
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
+- Jan T. Kim ---+
| email: jtt...@gmail.com|
| WWW: http://www.jtkim.dreamhosters.com/ |
*-=< hierarchical systems are for files, not for humans >=-*
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
