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<[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

Reply via email to