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 :). 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
