Add additional math methods by tychedelia · Pull Request #140 · processing/libprocessing

tychedelia

tychedelia changed the title ~~Feature/135 math methods~~ Add additional math methods

Apr 25, 2026

		return (value - start) / (stop - start)


		def remap(value, start1, stop1, start2, stop2):

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

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:

Keep map() for Processing compatibility, possibly by dispatching based on arguments like Processing.py does.
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.

		@@ -0,0 +1,69 @@
		"""Processing math methods and vector/quaternion types."""

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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:

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 function round>

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.

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?