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.
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
>>>
>>
>>
>>
>
>
> _______________________________________________
> 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
