Numpy with Trinket and-or with Python mode

Processing.py
1

I have been trying to use numpy with Processing on trinket but it seems that most of the basic functions are either not available or not working.

ex:

arr[1:H-1][0:W-2] + arr[1:H-1][2:W] // addition of 2D matrices doesn't work
np.linalg.norm(vec) // simple normalization doesn't work

//for normalization better import math module instead

from math import hypot

vec = np.array([x, y]) 
normalized_vec = vec / abs(hypot(x, y))

Though, it still can be useful when simple PVector operations are needed

ex:

PVector(20, 80) -> np.array([20, 80])

vec = np.array([2, 4])
vec * 3 // np.array([6, 12])
vec / 2 // np.array([1, 2])
vec + vec // np.array([4, 8])
...

test

1 Like
2

@solub – do you think upgrading processing.py to Jython 2.7.2 final would matter? can you tell if trinket is using numpy 13.3, the recommended version for maximum JyNI compatability?

3

I thinks it really depends on the quality of JyNI’s numpy implementation.

If it is as limited as the version that trinket is using for Python 2.7 then the upgrade is clearly not worth it. On the contrary, a more mature and stable implementation would bring a lot (a lot!) to the table.

I don’t know what version of numpy is currently being used by trinket (Python 2.7) but it is far from being workable: simple matrix operations return errors, basic functions (that are available in ver. 13.3) like zeros_like() or meshgrid() are missing, slicing is deficient…

I think the problem is not the version (13.3 is more than decent) but the relative exhaustiveness of the implementation.

4

@solub’s sketch w/ its source code as well: :angel:

3 Likes
5

Looks like Trinket has numpy 1.15.4 installed. Not sure if that is the same version available for Trinket’s processing.py, because numpy.__version__ and numpy.version.version don’t work in its processing.py sketch window – although they do in a general python window?

15.4 numpy is bad news for JyNI, which has many known problems above 13.3.

Also, it looks like Trinket uses Skulpt to host their generic Python (python2) sketches. Not sure how that relates to how they serve python mode.

6

– GoToLoop: I don’t really like to have the code alongisde the canvas. It always feels like we only get to see half of the code and half of the output. Having the text editor above or below the canvas would make more sense in my opinion, especially when embedding in a forum post. I might prefer leaving the full width to the canvas and pasting the corresponding code beneath.

– JeremyDouglass: My intuition is that 15.4 is the version used in Python 3 Trinkets not in processing.py Trinkets. The 2 versions are like night and day.

A few questions:

  • Is upgrading Processing.py to Jython 2.7.2 on the roadmap ? (regardless of JyNI)
  • Is it “difficult” (time consuming, complex) to make the upgrade ? (How likely is it to happen ?)
  • How 15.4 numpy in Trinket would be bad news for JyNI and its numpy 13.3 support ?
7

That’s true! But then you could leave another link just for the source code.
I had to use browser’s inspection in order to find out your source code’s link.

P.S.: Just found out the embed option “toggleCode=true” which allows us to toggle display & code! :partying_face:

1 Like
8

No, in the sense that it doesn’t have a roadmap – it is in maintenance. If a developer got involved, upgraded it and tested it, I think jdf (Jonathan Feinberg) would probably accept the patch and make a new release – or / in the meantime the mode could just be released from someone’s fork and manually installed.

I honestly don’t know. It might be an easy drop-in replacement, or it might be a lot of work.

Well, 15.4 numpy would be bad news for JyNI, which Jython needs to load numpy. My understanding is that the latest JyNI (2.7-alpha5) is best able to load numpy 1.13.3. Later numpy breaks it Jython 2.7.2, NumPy advice ¡ Issue #37 ¡ Stewori/JyNI ¡ GitHub
This is just based on what I have read, not experience.

That said, it looks like perhaps Trinket is using a hand-crafted partial numpy replacement running on Skulpt, since their target is JS, not JVM. I can’t tell. So that would have a completely different set of limits.

4 Likes
9

Hi @solub, I don’t have the necessary skills to test it, but I think that another ‘road’ to the ‘promissed land of numpy’ would be to access Processing’s PApplet class using Python 3 + PyJNIus (https://github.com/kivy/pyjnius) as one would using Java in Eclipse (https://happycoding.io/tutorials/java/processing-in-java).

1 Like
10

Sorry for bumping the thread.

I just found about jni4net, a bridge between Java and the .NET ecosystem. Do you think it would be possible to use it with Processing in order to access a .NET binding for Numpy (like SciSharp) ?

1 Like
11

Hi @solub !
The mantainer thinks it’ s not ready yet for the limelight, but py5 is the Python 3 + Processing way to go, check ou this wonderful write up by @tabreturn:

3 Likes
12

Hey @villares thank you for the poke !
Yes, I had a quick peek at it and it looks really promising ! I can’t wait to have some time on my hands to try it out.

Also thank you to @tabreturn for this very comprehensive write up, and to @monkstone for the helpful examples. This small Python-oriented Processing community brings joy to my heart.

3 Likes