Hi Luis, slice gives an error if asked for a slice that's out of the bounds of the ndarray. I've just checked, and the docs don't say so. One could imagine an argument for expecting an empty answer back, but it's worked this way for quite a long time, and there's no way to change that now.
A wrinkle is that it will only actually give the error later, when you try to make_physvaffine the result (e.g. by printing), which isn't very satisfactory on some level, but is part of the deal with "vaffine" ndarrays: they get very strictly lazily evaluated, not even their dimensions are ascertained initially. sequence(0) is a lot like zeroes(0) - you explicitly asked for an empty, so you got one. These, and the slice scenario, are not similar situations. Best regards, Ed ________________________________ From: Luis Mochan <[email protected]> Sent: 10 December 2024 2:08 AM To: perldl <[email protected]>; perldl <[email protected]> Subject: [Pdl-devel] empty slices Hello, I wonder if the following behavior is the expected behavior: pdl> $x=sequence(2) pdl> p $x(0:-1) [0 1] pdl> p $x(1:-1) [1] pdl> p $x(2:-1) Stringizing problem: Error in slice:slice starts out of bounds in pos 0 (start is 2; end is -1; inc is 0; source dim 0 runs 0 to 1). PDL::isempty(PDL=SCALAR(0x55800a893060)) called at... ... pdl> $y=sequence(0) pdl> p $y Empty[0] Shouldn't $x(2:-1) produce an empty ndarray, as $y, instead of an error? Regards, Luis -- o W. Luis Mochán, | tel:(52)(777)329-1734 /<(*) Instituto de Ciencias Físicas, UNAM | fax:(52)(777)317-5388 `>/ /\ Av. Universidad s/n CP 62210 | (*)/\/ \ Cuernavaca, Morelos, México | [email protected] /\_/\__/ GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16 C2DF 5F0A C52B 791E B9EB _______________________________________________ pdl-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/pdl-devel
_______________________________________________ pdl-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/pdl-devel
