MicroPython firmwares with "'MICROPY_PY_REVERSE_SPECIAL_METHODS'" enabled ?

[v923z]

That's a very good point. It calls into question whether there is much merit in MicroPython supporting only this subset.

In micropython, you are usually not faced with this problem: I believe, there is only one case, where two operands are of different kind, namely, when a string is multiplied by an integer scalar, as in

Code: Select all

'micropython' * 3

or

Code: Select all

3 * 'micropython' 

The difficulty with ulab is that all binary operators are valid between a scalar (type internal to micropython), and an ndarray (type external to micropython), and all of them are equally valid in the reversed order.

[pythoncoder]

This problem potentially arises with most user-defined mathematical classes.

In my quaternion class it is valid to perform the four basic arithmetic operations on quaternions against quaternions, scalars, 3-tuples and 4-tuples (with the one exception that you can't write q1/q2). So n/q croaks. As yet I have only implemented comparison operators with a q on each side, but comparing a q with other types is meaningful and, as you point out, I'll hit this problem there.

It seems to me that the supported subset seriously constrains the classes you can write.

[pythoncoder]

To add to this I created builds with and without MICROPY_PY_REVERSE_SPECIAL_METHODS for Pyboard D SF6W and for ESP8266. On each platform I verified that the reverse special methods only work with the appropriate build. I then tried to figure out exactly what resource is being conserved by disabling them.

On the SF6W the dfu files were exactly the same size, 1_063_685 bytes. Of more interest is free ram, so I issued

Code: Select all

import gc
gc.collect()
gc.mem_free()

The outcome was 385_488 bytes free with special methods, 385_632 without. A saving of 144 bytes.

Oddly on ESP8266 the free RAM was 36_488 bytes in both cases.

Incidentally my unit test would not run on ESP8266 because math.isclose doesn't exist on that platform, another undocumented feature

[v923z]

To add to this I created builds with and without MICROPY_PY_REVERSE_SPECIAL_METHODS for Pyboard D SF6W and for ESP8266. On each platform I verified that the reverse special methods only work with the appropriate build. I then tried to figure out exactly what resource is being conserved by disabling them.

On the SF6W the dfu files were exactly the same size, 1_063_685 bytes. Of more interest is free ram, so I issued

Code: Select all

import gc
gc.collect()
gc.mem_free()

The outcome was 385_488 bytes free with special methods, 385_632 without. A saving of 144 bytes.

Oddly on ESP8266 the free RAM was 36_488 bytes in both cases.

Incidentally my unit test would not run on ESP8266 because math.isclose doesn't exist on that platform, another undocumented feature

We should seriously consider finding ways of organising such snippets of information. All these are scattered all over the forum posts, and it is becoming prohibitively hard to locate what one needs.

[pythoncoder]

...
We should seriously consider finding ways of organising such snippets of information. All these are scattered all over the forum posts, and it is becoming prohibitively hard to locate what one needs.

It is indeed. I keep hoping for official documentation and formal build specifications. Perhaps they might come from the summer of docs, e.g. something on the lines of Damien's suggestion.

It would be good to see docs defining the phenomenal number of build options. Library docs should indicate when functionality is port specific. For example it is not obvious that a math library supporting trig functions may or may not support .isclose.

The assignment of Python language features and library functionality to platforms seems random. The Unix build omits functionality when the smallest host probably has 512MiB of RAM; but it does support math.isclose and reverse special methods. Then consider the Pyboard D SF6W. The perfect baremetal target for serious maths: plenty of RAM and a 64 bit hardware FPU. It supports math.isclose but not reverse special methods.

[rcolistete]

Good news, it is default for STM32 from this PR#6400 "stm32/mpconfigport.h: Enable MICROPY_PY_REVERSE_SPECIAL_METHODS."

dpgeorge commented 16 hours ago
Having reverse special methods like __rmul__ is a useful core feature, so enable it on all stm32 boards.

Adds 292 bytes to code size.

So it is not in MicroPython v1.13 stable, but from Sep 3, 2020 onwards.

[rcolistete]

I'll also use "MICROPY_PY_REVERSE_SPECIAL_METHODS'" enabled in all my new firmares for ESP8266, ESP32, Pycom, etc, without and with ulab module.