Is there a reason it's a factor and not a string? A string would seem to be more appropriate to me (given that we know it's a number that can't be represented exactly by R)
Hadley On Saturday, April 26, 2014, Martin Maechler <maech...@stat.math.ethz.ch> wrote: > >>>>> Simon Urbanek <simon.urba...@r-project.org <javascript:;>> > >>>>> on Sat, 19 Apr 2014 13:06:15 -0400 writes: > > > On Apr 19, 2014, at 9:00 AM, Martin Maechler < > maech...@stat.math.ethz.ch <javascript:;>> wrote: > >>>>>>> McGehee, Robert <robert.mcge...@geodecapital.com<javascript:;> > > > >>>>>>> on Thu, 17 Apr 2014 19:15:47 -0400 writes: > >> > >>>> This is all application specific and > >>>> sort of beyond the scope of type.convert(), which now behaves as > it > >>>> has been documented to behave. > >> > >>> That's only a true statement because the documentation was changed > to reflect the new behavior! The new feature in type.convert certainly does > not behave according to the documentation as of R 3.0.3. Here's a snippit: > >> > >>> The first type that can accept all the > >>> non-missing values is chosen (numeric and complex return values > >>> will represented approximately, of course). > >> > >>> The key phrase is in parentheses, which reminds the user to expect > a possible loss of precision. That important parenthetical was removed from > the documentation in R 3.1.0 (among other changes). > >> > >>> Putting aside the fact that this introduces a large amount of > unnecessary work rewriting SQL / data import code, SQL packages, my biggest > conceptual problem is that I can no longer rely on a particular function > call returning a particular class. In my example querying stock prices, > about 5% of prices came back as factors and the remaining 95% as numeric, > so we had random errors popping in throughout the morning. > >> > >>> Here's a short example showing us how the new behavior can be > unreliable. I pass a character representation of a uniformly distributed > random variable to type.convert. 90% of the time it is converted to > "numeric" and 10% it is a "factor" (in R 3.1.0). In the 10% of cases in > which type.convert converts to a factor the leading non-zero digit is > always a 9. So if you were expecting a numeric value, then 1 in 10 times > you may have a bug in your code that didn't exist before. > >> > >>>> options(digits=16) > >>>> cl <- NULL; for (i in 1:10000) cl[i] <- > class(type.convert(format(runif(1)))) > >>>> table(cl) > >>> cl > >>> factor numeric > >>> 990 9010 > >> > >> Yes. > >> > >> Murray's point is valid, too. > >> > >> But in my view, with the reasoning we have seen here, > >> *and* with the well known software design principle of > >> "least surprise" in mind, > >> I also do think that the default for type.convert() should be what > >> it has been for > 10 years now. > >> > > > I think there should be two separate discussions: > > > a) have an option (argument to type.convert and possibly read.table) > to enable/disable this behavior. I'm strongly in favor of this. > > In my (not committed) version of R-devel, I now have > > > str(type.convert(format(1/3, digits=17), exact=TRUE)) > Factor w/ 1 level "0.33333333333333331": 1 > > str(type.convert(format(1/3, digits=17), exact=FALSE)) > num 0.333 > > where the 'exact' argument name has been ``imported'' from the > underlying C code. > > [ As we CRAN package writers know by now, arguments nowadays can > hardly be abbreviated anymore, and so I am not open to longer > alternative argument names, as someone liking blind typing, I'm > not fond of camel case or other keyboard gymnastics (;-) but if someone > has a great idea for > a better argument name.... ] > > Instead of only TRUE/FALSE, we could consider NA with > semantics "FALSE + warning" or also "TRUE + warning". > > > > b) decide what the default for a) will be. I have no strong opinion, > I can see arguments in both directions > > I think many have seen the good arguments in both directions. > I'm still strongly advocating that we value long term stability > higher here, and revert to more compatibility with the many > years of previous versions. > > If we'd use a default of 'exact=NA', I'd like it to mean > FALSE + warning, but would not oppose much to TRUE + warning. > > I agree that for the TRUE case, it may make more sense to return > string-like object of a new (simple) class such as "bignum" > that was mentioned in this thread. > > OTOH, this functionality should make it into an R 3.1.1 in the > not so distant future, and thinking through consequences and > implementing the new class approach may just take a tad too much > time... > > Martin > > > But most importantly I think a) is better than the status quo - even > if the discussion about b) drags out. > > > Cheers, > > Simon > > ______________________________________________ > R-devel@r-project.org <javascript:;> mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- http://had.co.nz/ [[alternative HTML version deleted]] ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
