seems the conversion goes through floating point (was the simplest thing I could think of that would produce that behavior):
>>> n = 8591464408876390743 >>> x = long(float(n)) >>> x 8591464408876390400L >>> System.Int64(n) == x True HTH Ronnie On Mon, May 19, 2008 at 6:23 PM, Dino Viehland <[EMAIL PROTECTED]> wrote: > I don't think I've seen this reported anywhere. The good news is it does > do the right thing in 2.0 but I've opened a 1.1.2 bug for the issue ( > http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=16658). > That means we'll consider fixing it for 1.1.2 but I have no clue how simple > the fix will be – mainly because I have no clue how it got fixed in 2.0 J. > Thanks for the report. > > > > *From:* [EMAIL PROTECTED] [mailto: > [EMAIL PROTECTED] *On Behalf Of *Ronnie Maor > *Sent:* Monday, May 19, 2008 1:47 AM > *To:* Discussion of IronPython > *Subject:* [IronPython] precision problem with Int64 > > > > Hi all, > > Is the following a known bug? (IPy 1.1.1) > > >>> import System > >>> n = 8591464408876390743 > >>> x = System.Int64(n) > >>> x > 8591464408876390400L > >>> y = System.Int64(str(n)) > >>> y > 8591464408876390743L > >>> x == y > False > > n is positive and contained in 63 bits, so there shouldn't even be > signed/unsigned issues. > > ? > > > _______________________________________________ > Users mailing list > [email protected] > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > >
_______________________________________________ Users mailing list [email protected] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
