On Tue, Jan 3, 2012 at 3:41 PM, Chris Marshall <[email protected]>wrote:
> On Tue, Jan 3, 2012 at 4:34 PM, David Mertens <[email protected]> > wrote: > > > > > > On Tue, Jan 3, 2012 at 3:18 PM, Douglas Burke <[email protected]> > > wrote: > >> > >> On 1/2/12 11:18 PM, David Mertens wrote: > >> > >>> Because PDL doesn't like boolean evaluations **except for > single-element > >>> piddles**, this expression will croak if $a is anything more than a > >>> one-dimensional vector. Have you tried running that conditional when $a > >>> is more complex? For example, if $a is a matrix, this will croak. > >>> Something I didn't realize, but just learned messing with this, is that > >>> a single BAD value is considered boolean false. That's more clever than > >>> I had expected. :-) > >>> > >>> > >> > >> It's kind-of discussed in > >> > >> > >> > http://pdl.perl.org/PDLdocs/BadValues.html#bad_values_and_boolean_operators > >> > >> (or, perhaps, this is out of date and needs re-writing), but it may well > >> make sense for someone (not me, as I don't have the energy) to move the > >> operational/useful parts of this document to PDL::Bad, leaving the > BadValues > >> document more for the > >> implementation/you-don't-need-to-read-this-to-just-use-it > documentation. I > >> can't remember if the docs for PDL::Bad is empty if support is not > included, > >> and - of so - whether it is that serious an issue (since if you don't > have > >> the support compiled in then you don't really need to know about how it > >> works). > >> > >>> In PDL 2.4.10, you should be able to return pdl('bad'). That's a recent > >>> implementation of mine. :-) Alternatively, perhaps PDL should add BAD > to > >>> PDL::Constants (as well as INF, for that matter). > >> > >> > >> As the bad-value can be changed for the integer types (and even > >> floating-point types, depending on how the code is built), I'm not sure > that > >> you can really treat it as a constant, but this comment comes after > spending > >> all of 5 seconds thinking about the matter, so I may well be missing > >> something completely obvious here ;-) > > Yes, that is why it is not in there. Even IEEE values like Inf and NaN > can be ambiguous. > I was thinking about this today, because I define and use Inf in my plotting library (for which I have just written a collection of milestones and goals). First, generating infinity in Perl is as easy as this: my $inf = -pdl(0)->log->at(0); Mind you, sending zero to Perl's log function will make it squack, but not PDL's. This will give the current machine's representation of infinity for the current floating-point type you're using. As for generating nan, I'm not sure how I'd do it in Perl, because I only use it in C/XS code, but the usual way in C code is to multiply zero times your just-acquired value of infinity: double my_nan = my_inf * 0.0; Infinity times any positive number just returns infinity, but infinity times zero returns nan, in your machine's architecture-dependent representation. FYI. David -- Sent via my carrier pigeon.
_______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
