[PHP-DEV] Re: PHP support for matrix operations - BLAS, LAPACK.

[Christoph M. Becker]

On 05.12.2022 at 00:43, j adams wrote:

> I apologize if I have the wrong mailing list here. I'm hoping ot ask the
> PHP developer community if there's any appetite for functions to handle
> matrix operations and scientific computing.
>
> I took a course on machine learning which had us code solutions using
> matlab/octave. This year I embarked on trying to translate those functions
> to PHP and have been quite surprised to learn that pure php is quite
> inefficient for matrix multiplication. I've been trying to chase down an
> effective way to perform matrix operations in PHP and posting my questions
> and progress on this forum at PHPBuilder:
> https://board.phpbuilder.com/d/10403480-converting-matlab-machine-learning-routines-to-php-need-matrix-operations
>
> Fast matrix operations seem to be absolutely critical for machine learning,
> at least for Support Vector Machines and Neural Networks. I know that there
> is a FANN extension, but it seems to me that it would be beneficial for
> PHP's use in scientific applications if it had support -- either natively
> or via some extension -- for matrix operations and possibly other
> statistical or scientific computations. Python has numpy, for example.
>
> How does everyone feel about BLAS or LAPACK extension for PHP? I'm poorly
> equipped to cook up such a thing, but these libraries already exist and
> could offer great improvements in performance.

There is already , which should
serve these needs.

--
Christoph M. Becker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly

[Claude Pache]

> Le 3 déc. 2022 à 19:28, Larry Garfield  a écrit :
> 
> I also clarified that static properties are explicitly not supported with 
> a-viz.  

This is a serious issue, not necessarily because it is of great value, but 
because it introduces an unexpected asymmetry between static and non-static 
properties. In other words, from a user point-of-view, it is expected that 
staticness is orthogonal to visibility.

Therefore, I would expect that the RFC has a dedicated section about static 
properties (as it has already one about [un]typed properties), not just a small 
sentence in the intro that could be overlooked.


> and as it's of limited value we're not going to bother.

Whether it’s of limited value or not, depends, I suppose, of coding style. 
Personally, I use static properties for various good and bad reasons, and some 
of them would be happy to take advantage of asymmetric visibility. E.g.:

* I may store settings that concern the whole class (and that I cannot or want 
not register as constants) in static properties;

* My typical implementation of “monostate pattern” is not: 
`Foo::getInstance()->bar()`, `Foo::getInstance()->baz`, but: `Foo::bar()`, 
`Foo::$baz`;

* ...

Of course, I would accept the reason “it is difficult to implement”, but not 
the excuse “it is almost worthless”.


—Claude

RE: [PHP-DEV] [RFC][List/Assoc\unique]

[CHU Zhaowei]

Hi Ilija,

Thanks for the RFC. In general, I like the idea but there are certain things 
not clear to me.

1. What will happen if we pass a list to ` Assoc\unique`? 
```
Assoc\unique([1, 2, 3, 1]);
```

2. What will happen if the array (no matter list or assoc) contains pure value 
and reference which are strict equal? As the RFC says "references are 
preserved." 
```
$a = 1;
$arr1 = [$a, &$a];
$arr2 = [&$a, $a];
List\unique($arr1);
List\unique($arr2);
```

3. Currently the RFC (proposal section, function signature) claims the 
parameter are bool type, which is obvious wrong. But this is just a minor 
mistake, what I really want to ask here is do we support array only or any 
array like input?

> Side note: I *really* hope the discussion will be about more than just the 
> namespaces.

Adding two new namespaces with single function doesn't look good to me, 
especially I cannot think of anything that we may add to these two namespace in 
the future.

Regards,
CHU Zhaowei

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly

[Larry Garfield]

On Mon, Dec 5, 2022, at 12:47 PM, Claude Pache wrote:
>> Le 3 déc. 2022 à 19:28, Larry Garfield  a écrit :
>> 
>> I also clarified that static properties are explicitly not supported with 
>> a-viz.  
>
> This is a serious issue, not necessarily because it is of great value, 
> but because it introduces an unexpected asymmetry between static and 
> non-static properties. In other words, from a user point-of-view, it is 
> expected that staticness is orthogonal to visibility.
>
> Therefore, I would expect that the RFC has a dedicated section about 
> static properties (as it has already one about [un]typed properties), 
> not just a small sentence in the intro that could be overlooked.
>
>
>> and as it's of limited value we're not going to bother.
>
> Whether it’s of limited value or not, depends, I suppose, of coding 
> style. Personally, I use static properties for various good and bad 
> reasons, and some of them would be happy to take advantage of 
> asymmetric visibility. E.g.:
>
> * I may store settings that concern the whole class (and that I cannot 
> or want not register as constants) in static properties;
>
> * My typical implementation of “monostate pattern” is not: 
> `Foo::getInstance()->bar()`, `Foo::getInstance()->baz`, but: 
> `Foo::bar()`, `Foo::$baz`;
>
> * ...
>
> Of course, I would accept the reason “it is difficult to implement”, 
> but not the excuse “it is almost worthless”.

It is difficult to implement, and thus we're not going to put in the effort to 
figure out how to do it because the value is so much less. :-)  But fair 
enough, I'll move it to its own section so it's more readily apparent.

--Larry Garfield

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php