Add additional math methods

[tychedelia]

Closes#135

We're going with remap as noted here: https://discord.com/channels/1076634729618624534/1473643112512491692/1496498755028127905

[SableRaf]

Not a blocker but we could potentially add the optional 6th argument from p5.js's version of the map() function: map(value, start1, stop1, start2, stop2, [withinBounds]) where withinBounds is a boolean which (if true) makes the function constrain the return value to the newly mapped range.

[SableRaf]

Could we explicitly address the tradeoffs before making a decision on map() vs remap()?

From issue #131 it seems like there are at least two possible directions:

1. Keep map() for Processing compatibility, possibly by dispatching based on arguments like Processing.py does.
2. Use remap() to avoid shadowing Python’s built-in map(), like py5 does (see @hx2A's comment on 131)

Note: we should document this type of decisions on GitHub, since not everyone is on Discord and messages there are not publicly available without an account.

[SableRaf]

This PR implements the following functions from Processing4:

sin(), cos(), tan(), asin(), acos(), atan(), atan2(), sqrt(), exp(), log(), ceil(), floor(), degrees(), radians(), sq(), pow(), constrain(), lerp(), norm(), map(), mag(), dist()

It's currently missing:

• abs()
• max()
• min()
• round()

[tychedelia]

I should leave a comment to make this clear, but these are available in the global python namespace and I believe match processing semantics already.

Ex:

[I] char@mbp ~/s/g/p/libprocessing $ python3 compute-2
Python 3.14.4 (main, Apr 7 2026, 13:13:20) [Clang 17.0.0 (clang-1700.6.4.2)] on darwin
Type "help", "copyright", "credits" or "license"for more information.
>>> round
<built-in functionround>

[tychedelia]

Could we explicitly address the tradeoffs before making a decision on map() vs remap()?

I feel pretty strongly that shadowing built-ins is the wrong decision. map is a pretty common functional programming idiom in python and it would be frustrating if users were left with the option either to not use the wildcard import (requiring manually importing every processing API item one-by-one) or not be able to express common python patterns.

[catilac]

Could we explicitly address the tradeoffs before making a decision on map() vs remap()?

I feel pretty strongly that shadowing built-ins is the wrong decision. map is a pretty common functional programming idiom in python and it would be frustrating if users were left with the option either to not use the wildcard import (requiring manually importing every processing API item one-by-one) or not be able to express common python patterns.

I want to second this. We don't want to clobber the python ecosystem in being overly opinionated. If this somehow becomes an issue to downstream users we can address it then.

is this ready?