List operations now "array manipulations"

[zeffii]

To use Numpy we much step away from explicit Lists, and their exposure to the user. The only way to get speed from numpy is start from the point of an np.array and traverse the whole tree via 'representations' (views of the array) or flat copies.

I'm eager to get away from the superficial split in the current List basic and List interfere, it's not clear what criteria is used to give them that categorization (if I find that difficult, i can only imagine users being equally baffled).

We can with relative ease make fewer Nodes to operate on np.arrays, yet also implement all powerful np.array features . Some np.array functions are analogue to combining several of our old list nodes. I expect this to be easy to prove once we have a few nodes working.

[nortikin]

yes, it is what needed for redux. try to make system on math. Power side of sverchok will rise. And yes, naming was ugly, agree.

[nortikin]

if we use numpy for vertices and edges maybe, than polygons could be python lists still. than no need to make two-three arrays. or as case - for polygons only accept array data and arrays to slice... than many problems just disappear... verticis will still be [[[xyz]]], or deeper. vectorswill be [[[(x1y1z1)(x2y2z2)]]] and deeper. what object will be than? python object is object defined now in sverchok in level 1: [container [object [vector [digit ]]]] now will be object with main np.array coordinates [object [vertex [digit ]]] as np.array([[xyz],[xyz],[xyz]...]) so we can in calc process join arrays or separate, but every is an object. recursions - thatwhat i don't understand howto in np.array or we find depth and make exact slicing operations?

[zeffii]

we immediately lose the benefit of the numpy speed by mixing numpy with python lists

[nortikin]

than we need per object one array for vectors and vertices, but flat masking arrays for polygons... thats it. They are different and we ease life with as i writed upper.