Message-ID: <A4E5A0B016B8CB41A485FC629B633CED5605AD4322@GOLD.corp.lgc-group.com>
Date: 2013-11-27T17:12:28Z
From: S Ellison
Subject: cut2 not binning interval endpoints correctly
In-Reply-To: <CAAxdm-7B+JBVgwAx2VDL4uMO9AXa+yo34UREfLQSUMj0AnAMmA@mail.gmail.com>
> -----Original Message-----
>jim holtman <jholtman at gmail.com>
> You need to look at the full accuracy of the number representation:
Um... I think I did. But I'm not sure you did....
print(..., digits=20) has used different numbers of digits for your two print()s, probably because print() decided it needed more digits for the multi-valued vector. The internal representations were the same. Try
print(seq(0, 0.310, 0.001)[309], digits = 20)
[1] 0.307999999999999996
print(seq(0, 0.310, 0.001)[309], digits = 22)
[1] 0.3079999999999999960032
> print(0.308, digits = 22)
[1] 0.3079999999999999960032
0.308 does match the cut boundary 'exactly' in this case (which is why the usually unwise '==' returned TRUE), though neither is exactly 0.308.
Nonetheless, I understand that FAQ 7.31 is a good candidate for other 'unexpected' cut2 results. However, that isn't the whole story. It doesn't explain the corresponding cut(, right=FALSE) result, which should give the same answer as cut2 if finite representation were the sole cause. So there's summat else going on.
Steve E
*******************************************************************
This email and any attachments are confidential. Any use...{{dropped:8}}