Hi Dirk,
Thanks for taking the time to respond (both here and in other forums). Most of what I wanted to share I put in a followup response to Duncan (please read that thread if you’re interested). I would like to comment on the last point you brought up, though, in case anyone else finds it beneficial. For data which is exchanged programmatically machine-to-machine, I was able to use Java’s Double.toHexString() as a direct replacement for toString(). R is able to read this lossless (but still text) format. So this addresses some of the challenges we have with this change. Thanks, Tom On Apr 26, 2014, at 5:26 AM, Dirk Eddelbuettel <e...@debian.org> wrote: > > On 26 April 2014 at 07:28, Duncan Murdoch wrote: > | On 26/04/2014, 12:23 AM, Tom Kraljevic wrote: > | > > | > Hi, > | > > | > We at 0xdata use Java and R together, and the new behavior for read.csv > has > | > made R unable to read the output of Java’s Double.toString(). > | > | It may be less convenient, but it's certainly not "unable". Use colClasses. > | > | > | > > | > This, needless to say, is disruptive for us. (Actually, it was downright > shocking.) > | > | It wouldn't have been a shock if you had tested pre-release versions. > | Commercial users of R should be contributing to its development, and > | that's a really easy way to do so. > > Seconded. For what it is worth, I made five pre-release available within > Debian. Testing thses each was just an apt-get away. > > In any event, you can also farm out the old behaviour to a (local or even > CRAN) package that provides the old behaviour if your life depends upon it. > > Or you could real serialization rather than relying on the crutch that is csv. > > Dirk > > -- > Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
