Just to update everyone on this: Luis did open an issue as requested, which I
have now marked as fixed, because I've added [io] annotations to all the
instances I spotted where they were wrongly missing. I haven't released an
updated PDL::LA yet, because I'm just finishing up fixing some other
type-conversion stuff that was revealed (see
https://pdl.perl.org/advent/blog/2024/12/20/pdl-internals/ for more), and I
want to get it all at once.
[https://pdl.perl.org/advent/banner.jpg]<https://pdl.perl.org/advent/blog/2024/12/20/pdl-internals/>
Day 20: Perl Data Language internals - PDL Advent calendar
2024<https://pdl.perl.org/advent/blog/2024/12/20/pdl-internals/>
PDL is powerful and has many features. But as with any complex software system,
bugs can happen. Let's learn about two! "Those who love sausages and PDL should
watch neither being made," said Santa, dreamily.
pdl.perl.org
As noted in an email, I intend to add a readonly flag to PDL, so one can mark
an ndarray as such. That would then have PDL throw an error if you tried to
pass it as an output (which is what happens with inplace, assignments, etc). It
wouldn't have helped with an operation that wrongly missed off an [io]
annotation.
To answer a specific point raised here: sever will destroy any trans_parent,
doing nothing if there isn't one. It won't make a copy. Generally unless you
know you're doing slice on something and want to copy it, it's not much use to
you. If you want to copy only if not marked inplace, use $out =
$pdl->new_or_inplace.
Best regards,
Ed
________________________________
From: Luis Mochan <moc...@icf.unam.mx>
Sent: 05 December 2024 14:40
To: Ed . <ej...@hotmail.com>
Cc: perldl <pdl-gene...@lists.sourceforge.net>; perldl
<pdl-devel@lists.sourceforge.net>
Subject: Re: [Pdl-devel] cgtsv
Hi Ed,
On Thu, Dec 05, 2024 at 07:15:39AM +0000, Ed . wrote:
> If an input parameter gets modified, it absolutely needs to be
> marked [io]. Please could you open an issue on the repo noting at
> least that operation, and any others you spot that have the same
> problem? Sorry for missing that here.
Sure.
Some routines modify its input to give some information back. Some
modify its input only to save memory, and give no useful information
back. So in both cases, they should be marked 'io'.
> More conceptually, I feel that LAPACK bindings should not make
> copies of their inputs, that is for higher-level wrappings to do.
Agreed.
> In your case I believe that's in Photonic::Util?
Yes. I actually don't fully understand the current version of
Photonic::Util::cgtsv, as it makes copies only of inplace ndarrays and
marks them not inplace, but lapack's cgtsv modifies them anyway.
Now I have a more general doubt. Consider some class that has a
ndarray field, say ndarray, and an immutable object $obj of that class.
After I get the ndarray
my $pdl=$obj->ndarray;
if I modify $pdl using any of the operator-assignments .=, *=,
+=,... or by incrementing/decrementing, or by using some inplace
operation, I guess I would be modifying the data within the object
violating its immutability! What is the best way to protect the class
and avoid this risk? I guess the object might return a copy of the
ndarray, but that could be unnecessarily costly. It could also 'sever'
the return value, but I still haven't understood the 'sever' method,
and I'm not sure it would always protect the object's data. Is there,
or could there be, some flag to mark a pdl as immutable, so that
an error is raised whenever an attempt is made to modify it. I guess
this would be easy to implement for the PDL operators, but I'm not
sure if it would work when an external routine, such as those from
lapack, are fed with pointers to the pdl's data.
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 | moc...@fis.unam.mx /\_/\__/
GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16 C2DF 5F0A C52B 791E B9EB
_______________________________________________
pdl-devel mailing list
pdl-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-devel
