Hi Duncan,
I'm with Tom, don't want to be redundant but here's some extra info.
This made me think that the problem is not a 'theshold'. Any thoughts.
Also, if the "bad" number strings are entered at the R command prompt, they
are parsed correctly as the expected number. (not factors)
thanks,
-kev
Hi Duncan,
This program and output should answer your question regarding java behavior.
Basically the character toHexString() representation is shown to be lossless
for this
example (in Java).
Please let me know if there is any way I can help further. Id love for this
to work!
I would be h
On 26/04/2014, 6:40 PM, Tom Kraljevic wrote:
Hi Duncan,
This program and output should answer your question regarding java behavior.
Basically the character toHexString() representation is shown to be
lossless for this
example (in Java).
Please let me know if there is any way I can help furt
On Apr 26, 2014, at 4:59 PM, Martin Maechler wrote:
>
>> 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
On 26/04/2014, 4:12 PM, Tom Kraljevic wrote:
Hi,
One additional follow-up here.
Unfortunately, I hit what looks like an R parsing bug that makes the Java
Double.toHexString() output
unreliable for reading by R. (This is really unfortunate, because the format
is intended to be lossless
and
> Simon Urbanek
> on Sat, 19 Apr 2014 13:06:15 -0400 writes:
> On Apr 19, 2014, at 9:00 AM, Martin Maechler
wrote:
>>> McGehee, Robert
>>> on Thu, 17 Apr 2014 19:15:47 -0400 writes:
>>
This is all application specific and
sort of beyond th
> > >> structure(Sys.getenv(), class="simple.list")
> > >_ !
> >
> > Good idea; this is something we could do unconditionally, i.e.,
> > return from Sys.getenv().
> As the OP noted, the print method for simple.list will pad all
> lines to have the same length,
Hi,
One additional follow-up here.
Unfortunately, I hit what looks like an R parsing bug that makes the Java
Double.toHexString() output
unreliable for reading by R. (This is really unfortunate, because the format
is intended to be lossless
and it looks like it’s so close to fully working.)
Hi Duncan,
Please allow me to add a bit more context, which I probably should have added
to my original message.
We actually did see this in an R 3.1 beta which was pulled by an apt-get and
thought it had been released
accidentally. From my user perspective, the parsing of a string like
1.
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
Milan Bouchet-Valat wrote
> It seems that read.table() in R 3.0.1 (Linux 64-bit) does not consider
> quoted integers as an acceptable value for columns for which
> colClasses="integer". But when colClasses is omitted, these columns are
> read as integer anyway.
>
> For example, let's consider a fi
On 26/04/2014, 12:28 PM, Tom Kraljevic wrote:
Hi Duncan,
Please allow me to add a bit more context, which I probably should have
added to my original message.
We actually did see this in an R 3.1 beta which was pulled by an apt-get
and thought it had been released
accidentally. From my user
On 26/04/2014, 3:36 AM, peter dalgaard wrote:
On 25 Apr 2014, at 14:50 , peter dalgaard wrote:
Thanks. I've put in a bug report on this one now, so it shouldn't get missed
again. If nobody else gets to it first I'll deal with it.
I don't see any value in fixing the compareVersion example,
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'
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, i
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().
This, needless to say, is disruptive for us. (Actually, it was downright
shocking.)
+1 for restoring old behavior.
Thanks,
Tom
__
On 25 Apr 2014, at 14:50 , peter dalgaard wrote:
>> Thanks. I've put in a bug report on this one now, so it shouldn't get
>> missed again. If nobody else gets to it first I'll deal with it.
>>
>> I don't see any value in fixing the compareVersion example, but if someone
>> submits a bug rep
17 matches
Mail list logo
