Menu
▾
▴
pdl-devel — PDL Developers and Internals Discussion
You can subscribe to this list here.
| 2015 |
Jan
|
Feb
(44) |
Mar
(75) |
Apr
(42) |
May
(50) |
Jun
(82) |
Jul
(17) |
Aug
(45) |
Sep
(32) |
Oct
(32) |
Nov
(41) |
Dec
(22) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2016 |
Jan
(9) |
Feb
(5) |
Mar
(6) |
Apr
(6) |
May
(34) |
Jun
(47) |
Jul
(10) |
Aug
(2) |
Sep
(6) |
Oct
(35) |
Nov
(6) |
Dec
|
| 2017 |
Jan
(7) |
Feb
(5) |
Mar
(3) |
Apr
(2) |
May
(12) |
Jun
(1) |
Jul
(3) |
Aug
(3) |
Sep
|
Oct
|
Nov
(5) |
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
(16) |
Apr
(7) |
May
(10) |
Jun
(1) |
Jul
|
Aug
(2) |
Sep
|
Oct
(1) |
Nov
(2) |
Dec
(1) |
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
(32) |
May
(11) |
Jun
(5) |
Jul
(7) |
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(2) |
| 2021 |
Jan
|
Feb
(25) |
Mar
(38) |
Apr
(11) |
May
(3) |
Jun
(6) |
Jul
(2) |
Aug
(22) |
Sep
(12) |
Oct
(18) |
Nov
(6) |
Dec
(1) |
| 2022 |
Jan
(5) |
Feb
(47) |
Mar
(6) |
Apr
(9) |
May
(7) |
Jun
(2) |
Jul
(5) |
Aug
(15) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2023 |
Jan
|
Feb
(4) |
Mar
(6) |
Apr
(3) |
May
(2) |
Jun
(2) |
Jul
(3) |
Aug
(6) |
Sep
(17) |
Oct
(5) |
Nov
|
Dec
|
| 2024 |
Jan
(8) |
Feb
(4) |
Mar
(1) |
Apr
(8) |
May
(13) |
Jun
(10) |
Jul
|
Aug
|
Sep
(1) |
Oct
(16) |
Nov
(9) |
Dec
(18) |
| 2025 |
Jan
(47) |
Feb
(5) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(8) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Ed . <ej...@ho...> - 2025-01-13 19:05:52
|
Glad to hear! By the way, if it's only for the sake of that one function, would you like to add it to PDL::Ops, ideally called sqrt_upper, and with the Pars typespec of !real and complex-only datatypes? If you'd like to PR that, please do, else say and I'll add it myself.
I don't want to steal your thunder, but it does seem like an actually valuable little utility.
By the way, would you like to also (or separately) PR a doc update to Inline::Pdlpp with how to use it with Inline::Module? Warning, I do think that using pptemplate is just better, but it may as well be there for completeness.
Best regards,
Ed
________________________________
From: Luis Mochan <mo...@ic...>
Sent: 12 January 2025 00:38
To: Ed . <ej...@ho...>; perldl <pdl...@li...>; perldl <pdl...@li...>
Subject: Re: [Pdl-devel] Pdlpp modules
On Sat, Jan 11, 2025 at 11:52:53AM -0600, Luis Mochan wrote:
> I didn't know (or had forgotten) about the pptemplate; I'll try it, thanks.
> ...
With pptemplate things worked and installed without problem, thanks.
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 | mo...@fi... /\_/\__/
GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16 C2DF 5F0A C52B 791E B9EB
|
|
From: Luis M. <mo...@ic...> - 2025-01-12 01:16:35
|
Hi again,
By the way, I made a small package which may be useful (unless its
functionality is already part of PDL and I missed it): PDL::ApplyDim.
The idea is to factor out a common shuffling and unshuffling of
indices before calling pdl functions/methods that act only on the
first dimension(s). So, instead of
$pdl->mv($dim,0)->function($some, $extra, $args)->mv(0, $dim);
one may write
$pdl->apply_to(\&function, $dim, $some, $extra, $args);
$pdl->apply_to("function", $dim, $some, $extra, $args);
apply_to($pdl, \&function", $dim, $some, $extra, $args);
or
apply_to($pdl, "function", $dim, $some, $extra, $args);
...
For example, a scalar time dependent field, f(x,y,z,t) may be
represented by a 4D ndarray $f. We have $f->xvals, $f->yvals,
$f->zvals, but no $f->tvals. We could define
sub tvals($pdl){$pdl->apply_to(3, \&xvals)
Similarly, instead of
$pdl->reorder(3,2,0,1)->function(@otherargs)->reorder(2,3,1,0);
to move dimensions 3 and 2 to the front and shift the rest towards the
end, apply the function and then recover the original order, one may
write
$pdl->apply_to(\&function, [3,2], @otherargs);
or more generally
$pdl->apply_to(\&function, [$d0, $d1, $d2...], @otherargs);
The converse function is apply_not_to, to move the given dimensions to
the end, applying the function and then restoring them back to the front.
For example, to make a D-dimensional Fourier transform of
a rank 3 tensor field, represented by a (D+3)-dimensional ndarray, one
would have to move the first three dimensions (the tesorial indices)
to the end, perform the D-dimensional Fourier transform over the first
D indices and then bring the tensorial indices back to the front.
Regards,
Luis
On Sat, Jan 11, 2025 at 11:52:53AM -0600, Luis Mochan wrote:
> I didn't know (or had forgotten) about the pptemplate; I'll try it, thanks.
--
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 | mo...@fi... /\_/\__/
GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16 C2DF 5F0A C52B 791E B9EB
|
|
From: Luis M. <mo...@ic...> - 2025-01-12 00:38:49
|
On Sat, Jan 11, 2025 at 11:52:53AM -0600, Luis Mochan wrote:
> I didn't know (or had forgotten) about the pptemplate; I'll try it, thanks.
> ...
With pptemplate things worked and installed without problem, thanks.
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 | mo...@fi... /\_/\__/
GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16 C2DF 5F0A C52B 791E B9EB
|
|
From: Luis M. <mo...@ic...> - 2025-01-11 18:18:04
|
I didn't know (or had forgotten) about the pptemplate; I'll try it, thanks. I use Pdlpp expecting it to be simple, but then, making it installable is not so simple. I tried several semiautomatic approaches but they didn't quite work. I uploaded a copy of my last attempt to github, https://github.com/wlmb/PDL-UpperSqrt It is a simple function to choose one of the two square roots of a number, by setting the branch cut just below the real axis instead of along the negative axis as done by the usual library-provided complex sqrt functions. Regards, Luis On Sat, Jan 11, 2025 at 03:46:26AM +0000, Ed . wrote: > Hi Luis, > > I had a go with Inline::Module and Inline::Pdlpp back in 2017 or so, but eventually gave up as I feel a "proper" PDL::PP module is better. I still think it would be valuable to a) get your situation working, and b) capture how such a thing is done in the docs of Inline::Pdlpp. > > With a view to both those things, could you maybe put your current code on GitHub? > > Also, have you had a try with pptemplate, a script installed with PDL, to make a skeleton PDL::PP distribution? > > Best regards, > Ed > > ________________________________ > From: Luis Mochan <mo...@ic...> > Sent: 11 January 2025 03:16 > To: perldl <pdl...@li...>; perldl <pdl...@li...> > Subject: [Pdl-devel] Pdlpp modules > > > Hi, > > I started experimenting with installing distributions that use > Inline::Pdlpp code and Inline::Module. Following a mixture of > instructions I found in the documentation of Inline::Module, > Inline::Module::Tutorial and Inline::Pdlpp I had success running under > Perl-5.36.0, i.e., I could use the installed module, but not under > Perl-5.40.0, where I got an error like > > Attempt to call undefined import method with arguments ("Pdlpp" ...) via package "My::Package::Inline" > > Does anyone know what may be the relevant change between 5.36 and 5.40 > and how to overcome the error? > > Has anyone had success building pdl packages with Inline::Module under > 5.40? > > 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 | mo...@fi... /\_/\__/ > GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16 C2DF 5F0A C52B 791E B9EB > > > _______________________________________________ > pdl-devel mailing list > pdl...@li... > https://lists.sourceforge.net/lists/listinfo/pdl-devel -- 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 | mo...@fi... /\_/\__/ GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16 C2DF 5F0A C52B 791E B9EB |
|
From: Ed . <ej...@ho...> - 2025-01-11 03:53:00
|
Hi Luis, As you may have seen in the pdl repo, I've now added both spline (using pchip_chsp) and PCH (piecewise cubic Hermite (which is what PCHIP stands for)), using pchip_chim) interpolation. There isn't yet an options to add control of boundary conditions, but I'm thinking an additional boundary option for the ic and vc settings, and changing from pchip_chic to pchip_chim. Thoughts? Best regards, Ed ________________________________ From: Luis Mochan <mo...@ic...> Sent: 11 January 2025 02:54 To: Ed . <ej...@ho...> Cc: Boyd Duffee <boy...@gm...>; pdl-devel <pdl...@li...>; perldl <pdl...@li...> Subject: Re: [Pdl-devel] curl of vector Hi Ed, all, On Tue, Jan 07, 2025 at 08:16:56PM +0000, Ed . wrote: > Hi Luis and all, > > Two points: > > ... > I've now added a Ufunc::diffcentred (based on Luis's rotate algorithm), and Ufunc::partial; Great! > the latter adjusts Luis's work to take an ndarray as first param so it can be a method, and takes instruction on which method to use (centred (default), forward, backward). I'm about to add a PCHIP option too, currently only using https://metacpan.org/pod/PDL::Primitive#pchip_chim, but it would be possible to use pchip_chic which offers more control of boundary conditions. Feedback welcome. I was not aware about the pchip functions (what does the acronym stand for?). I had used the PDL::Ufunc module to make Hermite interpolations. As I read, the pchim_chim derivatives apply only to monotonic functions. For others, it produces a piecewise monotonic result with extremes at data points. The chip_chic seem to be more general and admit different choices of boundary conditions. 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 | mo...@fi... /\_/\__/ GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16 C2DF 5F0A C52B 791E B9EB |
|
From: Ed . <ej...@ho...> - 2025-01-11 03:46:41
|
Hi Luis,
I had a go with Inline::Module and Inline::Pdlpp back in 2017 or so, but eventually gave up as I feel a "proper" PDL::PP module is better. I still think it would be valuable to a) get your situation working, and b) capture how such a thing is done in the docs of Inline::Pdlpp.
With a view to both those things, could you maybe put your current code on GitHub?
Also, have you had a try with pptemplate, a script installed with PDL, to make a skeleton PDL::PP distribution?
Best regards,
Ed
________________________________
From: Luis Mochan <mo...@ic...>
Sent: 11 January 2025 03:16
To: perldl <pdl...@li...>; perldl <pdl...@li...>
Subject: [Pdl-devel] Pdlpp modules
Hi,
I started experimenting with installing distributions that use
Inline::Pdlpp code and Inline::Module. Following a mixture of
instructions I found in the documentation of Inline::Module,
Inline::Module::Tutorial and Inline::Pdlpp I had success running under
Perl-5.36.0, i.e., I could use the installed module, but not under
Perl-5.40.0, where I got an error like
Attempt to call undefined import method with arguments ("Pdlpp" ...) via package "My::Package::Inline"
Does anyone know what may be the relevant change between 5.36 and 5.40
and how to overcome the error?
Has anyone had success building pdl packages with Inline::Module under
5.40?
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 | mo...@fi... /\_/\__/
GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16 C2DF 5F0A C52B 791E B9EB
_______________________________________________
pdl-devel mailing list
pdl...@li...
https://lists.sourceforge.net/lists/listinfo/pdl-devel
|
|
From: Luis M. <mo...@ic...> - 2025-01-11 03:16:13
|
Hi,
I started experimenting with installing distributions that use
Inline::Pdlpp code and Inline::Module. Following a mixture of
instructions I found in the documentation of Inline::Module,
Inline::Module::Tutorial and Inline::Pdlpp I had success running under
Perl-5.36.0, i.e., I could use the installed module, but not under
Perl-5.40.0, where I got an error like
Attempt to call undefined import method with arguments ("Pdlpp" ...) via package "My::Package::Inline"
Does anyone know what may be the relevant change between 5.36 and 5.40
and how to overcome the error?
Has anyone had success building pdl packages with Inline::Module under
5.40?
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 | mo...@fi... /\_/\__/
GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16 C2DF 5F0A C52B 791E B9EB
|
|
From: Luis M. <mo...@ic...> - 2025-01-11 02:54:39
|
Hi Ed, all, On Tue, Jan 07, 2025 at 08:16:56PM +0000, Ed . wrote: > Hi Luis and all, > > Two points: > > ... > I've now added a Ufunc::diffcentred (based on Luis's rotate algorithm), and Ufunc::partial; Great! > the latter adjusts Luis's work to take an ndarray as first param so it can be a method, and takes instruction on which method to use (centred (default), forward, backward). I'm about to add a PCHIP option too, currently only using https://metacpan.org/pod/PDL::Primitive#pchip_chim, but it would be possible to use pchip_chic which offers more control of boundary conditions. Feedback welcome. I was not aware about the pchip functions (what does the acronym stand for?). I had used the PDL::Ufunc module to make Hermite interpolations. As I read, the pchim_chim derivatives apply only to monotonic functions. For others, it produces a piecewise monotonic result with extremes at data points. The chip_chic seem to be more general and admit different choices of boundary conditions. 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 | mo...@fi... /\_/\__/ GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16 C2DF 5F0A C52B 791E B9EB |
|
From: Boyd D. <boy...@gm...> - 2025-01-07 22:31:48
|
Hi Ed, I've added https://github.com/PDLPorters/pdl/issues/518 to hold comments on benchmarking PDL. I'll take a run at it when the weather gets warmer (it's still cold in the PC room 8-} ), but I've linked to my previous experience in case anyone else wants to have a go. But be warned - benchmarking tickles the obsessive part of your brain something fierce. cheers, Boyd On Tue, 7 Jan 2025 at 20:16, Ed . <ej...@ho...> wrote: > Hi Luis and all, > > Two points: > > - I've been looking at how Julia does loop fusion, in order to steal > ideas; these are now starting to form more concretely, which I think is > good! But I also looked up how it does on performance, and learned of a > thread where they discussed a benchmark: > https://discourse.julialang.org/t/programming-language-benchmark-2/108429 - > I'd like us to have a benchmark in that for PDL, does anyone feel like > having a go? Boyd? > - I've now added a Ufunc::diffcentred (based on Luis's rotate algorithm), > and Ufunc::partial; the latter adjusts Luis's work to take an ndarray as > first param so it can be a method, and takes instruction on which method to > use (centred (default), forward, backward). I'm about to add a PCHIP option > too, currently only using > https://metacpan.org/pod/PDL::Primitive#pchip_chim, but it would be > possible to use pchip_chic which offers more control of boundary > conditions. Feedback welcome. > > Best regards, > Ed > > ------------------------------ > *From:* Luis Mochan <mo...@ic...> > *Sent:* 21 November 2024 15:55 > *To:* Ed . <ej...@ho...> > *Cc:* Boyd Duffee <boy...@gm...>; pdl-devel < > pdl...@li...>; perldl < > pdl...@li...> > *Subject:* Re: [Pdl-devel] curl of vector > > On Thu, Nov 21, 2024 at 03:09:37PM +0000, Ed . wrote: > > Hi Luis, > > > > Thank you for both the code and the explanation! I was aware of the > limitations of diffover for this (including its name - just "diff" caused > clashes with Text::Diff in a downstream module). I'm proposing to rename > "diffover" to "numdiff" (for numerical differentiation) in the next version > of PDL, any objections? > > However, it just takes the differences between consecutive values. I > would call it firstdiff, as there are also second, third, > etc. diffs. These are analogous, but not equal, to the corresponding > (first, second, etc.) derivatives one find in calculus, and may be > used to build approximate derivatives, as in the examples. > > > I considered using diff2 in my quickly-written prototype, but chose > > diffover so as not to shrink the dim by 1. > > There are other PDL methods that allow the user to specify what to do > with the boundaries. Maybe the same should be done here. In my > solution the boundary could be kept if the function is periodic, but > otherwise, it should be thrown away. Another alternative is to add > values beyond the boundary: repeating the boundary value would > correspond to a 0 value for the derivative at the boundary. One could > also add f_{n+1}=2f_{n}-f_{n-1}, which would correspond to a null > curvature at the boundary. Or the easiest, which is to trim down the > derivative at the boundary by droping the last element for forward > differences, the first for backward differences and both for centered > differences. > > > I am also keen to capture the 3 functions you've made, probably with > > "partial" going into Ufunc, and gaining an options param that has > > "difference" of either "forward", "backward", or "centred", or > > "shrink" using diff2. "div" and "curl" would then "just" be examples > > in the docs. Does anyone see any difficulties with this? Boyd, I don't > > feel this would clash with an Advent posting in any important way, but > > I'm very pleased to hear your thoughts if you disagree :-) > > Would be useful. > > Notice that I assumed the function was defined on a regular grid. If > not, more elaborate schemes would be needed to estimate the centered > derivative. > > Another alternative for finding derivative, which may be useful in > some cases, is to make a Fourier transform of the data, multiply it by > i()*(wavevector) and then transform back. > > Best regards, > Luis > > > > > > Best regards, > > Ed > > > > > -- > > 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 | mo...@fi... /\_/\__/ > GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16 C2DF 5F0A C52B 791E B9EB > |
|
From: Ed . <ej...@ho...> - 2025-01-07 20:31:44
|
Hi Luis and all, Two points: * I've been looking at how Julia does loop fusion, in order to steal ideas; these are now starting to form more concretely, which I think is good! But I also looked up how it does on performance, and learned of a thread where they discussed a benchmark: https://discourse.julialang.org/t/programming-language-benchmark-2/108429 - I'd like us to have a benchmark in that for PDL, does anyone feel like having a go? Boyd? * I've now added a Ufunc::diffcentred (based on Luis's rotate algorithm), and Ufunc::partial; the latter adjusts Luis's work to take an ndarray as first param so it can be a method, and takes instruction on which method to use (centred (default), forward, backward). I'm about to add a PCHIP option too, currently only using https://metacpan.org/pod/PDL::Primitive#pchip_chim, but it would be possible to use pchip_chic which offers more control of boundary conditions. Feedback welcome. Best regards, Ed ________________________________ From: Luis Mochan <mo...@ic...> Sent: 21 November 2024 15:55 To: Ed . <ej...@ho...> Cc: Boyd Duffee <boy...@gm...>; pdl-devel <pdl...@li...>; perldl <pdl...@li...> Subject: Re: [Pdl-devel] curl of vector On Thu, Nov 21, 2024 at 03:09:37PM +0000, Ed . wrote: > Hi Luis, > > Thank you for both the code and the explanation! I was aware of the limitations of diffover for this (including its name - just "diff" caused clashes with Text::Diff in a downstream module). I'm proposing to rename "diffover" to "numdiff" (for numerical differentiation) in the next version of PDL, any objections? However, it just takes the differences between consecutive values. I would call it firstdiff, as there are also second, third, etc. diffs. These are analogous, but not equal, to the corresponding (first, second, etc.) derivatives one find in calculus, and may be used to build approximate derivatives, as in the examples. > I considered using diff2 in my quickly-written prototype, but chose > diffover so as not to shrink the dim by 1. There are other PDL methods that allow the user to specify what to do with the boundaries. Maybe the same should be done here. In my solution the boundary could be kept if the function is periodic, but otherwise, it should be thrown away. Another alternative is to add values beyond the boundary: repeating the boundary value would correspond to a 0 value for the derivative at the boundary. One could also add f_{n+1}=2f_{n}-f_{n-1}, which would correspond to a null curvature at the boundary. Or the easiest, which is to trim down the derivative at the boundary by droping the last element for forward differences, the first for backward differences and both for centered differences. > I am also keen to capture the 3 functions you've made, probably with > "partial" going into Ufunc, and gaining an options param that has > "difference" of either "forward", "backward", or "centred", or > "shrink" using diff2. "div" and "curl" would then "just" be examples > in the docs. Does anyone see any difficulties with this? Boyd, I don't > feel this would clash with an Advent posting in any important way, but > I'm very pleased to hear your thoughts if you disagree :-) Would be useful. Notice that I assumed the function was defined on a regular grid. If not, more elaborate schemes would be needed to estimate the centered derivative. Another alternative for finding derivative, which may be useful in some cases, is to make a Fourier transform of the data, multiply it by i()*(wavevector) and then transform back. Best regards, Luis > > Best regards, > Ed > -- 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 | mo...@fi... /\_/\__/ GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16 C2DF 5F0A C52B 791E B9EB |
|
From: Ed . <ej...@ho...> - 2024-12-31 19:15:40
|
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 <mo...@ic...> Sent: 05 December 2024 14:40 To: Ed . <ej...@ho...> Cc: perldl <pdl...@li...>; perldl <pdl...@li...> 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 | mo...@fi... /\_/\__/ GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16 C2DF 5F0A C52B 791E B9EB |
|
From: Karl G. <kar...@ma...> - 2024-12-28 04:12:18
|
Likewise thank you from me for the opportunity to participate! It is a nice set of neat articles best Karl > On 26 Dec 2024, at 10:15 AM, Christos P Argyropoulos <CAr...@sa...> wrote: > > Boyd and Ed > Thank you for the opportunity to contribute. Merry Christmas ! > > Christos > > Christos Argyropoulos MD, MS, PhD, FASN > Division Chief, Nephrology > Department of Internal Medicine > Lead, Hub Research Capacity > Clinical and Translational Science Center > University of New Mexico School of Medicine > 1 University of New Mexico, > MSC 04-2785 > Albuquerque NM 87131 > Phone: (505) 272-0600 > Fax: (505) 272-0598 > Email: car...@un... > car...@sa... > Linkedin: www.linkedin.com/in/chrisarg/ > BlueSky: @christosargyrop.bsky.social > From: Boyd Duffee <boy...@gm...> > Sent: Wednesday, December 25, 2024 10:22:34 AM > To: perldl <pdl...@li...>; perldl <pdl...@li...>; Ed <ej...@ho...>; DeForest, Craig E. <cra...@sw...>; 諏訪園秀吾 <zvb...@ni...>; Zakariyya Mughal <zak...@gm...>; Christos P Argyropoulos <CAr...@sa...>; Karl Glazebrook <kar...@ma...> > Subject: Advent Calendar Success > > [[-- External - this message has been sent from outside the University --]] > > I'd like to take the time to thank everyone involved in making the PDL Advent Calendar a success this year. The idea came to us late and many people stepped up at short notice. It has helped to promote PDL among the wider Perl community and we have appreciated everyone's efforts. You can see the whole shebang from the link off the main webpage or going to https://pdl.perl.org/advent/ <https://urldefense.com/v3/__https://pdl.perl.org/advent/__;!!KXH1hvEXyw!bQOsvUZcU1ddYOI63_AkKPgA2IGmbVX4HgiXzX3D1g8bcT36HTOqwEXW-LkzFlTp5vRAMMOduz91Bx79ZMqGDHKIuz5kiw$> > > I've seen some good comments in the r/perl subreddit and these posts act as small tutorials that pull new coders in, showing them how PDL can be used to do great things. Our new catchphrase, only half in jest, is "If you do X, you need PDL". > > Thank you to Vikas, JJ, Shugo, Harald, Craig, Zaki, Christos and Karl for getting involved. I've enjoyed the range and depth of topics you've posted and look forward to exploring them further. > > This would never have been possible if Ed hadn't got behind this mad idea, putting up with my Pull Requests and general git-foolishness all the while making a borrowed blogging engine serve our needs. > > Merry Christmas and Happy and Safe Holidays to you all, > Boyd > -- > Boyd Duffee > Lance is an uncommon name nowadays, > but in medieval times people were called Lance a lot. |
|
From: Boyd D. <boy...@gm...> - 2024-12-25 17:22:52
|
I'd like to take the time to thank everyone involved in making the PDL Advent Calendar a success this year. The idea came to us late and many people stepped up at short notice. It has helped to promote PDL among the wider Perl community and we have appreciated everyone's efforts. You can see the whole shebang from the link off the main webpage or going to https://pdl.perl.org/advent/ I've seen some good comments in the r/perl subreddit and these posts act as small tutorials that pull new coders in, showing them how PDL can be used to do great things. Our new catchphrase, only half in jest, is "If you do X, you need PDL". Thank you to Vikas, JJ, Shugo, Harald, Craig, Zaki, Christos and Karl for getting involved. I've enjoyed the range and depth of topics you've posted and look forward to exploring them further. This would never have been possible if Ed hadn't got behind this mad idea, putting up with my Pull Requests and general git-foolishness all the while making a borrowed blogging engine serve our needs. Merry Christmas and Happy and Safe Holidays to you all, Boyd -- Boyd Duffee Lance is an uncommon name nowadays, but in medieval times people were called Lance a lot. |
|
From: Luis M. <mo...@ic...> - 2024-12-10 03:04:56
|
Hi, Thanks for the explanation. Regards, Luis On Tue, Dec 10, 2024 at 02:20:06AM +0000, Ed . wrote: > 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 <mo...@ic...> > Sent: 10 December 2024 2:08 AM > To: perldl <pdl...@li...>; perldl <pdl...@li...> > 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 | mo...@fi... /\_/\__/ > GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16 C2DF 5F0A C52B 791E B9EB > > > _______________________________________________ > pdl-devel mailing list > pdl...@li... > https://lists.sourceforge.net/lists/listinfo/pdl-devel -- 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 | mo...@fi... /\_/\__/ GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16 C2DF 5F0A C52B 791E B9EB |
|
From: Ed . <ej...@ho...> - 2024-12-10 02:20:27
|
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 <mo...@ic...>
Sent: 10 December 2024 2:08 AM
To: perldl <pdl...@li...>; perldl <pdl...@li...>
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 | mo...@fi... /\_/\__/
GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16 C2DF 5F0A C52B 791E B9EB
_______________________________________________
pdl-devel mailing list
pdl...@li...
https://lists.sourceforge.net/lists/listinfo/pdl-devel
|
|
From: Luis M. <mo...@ic...> - 2024-12-10 02:08:42
|
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 | mo...@fi... /\_/\__/
GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16 C2DF 5F0A C52B 791E B9EB
|
|
From: Luis <mo...@ic...> - 2024-12-09 03:19:05
|
----- Forwarded message from Luis Mochán <mo...@fi...> -----
Date: Sun, 08 Dec 2024 20:17:06 -0600
From: Luis Mochán <mo...@fi...>
To: "Ed ." <ej...@ho...>
Subject: Re: approx fails for complex types
User-Agent: K-9 Mail for Android
Hi Ed,
I realized that afterwards, it is a common risk of macro expansions. I
was in some hurry and didn't realize the error in the pr until
now. Thanks for the advice.
Luis
On December 8, 2024 4:14:14 PM CST, "Ed ." <ej...@ho...> wrote:
>Hi Luis,
>
>There's nothing wrong with the expansion of the macro, but there was something wrong with the code I wrote, which was for real types:
>
>value = a * b*b; /* correct */
>
>but for complex values:
>
>value = a * b*b+c*c; /* wrong, I meant a * (b*b+c*c) */
>
>Thank you for the pull request (#507)! I adjusted it to add your new test to the existing tests in t/primitive-misc.t rather than adding a new file. I've also changed it so that the brackets are added only for the complex case.
>
>Notes to all:
>
> *
>if you do add a new file, you need to add it to MANIFEST as well. That was why the PR failed the release tests, which check that everything is either in MANIFEST or is skipped in MANIFEST.SKIP. You can run those yourself locally with RELEASE_TESTING=1 prove -l xt
> *
>if you do make a PR, please check it does in fact pass the CI, which due to the above this didn't.
> *
>when making a PR, please make a new local branch rather than using your master branch - as it is, you'll need to `git reset --hard HEAD^^` to erase your commits before doing a `git pull --rebase` to get my updated ones
>
>Above all those points though, please do make PRs! It's hugely valuable and makes PDL better for everyone. It's only that bearing the above points in mind will make my life a bit easier :-)
>
>I've merged the adjusted PR, and it will be in the next PDL. That shouldn't be too much longer, as I've nearly finished separating out the externally-dependent modules as discussed elsewhere.
>
>Best regards,
>Ed
>
>________________________________
>From: Luis Mochan <mo...@ic...>
>Sent: 08 December 2024 8:03 PM
>To: Ed . <ej...@ho...>
>Cc: pdl-devel <pdl...@li...>; perldl <pdl...@li...>
>Subject: approx fails for complex types
>
>Hi All,
>
>I found a mysterious error when comparing complex types. For instance,
>
> pdl> p approx(i,5*i)
> 1
> pdl> p approx(5*i,i)
> 0
>
>i.e., i is close to 5i (wrong) but 5i is not close to i (correct).
>
>I found a (provisional?) fix, by simply using parenthesis around
> PDL_IF_GENTYPE_REAL(...)
>in Primitive.pd, but I guess the macro would have to be checked and I
>don't know if it might have produced other errors elsewhere.
>
>Best 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 | mo...@fi... /\_/\__/
>GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16 C2DF 5F0A C52B 791E B9EB
--
Enviado desde mi celular; disculpe la horrografía
----- End forwarded message -----
--
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 | mo...@fi... /\_/\__/
GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16 C2DF 5F0A C52B 791E B9EB
|
|
From: Ed . <ej...@ho...> - 2024-12-08 22:14:24
|
Hi Luis,
There's nothing wrong with the expansion of the macro, but there was something wrong with the code I wrote, which was for real types:
value = a * b*b; /* correct */
but for complex values:
value = a * b*b+c*c; /* wrong, I meant a * (b*b+c*c) */
Thank you for the pull request (#507)! I adjusted it to add your new test to the existing tests in t/primitive-misc.t rather than adding a new file. I've also changed it so that the brackets are added only for the complex case.
Notes to all:
*
if you do add a new file, you need to add it to MANIFEST as well. That was why the PR failed the release tests, which check that everything is either in MANIFEST or is skipped in MANIFEST.SKIP. You can run those yourself locally with RELEASE_TESTING=1 prove -l xt
*
if you do make a PR, please check it does in fact pass the CI, which due to the above this didn't.
*
when making a PR, please make a new local branch rather than using your master branch - as it is, you'll need to `git reset --hard HEAD^^` to erase your commits before doing a `git pull --rebase` to get my updated ones
Above all those points though, please do make PRs! It's hugely valuable and makes PDL better for everyone. It's only that bearing the above points in mind will make my life a bit easier :-)
I've merged the adjusted PR, and it will be in the next PDL. That shouldn't be too much longer, as I've nearly finished separating out the externally-dependent modules as discussed elsewhere.
Best regards,
Ed
________________________________
From: Luis Mochan <mo...@ic...>
Sent: 08 December 2024 8:03 PM
To: Ed . <ej...@ho...>
Cc: pdl-devel <pdl...@li...>; perldl <pdl...@li...>
Subject: approx fails for complex types
Hi All,
I found a mysterious error when comparing complex types. For instance,
pdl> p approx(i,5*i)
1
pdl> p approx(5*i,i)
0
i.e., i is close to 5i (wrong) but 5i is not close to i (correct).
I found a (provisional?) fix, by simply using parenthesis around
PDL_IF_GENTYPE_REAL(...)
in Primitive.pd, but I guess the macro would have to be checked and I
don't know if it might have produced other errors elsewhere.
Best 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 | mo...@fi... /\_/\__/
GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16 C2DF 5F0A C52B 791E B9EB
|
|
From: Luis M. <mo...@ic...> - 2024-12-08 20:04:04
|
Hi All,
I found a mysterious error when comparing complex types. For instance,
pdl> p approx(i,5*i)
1
pdl> p approx(5*i,i)
0
i.e., i is close to 5i (wrong) but 5i is not close to i (correct).
I found a (provisional?) fix, by simply using parenthesis around
PDL_IF_GENTYPE_REAL(...)
in Primitive.pd, but I guess the macro would have to be checked and I
don't know if it might have produced other errors elsewhere.
Best 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 | mo...@fi... /\_/\__/
GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16 C2DF 5F0A C52B 791E B9EB
|
|
From: Ed . <ej...@ho...> - 2024-12-07 14:11:10
|
Hi Karl, For an immediate answer: take a look in git master's Changes file plus anything still in the Libtmp directory. Everything that was in IO or Graphics has either been moved into Basic (and is therefore staying in, including IO::FITS and IO::Misc), or is shown in Changes and has been removed and released as a separate distro. To see the new file/directory layout, look in Basic/lib - all modules, including PP ones, are in their obvious location, such as lib/PDL/Primitive.pd - one benefit of this is it allows parallel builds, as already mentioned. The only potential exception to the above is PDL::Func, if I can find/port in a reasonable time to C an implementation of PCHIP and [M]AKIMA. Relying on Fortran stuff is an external dependency which will be ceasing. Best regards, Ed ________________________________ From: Karl Glazebrook <kar...@ma...> Sent: 07 December 2024 8:21 AM To: Ed . <ej...@ho...> Cc: David Mertens <dcm...@gm...>; Jörg Sommrey <jo...@so...>; pdl-devel <pdl...@li...>; perldl <pdl...@li...> Subject: Re: [Pdl-general] [Pdl-devel] PDL disappeared from CPAN? Is there a full list of the modules to be split off? Karl On 4 Dec 2024, at 9:16 AM, Ed . <ej...@ho...> wrote: Hi all, This is due to a known problem in MetaCPAN the website (not CPAN as a whole). It's triggered here by me releasing modules as independent distributions that are currently part of the PDL distro (such as PDL::Transform::Proj4); when MetaCPAN sees such a new release, it de-indexes the distro that package was in before, which here is the whole of PDL. See https://github.com/metacpan/metacpan-web/issues/3245 for more context. This should cease to be an issue once I have finished releasing all the contained non-fundamental parts of PDL (which is many, many of them) especially the ones with external dependencies (GSL, Proj4, HDF, GD, OpenGL, the Fortran ones, among others). Shortly after that, I will release the new, slimmed-down PDL. You may see a resemblance between this and the previously (in 2015 and onwards) discussed splitting of PDL into a PDL::Core, other parts, and then a rump PDL. I feel this is a better approach, particularly since those externally-dependent modules could not actually be relied on since you might install PDL without e.g. GSL; to get PDL with GSL, you'd need to reinstall the whole of PDL again and hope for the best. What this means for users of PDL is currently that, as previously, if you make code that needs certain parts of "main" PDL (like the GSL bindings), you need to express this in the metadata of your project. What it will mean when the process is finished, is that PDL will install (much) quicker, and that to get those other modules, you expressly install them, and they will install very quickly (on one device here, Transform::Proj4 builds and tests in about 2 secs, and PDL::GSL in about 10). Any questions or problems, please let me know (possibly on the list)! Best regards, Ed ________________________________ From: David Mertens <dcm...@gm...<mailto:dcm...@gm...>> Sent: 03 December 2024 2:22 PM To: Jörg Sommrey <jo...@so...<mailto:jo...@so...>>; pdl-devel <pdl...@li...<mailto:pdl...@li...>> Subject: Re: [Pdl-devel] PDL disappeared from CPAN? Fyi, this was resolved. I just realized I forgot to CC-all on my reply, so I'm sending this back to the mailing list. David On Tue, Dec 3, 2024, 8:21 AM Jörg Sommrey <jo...@so...<mailto:jo...@so...>> wrote: Probably a transient malfunction on CPAN. Searching CPAN for "PDL" produced some hits, but not including "PDL" or "PDL::Core". Accessing https://metacpan.org/pod/PDL::Core etc. resulted in a 404 error page. Looks like everything is back now. -jo On Tue 03 Dec 2024 01:58:30 PM CET, David Mertens <dcm...@gm...<mailto:dcm...@gm...>> wrote: > I have no trouble locating PDL on metacpan, and from there the > documentation links all work. Googling PDL::Core pulls up meetacpan link as > the first hit. > > Do you mean metacpan or the CPAN client? > > David > > On Tue, Dec 3, 2024, 5:12 AM Jörg Sommrey <jo...@so...<mailto:jo...@so...>> wrote: > >> Hi all, >> >> what happened to PDL on CPAN? Cannot see any of the core modules anymore. >> >> -jo >> >> >> _______________________________________________ >> pdl-devel mailing list >> pdl...@li...<mailto:pdl...@li...> >> https://lists.sourceforge.net/lists/listinfo/pdl-devel >> _______________________________________________ pdl-general mailing list pdl...@li...<mailto:pdl...@li...> https://lists.sourceforge.net/lists/listinfo/pdl-general |
|
From: Karl G. <kar...@ma...> - 2024-12-07 08:41:50
|
Is there a full list of the modules to be split off? Karl > On 4 Dec 2024, at 9:16 AM, Ed . <ej...@ho...> wrote: > > Hi all, > > This is due to a known problem in MetaCPAN the website (not CPAN as a whole). It's triggered here by me releasing modules as independent distributions that are currently part of the PDL distro (such as PDL::Transform::Proj4); when MetaCPAN sees such a new release, it de-indexes the distro that package was in before, which here is the whole of PDL. > > See https://github.com/metacpan/metacpan-web/issues/3245 for more context. > > This should cease to be an issue once I have finished releasing all the contained non-fundamental parts of PDL (which is many, many of them) especially the ones with external dependencies (GSL, Proj4, HDF, GD, OpenGL, the Fortran ones, among others). Shortly after that, I will release the new, slimmed-down PDL. > > You may see a resemblance between this and the previously (in 2015 and onwards) discussed splitting of PDL into a PDL::Core, other parts, and then a rump PDL. I feel this is a better approach, particularly since those externally-dependent modules could not actually be relied on since you might install PDL without e.g. GSL; to get PDL with GSL, you'd need to reinstall the whole of PDL again and hope for the best. > > What this means for users of PDL is currently that, as previously, if you make code that needs certain parts of "main" PDL (like the GSL bindings), you need to express this in the metadata of your project. What it will mean when the process is finished, is that PDL will install (much) quicker, and that to get those other modules, you expressly install them, and they will install very quickly (on one device here, Transform::Proj4 builds and tests in about 2 secs, and PDL::GSL in about 10). > > Any questions or problems, please let me know (possibly on the list)! > > Best regards, > Ed > > From: David Mertens <dcm...@gm... <mailto:dcm...@gm...>> > Sent: 03 December 2024 2:22 PM > To: Jörg Sommrey <jo...@so... <mailto:jo...@so...>>; pdl-devel <pdl...@li... <mailto:pdl...@li...>> > Subject: Re: [Pdl-devel] PDL disappeared from CPAN? > > Fyi, this was resolved. I just realized I forgot to CC-all on my reply, so I'm sending this back to the mailing list. > > David > > On Tue, Dec 3, 2024, 8:21 AM Jörg Sommrey <jo...@so... <mailto:jo...@so...>> wrote: > Probably a transient malfunction on CPAN. Searching CPAN for "PDL" > produced some hits, but not including "PDL" or "PDL::Core". Accessing > https://metacpan.org/pod/PDL::Core etc. resulted in a 404 error page. > > Looks like everything is back now. > > -jo > > > On Tue 03 Dec 2024 01:58:30 PM CET, David Mertens > <dcm...@gm... <mailto:dcm...@gm...>> wrote: > > > I have no trouble locating PDL on metacpan, and from there the > > documentation links all work. Googling PDL::Core pulls up meetacpan link as > > the first hit. > > > > Do you mean metacpan or the CPAN client? > > > > David > > > > On Tue, Dec 3, 2024, 5:12 AM Jörg Sommrey <jo...@so... <mailto:jo...@so...>> wrote: > > > >> Hi all, > >> > >> what happened to PDL on CPAN? Cannot see any of the core modules anymore. > >> > >> -jo > >> > >> > >> _______________________________________________ > >> pdl-devel mailing list > >> pdl...@li... <mailto:pdl...@li...> > >> https://lists.sourceforge.net/lists/listinfo/pdl-devel > >> > > > _______________________________________________ > pdl-general mailing list > pdl...@li... <mailto:pdl...@li...> > https://lists.sourceforge.net/lists/listinfo/pdl-general |
|
From: Luis M. <mo...@ic...> - 2024-12-05 14:40:17
|
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 | mo...@fi... /\_/\__/
GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16 C2DF 5F0A C52B 791E B9EB
|
|
From: Ed . <ej...@ho...> - 2024-12-05 07:15:53
|
Hi Luis,
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.
More conceptually, I feel that LAPACK bindings should not make copies of their inputs, that is for higher-level wrappings to do. In your case I believe that's in Photonic::Util?
Best regards,
Ed
________________________________
From: Luis Mochan <mo...@ic...>
Sent: 04 December 2024 11:54 PM
To: perldl <pdl...@li...>; perldl <pdl...@li...>
Subject: [Pdl-devel] cgtsv
Hi,
I use the routine
PDL::LinearAlgebra::Complex::cgtsv
to solve systems of linear equations described by a tridiagonal
matrix. The arguments are the sub-diagonal, the diagonal, the
supradiagonal and the right hand side of the equations. I found one of
my programs has a misterious error, as it uses cgtsv to solve a
symmetric tridiagonal system,
my $sub_diagonal=my $supra_diagonal;
cgstv($sub_diagonal, $diagonal, $supra_diagonal, $right_hand_side);
I didn't realize until today that cgstv modified the contents of the
$sub_diagonal array, and thus, it silently and erroneously modified the
$supra_diagonal, which in my case was an ndarray that shared the
numerical data.
The signature of the function is:
cgtsv
Signature: (complex [phys]DL(n);complex [phys]D(n);complex [phys]DU(n);complex [io,phys]B(n,nrhs); int [o,phys]info())
As the parameter 'DL' is not marked 'io' I erroneously assumed it wouldn't be
modified, although the documentations states further down that it
does.
My questions are: Is the signature above correct? Should parameters
that are modified be marked 'io' or something else? Or would it be better
for routines such as cgtsv to make a copy of their inputs to avoid
modifying the original arguments? Would it be considered too costly in
general?
Best 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 | mo...@fi... /\_/\__/
GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16 C2DF 5F0A C52B 791E B9EB
_______________________________________________
pdl-devel mailing list
pdl...@li...
https://lists.sourceforge.net/lists/listinfo/pdl-devel
|
|
From: Luis M. <mo...@ic...> - 2024-12-04 23:54:10
|
Hi,
I use the routine
PDL::LinearAlgebra::Complex::cgtsv
to solve systems of linear equations described by a tridiagonal
matrix. The arguments are the sub-diagonal, the diagonal, the
supradiagonal and the right hand side of the equations. I found one of
my programs has a misterious error, as it uses cgtsv to solve a
symmetric tridiagonal system,
my $sub_diagonal=my $supra_diagonal;
cgstv($sub_diagonal, $diagonal, $supra_diagonal, $right_hand_side);
I didn't realize until today that cgstv modified the contents of the
$sub_diagonal array, and thus, it silently and erroneously modified the
$supra_diagonal, which in my case was an ndarray that shared the
numerical data.
The signature of the function is:
cgtsv
Signature: (complex [phys]DL(n);complex [phys]D(n);complex [phys]DU(n);complex [io,phys]B(n,nrhs); int [o,phys]info())
As the parameter 'DL' is not marked 'io' I erroneously assumed it wouldn't be
modified, although the documentations states further down that it
does.
My questions are: Is the signature above correct? Should parameters
that are modified be marked 'io' or something else? Or would it be better
for routines such as cgtsv to make a copy of their inputs to avoid
modifying the original arguments? Would it be considered too costly in
general?
Best 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 | mo...@fi... /\_/\__/
GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16 C2DF 5F0A C52B 791E B9EB
|
|
From: Boyd D. <boy...@gm...> - 2024-12-04 21:44:52
|
I'm not sure if we've made it to Randall Munroe's advent calendar[0], but PDL has made it to Advent Planet[1] and Perl Weekly. You can check it out at https://pdl.perl.org/advent/ We still have room for anyone to write a short blog post about how and why they use PDL. The more people that come forward, the better it looks and it's an easy way to bring attention to your work with minimal effort. I've quite enjoyed the posts already submitted and am looking forward to seeing the ones in progress. We've been tracking suggestions and discussions on https://github.com/PDLPorters/pdl/issues/503 Please think about getting involved. It's great exposure for PDL and helps expand the points of entry for people coming to the project. thanks, Boyd [0] https://xkcd.com/3019/ [1] https://lenjaffe.com/AdventPlanet/ -- Boyd Duffee Lance is an uncommon name nowadays, but in medieval times people were called Lance a lot. |
