Re: Numeric Analysis - Root Finding

From: Date: Thu, 18 Mar 2004 21:34:44 +0000
Subject: Re: Numeric Analysis - Root Finding
References: 1  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-26566@lists.php.net to get a copy of this message
(CC'ing to pea-rdev for comments) --- Paul Meagher <paul@datavore.com> wrote: > Hi Jesus, > > One serious issue I ran into with my last article > was the namespace issue. > > While prefixing all files with namespace identifiers > like: > > PHPMath_Functions_ > > helps to ensure that PHPMath code plays nice with > PEAR code, it seems way > to verbose for my liking. I would prefer class and > function names that > descriptive but succinct. Indeed, that is a problem. And one that will not go away with PHP 5, as the namespaces support was abandoned (at least for now). I will see this as a problem for functions distributed as methods packaged inside a class, but should not be for self-contained functions > > For example, I now prefer to invoke my probability > distributions by just > doing this: > > $norm = new NormalDistribution($mean, $variance); > > Instead of > > $norm = new > PHPMath_ProbabilityDistributions_Normal($mean, > $variance); > > This can get really nasty when inheriting classes: > > class PHPMath_ProbabilityDistributions_Normal > extends > PHPMath_ProbabilityDistributions Agree, subpackages will be a nightmare too, we'll end with some of the kilometric names sometimes one encounters in Java ;-) How about using interceptors and distributing in each package the verboselly named class, e.g.: PHPMath_ProbabilityDistributions_Normal along with a class named: _NormalDistribution that implements a delegator-style approach (PHP 5 syntax, but similar can be done w/ PHP 4 syntax): class _NormalDistribution { private $dist; function __construct() { $this->dist = new PHPMath_ProbabilityDistributions_Normal(); } function __call($method, $args) { return call_user_func_array(&$this->dist, $method, $args); } function __get($var) { return $this->dist->$var } function __set($var, $val) { return $this->dist->$var = $val; } } (untested code, just wrote it quickly as an example) In this way, we can have our cake and eat it too (sort of :-) > I don't think adding a bunch of namespace symbols is > the way to go with > math code as the majority of math code errs on the > side of brevity rather > than verbosity. If the API is too verbose, most > math people won't use it. > > That is just my 2 cents. > > I do like the idea of revisiting a method we might > use to automatically > package the functions into libraries or packages. > > I have been thinking about adding a "download" icon > to the various folder > that would zip up all the code in the folder and > subfolder. I have used > the PEAR archive class in other projects and quite > like it. The manner in > which the folder code is turned into a tarball might > be user configurable > in some ways (add namespace to classes/functions, > aggregate folder > contents into one file, etc...). This would involve > parsing through the > files and modifying them if necessary before > packaging them into a > tarball. Yup, we can generate some pacakages on the fly, in particular if all functions are self-contained, and create or ask the user requesting what class name to use, but I am not sure if that will be good for consistency. User Foo can ask for functions A, B, and C, and user Bar wants A, B, and D, and both pick the same class name, so user Plink sees the code of Bar and then tries to use the libs from Foo and all hell breaks lose. Perhaps bundling pre-created packages into a package collection will be better. > There are probably other approaches that would work. Hopefully the PEAR dev guys will have some other perspectives, as this can be a way for people to proceed if they want to release they procedural code and would also allow the users to take advantage of the PEAR packager. > Regards, > Paul > > > <quote who="Jesus Castagnetto"> > > Got the code from the tarball in the second URL > (did > > not try the zip). > > > > Personally I'd like to see some of the code you > are > > proposing both as individual self-contained > functions, > > and as PEAR installable packages. > > > > I'll take a look at your code this weekend. Also > will > > try to come up with some general strategy so we > can > > distribute the phpmath code as individual > functions, > > but also be able to automate the creation of > classes > > containing the functions and then generate the > > packages. > > > > Maybe we should also start coming up with some > naming > > conventions for the functions or function files to > > make the automatic packaging simpler? > > > > Cheers. > > > > --- Firman Wandayandi <fwd@vfemail.net> wrote: > >> Hi Paul, > >> > >> Sorry, the tarball doesn't work. Would you like > to > >> try the following > >> addresses: > >> > >> > > > http://firman-wandayandi.netfirms.com/misc/download/rootfinding.zip > >> or > >> http://www.grant.org.uk/rootfinding.tgz > >> > >> Regards, > >> Firman > >> > >> ----- Original Message ----- > >> From: "Paul Meagher" <paul@datavore.com> > >> To: <fwd@vfemail.net> > >> Sent: Thursday, March 18, 2004 9:40 PM > >> Subject: Re: Numeric Analysis - Root Finding > >> > >> > >> > When I followed your link I got a response > about > >> netfirms not allowing > >> > direct image downloads. > >> > > >> > I then used wget instead and tried to unpack > the > >> tarball and got this > >> > message: > >> > > >> > #>~/src$ gunzip -c rootfinding.tgz | tar -xvf - > >> > gunzip: rootfinding.tgz: not in gzip format > >> > #>~/src$ > >> > > >> > Not sure if others are experiencing these > >> difficulties as well. > >> > > >> > regards, > >> > paul > >> > > >> > > >> > > >> > <quote who="Firman Wandayandi"> > >> > > Hi all, > >> > > > >> > > Here is the address tgz archive file that you > >> can download root finding > >> > > application: > >> > > > >> > > > http://firman-wandayandi.netfirms.com/misc/download/rootfinding.tgz > >> > > > >> > > Look like many bugs there, sorry I'm a PHP > >> beginner when I develop this. > >> > > > >> > > I have plan to purpose this to pear or any > kind, > >> but I not sure it's > >> > > useful. > >> > > > >> > > Feel free to send any comments. > >> > > > >> > > Kind Regards, > >> > > Firman > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > >> > > >> > Regards, > >> > > >> > Paul Meagher > >> > > >> > Datavore Productions > >> > 50 Wood Grove Drive > >> > Truro, Nova Scotia > >> > B2N-6Y4 > >> > 1.902.895.9671 > >> > www.datavore.com > >> > > >> > > >> > ----------------------------------------- > >> > This email was sent using Email Master. > >> > "Email Power Tools!" > >> > http://www.emailmaster.ca/ > >> > > >> > >> > >> ower Tools!" > >> > http://www.emailmaster.ca/ > >> > > >> > >> > >> > > > > ===== > > Jesus M. Castagnetto - jesus_castagnetto@yahoo.com > > Personal: http://www.castagnetto.org/ > > Research: http://metallo.scripps.edu/ > > PEAR stuff: http://pear.php.net/user/jmcastagnetto > > For PHP related stuff: jmcastagnetto@php.net > > > > __________________________________ > > Do you Yahoo!? > > Yahoo! Mail - More reliable, more storage, less > spam > > http://mail.yahoo.com > > > > > Regards, > > Paul Meagher > > Datavore Productions > 50 Wood Grove Drive > Truro, Nova Scotia > B2N-6Y4 > 1.902.895.9671 > www.datavore.com > > > ----------------------------------------- > This email was sent using Email Master. > "Email Power Tools!" > http://www.emailmaster.ca/ ===== Jesus M. Castagnetto - jesus_castagnetto@yahoo.com Personal: http://www.castagnetto.org/ Research: http://metallo.scripps.edu/ PEAR stuff: http://pear.php.net/user/jmcastagnetto For PHP related stuff: jmcastagnetto@php.net __________________________________ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com

« previous php.pear.dev (#26566) next »