CircuitPython - a Python implementation for teaching coding with microcontrollers https://git.suspectdevices.com/suspect-devices/circuitpython/atom?h=v1.9.4 2018-05-11T03:51:18+00:00 2018-05-11T03:51:18+00:00 Damien George damien.p.george@gmail.com 2018-05-11T03:51:18+00:00 urn:sha1:d2c1db1e5cca03c9a34614af6d12045aefe3d719 Printing of uPy floats can differ by the floating-point precision on different architectures (eg 64-bit vs 32-bit x86), so it's not possible to using printing of floats in some parts of this test. Instead we can just check for equivalence with what is known to be the correct answer. 2018-03-01T06:00:02+00:00 Damien George damien.p.george@gmail.com 2018-03-01T06:00:02+00:00 urn:sha1:955ee6477f4b1d3a70bfe97a1e7727848bf2d06d Prior to this patch, some architectures (eg unix x86) could render floats with "negative" digits, like ")". For example, '%.23e' % 1e-80 would come out as "1.0000000000000000/)/(,*0e-80". This patch fixes the known cases. 2018-03-01T05:02:59+00:00 Damien George damien.p.george@gmail.com 2018-03-01T05:02:59+00:00 urn:sha1:7b050fa76c6a763043739d40c82dde839d7f8fd9 Prior to this patch, some architectures (eg unix x86) could render floats with a ":" character in them, eg 1e+39 would come out as ":e+38" (":" is just after "9" in ASCII so this is like 10e+38). This patch fixes some of these cases. 2018-03-01T04:51:03+00:00 Damien George damien.p.george@gmail.com 2018-03-01T04:47:17+00:00 urn:sha1:bc12eca461a317df842ce2e616afa97670cd0ce3 Prior to this patch the %f formatting of some FP values could be off by up to 1, eg '%.0f' % 123 would return "122" (unix x64). Depending on the FP precision (single vs double) certain numbers would format correctly, but others wolud not. This patch should fix all cases of rounding for %f. 2018-02-26T04:54:03+00:00 Damien George damien.p.george@gmail.com 2018-02-26T04:54:03+00:00 urn:sha1:6dad0885692f8d1e743873fb4be241f1fd1cb91a Float parsing (both single and double precision) may have a relative error of order the floating point precision, so adjust tests to take this into account by not printing all of the digits of the answer. 2018-02-08T03:35:43+00:00 Damien George damien.p.george@gmail.com 2018-02-08T03:35:43+00:00 urn:sha1:bbb08431f3c45d94c1e6aa0762b8f13ccce1fe8e It was raising an exception but it should return infinity. 2018-02-08T03:02:50+00:00 Damien George damien.p.george@gmail.com 2018-02-08T03:02:50+00:00 urn:sha1:b75cb8392bdf5f8c12072eac3adbdaad53d1e8d2 Prior to this patch, a float literal that was close to subnormal would have a loss of precision when parsed. The worst case was something like float('10000000000000000000e-326') which returned 0.0. 2017-12-19T03:50:33+00:00 Damien George damien.p.george@gmail.com 2017-12-19T03:50:33+00:00 urn:sha1:7cae17fac774bec7529581f074cfa95716b984b1 2017-11-27T01:51:52+00:00 Damien George damien.p.george@gmail.com 2017-11-27T01:51:52+00:00 urn:sha1:84895f1a210d0037a86887f0f647570bdf40afa2 This patch improves parsing of floating point numbers by converting all the digits (integer and fractional) together into a number 1 or greater, and then applying the correct power of 10 at the very end. In particular the multiple "multiply by 0.1" operations to build a fraction are now combined together and applied at the same time as the exponent, at the very end. This helps to retain precision during parsing of floats, and also includes a check that the number doesn't overflow during the parsing. One benefit is that a float will have the same value no matter where the decimal point is located, eg 1.23 == 123e-2. 2017-11-21T04:01:38+00:00 Damien George damien.p.george@gmail.com 2017-11-21T04:01:38+00:00 urn:sha1:a07fc5b6403b9a8bf7e7cb64f857272e5346d7e2 This generalises and simplifies the code and follows CPython behaviour.