I see. This makes some sense to me. I think the proper thing to do here is use Perl's int built-in, but this could be made to work.
This would require Exporter to export some other-named method into the user's package under the name floor. I don't know that Exporter can do that. Other CPAN modules can (Sub::Exporter, maybe?), but not Exporter. Or we could handle it ourselves under PDL::import, I guess. David On Jan 12, 2012 5:51 AM, "chm" <[email protected]> wrote: > On 1/11/2012 10:45 PM, Craig DeForest wrote: > >> It would be even more surprising if floor() returned a PDL in most >> (but not all) cases. Then you could not say (for example) >> $a->inplace->floor->indexND($**b); # would crash or (just as bad but >> more subtly) $a->inplace->floor += 5; # would crash or silently do >> nothing (depending on perl version) without breakage. >> > > My thought was that the fix would *only* > be for the sub version of floor, not the > method call. > > --Chris > > If there is any irregularity, it is in PDL::new_from_specification, >> but I still think that idiom is a good DWIMism. >> >> >> >> On Jan 11, 2012, at 7:43 PM, chm wrote: >> >> On 1/11/2012 4:28 PM, David Mertens wrote: >>> >>>> Chris - >>>> >>>> The cynic in me would argue that this would be a non-issue with >>>> stricter namespacing, but I suppose that in the end one would >>>> have imported this >>>> >>> >> method and run into the same problem even with stricter >>>> namespacing. >>>> >>>> I think your idea makes sense, but I fear there is little we can >>>> do about it now. User code might depend on the result being a >>>> piddle. Perhaps we >>>> >>> >> could implement this for PDL3, the non-backwards-compatible >>>> version of PDL that rocks the numerical community's world slated >>>> to come out Christmas (of some uspecified year). :-D >>>> >>> >>> It seems more of a "feature" that floor() converts a normal perl >>> scalar into a piddle in addition to its documented functionality. >>> >>> It definitely conflicts (uneccessarily) with the existing >>> POSIX::floor functionality present in the perl core module set. >>> There are arguments for either case although the "surprise" factor >>> where sequence() does not do what you mean because of the >>> PDL::floor data type conversion seems persuasive to me. >>> >>> Not something to rush in to, but I don't think we should resort to >>> preserving buggy implementations when it decreases the usability >>> and users ability to understand what/how PDL works.... >>> >>> --Chris >>> >>> >>> On Wed, Jan 11, 2012 at 3:13 PM, Chris >>>> Marshall<devel.chm.01@gmail.**com <[email protected]>>wrote: >>>> >>>> I was writing some code to generate sequence vectors of the >>>>> appropriate dimensionality and I ran the following sequence: >>>>> >>>>> pdl> $nmax = 1; pdl> $nvec = sequence(floor($nmax+1)); pdl> >>>>> p $nvec 0 >>>>> >>>>> which surprised me since I expected the result to be [0,1] >>>>> since floor($nmax+1) is 2. It turns out the result is correct >>>>> according to the documentation _since_ the floor() routine >>>>> generates a pdl output value even if the input is a perl >>>>> scalar. If you use POSIX::floor instead, I get the expected >>>>> result: >>>>> >>>>> pdl> $nvec = sequence(POSIX::floor($nmax+1)**); pdl> p $nvec >>>>> [0 1] >>>>> >>>>> Maybe the PDL::floor routine (and similar routines) should >>>>> return perl scalars when passed perl scalars as input args >>>>> instead of piddles. Goes to show you, PDL can always surprise >>>>> you! :-) >>>>> >>>>> --Chris >>>>> >>>>
_______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
