Hi Pierre Joye, > Not sure you care or read my reply but I had to jump in one more time here :) > > On Sat, Sep 18, 2021 at 8:49 AM tyson andre <tysonandre...@hotmail.com> wrote: > > > setSize is useful in allocating exactly the variable amount of memory > > needed while using less memory than a PHP array. > > `setSize($newSize, 0)` would be much more efficient and concise in > > initializing the value. > > > > - Or in quickly reducing the size of the array rather than repeatedly > > calling pop in a loop. > > I would rather not reduce it at all, but use the vector_size and keep > it. User land set its max size but a realloc/free should not be > necessary and counter productive from a perf point of view. If one > uses it in a daemon, it can always be destroyed as needed. > > > > To echo Pierre, a Vector needs to be of a single guaranteed type. > > > Yes, this gets us back to the generics conversation again, but I presume > > > (perhaps naively?) there are ways to address this question without > > > getting into full-blown generics. > > > > Yep, as you said, this type is mixed, just like the SplFixedArray, > > ArrayObject, values of SplObjectStorage/WeakMap, etc. > > Generic support is something that's been brought up before, investigated, > > then abandoned. > > > > My concerns with adding StringVector, MixedVector, IntVector, FloatVector, > > BoolVector, ArrayVector (confusing), ObjectVector, etc is that > > > > - I doubt many people would agree that there's a wide use case for any > > specific one of them compared to a vector of any type. > > I am lost here. This is the main usage of Vector. For linear > arithmetic like dot product, masking, add/sub/mul/div of vector etc. I > do not see any other usage per see for all the things I have > implemented or saw out there. Additionally, f.e., a string is a vector > already on its own, I am not sure a vector of vectors makes sense ;). > > > This would be even harder to argue for than just a single Vector type. > > - Mixes of null and type `T` might make sense in many cases (e.g. optional > > objects, statistics that failed to get computed, etc) but would be > > forbidden by that > > - It would be a bad choice if generic support did get added in the future. > > These are special cases for general purposes of vectors. Implementing > vectors focusing on these special cases rather than the general > purpose (vectorization) would be a strategic mistake. I mentioned it > before, but please take a look at the numpy's Vector f.e., with > python's operator overload, what has been done there is simply > amazing, bringing vector processing/arithmetic a huge boost in > performance, even with millions of entries (14 to 400x speed boost > compared to classic array, even fixed). > > > > But really, a non-type-guaranteed Vector/List construct is of fairly > > > little use to me in practice, and that's before we even get into the > > > potential performance optimizations for map() and filter() from type > > > guarantees. > > > > See earlier comments on `vec`/Generics not being actively worked on right > > now and probably being a far way away from an implementation that would > > pass a vote. > > Generics!=Vector. But I hope that's not the way we are heading here :) > > > As for optimizations, opcache currently doesn't optimize individual global > > functions (let alone methods), it optimizes opcodes. > > Even array_map()/array_filter() aren't optimized, they call callbacks in an > > ordinary way. > > E.g. https://github.com/php/php-src/pull/5588 or > > https://externals.io/message/109847 regarding ordinary methods. > > > > Aside: In the long term, I think the opcache core team had a long-term plan > > of changing the intermediate representation to make these types of > > optimizations feasible without workarounds like the one I proposed in 5588 > > You are fully correct here, I see a lack of the engine devs > involvement (not complaining, just a state of the affairs :) in such > RFC where this kind of feature could greatly benefit PHP. Well > planned, this is a huge addition to PHP. > > It is also why I am convinced that doing it right for Vectors (as a > start) and thinking forwards to JIT and ops overloading (internally or > userland) to allow smooth and nice vectorization (as some parts use > them already internally f.e.) will bring PHP up to speed with the > competition. If we don't, we just have something that would be similar > to what anyone could do in userland with more flexibility.
I have no plans to change the direction of this RFC in those directions and no personal interest in working on generics (where others have attempted and failed) or operator overloading for array operations. **Adding anything like numpy's operator overloading or generics is entirely out of the scope of my proposal and not the goal of my proposal.** Both of those are massive projects compared to adding a small number of data structures. **See (https://github.com/Danack/RfcCodex/blob/master/etiquette/rfc_etiquette.md#dont-volunteer-other-people-for-huge-amounts-of-work)** numpy.Vector is not part of a standard library. It is a data structure within a library **dedicated to numeric processing/array computing** - it is not a general-purpose standard library datastructure. If you have a desire to see a similar project for use cases you have for PHP, working on a PECL would be an analogous approach. The typed arrays like numpy would be impossible to check at runtime - you'd only have the property/return type hint/ This proposal already has a fixed-sized type - that type is `mixed` (or `zval` internally), like ArrayObject, WeakMap, etc. already have in their values. (Similar to how basic Java collections (e.g. ArrayList<String>) are all collections of `Object` after generic type erasure.) Regards, Tyson
