On Wed, Sep 1, 2010 at 8:57 AM, Chris Marshall <[email protected]> wrote: > On 8/31/2010 10:35 PM, P Kishor wrote: >> >> With the help of ngood(), I know that my $pdl has 6766 good values. I >> printed out the unique values, and I have 28 unique good values (btw, >> is there a PDL method that returns the unique values in a piddle? >> Kinda like ngoodover() and ngood(), but instead of the number of good >> values, returns the actual good values?). > > I suggest that you familiarize yourself with > (and use) the on-line help and apropos commands > available in either PDL shell: perldl or pdl2. > > E.g., try 'apropos unique'. >
Rats! That's the one thing I didn't do. After 15 hours of struggling with perceived inconsistencies in a new and complex program, I scanned through all the docs I could think of.. PDL::Basic, PDL::Core... but didn’t go through PDL::Primitive, and didn't type 'apropos unique' in the shell. Many thanks for the tip. PDL has become superbly easy to install (relative to what it used to be), thanks to your hard work, and feedback from installers. PDL still has a very long way to go to have consistency in its operation, user-interface, syntax and ease of finding what one wants to do. I know that constant and rapid-fire questions from a new user such as me might be irritating for established users, but they may be a good indication of improvement required in user-interface... the point at which the user and the software meet, which, in PDL, happens to be the program and its documentation. I think I have brought this up before -- There is absolutely no reason why graphics modules that "display" should be under PDL::Graphics::* namespace and graphics modules that read and write should be under the PDL::IO::* namespace. Makes sense to the creator perhaps. To the user (me), a graphics module is one that I create graphics with... the display ones happen to write to a display device, the IO ones happen to write to a file device. There is absolutely no reason why on CPAN PDL::IO::Pic should be listed under "Modules," while PDL::IO::GD (which does exactly analogous tasks as the former) should be listed only under "Documentation." There is absolutely no reason why PDL::IO::Pic shouldn't handle bad values, but PDL::IO::GD does. And there is no reason that while PDL::IO::Pic doesn't handle bad values, it shouldn't inform the user explicitly that, "Hey! you trying to use BAD values, I can't handle BAD values." Seriously, if Chris hadn't held my hands with patience, I could have spent a lifetime trying to figure out why I was getting a PDL::index bad index -217468... whatever error. Actually, as I said, the error wasn't even in PDL::IO::Pic. The error was in the index command being used in PDL::ImageRGB.pm. As Chris said, yes, it is `index` that doesn't handle BAD values, and yes, it says so right on the tin... if only I had looked. Man, that seems simple... but, to discover that, I have to open up PDL::ImageRGB, replicate everything that it does, be foxed for a day and a half, follow the trail to index, and then go back and re-familiarize myself with its docs to connect the dots that index is barfing. Yes, a few days, and Chris's patient hand-holding, and I could figure it out. Once I do it, it all seems logical. Or, even if it doesn't, I move on, thinking I don't need to do anything now that I know how. That is a grave mistake. We really need to improve consistency in how the hundreds, perhaps thousands of PDL commands are documented, in how they behave, in their user-interface with the user, in their syntax and operations, in the way they are called (foo() vs. $pdl->foo()), in the way they are named -- there are sum and sumover; ngood and ngoodover; nbad and nbadover, but it is not avg and avgover.. instead, it is avg and average! There is uniq, but no uniqover. What can I do to help improve this? PDL is an amazing set of programs, putting anything competing out there to shame or giving it a run for its money. But, it has a long way to go if it aspires to improve the size of its user-base and following. It has to become consistent and easy to use. It really needs to go through a user-interface overhaul. Once again, what can I do to help in that? -- Puneet Kishor http://www.punkish.org Carbon Model http://carbonmodel.org Charter Member, Open Source Geospatial Foundation http://www.osgeo.org Science Commons Fellow, http://sciencecommons.org/about/whoweare/kishor Nelson Institute, UW-Madison http://www.nelson.wisc.edu ----------------------------------------------------------------------- Assertions are politics; backing up assertions with evidence is science ======================================================================= -- Puneet Kishor http://www.punkish.org Carbon Model http://carbonmodel.org Charter Member, Open Source Geospatial Foundation http://www.osgeo.org Science Commons Fellow, http://sciencecommons.org/about/whoweare/kishor Nelson Institute, UW-Madison http://www.nelson.wisc.edu ----------------------------------------------------------------------- Assertions are politics; backing up assertions with evidence is science ======================================================================= _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
