So David’s recent “ping” on the long-standing desire to propagate bad values in the constructor got me thinking…
Right now the constructor is totally badval-ignorant. In fact, it uses the global variable $PDL::undefval to pad PDLs, and if $PDL::undefval isn’t set, it makes up a reasonable choice (0) and autosets that value. That’s sort of a cheesy way to do things: I believe the BAD code already existed when I wrote the deep-copy constructor, and I should have known better. So, er, sorry about that. But now, a lot of code depends on that default behavior. For example, given an array $rp, it’s convenient to complexify it by saying “$cplx = pdl($rp,0)->mv(-1,0)”. So I don’t want to do the natural thing, which is to set missing values to BAD by default. Yet it seems even more broken to pass-through bad values, and also pad with undefval for missing elements, which is the natural non-invasive way to make things work. I suggest using the hybrid style for pdl() and generating a newer bpdl() or something that behaves more regularly (i.e. sets all missing values to BAD instead of padding with a separate global $PDL::undefval). What’s the general consensus here? Cheers, Craig ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e _______________________________________________ pdl-devel mailing list pdl-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pdl-devel
