And why we always 'use warnings' (and strict too) On Thu, Jan 19, 2012 at 1:56 PM, Joel Berger <[email protected]> wrote: > As we learn from Nancy-typing > (http://calculist.blogspot.com/2006/02/nancy-typing.html) Nan is easy > to make in Perl. Its a numeric coercion of 'Nan' > > This is why perl -E' say "Nihilist" if "Nancy" != "Nancy"' is so much fun. > > Joel > > > On Thu, Jan 19, 2012 at 1:45 PM, Chris Marshall <[email protected]> > wrote: >> 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
_______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
