On Thu, Jan 19, 2012 at 2:38 PM, David Mertens <[email protected]> wrote: > 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.
Yes, but INF is not defined for integer data types and the values are different between 4byte and 8byte floats. As for NaNs, there are multiple NaN values that are allowed---more like an equivalence class. At any rate, it seems clear that they don't fit the idea of a constant. --Chris _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
