| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
| |
I.e. they don't run successfully with MICROPY_LONGINT_IMPL_NONE
and MICROPY_LONGINT_IMPL_LONGLONG (the problem is that they generate
different output than CPython, TODO to fix that).
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The use of large literal numbers is a big no-no when it comes to writing
programs which work with different int representations. Also, some checks
are pretty adhoc (e.g using struct module to check for 64-bitness). This
change bases entire detection on sys.maxsize and integer operarions, and
thus more correct, even if longer.
Note that this change doesn't mean that any of these tests can pass with
anything but MPZ - even despite checking for various int representations,
the tests aren't written to be portable among them.
|
| | |
|
| | |
|
| |
|
|
|
| |
- Tests vary based on build configuration (32/64-bit and internal int type).
- Added tests for exceptions raised on overflow of int type.
|
| |
|
|
| |
Addresses issue #1044 (see also #1040). Could do with a better fix.
|
| | |
|
| | |
|
| | |
|
|
|
This fixes conversion when float type has more mantissa bits than small int,
and float value has small exponent. This is for example the case of 32-bit
platform using doubles, and converting value of time.time(). Conversion of
floats with larg exponnet is still not handled correctly.
|
