Re: [Pdl-general] Plotting flat xyz data as an image.

[Luis Mochan]

If your data is defined on a regular x-y grid you could reshape it to
a 2D array, as in

 gplot(with=>'image',$x->reshape($n,$m), $y->reshape($n,$m), $z->reshape($n,$m))

with $n and $m the number of pixels along x and along y. If the x-y
data is irregular but almost on a grid, you could use

 gplot({trid=>1, view=>'map'},with=>'pm3d',$x->reshape($n,$m),
 $y->reshape($n,$m), $z->reshape($n,$m))

For example, the attached image was produced with

   $x=xvals(10,10)+random(10,10);
   $y=yvals(10,10)+random(10,10);
   $z=rvals(10,10);
   gplot({trid=>1, view=>'map'},with=>'pm3d',$x, $y, $z);

Regards,
Luis


On Thu, Apr 18, 2024 at 02:19:29PM -0700, Jovan Trujillo wrote:
> If you look at my example code it shows that the Excel data basically has
> the coordinates flattened to a list:
>
> my $x = flat(xvals(10,10)); # This is basically how x-coordinates are
> output from my machine.
> my $y = flat(yvals(10,10)); # Same format as x-coordinates
> my $z = sequence(100)*rand(1); # Some dummy data for this example.
>
> This is just an example to show the structure of the data coming in. A
> sample of the data in the Excel file looks like this:
>
> X (um) Y (um) R (Ohms/sq)
> 174466.6 148753.6 3.205395
> 174438.8 149112.8 2.041845
> 174410.4 149471.7 2.192256
> 174382.7 149830.3 2.345829
> 174354.9 150189.4 2.256398
> 174326.8 150548.4 2.134265
> 174299.2 150907.4 2.360153
> 174271.1 151265.9 2.303999
> 174243.3 151624.9 2.437044
> 174215.4 151983.8 2.454804
> 174187.4 152343 2.407471
> 174159.6 152701.7 2.339043
> 174131.5 153060.5 2.363042
> 174103.9 153419.6 2.399614
> 174075.8 153778.4 2.352736
> 174047.8 154137.4 2.267724
> 174020.1 154496.3 2.219654
> 173992.3 154855.3 2.157816
>
>
>
> I have parsed that data into $x, $y, and $z but $z needs to be mapped into
> an N x N matrix for image plotting using the coordinates given in $x and
> $y. The machine walks along Y and then steps to the next X coordinate when
> it reaches the end of Y. All points in X and Y are expected to be unique. I
> need to create the matrix using zeroes(N,N) since I know how many points I
> took in X and Y, and then create a sequence that interpolates $x and $y
> into matrix index values. Then use matching to know where in the matrix the
> $z values belong. If there is something built into PDL to do that let me
> know.
>
> I hope this helps clarify the problem.
>
> Thanks,
> Jovan
>
> On Thu, Apr 18, 2024 at 1:35 PM David Mertens 
> wrote:
>
> > Hello Jovan,
> >
> > Did you try this?
> > my $z = sequence(10,10)*rand(1);
> >
> > Seems to me you just need a z-value pdl that has the same dimensions as
> > the x and y coordinates.
> >
> > David
> >
> > On Thu, Apr 18, 2024, 1:11 PM Jovan Trujillo 
> > wrote:
> >
> >> Hi Greg,
> >> Yes, I've been looking into a heat map or flattened 3d scatterplot. In
> >> Mathematica, I can easily import the Excel spreadsheet and plot using
> >> ListDensityPlot to give me a nice high-resolution image of the data.
> >>
> >> But my question is simply a mapping problem. If I have two piddles with
> >> $x and $y coordinates and a third representing the $data, how do I create a
> >> $matrix that maps the $data based on the coordinates from $x and $y? If I
> >> had $matrix I can simply plot image($matrix) with PDL::Graphics::Gnuplot.
> >>
> >> Thank you,
> >> Jovan
> >>
> >> On Thu, Apr 18, 2024 at 1:16 AM Grégory Vanuxem 
> >> wrote:
> >>
> >>> Hello,
> >>>
> >>> I haven’t carefully looked at your problem with GNUPlot but I wonder if
> >>> what you are trying to achieve could not be done with surface routines,
> >>> that’s with 3d ones ? Or maybe something like heatmap like this question:
> >>>
> >>>
> >>> https://stackoverflow.com/questions/76577557/trying-to-create-heat-map-using-ggplot-similar-to-density-contour-plot-but-wh
> >>>
> >>> Just to give some hints on possible routines.
> >>>
> >>> - Greg
> >>>
> >>> Le jeu. 18 avr. 2024 à 01:53, Jovan Trujillo 
> >>> a écrit :
> >>>
>  Hi all,
> 
>  I've been wracking my brain all morning trying to figure this out, but
>  how could I convert a set of 3 1D piddles containing xyz data into a 
>  matrix
>  for plotting as an image using PDL::Graphics::Gnuplot? Say for example:
> 
>  use PDL;
>  use PDL::Graphics::Gnuplot qw/image gplot/;
> 
>  my $x = flat(xvals(10,10)); # This is basically how x-coordinates are
>  output from my machine.
>  my $y = flat(yvals(10,10)); # Same format as x-coordinates
>  my $z = sequence(100)*rand(1); # Some dummy data for this example.
> 
>  my $image; # How do I map $x,$y,$z into this 10x10 $image piddle?
>  image($image);
> 
>  That's my basic problem. How do I map $x,$y,$z data into an $image
>  matrix?
> 
>  Thank you,
>  Jovan
>  ___
>  pdl-general mailing list
>  pdl-general@lists.sourceforge.net
>  https://lists.sourceforge.net/lists/listinfo/pdl-general
> 
> >>> 

Re: [Pdl-general] [Pdl-devel] naming conventions

[Luis Mochan]

On Tue, Jan 30, 2024 at 09:40:59PM -0600, Luis Mochan wrote:
> ...>
> On Mon, Jan 29, 2024 at 10:19:56PM -0500, David Mertens wrote:
> > Hello Luis,
> >
> > Ever crafty, Perl gives you another way to solve this. You could put your
> > functions under another name space and invoke them by explicitly naming the
> > package and function. For example, if you have a function "do_it" in
> > package MY, you could invoke it as
> >
> > $pdl->MY::do_it(...args...)
> >

Found another alternative, as in:
my $f=sub($x){$x**2}; #or $f=sub{$_[0]**2};
print sequence(10)->$f;
Curiously, it works in general but not the sub($x){...} in the pdl REPL.


-- 

  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-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

Re: [Pdl-devel] naming conventions

[Luis Mochan]

On Tue, Jan 30, 2024 at 09:40:59PM -0600, Luis Mochan wrote:
> ...>
> On Mon, Jan 29, 2024 at 10:19:56PM -0500, David Mertens wrote:
> > Hello Luis,
> >
> > Ever crafty, Perl gives you another way to solve this. You could put your
> > functions under another name space and invoke them by explicitly naming the
> > package and function. For example, if you have a function "do_it" in
> > package MY, you could invoke it as
> >
> > $pdl->MY::do_it(...args...)
> >

Found another alternative, as in:
my $f=sub($x){$x**2}; #or $f=sub{$_[0]**2};
print sequence(10)->$f;
Curiously, it works in general but not the sub($x){...} in the pdl REPL.


-- 

  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

Re: [Pdl-devel] RESEND: Change in xvals/yvals/zvals behavior

[Luis Mochan]

On Tue, Jan 30, 2024 at 04:25:40AM +, Ed . wrote:
> Hi Diab,
>
> PDL 2.085 has just been released,...
> ...

Great!

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

Re: [Pdl-devel] naming conventions

[Luis Mochan]

Nice! I was not aware that Perl allowed calling a method from an unrelated
package (if you take the risk). Thanks!
Regards,
Luis



On Mon, Jan 29, 2024 at 10:19:56PM -0500, David Mertens wrote:
> Hello Luis,
>
> Ever crafty, Perl gives you another way to solve this. You could put your
> functions under another name space and invoke them by explicitly naming the
> package and function. For example, if you have a function "do_it" in
> package MY, you could invoke it as
>
> $pdl->MY::do_it(...args...)
>
> For brevity you would do well to choose a short-named top-level namespace.
> This of course runs the possibility of conflicting with other things, but
> it is very unlikely to conflict with PDL since PDL doesn't put stuff
> outside of its namespace. (Except for PDL::Graphics::Prima, which follows
> the Prima convention of putting certain groupings of constants/functions in
> top-level namespaces to avoid import/export craziness. Of course, if you
> use PDL::Graphics::Prima, you already know about them, and if you don't, it
> doesn't matter.) Here's a complete (non-PDL-specific) working example
> illustrating the basic idea:
>
> %<
> use strict;
> use warnings;
>
> package foo;
>
> sub new {
> my ($class, %values) = @_;
> return bless \%values, $class;
> }
>
> sub hello {
> my ($self) = @_;
> my $name = $self->{name} // '(no name)';
> print "Hello from $name\n";
> }
>
> package alpha;
>
> sub beta_speak {
> my $self = shift;
> print "Beta speak alpha!\n";
> $self->hello;
> }
>
> package main;
>
> my $thing = foo->new(name => 'elgar');
>
> print "hello() method\n";
> $thing->hello;
> print "alpha::beta_speak\n";
> $thing->alpha::beta_speak;
>
> print "All done!\n";
> >%
>
> David
>
> On Sun, Jan 28, 2024 at 12:21 PM Luis Mochan  wrote:
>
> > Thanks!
> >
> > Regards,
> > Luis
> >
> > On Sun, Jan 28, 2024 at 04:25:27PM +, Ed . wrote:
> > > Hi Luis,
> > >
> > > This is a long-standing issue in PDL. If your code creates a
> > PDL::somefunction, there is indeed a risk that someone else’s code also
> > makes a PDL::somefunction, and there will be a problem. Using “warnings” in
> > both modules will at least tell you it happened.
> > >
> > > A way to dodge this is to make a subclass of PDL called e.g. PDL::Other
> > that all your code’s objects are in, and instead make
> > PDL::Other::somefunction. You’d create objects with
> > PDL::Other->new(@args_as_normal). This is tested in t/subclass.t and ought
> > to work, including that any operations’ results will also be in that
> > subclass. If you try it and find any surprises, please say so on here! Then
> > I can capture that into t/subclass.t and fix it.
> > >
> > > Best regards,
> > > Ed
> > >
> > > 
> > > From: Luis Mochan 
> > > Sent: Sunday, January 28, 2024 2:41:27 PM
> > > To: perldl ; perldl <
> > pdl-devel@lists.sourceforge.net>
> > > Subject: [Pdl-devel] naming conventions
> > >
> > > Hi,
> > > It is sometimes convenient to call my own functions that operate on
> > ndarrays
> > > using the object notation: $ndarray->somefunction. A simple way to do
> > > it is to define the function within the PDL name space as in
> > >sub PDL::somefunction($self,...){...}
> > > Is there a better way? Adding functions to a package as a user of that
> > > package is risky as there might be a name collision with internal
> > > functions actually defined within the PDL packages. Is there a naming
> > > convention in PDL to avoid the collision? I vaguely recall there are
> > > some subtleties if one wants to make new classes derived from PDL.
> > > 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
> > > p

Re: [Pdl-general] [Pdl-devel] naming conventions

[Luis Mochan]

Nice! I was not aware that Perl allowed calling a method from an unrelated
package (if you take the risk). Thanks!
Regards,
Luis



On Mon, Jan 29, 2024 at 10:19:56PM -0500, David Mertens wrote:
> Hello Luis,
>
> Ever crafty, Perl gives you another way to solve this. You could put your
> functions under another name space and invoke them by explicitly naming the
> package and function. For example, if you have a function "do_it" in
> package MY, you could invoke it as
>
> $pdl->MY::do_it(...args...)
>
> For brevity you would do well to choose a short-named top-level namespace.
> This of course runs the possibility of conflicting with other things, but
> it is very unlikely to conflict with PDL since PDL doesn't put stuff
> outside of its namespace. (Except for PDL::Graphics::Prima, which follows
> the Prima convention of putting certain groupings of constants/functions in
> top-level namespaces to avoid import/export craziness. Of course, if you
> use PDL::Graphics::Prima, you already know about them, and if you don't, it
> doesn't matter.) Here's a complete (non-PDL-specific) working example
> illustrating the basic idea:
>
> %<
> use strict;
> use warnings;
>
> package foo;
>
> sub new {
> my ($class, %values) = @_;
> return bless \%values, $class;
> }
>
> sub hello {
> my ($self) = @_;
> my $name = $self->{name} // '(no name)';
> print "Hello from $name\n";
> }
>
> package alpha;
>
> sub beta_speak {
> my $self = shift;
> print "Beta speak alpha!\n";
> $self->hello;
> }
>
> package main;
>
> my $thing = foo->new(name => 'elgar');
>
> print "hello() method\n";
> $thing->hello;
> print "alpha::beta_speak\n";
> $thing->alpha::beta_speak;
>
> print "All done!\n";
> >%
>
> David
>
> On Sun, Jan 28, 2024 at 12:21 PM Luis Mochan  wrote:
>
> > Thanks!
> >
> > Regards,
> > Luis
> >
> > On Sun, Jan 28, 2024 at 04:25:27PM +, Ed . wrote:
> > > Hi Luis,
> > >
> > > This is a long-standing issue in PDL. If your code creates a
> > PDL::somefunction, there is indeed a risk that someone else’s code also
> > makes a PDL::somefunction, and there will be a problem. Using “warnings” in
> > both modules will at least tell you it happened.
> > >
> > > A way to dodge this is to make a subclass of PDL called e.g. PDL::Other
> > that all your code’s objects are in, and instead make
> > PDL::Other::somefunction. You’d create objects with
> > PDL::Other->new(@args_as_normal). This is tested in t/subclass.t and ought
> > to work, including that any operations’ results will also be in that
> > subclass. If you try it and find any surprises, please say so on here! Then
> > I can capture that into t/subclass.t and fix it.
> > >
> > > Best regards,
> > > Ed
> > >
> > > 
> > > From: Luis Mochan 
> > > Sent: Sunday, January 28, 2024 2:41:27 PM
> > > To: perldl ; perldl <
> > pdl-de...@lists.sourceforge.net>
> > > Subject: [Pdl-devel] naming conventions
> > >
> > > Hi,
> > > It is sometimes convenient to call my own functions that operate on
> > ndarrays
> > > using the object notation: $ndarray->somefunction. A simple way to do
> > > it is to define the function within the PDL name space as in
> > >sub PDL::somefunction($self,...){...}
> > > Is there a better way? Adding functions to a package as a user of that
> > > package is risky as there might be a name collision with internal
> > > functions actually defined within the PDL packages. Is there a naming
> > > convention in PDL to avoid the collision? I vaguely recall there are
> > > some subtleties if one wants to make new classes derived from PDL.
> > > 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
> > > p

Re: [Pdl-general] [Pdl-devel] RESEND: Change in xvals/yvals/zvals behavior

[Luis Mochan]

On Tue, Jan 30, 2024 at 04:25:40AM +, Ed . wrote:
> Hi Diab,
>
> PDL 2.085 has just been released,...
> ...

Great!

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-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

Re: [Pdl-devel] naming conventions

[Luis Mochan]

Thanks!

Regards,
Luis

On Sun, Jan 28, 2024 at 04:25:27PM +, Ed . wrote:
> Hi Luis,
>
> This is a long-standing issue in PDL. If your code creates a 
> PDL::somefunction, there is indeed a risk that someone else’s code also makes 
> a PDL::somefunction, and there will be a problem. Using “warnings” in both 
> modules will at least tell you it happened.
>
> A way to dodge this is to make a subclass of PDL called e.g. PDL::Other that 
> all your code’s objects are in, and instead make PDL::Other::somefunction. 
> You’d create objects with PDL::Other->new(@args_as_normal). This is tested in 
> t/subclass.t and ought to work, including that any operations’ results will 
> also be in that subclass. If you try it and find any surprises, please say so 
> on here! Then I can capture that into t/subclass.t and fix it.
>
> Best regards,
> Ed
>
> 
> From: Luis Mochan 
> Sent: Sunday, January 28, 2024 2:41:27 PM
> To: perldl ; perldl 
> 
> Subject: [Pdl-devel] naming conventions
>
> Hi,
> It is sometimes convenient to call my own functions that operate on ndarrays
> using the object notation: $ndarray->somefunction. A simple way to do
> it is to define the function within the PDL name space as in
>sub PDL::somefunction($self,...){...}
> Is there a better way? Adding functions to a package as a user of that
> package is risky as there might be a name collision with internal
> functions actually defined within the PDL packages. Is there a naming
> convention in PDL to avoid the collision? I vaguely recall there are
> some subtleties if one wants to make new classes derived from PDL.
> 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

-- 

  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

Re: [Pdl-general] [Pdl-devel] naming conventions

[Luis Mochan]

Thanks!

Regards,
Luis

On Sun, Jan 28, 2024 at 04:25:27PM +, Ed . wrote:
> Hi Luis,
>
> This is a long-standing issue in PDL. If your code creates a 
> PDL::somefunction, there is indeed a risk that someone else’s code also makes 
> a PDL::somefunction, and there will be a problem. Using “warnings” in both 
> modules will at least tell you it happened.
>
> A way to dodge this is to make a subclass of PDL called e.g. PDL::Other that 
> all your code’s objects are in, and instead make PDL::Other::somefunction. 
> You’d create objects with PDL::Other->new(@args_as_normal). This is tested in 
> t/subclass.t and ought to work, including that any operations’ results will 
> also be in that subclass. If you try it and find any surprises, please say so 
> on here! Then I can capture that into t/subclass.t and fix it.
>
> Best regards,
> Ed
>
> 
> From: Luis Mochan 
> Sent: Sunday, January 28, 2024 2:41:27 PM
> To: perldl ; perldl 
> 
> Subject: [Pdl-devel] naming conventions
>
> Hi,
> It is sometimes convenient to call my own functions that operate on ndarrays
> using the object notation: $ndarray->somefunction. A simple way to do
> it is to define the function within the PDL name space as in
>sub PDL::somefunction($self,...){...}
> Is there a better way? Adding functions to a package as a user of that
> package is risky as there might be a name collision with internal
> functions actually defined within the PDL packages. Is there a naming
> convention in PDL to avoid the collision? I vaguely recall there are
> some subtleties if one wants to make new classes derived from PDL.
> 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-de...@lists.sourceforge.net
> 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  | moc...@fis.unam.mx   /\_/\__/
GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16  C2DF 5F0A C52B 791E B9EB


___
pdl-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

[Pdl-general] naming conventions

[Luis Mochan]

Hi,
It is sometimes convenient to call my own functions that operate on ndarrays
using the object notation: $ndarray->somefunction. A simple way to do
it is to define the function within the PDL name space as in
   sub PDL::somefunction($self,...){...}
Is there a better way? Adding functions to a package as a user of that
package is risky as there might be a name collision with internal
functions actually defined within the PDL packages. Is there a naming
convention in PDL to avoid the collision? I vaguely recall there are
some subtleties if one wants to make new classes derived from PDL.
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-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

[Pdl-devel] naming conventions

[Luis Mochan]

Hi,
It is sometimes convenient to call my own functions that operate on ndarrays
using the object notation: $ndarray->somefunction. A simple way to do
it is to define the function within the PDL name space as in
   sub PDL::somefunction($self,...){...}
Is there a better way? Adding functions to a package as a user of that
package is risky as there might be a name collision with internal
functions actually defined within the PDL packages. Is there a naming
convention in PDL to avoid the collision? I vaguely recall there are
some subtleties if one wants to make new classes derived from PDL.
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

Re: [Pdl-general] Changes I noted PDL2.025 -> PDL2.084 - PDL::NiceSlice issue

[Luis Mochan]

I found some time back problems with NiceSlice. Actually, with
Filter::Simple (used by default by NiceSlice, though it can use other
options, controlled with environment variables). I vaguely recall that
two slashes, as in two divisions consecutive, confuse it completely,
as they seem as regular expression.

I found this in my notes of 2022-11-05:
---
Make a filter:
  package MyFilter;
  use v5.36;
  use Filter::Simple;
  FILTER_ONLY
  code_no_comments => sub { say "Code:\n$_" },
  all => sub { say "All:\n$_" };
  1;
And a program:
  use v5.36;
  use lib ".";
  use MyFilter;
  my $x=1;
  say $x/2/3;

Execution yields:

  Code:
  my $x=1;
  say $x3;

  All:
  my $x=1;
  say $x/2/3;

  0.167

This means that /2/ is removed incorrectly. The name of the variable
($x and not $y) seems important.
---

Regards,
Luis




On Sun, Jan 07, 2024 at 12:01:27PM +1100, Karl Glazebrook via pdl-general wrote:
>
>
> > On 7 Jan 2024, at 11:55 am, Karl Glazebrook via pdl-general 
> >  wrote:
> >
> > (The mismatch of line numbers seems to be related to the use of hereto text 
> > earlier in the code, the debugger shows different line numbers)
> >
>
>
> PS just to prove this point given the line numbers issue:
>
>
>
>
> syntax error at /Users/karl/Software/perl/KGB/Redshift.pm line 251, near 
> "$FOO("
> Execution of /Users/karl/Software/perl/KGB/Redshift.pm aborted due to 
> compilation errors.
>
>
>
> You can see FOO triggers a compilation error and BAR does not, use 
> PDL::NiceSlice is way at the top of the module
>
> Karl
>


> ___
> pdl-general mailing list
> pdl-general@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/pdl-general


-- 

  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-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

Re: [Pdl-general] Changes I noted PDL2.025 -> PDL2.084 - rcols issue

[Luis Mochan]

I was able to reproduce it, and I don't understand it. Median, min,
max fail even after printing the updated $x, as if there were to
different variables $x.

On Sun, Jan 07, 2024 at 11:26:56AM +1100, Karl Glazebrook via pdl-general wrote:
> Hi all,
>
> This dinosaur just upgraded from PDL v2.025 to v.2.084 (yes, I know that is 
> lame)
>
> I noticed a few things when running one of my complicated codes, I will start 
> seperate email threads
>
> First there seems to be a serious rcols bug:
>
>
> e.g. create a file
>
> # tmp.dat
> 1
> 2
> 3
> 4
>
>
> Loaded PDL v2.084 (supports bad values)
> pdl> $x = rcols 'tmp.dat'
> Reading data into ndarrays of type: [ Double ]
> Read in  4  elements.
>
> pdl> p $x
> [1 2 3 4]
> pdl> $x *= 100
>
> pdl> p $x
> [100 200 300 400]
> pdl> p median($x)
> 0
> pdl> p $x
> [100 200 300 400]
>
>
> It seems the median function sees the values BEFORE the inplace 
> multiplacation, whereas print does not. This is very bad. min() and max() are 
> similar. No idea what is going on here! The behaviour or absent from v2.025
>
> Notes
> - making a $x->copy() removes the effect
> - creating $x using sequence also removes, so it is something to do with 
> rcols() and not inplace in general?
>
> I’d be interested to know if others can reproduce this. It definitely needs a 
> fix
>
> best
>
> Karl
>
>
>


> ___
> pdl-general mailing list
> pdl-general@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/pdl-general


-- 

  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-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

Re: [Pdl-general] Changes I noted PDL2.025 -> PDL2.084 - rcols issue

[Luis Mochan]

I noticed that medover and maxover do work as expected in this case.


On Sun, Jan 07, 2024 at 11:26:56AM +1100, Karl Glazebrook via pdl-general wrote:
> Hi all,
>
> This dinosaur just upgraded from PDL v2.025 to v.2.084 (yes, I know that is 
> lame)
>
> I noticed a few things when running one of my complicated codes, I will start 
> seperate email threads
>
> First there seems to be a serious rcols bug:
>
>
> e.g. create a file
>
> # tmp.dat
> 1
> 2
> 3
> 4
>
>
> Loaded PDL v2.084 (supports bad values)
> pdl> $x = rcols 'tmp.dat'
> Reading data into ndarrays of type: [ Double ]
> Read in  4  elements.
>
> pdl> p $x
> [1 2 3 4]
> pdl> $x *= 100
>
> pdl> p $x
> [100 200 300 400]
> pdl> p median($x)
> 0
> pdl> p $x
> [100 200 300 400]
>
>
> It seems the median function sees the values BEFORE the inplace 
> multiplacation, whereas print does not. This is very bad. min() and max() are 
> similar. No idea what is going on here! The behaviour or absent from v2.025
>
> Notes
> - making a $x->copy() removes the effect
> - creating $x using sequence also removes, so it is something to do with 
> rcols() and not inplace in general?
>
> I’d be interested to know if others can reproduce this. It definitely needs a 
> fix
>
> best
>
> Karl
>
>
>


> ___
> pdl-general mailing list
> pdl-general@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/pdl-general


-- 

  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-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

Re: [Pdl-general] rotate matrix

[Luis Mochan]

On Sun, Oct 15, 2023 at 05:26:12PM -0700, Mark NanoNebulas wrote:
> ...
> could you put the Rotxz into 4178 dimensions I dont understand how your
> doing it in 3

The rotation matrix is a 3x3 matrix. It can operate on a column vector
(1x3 matrix) or on many column vectors at once (on an Nx3 ndarray) or
even on a multidimensional ndarray of dimensions Nx3xPxQ (The second
dimension must be 3).

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-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

Re: [Pdl-general] rotate matrix

[Luis Mochan]

This worked for me to generate x-z d orbitals. The other planes are similar.
I simply applied 4 different 45 degree rotations to your points and
plotted them all together. I added two additional points to fix the scale.

##
use PDL;
use PDL::Complex;
use PDL::Graphics::TriD;
use PDL::Math;
my $c = 10; ## speed
my $Rotxz=pdl([[1/sqrt 2, 0, -1/sqrt 2],[0,1,0], [1/sqrt 2, 0, 1/sqrt 2]]);
nokeeptwiddling3d;
while(1){
for my $phase(-360..360) {  ## 360
my $photons = 4178; ### [Density] 2444 4178
my $t=rvals(zeros($photons));
my $cz=$c; # -1**$t*$c
my $cy=sin($t*$c);
my $cx=sin($t)*$c;
my $w=$cz-$cy-$cx;
my $color=(pdl[my $r=cos($cy+$c+$cz), my $g=sin($w), my 
$b=cos($w)])->mv(-1,0);
my $i=($cz-$cx-$cy);
my $q=$c*($i*$phase);
my $R = $b*sin($b);
my $phi = $r*$q;
my $theta = $g*cos($g);
my $points=($R*pdl[sin($theta)*cos($phi), 
sin($phi)*sin($theta),cos($theta)]);
my $allpoints=pdl(
$Rotxz x $points, $Rotxz->transpose x $points, -$Rotxz x $points, 
-$Rotxz->transpose x $points
)->mv(1,0);
points3d(pdl[[1,1,1],[-1,-1,-1]]);
hold3d();
points3d($allpoints, $color->dummy(2));
release3d();
}
}


On Sat, Oct 14, 2023 at 06:01:34PM -0700, Mark NanoNebulas wrote:
> i found out how to move the point in the y axis here
>   $dd++;
> $xxx = $xx*cos($yy)*sin($zz)+sin($xx);  ### cos   change the spin of the
> electron here
> $yyy = $xx*sin($yy)*sin($zz)+sin($xx+$dd);  ### sin
> $zzz = $xx*cos($zz);  ### cos
>
> this seems to work but can it make all the d orbitals i need ???
>
> -Mark Baker
>
>
> On Sat, Oct 14, 2023 at 7:18 AM Luis Mochan  wrote:
>
> > Hi,
> > I didn't quite understand the code. I simplified it a bit, removed
> > many noop instructions, changed the speed, negated the twiddling and
> > the result looks like a nice lobe of a p orbital, made up of points
> > along some spiral, rotating about its axis. Is this the rotation you
> > want or do you want to rotate the symmetry axis from the z direction to an
> > arbitrary direction? You could apply a 3x3 rotation matrix to the
> > $points array in the code below. If you want a point to remain fixed,
> > first translate it to the origin, the rotate, and then rotate back.
> > Regards,
> > Luis
> > 
> > ##
> > use PDL;
> > use PDL::Complex;
> > use PDL::Graphics::TriD;
> > use PDL::Math;
> > nokeeptwiddling3d;
> > my $c = 10; ## speed
> > while(1){
> > for my $phase(-360..360) {  ## 360
> > my $photons = 4178; ### [Density] 2444 4178
> > my $t=rvals(zeros($photons));
> > my $cz=$c; # -1**$t*$c
> > my $cy=sin($t*$c);
> > my $cx=sin($t)*$c;
> > my $w=$cz-$cy-$cx;
> > my $color=(pdl[my $r=cos($cy+$c+$cz), my $g=sin($w), my
> > $b=cos($w)])->mv(-1,0);
> > my $i=($cz-$cx-$cy);
> > my $q=$c*($i*$phase);
> > my $R = $b*sin($b);
> > my $phi = $r*$q;
> > my $theta = $g*cos($g);
> > my $points=($R*pdl[sin($theta)*cos($phi),
> > sin($phi)*sin($theta),cos($theta)])->mv(-1,0);
> > points3d $points,$color;
> > }
> > }
> >
> >
> >
> > On Fri, Oct 13, 2023 at 10:36:17AM -0700, Mark NanoNebulas wrote:
> > > Hi im trying to rotate this obital so that i can place them all over in
> > > balanced arrangements of orbs like the chemistry book says but i dont
> > know
> > > how to rotate a matrix in all directions, can anybody help
> > > heres the code
> > >
> > > ##
> > > use PDL;
> > > use PDL::Complex;
> > > use PDL::Graphics::TriD;
> > > use PDL::Math; keeptwiddling3d;
> > > $PDL::BIGPDL=1;
> > >  ## remember this can crash the computer if you dont have enough RAM and
> > > swap in linux or pagefile in windows
> > >
> > >
> > >
> > >  for (;;){
> > >   $c = (400) ; ## speed
> > >  for $phase(-360..360) {  ## 360
> > >  $phases = $phase*0.001;
> > >  $frequency = ($c**-1);
> > >  $n= (6.28*$c*$frequency+($phases));
> > >
> > >  $photons = 4178; ### [Density] 2444 4178
> > >
> > >
> > >  $t=rvals(exp(zeros($photons)));
> > >  $cz=-1**$t*$c; # -1**$t*$c
> > >  $cy=-1**sin($t*$c); #-1**$c*sin($t*$c)
> > >  $cx=-1**$c*sin(rvals($t))*$c;
> > #-1**$c

Re: [Pdl-general] rotate matrix

[Luis Mochan]

Hi,
I didn't quite understand the code. I simplified it a bit, removed
many noop instructions, changed the speed, negated the twiddling and
the result looks like a nice lobe of a p orbital, made up of points
along some spiral, rotating about its axis. Is this the rotation you
want or do you want to rotate the symmetry axis from the z direction to an
arbitrary direction? You could apply a 3x3 rotation matrix to the
$points array in the code below. If you want a point to remain fixed,
first translate it to the origin, the rotate, and then rotate back.
Regards,
Luis

##
use PDL;
use PDL::Complex;
use PDL::Graphics::TriD;
use PDL::Math;
nokeeptwiddling3d;
my $c = 10; ## speed
while(1){
for my $phase(-360..360) {  ## 360
my $photons = 4178; ### [Density] 2444 4178
my $t=rvals(zeros($photons));
my $cz=$c; # -1**$t*$c
my $cy=sin($t*$c);
my $cx=sin($t)*$c;
my $w=$cz-$cy-$cx;
my $color=(pdl[my $r=cos($cy+$c+$cz), my $g=sin($w), my 
$b=cos($w)])->mv(-1,0);
my $i=($cz-$cx-$cy);
my $q=$c*($i*$phase);
my $R = $b*sin($b);
my $phi = $r*$q;
my $theta = $g*cos($g);
my $points=($R*pdl[sin($theta)*cos($phi), 
sin($phi)*sin($theta),cos($theta)])->mv(-1,0);
points3d $points,$color;
}
}



On Fri, Oct 13, 2023 at 10:36:17AM -0700, Mark NanoNebulas wrote:
> Hi im trying to rotate this obital so that i can place them all over in
> balanced arrangements of orbs like the chemistry book says but i dont know
> how to rotate a matrix in all directions, can anybody help
> heres the code
>
> ##
> use PDL;
> use PDL::Complex;
> use PDL::Graphics::TriD;
> use PDL::Math; keeptwiddling3d;
> $PDL::BIGPDL=1;
>  ## remember this can crash the computer if you dont have enough RAM and
> swap in linux or pagefile in windows
>
>
>
>  for (;;){
>   $c = (400) ; ## speed
>  for $phase(-360..360) {  ## 360
>  $phases = $phase*0.001;
>  $frequency = ($c**-1);
>  $n= (6.28*$c*$frequency+($phases));
>
>  $photons = 4178; ### [Density] 2444 4178
>
>
>  $t=rvals(exp(zeros($photons)));
>  $cz=-1**$t*$c; # -1**$t*$c
>  $cy=-1**sin($t*$c); #-1**$c*sin($t*$c)
>  $cx=-1**$c*sin(rvals($t))*$c; #-1**$c*bessj0(rvals($t,{Centre=>[0]}))*$c;
>
>
>  $w=$cz-$cy-$cx;
>  $g=sin($w);   #sin
>  $r=cos($cy+$c+$cz); #cos
>  $b=cos($w); #cos
>  $i=($cz-$cx-$cy);
>   $q=$c*($i*$n);
>  $xx = $b*sin($b);  ###
>   $yy = $r*($q);  ###
>   $zz = $g*cos($g);  ###
>
> $xxx = $xx*cos($yy)*sin($zz);  ###
> $yyy = $xx*sin($yy)*sin($zz);  ###
> $zzz = $xx*cos($zz);
>
> points3d[$xxx,$yyy,$zzz],[$r,$g,$b];
>
> ##
>
> if i can get this orbital to rotate in all directions, then i can represent
> atoms
> better cause they are balanced by the number of electrons so the orbs
> repeal each other, please any help would be appreciated !!!
>
> Best,
> -Mark Baker


> ___
> pdl-general mailing list
> pdl-general@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/pdl-general


-- 

  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-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

[Pdl-general] emacs, perl and jupyter

[Luis Mochan]

To those of you that use Emacs to edit Perl programs, or are
interested in it: I was able to integrate Zaki Mughal's package
Devel::Iperl, with Jupyter and Emacs in order to be able to develop
Perl programs (including PDL) incrementally/interactively using code
blocks within Org-Mode files. The org files may contain notes, program
fragments, results, and may be exported to latex, pdf, html, markdown,
docx, etc. I left some notes here:
   https://wlmb.github.io/2023/08/08/jupyter/
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-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

Re: [Pdl-general] How do you dice based on a boolean matrix?

[Luis Mochan]

You could use whereND, as:
 pdl> p $target=sequence(5,10)
 [
   [ 0  1  2  3  4]
   [ 5  6  7  8  9]
   [10 11 12 13 14]
   [15 16 17 18 19]
   [20 21 22 23 24]
   [25 26 27 28 29]
   [30 31 32 33 34]
   [35 36 37 38 39]
   [40 41 42 43 44]
   [45 46 47 48 49]
 ]

Set a 1D mask
 pdl> p $mask=random(10)>0.5
 [1 0 0 1 1 0 1 1 1 0]
Use mask to select elements. Notice the transpositions (here with mv)
so that mask corresponds to rows, not to columns.
 pdl> p $target->mv(0,1)->whereND($mask)->mv(1,0)
 [
   [ 0  1  2  3  4]
   [15 16 17 18 19]
   [20 21 22 23 24]
   [30 31 32 33 34]
   [35 36 37 38 39]
   [40 41 42 43 44]
 ]
Operate on selected rows.
 pdl> p $target->mv(0,1)->whereND($mask)->mv(1,0)**=2
 [
   [   0149   16]
   [ 225  256  289  324  361]
   [ 400  441  484  529  576]
   [ 900  961 1024 1089 1156]
   [1225 1296 1369 1444 1521]
   [1600 1681 1764 1849 1936]
 ]
Print the modified target
 pdl> p $target
 [
   [   0149   16]
   [   56789]
   [  10   11   12   13   14]
   [ 225  256  289  324  361]
   [ 400  441  484  529  576]
   [  25   26   27   28   29]
   [ 900  961 1024 1089 1156]
   [1225 1296 1369 1444 1521]
   [1600 1681 1764 1849 1936]
   [  45   46   47   48   49]
 ]

Regards,
Luis


On Wed, Aug 09, 2023 at 12:10:09AM -0700, Eric Wheeler wrote:
> Hello all!
>
> I would like to get a diced/sliced/indexed piddle that is derived from a
> larger matrix based on rows indicated by a mask.
>
> For example, lets say I have a mask and I want to dice a matrix's rows
> where the mask has a value of 1 (in any location):
>
>   pdl> p $mask = random(10)->transpose > 0.5
>
>   [
>[0]
>[0]
>[1]
>[0]
>[1]
>[1]
>[1]
>[0]
>[1]
>[0]
>   ]
>
> and lets say that this is the origin matrix I want to dice:
>
>   pdl> p $target = sequence(5, 10)
>
>   [
>[ 0  1  2  3  4]
>[ 5  6  7  8  9]
>[10 11 12 13 14]
>[15 16 17 18 19]
>[20 21 22 23 24]
>[25 26 27 28 29]
>[30 31 32 33 34]
>[35 36 37 38 39]
>[40 41 42 43 44]
>[45 46 47 48 49]
>   ]
>
> I would like to have a result that has only the rows where the mask is
> marked with a 1, like this:
>
>   $result = filter_somehow_from($target by $mask);
>   [
>[30 31 32 33 34]
>[35 36 37 38 39]
>[40 41 42 43 44]
>[45 46 47 48 49]
>   ]
>
> so I can modify the result in-place, like square it:
>
>   $result **= 2;
>
>[ 900  961 1024 1089 1156]
>[1225 1296 1369 1444 1521]
>[1600 1681 1764 1849 1936]
>[2025 2116 2209 2304 2401]
>
> so the `**= 2` will modify to the original matrix:
>
>   [
>[ 0  1  2  3  4]
>[ 5  6  7  8  9]
>[10 11 12 13 14]
>[15 16 17 18 19]
>[20 21 22 23 24]
>[25 26 27 28 29]
>[ 900  961 1024 1089 1156]
>[1225 1296 1369 1444 1521]
>[1600 1681 1764 1849 1936]
>[2025 2116 2209 2304 2401]
>   ]
>
>
> I know I could do something with ->slice to modify in-place, but ':,6:9' is 
> not $mask:
>
>   pdl> p $target->slice(':,6:9') **= 2
>
>   [
>[ 900  961 1024 1089 1156]
>[1225 1296 1369 1444 1521]
>[1600 1681 1764 1849 1936]
>[2025 2116 2209 2304 2401]
>   ]
>
>   pdl> p $target
>
>   [
>[   01234]
>[   56789]
>[  10   11   12   13   14]
>[  15   16   17   18   19]
>[  20   21   22   23   24]
>[  25   26   27   28   29]
>[ 900  961 1024 1089 1156]
>[1225 1296 1369 1444 1521]
>[1600 1681 1764 1849 1936]
>[2025 2116 2209 2304 2401]
>   ]
>
> So $mask defines the rows I need to modify, and $mask could have 1's in
> any location, and those are the locations I need to twiddle.
>
> Ideas?
>
> Thanks for your help!
>
> --
> Eric Wheeler
>
>
> ___
> pdl-general mailing list
> pdl-general@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/pdl-general
>

-- 

  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-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

Re: [Pdl-general] Trid demo

[Luis Mochan]

points3d($r,{PointSize=>2})

worked for me

Regards,
Luis

On Fri, Jul 28, 2023 at 06:15:32PM -0700, Mark NanoNebulas wrote:
> I got cpanm PDL@2.082 to work(install) with all the Trid demos working
> perfectly
> Thanks Ed Thanks Zaki
> can any one give me the right way to change the "points3d" Point size i
> tried
> {PointSize=>2}, {Point::Size=>2} sorry i cant remember how to do this ,can
> anyone help ???
>
> On Wed, Jul 26, 2023 at 2:40 PM Zakariyya Mughal 
> wrote:
>
> > On 2023-07-26 at 10:51:26 -0700, Mark NanoNebulas wrote:
> > > Awesome, thanks for the info!
> > > Ed do you know the last version of PDL with Trid in the demos ???
> >
> > PDL still has the TriD demos:
> > .
> >
> > Which OS and distribution are you using? We may be able to give
> > step-by-step instructions on what you need to have installed.
> >
> > - Zaki Mughal
> >
> > >
> > > On Wed, Jul 26, 2023 at 9:09 AM Ed .  wrote:
> > >
> > > > To install a version of PDL other than the latest, e.g. for 2.082:
> > cpanm
> > > > PDL@2.082
> > > >
> > > >
> > > >
> > > > The TriD modules and demo are still supplied, and should still work. If
> > > > you can tell us what happens when you run “perl Makefile.PL” at the top
> > > > level of the latest PDL, that would help. You’ll need not only OpenGL,
> > but
> > > > now also OpenGL::GLUT, for the POGL stuff to work.
> > > >
> > > >
> > > >
> > > > Best regards,
> > > >
> > > > Ed
> > > >
> > > >
> > > >
> > > > *From: *Mark NanoNebulas 
> > > > *Sent: *26 July 2023 13:55
> > > > *To: *pdl-general@lists.sourceforge.net
> > > > *Subject: *[Pdl-general] Trid demo
> > > >
> > > >
> > > >
> > > > Hello I was wondering when you guys plan on putting the Trid demo back
> > > >
> > > > on the PDL install i mean i CANT USE Trid at all now, my OpenGL works
> > > >
> > > > i took a look at the install files and i cant even find the
> > TRID::Graphics
> > > > modules there any more, so if TRID is not going to be in PDL install no
> > > > more can someone help me install a older version that still has Trid...
> > > >
> > > > can you even install a old version with CPAN, i tried and couldnt
> > figure
> > > > it out
> > > >
> > > > i tried to install version 2.008 where you
> > > >
> > > > perl Makefile.pl
> > > >
> > > > but thats where it failed and i was in the directory said something
> > like
> > > >
> > > > it couldnt find "basic" something and quit installing
> > > >
> > > >
> > > >
> > > > so i mean i would really like to use PDL to program atoms and electrons
> > > > and positrons... otherwise ill have to learn assembly on *KolibriOS* it
> > > > has a PDL like
> > > >
> > > > demo that  doesn't use Trid or OpenGL its pure assembly language in a
> > 3d
> > > > graphics window but it seems to have the (with out color) same matrix
> > 3D
> > > > imaging as PDL, i found they might have programed the electron before
> > me
> > > > (maybe with out knowing) cause i found the same geometry as my electron
> > > > here take a look
> > > >
> > > >
> > > >
> > > >  https://youtu.be/TKhokqmgFzI
> > > >
> > > >
> > > >
> > > > well cause I really like using PDL to make the OpenGL matrices and i
> > like
> > > > the idea
> > > >
> > > > of having simulation software where you can use atoms like legos and
> > build
> > > > molecules, but with Trid gone out of the demos that dream seems
> > shattered
> > > > at least with PDL without learning the ins and outs of POGL
> > > >
> > > >
> > > >
> > > > any help would be great...
> > > >
> > > >
> > > >
> > > > Cheers
> > > >
> > > >
> > > >
> > > > -Mark Nanonebulas
> > > >
> > > > on youtube
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> >
> >
> > > ___
> > > pdl-general mailing list
> > > pdl-general@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/pdl-general
> >
> >
> >
> > ___
> > pdl-general mailing list
> > pdl-general@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/pdl-general
> >


> ___
> pdl-general mailing list
> pdl-general@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/pdl-general


-- 

  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-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

[Pdl-devel] strange bug in gnuplot

[Luis Mochan]

I have a strange bug in PDL::Graphics::Gnuplot. Consider the following program:

use PDL;
use PDL::Graphics::Gnuplot;
use IO::Prompter;
$title="A title with many useless letters";
gplot({title=>$title}, with=>"lines", zeroes(20)->xvals**2);
prompt -void, -single, "Ready?";

In my system (debian/testing, PDL 2.082, Perl 5.36) the last "s" in
the title is truncated, as seen in the attached image. My default
gnuplot terminal is qt. The truncation, if any, depends on the content
of the title, not only on its length. I can fix it sometimes by adding
enough trailing whitespace characters. If I generate a hardcopy from
the 'qt' menu, the title becomes complete again. If I run gnuplot
interactively, without going through pdl, the title is not
truncated. It is not too important, but it is annoying, as I sometimes
use the title to record important parameters.

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

[Pdl-general] strange bug in gnuplot

[Luis Mochan]

I have a strange bug in PDL::Graphics::Gnuplot. Consider the following program:

use PDL;
use PDL::Graphics::Gnuplot;
use IO::Prompter;
$title="A title with many useless letters";
gplot({title=>$title}, with=>"lines", zeroes(20)->xvals**2);
prompt -void, -single, "Ready?";

In my system (debian/testing, PDL 2.082, Perl 5.36) the last "s" in
the title is truncated, as seen in the attached image. My default
gnuplot terminal is qt. The truncation, if any, depends on the content
of the title, not only on its length. I can fix it sometimes by adding
enough trailing whitespace characters. If I generate a hardcopy from
the 'qt' menu, the title becomes complete again. If I run gnuplot
interactively, without going through pdl, the title is not
truncated. It is not too important, but it is annoying, as I sometimes
use the title to record important parameters.

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  | moc...@fis.unam.mx   /\_/\__/
GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16  C2DF 5F0A C52B 791E B9EB
___
pdl-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

Re: [Pdl-general] PDL::OpenCV 0.001 released

[Luis Mochan]

I tried to install PDL::OpenCV under Debian/bookworm using perlbrew
and cpanm with perl 5.36.0. I got errors such as:

   opencv_wrapper.cpp:1:10: fatal error: opencv2/opencv.hpp: No such file or 
directory
1 | #include 

I found that the include file had been installed under my perlbrew directory

   
/home/mochan/perl5/perlbrew/perls/perl-5.36.0/lib/site_perl/5.36.0/x86_64-linux/auto/share/dist/Alien-OpenCV/include/opencv4/opencv2/opencv.hpp

but it seems it was being searched under /usr/local/include. To test
this I manually made a link from .../opencv2 to /usr/local/include/opencv2.

Then the compilation of PDL::OpenCV proceeded further, until I hit another
error:

wraplocal.cpp:3:10: fatal error: opencv2/tracking.hpp: No such file or 
directory
3 | #include 

I found Alien::OpenCV had installed .../opencv2/video/tracking.hpp,
but not .../opencv2/tracking.hpp.

I ran perl -MAlien::OpenCV -E 'say Alien::OpenCV->cflags' and I also
got an empty result.

Hope this helps.

Regards,
Luis



On Tue, Apr 04, 2023 at 07:56:32PM +, Adam Russell wrote:
> I ran perl -MAlien::OpenCV -E 'say Alien::OpenCV->cflags' and I get an empty 
> response. No error about not finding the module, so safe to assume it's 
> installed. But I guess none of the flags were set?
>
> Scrolling through the installation output I see stuff like
>
>
> /Users/adamrussell/.cpan/build/Alien-OpenCV-0.002-0/_alien/build_0YqR/opencv-opencv-1668f2a/modules/ts/include/opencv2/ts/ts_gtest.h:18906:10:
>  note: in implicit copy constructor for 
> 'testing::internal::CartesianProductHolder5  (const cv::Mat &, const cv::Mat &)>>, testing::internal::ValueArray5 int, int, int, int>, testing::internal::ValueArray3, 
> cv::Size_, cv::Size_>, testing::internal::ValueArray3 int>, testing::internal::ValueArray1>>' first 
> required here
>   return internal::CartesianProductHolder5
> so it looks like it built it's own and did not find the MacPorts version? But 
> then would it not have an easier time finding it's own header files?
>
> I really can't mix Homebrew and Macports on this particular machine and 
> chance risk breaking other things. Happy to try and get this to work any way 
> I can though!
>
> 
> From: Ed . 
> Sent: Tuesday, April 4, 2023 2:24 PM
> To: Adam Russell ; pdl-general@lists.sourceforge.net 
> 
> Subject: RE: [Pdl-general] PDL::OpenCV 0.001 released
>
>
> Hi Adam,
>
>
>
> Thanks for the report! Can you check and see whether Alien::OpenCV found the 
> MacPorts one or built its own? And can you say what this shows?
>
>
>
> perl -MAlien::OpenCV -E 'say Alien::OpenCV->cflags'
>
>
>
> (Also, are you able to try out the Homebrew OpenCV? I’ve only experimented 
> with the Homebrew myself)
>
>
>
> Best regards,
>
> Ed
>
>
>
> From: Adam Russell
> Sent: 04 April 2023 19:10
> To: 
> pdl-general@lists.sourceforge.net
> Subject: Re: [Pdl-general] PDL::OpenCV 0.001 released
>
>
>
> I get this build error. But I definitely have this, it is located in a usual 
> location for MacPorts: /opt/local/include/opencv4/opencv2/opencv.hpp
>
>
>
> Is there some trick to get this to be found properly? I am installing via 
> cpan, just a simple 'cpan> install PDL::OpenCV` which otherwise seems to 
> proceed well in terms of installing needed dependencies and so forth.
>
>
>
> opencv_wrapper.cpp:1:10: fatal error: 'opencv2/opencv.hpp' file not found
>
> #include 
>
>  ^~~~
>
> 1 error generated.
>
> make: *** [opencv_wrapper.o] Error 1
>
>   ETJ/PDL-OpenCV-0.001.tar.gz
>
>   /usr/bin/make -- NOT OK
>
> Failed during this command:
>
>  ETJ/PDL-OpenCV-0.001.tar.gz  : make NO
>
>
>
>
>
>
>
> Date: Sun, 26 Mar 2023 06:50:19 +
> From: "Ed ." 
> To: "pdl-de...@lists.sourceforge.net"
> , perldl
> 
> Subject: [Pdl-general] PDL::OpenCV 0.001 released
> Message-ID:
> 
> 
>
> Content-Type: text/plain; charset="windows-1252"
>
> Dear PDL folks,
>
> PDL::OpenCV 0.001 has just been released. Notable changes since never:
>
>
>   *   It supports modules highgui, imgcodecs, imgproc, objdetect, tracking, 
> videoio
>   *   Where possible, all inputs and outputs are ndarrays which get wrapped 
> into Mat, Rect, std::vector, etc internally
>   *   In particular, it supports just about every class and function within 
> those modules that are supported by the Python binding
>   *   There is a simplistic translation of the Doxygen docs into POD, see on 
> MetaCPAN: https://metacpan.org/dist/PDL-OpenCV
>   *   It includes a perldl demo which shows off basic image-processing stuff 
> (?demo opencv?)
>
> Future plans, in something like intended order:
>
>   *   Support the ?Params? classes (possibly from Perl-land as a hash-ref)
>   *   Support more of the modules, both in the main OpenCV distribution and 
> the ?contrib? ones
>
> The IRC channel (#pdl on irc.perl.org) is a great virtual place to come and 
> 

Re: [Pdl-general] [Pdl-devel] PDL 2.082 released

[Luis Mochan]

Congrats and thanks!

On Thu, Mar 23, 2023 at 03:31:22AM +, Ed . wrote:
> Dear PDL folks,
>
> PDL 2.082 has just been released...

-- 

  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-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

Re: [Pdl-devel] PDL 2.082 released

[Luis Mochan]

Congrats and thanks!

On Thu, Mar 23, 2023 at 03:31:22AM +, Ed . wrote:
> Dear PDL folks,
>
> PDL 2.082 has just been released...

-- 

  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

Re: [Pdl-devel] inconsistent determinant

[Luis Mochan]

Hi Ed,
Thanks for looking at this. It was not too important, but it was
surprising, as I was chaining pdl methods (...->det->approx(0) to
detetct singular matrices) and I was getting somewhat strange error messages
as det was sometimes an ndarray and other times a scalar.
Regards,
Luis

On Sat, Feb 11, 2023 at 04:49:39AM +, Ed . wrote:
> Hi Luis,
>
> The key (if you’ll forgive the pun) is the behaviour of the “det” function, 
> which is (at this writing) defined in Basic/MatrixOps/matrixops.pd as:
>
> sub det {
>   my($x) = shift;
>   my($opt) = shift;
>   $opt = {} unless defined($opt);
>   my($lu,$perm,$par);
>   if(exists ($opt->{lu}) and (ref $opt->{lu} eq 'ARRAY')) {
> ($lu,$perm,$par) =  @{$opt->{lu}};
>   } else {
> ($lu,$perm,$par) = lu_decomp($x);
> $opt->{lu} = [$lu,$perm,$par]
>   if(exists($opt->{lu}));
>   }
>   ( (defined $lu) ? $lu->diagonal(0,1)->prodover * $par : 0 );
> }
>
> You will see the last line returns a Perl scalar 0 if the $lu came back 
> undefined, otherwise it will do a prodover on the diagonal, which returns a 
> PDL ndarray. Here is my slightly-modified version of your script:
>
> use strict; use warnings; use feature 'say';
> use PDL;
> my $m1=pdl[[-2,-2,-2], [-1,-2,-2], [0,-2,-2]];
> my $m2=pdl[[-2,-2,-2],[-1,-1,-2],[0,0,-2]];
> for($m1, $m2){
> my $det = $_->det(my $opt={lu=>undef});
> say "Got det=$det (Ref=@{[ref $det]}) lu=(@{$opt->{lu}}) for Matrix=$_";
> }
>
> I will look in a while at why the lu_decomp is behaving differently for the 
> two matrices. It is almost certainly a bug.
>
> Best regards,
> Ed
>
> From: Luis Mochan<mailto:moc...@icf.unam.mx>
> Sent: 11 February 2023 04:20
> To: perldl<mailto:pdl-gene...@lists.sourceforge.net>; 
> perldl<mailto:pdl-devel@lists.sourceforge.net>
> Subject: [Pdl-devel] inconsistent determinant
>
> I found a curious situation when running pdl, as illustrated in the
> following example.  I build two singular 3x3 matrices and calculate
> their determinant, which is zero. However, in one case I get a PDL
> scalar and in the other I get a Perl scalar. I don't know why the
> different behaviour:
>
> # Program
> use v5.36;
> use PDL;
> my $m1=pdl[[-2,-2,-2], [-1,-2,-2], [0,-2,-2]];
> my $m2=pdl[[-2,-2,-2],[-1,-1,-2],[0,0,-2]];
> for($m1, $m2){
> say "Matrix=$_", "Det=", $_->det, "\nRef=", ref $_->det;
> }
>
>
> #Results:
> Matrix=
> [
>  [-2 -2 -2]
>  [-1 -2 -2]
>  [ 0 -2 -2]
> ]
> Det=0
> Ref=PDL
> Matrix=
> [
>  [-2 -2 -2]
>  [-1 -1 -2]
>  [ 0  0 -2]
> ]
> Det=0
> Ref=
>
> I'm currently running PDL v2.081 under Perl 5.36 in Linux/testing.
>
> 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  | 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
>

-- 

  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

Re: [Pdl-general] [Pdl-devel] inconsistent determinant

[Luis Mochan]

Hi Ed,
Thanks for looking at this. It was not too important, but it was
surprising, as I was chaining pdl methods (...->det->approx(0) to
detetct singular matrices) and I was getting somewhat strange error messages
as det was sometimes an ndarray and other times a scalar.
Regards,
Luis

On Sat, Feb 11, 2023 at 04:49:39AM +, Ed . wrote:
> Hi Luis,
>
> The key (if you’ll forgive the pun) is the behaviour of the “det” function, 
> which is (at this writing) defined in Basic/MatrixOps/matrixops.pd as:
>
> sub det {
>   my($x) = shift;
>   my($opt) = shift;
>   $opt = {} unless defined($opt);
>   my($lu,$perm,$par);
>   if(exists ($opt->{lu}) and (ref $opt->{lu} eq 'ARRAY')) {
> ($lu,$perm,$par) =  @{$opt->{lu}};
>   } else {
> ($lu,$perm,$par) = lu_decomp($x);
> $opt->{lu} = [$lu,$perm,$par]
>   if(exists($opt->{lu}));
>   }
>   ( (defined $lu) ? $lu->diagonal(0,1)->prodover * $par : 0 );
> }
>
> You will see the last line returns a Perl scalar 0 if the $lu came back 
> undefined, otherwise it will do a prodover on the diagonal, which returns a 
> PDL ndarray. Here is my slightly-modified version of your script:
>
> use strict; use warnings; use feature 'say';
> use PDL;
> my $m1=pdl[[-2,-2,-2], [-1,-2,-2], [0,-2,-2]];
> my $m2=pdl[[-2,-2,-2],[-1,-1,-2],[0,0,-2]];
> for($m1, $m2){
> my $det = $_->det(my $opt={lu=>undef});
> say "Got det=$det (Ref=@{[ref $det]}) lu=(@{$opt->{lu}}) for Matrix=$_";
> }
>
> I will look in a while at why the lu_decomp is behaving differently for the 
> two matrices. It is almost certainly a bug.
>
> Best regards,
> Ed
>
> From: Luis Mochan<mailto:moc...@icf.unam.mx>
> Sent: 11 February 2023 04:20
> To: perldl<mailto:pdl-general@lists.sourceforge.net>; 
> perldl<mailto:pdl-de...@lists.sourceforge.net>
> Subject: [Pdl-devel] inconsistent determinant
>
> I found a curious situation when running pdl, as illustrated in the
> following example.  I build two singular 3x3 matrices and calculate
> their determinant, which is zero. However, in one case I get a PDL
> scalar and in the other I get a Perl scalar. I don't know why the
> different behaviour:
>
> # Program
> use v5.36;
> use PDL;
> my $m1=pdl[[-2,-2,-2], [-1,-2,-2], [0,-2,-2]];
> my $m2=pdl[[-2,-2,-2],[-1,-1,-2],[0,0,-2]];
> for($m1, $m2){
> say "Matrix=$_", "Det=", $_->det, "\nRef=", ref $_->det;
> }
>
>
> #Results:
> Matrix=
> [
>  [-2 -2 -2]
>  [-1 -2 -2]
>  [ 0 -2 -2]
> ]
> Det=0
> Ref=PDL
> Matrix=
> [
>  [-2 -2 -2]
>  [-1 -1 -2]
>  [ 0  0 -2]
> ]
> Det=0
> Ref=
>
> I'm currently running PDL v2.081 under Perl 5.36 in Linux/testing.
>
> 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  | moc...@fis.unam.mx   /\_/\__/
> GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16  C2DF 5F0A C52B 791E B9EB
>
>
> ___
> pdl-devel mailing list
> pdl-de...@lists.sourceforge.net
> 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  | moc...@fis.unam.mx   /\_/\__/
GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16  C2DF 5F0A C52B 791E B9EB


___
pdl-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

[Pdl-general] inconsistent determinant

[Luis Mochan]

I found a curious situation when running pdl, as illustrated in the
following example.  I build two singular 3x3 matrices and calculate
their determinant, which is zero. However, in one case I get a PDL
scalar and in the other I get a Perl scalar. I don't know why the
different behaviour:

# Program
use v5.36;
use PDL;
my $m1=pdl[[-2,-2,-2], [-1,-2,-2], [0,-2,-2]];
my $m2=pdl[[-2,-2,-2],[-1,-1,-2],[0,0,-2]];
for($m1, $m2){
say "Matrix=$_", "Det=", $_->det, "\nRef=", ref $_->det;
}


#Results:
Matrix=
[
 [-2 -2 -2]
 [-1 -2 -2]
 [ 0 -2 -2]
]
Det=0
Ref=PDL
Matrix=
[
 [-2 -2 -2]
 [-1 -1 -2]
 [ 0  0 -2]
]
Det=0
Ref=

I'm currently running PDL v2.081 under Perl 5.36 in Linux/testing.

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  | moc...@fis.unam.mx   /\_/\__/
GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16  C2DF 5F0A C52B 791E B9EB


___
pdl-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

[Pdl-devel] inconsistent determinant

[Luis Mochan]

I found a curious situation when running pdl, as illustrated in the
following example.  I build two singular 3x3 matrices and calculate
their determinant, which is zero. However, in one case I get a PDL
scalar and in the other I get a Perl scalar. I don't know why the
different behaviour:

# Program
use v5.36;
use PDL;
my $m1=pdl[[-2,-2,-2], [-1,-2,-2], [0,-2,-2]];
my $m2=pdl[[-2,-2,-2],[-1,-1,-2],[0,0,-2]];
for($m1, $m2){
say "Matrix=$_", "Det=", $_->det, "\nRef=", ref $_->det;
}


#Results:
Matrix=
[
 [-2 -2 -2]
 [-1 -2 -2]
 [ 0 -2 -2]
]
Det=0
Ref=PDL
Matrix=
[
 [-2 -2 -2]
 [-1 -1 -2]
 [ 0  0 -2]
]
Det=0
Ref=

I'm currently running PDL v2.081 under Perl 5.36 in Linux/testing.

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

Re: [Pdl-general] PDL::NiceSlice and Perl 5.36

[Luis Mochan]

The PDL::NiceSlice bug seems not to be a PDL bug, but rather a
Filter::Simple bug. I made a trivial source filter, unrelated to PDL
package MyFilter;
use v5.36;
use Filter::Simple;
FILTER_ONLY
code_no_comments => sub { say "Code:\n$_" },
all => sub { say "All:\n$_" };
1;
and a small program
use v5.36;
use lib ".";
use MyFilter;
my $x=1;
say $x/2/3;
and when I run it I get the same odd behavior
~$ perl rem1.pl
Code:
my $x=1;
say $x3;

All:
my $x=1;
say $x/2/3;

0.167
which shows that the fragment between slashes is erroneously removed by
Filter::Simple. I filled a bug report at
https://github.com/Perl/perl5/issues/20489

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-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

Re: [Pdl-general] PDL::NiceSlice and Perl 5.36

[Luis Mochan]

Regarding NiceSlice, I made a further couple of tests:
Take the program

#! /usr/bin/env perl
use PDL;
BEGIN{$PDL::NiceSlice::debug_filter=1;}
use PDL::NiceSlice;
my $x=pdl(1);
my $V=$x/$x((0))/2;

A add the ...debug_filter=1 line to print debugging info.

I run it:

$ ./rem.pl
* Input:
my $x=pdl(1);
my $V=$x2;

* Output: my $x=pdl(1);
my $V=$x2;

*** Final: my $x=pdl(1);
my $V=$x/$x((0))/2;

syntax error at ./rem.pl line 6, near "$x("
Execution of ./rem.pl aborted due to compilation errors.

So it seems that the source filter por NiceSlice doesn't receive all
of the code. The fragment /$x((0)) is removed from the line
$x/$x((0))/2, so the filter only receives $x2. As there is no slicing
in it, the filter returns its input unmodified and then Filter::Simple
puts the /$x((0))/ back in to produce the final code which is invalid
perl. So it seems that Filter::Simple is somehow confused by the two
slashes. If I remove $x/ or /2 the code works. I thought it might be
related to  /.../ looking like a search pattern. However if I change
$x/ by $x*1/

#! /usr/bin/env perl
use PDL;
BEGIN{$PDL::NiceSlice::debug_filter=1;}
use PDL::NiceSlice;
my $x=pdl(1);
my $V=$x/$x((0))/2;

and run it,

$ ./rem.pl
* Input:
my $x=pdl(1);
my $V=$x*1/$x((0))/2;

* Output: my $x=pdl(1);
my $V=$x*1/$x->slice([0,0,0])/2;

*** Final: my $x=pdl(1);
my $V=$x*1/$x->slice([0,0,0])/2;

then the fragment /$x((0))/ is not removed from the input.

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-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

Re: [Pdl-general] PDL::NiceSlice and Perl 5.36

[Luis Mochan]

Quite misterious:

I simplified the code to the following:

   #! /usr/bin/env perl
   use PDL;
   use PDL::NiceSlice;
   my $x=sequence(1);
   my $V=$x/$x((-1));
   #my $w=$A/$x((-1));

and it fails with the message

syntax error at rem.txt line 5, near "$x("

The error corresponds to the line 'my $V=$x/$x((-1));'

Nevertheless, if I remove the last comment, as in

   #! /usr/bin/env perl
   use PDL;
   use PDL::NiceSlice;
   my $x=sequence(1);
   my $V=$x/$x((-1));

the error message disappears. If I move the comment to the
previous line it also disappears, but if I put it in the same line
after the statement the error reappears. If I remove $x((-1)) from the
comment the error also disappears. I guess it would be useful to see
what is the output of the NiceSlice filter that contains the error and
that is fed to Perl, but I don't know much about input filters.

Regards,
Luis


On Thu, Nov 03, 2022 at 03:58:23PM +0300, Yury Pakhomov wrote:
> Hello All!
>
> After update my system (Slackware 15) some PDL programs crashed.
> For example, below is simple part of my code.
>
> code.pl
> 
> #! /usr/bin/perl -w
> #use v5.36;
> use PDL;
> use PDL::NiceSlice;
>
> my $c=299792;
>
> my $x=5000+sequence(100);
>
> # Average step in lam
> my $dx=($x((-1))-$x((0)))/(nelem($x)-1);
>
> # Minimal step in V scale
> my $dV=$c*$dx/$x((-1));
>
> # Create uniform V scale (km/s)
> my $n=int(log($x((-1))/$x((0)))/log(1+$dV/$c))+2;
> my $v=sequence($n)*$dV;
> _
>
> # perl -c code.pl
> syntax error at bad2.pl line 14, near "$x("
> bad2.pl had compilation errors.
>
> If I change line 14 to "my $dV=$c*$dx/$x->at(-1)->sclr;" then works fine.
> Also the original code in other computer (perl 5.34) works fine too.
> Moreover, if delete last three lines in code.pl, then it works!
> Where source of these errors?
>
>
>
>
> ___
> pdl-general mailing list
> pdl-general@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/pdl-general
>

-- 

  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-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

Re: [Pdl-general] PDL::NiceSlice and Perl 5.36

[Luis Mochan]

If I change the NiceSlice engine, using

$ PDL_NICESLICE_ENGINE=Filter::Util::Call program.pl

I don't get the error, and the output of the filter is

my $x=sequence(1);
my $V=$x/$x->slice([-1,0,0]);
#my $w=$A/$y->slice([-1,0,0]);

so that both the actual $x((-1)) and the same in the comment are
replaced by a call to 'slice'. The same happens if I use

$ PDL_NICESLICE_ENGINE=Module::Compile program.pl

Thus, I guess the problem lies in PDL::NiceSlice::FilterSimple

Regards,
Luis




On Fri, Nov 04, 2022 at 05:41:46PM -0600, Luis Mochan wrote:
> Well, I found how to get the output from the filter.
> Consider the code:
>
> #! /usr/bin/env perl
> use PDL;
> use PDL::NiceSlice;
> use Filter::sh 'tee rem1.pl';
> my $x=sequence(1);
> my $V=$x/$x((-1));  #my $w=$A/$x((-1));
>
> The line
>
> use Filter::sh 'tee rem1.pl';
>
> sends a copy of the last lines of the preprocessed source to the file
> rem1.pl. After feeding the code above to perl, the contents of rem1.pl
> are
>
> my $x=sequence(1);
> my $V=$x/$x((-1));
> #my $w=$A/$x->slice([-1,0,0]);
>
> This shows that the NiceSlice filter is applied to the $x in the
> comment and not to the $x in the executable line. This happens even if
> I use $y instead of $x in the comment.
>
> Regards,
> Luis
>
>
>
> On Fri, Nov 04, 2022 at 11:46:05PM +0300, Yury Pakhomov wrote:
> > Hi Ed,
> >
> > I use last version of PDL 2.081. This problem also affected preview 2.080
> > version.
> >
> > Other machine has Fedora Core 36 with perl 5.34 and PDL 2.076
> >
> > Best regards,
> >
> > Yury
> >
> > 04.11.2022 18:49, Ed. пишет:
> > >
> > > Hi Yury,
> > >
> > > I had a look and I don’t think Slackware packages PDL. Can you tell us
> > > what version of PDL you have installed, on the two machines where you’ve
> > > tried your script?
> > >
> > > Best regards,
> > >
> > > Ed
> > >
> > > *From: *Yury Pakhomov <mailto:pakho...@inasan.ru>
> > > *Sent: *03 November 2022 13:14
> > > *To: *perldl <mailto:pdl-general@lists.sourceforge.net>
> > > *Subject: *[Pdl-general] PDL::NiceSlice and Perl 5.36
> > >
> > > Hello All!
> > >
> > > After update my system (Slackware 15) some PDL programs crashed.
> > > For example, below is simple part of my code.
> > >
> > > code.pl
> > > 
> > > #! /usr/bin/perl -w
> > > #use v5.36;
> > > use PDL;
> > > use PDL::NiceSlice;
> > >
> > > my $c=299792;
> > >
> > > my $x=5000+sequence(100);
> > >
> > > # Average step in lam
> > > my $dx=($x((-1))-$x((0)))/(nelem($x)-1);
> > >
> > > # Minimal step in V scale
> > > my $dV=$c*$dx/$x((-1));
> > >
> > > # Create uniform V scale (km/s)
> > > my $n=int(log($x((-1))/$x((0)))/log(1+$dV/$c))+2;
> > > my $v=sequence($n)*$dV;
> > > _
> > >
> > > # perl -c code.pl
> > > syntax error at bad2.pl line 14, near "$x("
> > > bad2.pl had compilation errors.
> > >
> > > If I change line 14 to "my $dV=$c*$dx/$x->at(-1)->sclr;" then works fine.
> > > Also the original code in other computer (perl 5.34) works fine too.
> > > Moreover, if delete last three lines in code.pl, then it works!
> > > Where source of these errors?
> > >
> > >
> > >
> > >
> > > ___
> > > pdl-general mailing list
> > > pdl-general@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/pdl-general
> > >
>
>
> > ___
> > pdl-general mailing list
> > pdl-general@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/pdl-general
>
>
> --
>
>   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-general mailing list
> pdl-general@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/pdl-general

-- 

  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-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

Re: [Pdl-general] PDL::NiceSlice and Perl 5.36

[Luis Mochan]

Well, I found how to get the output from the filter.
Consider the code:

#! /usr/bin/env perl
use PDL;
use PDL::NiceSlice;
use Filter::sh 'tee rem1.pl';
my $x=sequence(1);
my $V=$x/$x((-1));  #my $w=$A/$x((-1));

The line

use Filter::sh 'tee rem1.pl';

sends a copy of the last lines of the preprocessed source to the file
rem1.pl. After feeding the code above to perl, the contents of rem1.pl
are

my $x=sequence(1);
my $V=$x/$x((-1));
#my $w=$A/$x->slice([-1,0,0]);

This shows that the NiceSlice filter is applied to the $x in the
comment and not to the $x in the executable line. This happens even if
I use $y instead of $x in the comment.

Regards,
Luis



On Fri, Nov 04, 2022 at 11:46:05PM +0300, Yury Pakhomov wrote:
> Hi Ed,
>
> I use last version of PDL 2.081. This problem also affected preview 2.080
> version.
>
> Other machine has Fedora Core 36 with perl 5.34 and PDL 2.076
>
> Best regards,
>
> Yury
>
> 04.11.2022 18:49, Ed. пишет:
> >
> > Hi Yury,
> >
> > I had a look and I don’t think Slackware packages PDL. Can you tell us
> > what version of PDL you have installed, on the two machines where you’ve
> > tried your script?
> >
> > Best regards,
> >
> > Ed
> >
> > *From: *Yury Pakhomov 
> > *Sent: *03 November 2022 13:14
> > *To: *perldl 
> > *Subject: *[Pdl-general] PDL::NiceSlice and Perl 5.36
> >
> > Hello All!
> >
> > After update my system (Slackware 15) some PDL programs crashed.
> > For example, below is simple part of my code.
> >
> > code.pl
> > 
> > #! /usr/bin/perl -w
> > #use v5.36;
> > use PDL;
> > use PDL::NiceSlice;
> >
> > my $c=299792;
> >
> > my $x=5000+sequence(100);
> >
> > # Average step in lam
> > my $dx=($x((-1))-$x((0)))/(nelem($x)-1);
> >
> > # Minimal step in V scale
> > my $dV=$c*$dx/$x((-1));
> >
> > # Create uniform V scale (km/s)
> > my $n=int(log($x((-1))/$x((0)))/log(1+$dV/$c))+2;
> > my $v=sequence($n)*$dV;
> > _
> >
> > # perl -c code.pl
> > syntax error at bad2.pl line 14, near "$x("
> > bad2.pl had compilation errors.
> >
> > If I change line 14 to "my $dV=$c*$dx/$x->at(-1)->sclr;" then works fine.
> > Also the original code in other computer (perl 5.34) works fine too.
> > Moreover, if delete last three lines in code.pl, then it works!
> > Where source of these errors?
> >
> >
> >
> >
> > ___
> > pdl-general mailing list
> > pdl-general@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/pdl-general
> >


> ___
> pdl-general mailing list
> pdl-general@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/pdl-general


-- 

  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-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

Re: [Pdl-general] conv2d

[Luis Mochan]

Hi Eric,

With some colleagues we have been developing a system with PDL to
calculate optical properties of metamaterials: macroscopic response,
electric field, non-linear response, spatial dispersion...

https://github.com/wlmb/Photonic
https://metacpan.org/pod/Photonic

Regards,
Luis

On Mon, Oct 10, 2022 at 05:31:43PM -0700, Eric Wheeler wrote:
> On Mon, 15 Aug 2022, Luis Mochan wrote:
>
> > Hello,
> > I tried to use conv2d from PDL::Image2D to make a simple average, as in
> > $z->conv2d(ones(3,3))/9;
> > to take the arithmetic average a pixel with its neareast
> > neighbors. However, what I want to average is a component of an
> > electric field which is complex valued.
>
> Hi Luis,
>
> Just curious, if you're able to share, what kind of electric field work
> are you doing with PDL?
>
> I've been playing with PDL and S-parameters quite a bit if you are in the
> RF domain:
>
>   https://metacpan.org/pod/PDL::IO::Touchstone
>
> ...


-- 

  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-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

Re: [Pdl-general] How would you find where an N-piddle switches from positive to negative?

[Luis Mochan]

Maybe rle can gelp get all sign changes, as in your second example:

 pdl> $a=pdl[ 5.3332316,  4.3332316,  3.3332316,  2.3332316,  1.3332316, 
0.33323163, -0.66676837, -1.6667684, -2.6667684, -3.6667684]
 pdl> p $a
 [ 5.3332316  4.3332316  3.3332316  2.3332316  1.3332316 0.33323163 
-0.66676837 -1.6667684 -2.6667684 -3.6667684]
 pdl> p $a<=>0
 [1 1 1 1 1 1 -1 -1 -1 -1]

$a<=>0 is just the sign of the elements of $a

 pdl> p +($a<=>0)->rle
 [6 4] [1 -1]

which means there are 6 1's followed by 4 -1's

 pdl> ($rle)=($a<=>0)->rle;

$rle has [6 4]

 pdl> p $rle((0))-1
 5

I choose the first sign change with ((0)) and subtract 1 to get the
index from the number of elements.

You can put everything together as in

 pdl> p +[($a<=>0)->rle]->[0]->((0))-1
 5

You could generalize this to get further resonances in more
complicated circuits.

Regards,
Luis


On Wed, Oct 05, 2022 at 06:50:32PM -0700, Eric Wheeler wrote:
> Hello all,
>
> I'm trying to find the series resonant frequency of an RF component, which
> is where the component reactance switches from positive to negtive or
> vice-versa.
>
> Given an N-vector PDL of sorted elements, I need to know at what index it
> switches from positive to negative.
>
> Here are some examples; in real life these are real values from physical
> measurements, so they are never going to be nice round integers---but you
> can assume they will be sorted in ascending or descending order.
>
> Example 1:
>
>   pdl> p sequence(10)-5
>   [-5 -4 -3 -2 -1 0 1 2 3 4]
>^^
>   I need to know "index 4" is the place at which it switches.
>
>
> Example 2:
>
>   pdl> p ((-sequence(10))+5+rand())
>   [ 5.3332316  4.3332316  3.3332316  2.3332316  1.3332316 0.33323163 
> -0.66676837 -1.6667684 -2.6667684 -3.6667684]
>   ^^
>   In this floating-point example it would be "index 5"
>
>
> Is there already a "PDL-broadcast-way" of doing this?
>
> How would you do it?
>
> --
> Eric Wheeler
>
>
> ___
> pdl-general mailing list
> pdl-general@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/pdl-general
>

-- 

  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-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

Re: [Pdl-devel] [Pdl-general] conv2d

[Luis Mochan]

Hi,

On Mon, Aug 22, 2022 at 01:33:45PM +, Ed . wrote:
> Hi Luis,
>
> Glad to hear it! Could you share the code you’ve used? It might make a great 
> demo to add to P:G:Gnuplot.

The following code plots two opaque vertical bars, a black one on the
left and a red one on the right. On top of that it plots two
semitransparent horizontal bars, a black one at the bottom and a green
one on top. I enclose the result: As expected, I get black on
the bottom left corner, red on the bottom right, and green on the top
left. I get some kind of yellow on the top right corresponding to the
red bar seen trough the semitransparent green bar.

use PDL;
use PDL::Graphics::Gnuplot;
my $a=zeroes(2,2);
gplot({terminal=>"pngcairo", output=>"rem.png"},
with=>"rgbalpha",$a->xvals, $a->yvals,
255*$a->xvals, $a->zeroes, $a->zeroes, 255*$a->ones,
with=>"rgbalpha",$a->xvals, $a->yvals,
$a->zeroes, 255*$a->yvals, $a->zeroes, 127*$a->ones);


I tried the "png" terminal, instead of "pngcairo" but it failed.
The interactive terminal 'qt' does work and it exports correctly to
png.

I guess I don't fully understand gnuplot. I tried the plot above but
directly from gnuplot,

gnuplot> plot 'rem.txt' u 1:2:3:5:5:7 w rgbalpha
gnuplot> replot 'rem.txt' u 1:2:5:4:5:6 w rgbalpha

where rem.txt contains the data
0 0 00   0 127 255
0 1 0255 0 127 255

1 0 255  0   0 127 255
1 1 255  255 0 127 255

and the code worked with the interactive 'qt' terminal, yielding the
same image as the one enclosed, but

gnuplot> set term 'pngcairo'
gnuplot> set out 'rem1.png
gnuplot> plot 'rem.txt' u 1:2:3:5:5:7 w rgbalpha
gnuplot> replot 'rem.txt' u 1:2:5:4:5:6 w rgbalpha
gnuplot> set out

failed! (only the red image was plotted).

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

Re: [Pdl-general] [Pdl-devel] conv2d

[Luis Mochan]

Hi,

On Mon, Aug 22, 2022 at 01:33:45PM +, Ed . wrote:
> Hi Luis,
>
> Glad to hear it! Could you share the code you’ve used? It might make a great 
> demo to add to P:G:Gnuplot.

The following code plots two opaque vertical bars, a black one on the
left and a red one on the right. On top of that it plots two
semitransparent horizontal bars, a black one at the bottom and a green
one on top. I enclose the result: As expected, I get black on
the bottom left corner, red on the bottom right, and green on the top
left. I get some kind of yellow on the top right corresponding to the
red bar seen trough the semitransparent green bar.

use PDL;
use PDL::Graphics::Gnuplot;
my $a=zeroes(2,2);
gplot({terminal=>"pngcairo", output=>"rem.png"},
with=>"rgbalpha",$a->xvals, $a->yvals,
255*$a->xvals, $a->zeroes, $a->zeroes, 255*$a->ones,
with=>"rgbalpha",$a->xvals, $a->yvals,
$a->zeroes, 255*$a->yvals, $a->zeroes, 127*$a->ones);


I tried the "png" terminal, instead of "pngcairo" but it failed.
The interactive terminal 'qt' does work and it exports correctly to
png.

I guess I don't fully understand gnuplot. I tried the plot above but
directly from gnuplot,

gnuplot> plot 'rem.txt' u 1:2:3:5:5:7 w rgbalpha
gnuplot> replot 'rem.txt' u 1:2:5:4:5:6 w rgbalpha

where rem.txt contains the data
0 0 00   0 127 255
0 1 0255 0 127 255

1 0 255  0   0 127 255
1 1 255  255 0 127 255

and the code worked with the interactive 'qt' terminal, yielding the
same image as the one enclosed, but

gnuplot> set term 'pngcairo'
gnuplot> set out 'rem1.png
gnuplot> plot 'rem.txt' u 1:2:3:5:5:7 w rgbalpha
gnuplot> replot 'rem.txt' u 1:2:5:4:5:6 w rgbalpha
gnuplot> set out

failed! (only the red image was plotted).

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-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

Re: [Pdl-general] [Pdl-devel] conv2d

[Luis Mochan]

Sorry for the noise, it seems I've got it working now.
Regards,
Luis


On Sun, Aug 21, 2022 at 08:23:51PM -0500, Luis Mochan wrote:
> Hi,
> I have used PDL::Graphics::Gnuplot to display the electric field
> resulting from a calculation for some system. I would like to overlay
> the image of the system over the field. I tried to use the 'png
> transparent' terminal and made the plots {with=>'rgbalpha'} to have an
> alpha channel, but it didn't work. Has anyone been succesful trying to
> do something similar?
> 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-de...@lists.sourceforge.net
> 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  | moc...@fis.unam.mx   /\_/\__/
GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16  C2DF 5F0A C52B 791E B9EB


___
pdl-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

Re: [Pdl-devel] [Pdl-general] conv2d

[Luis Mochan]

Sorry for the noise, it seems I've got it working now.
Regards,
Luis


On Sun, Aug 21, 2022 at 08:23:51PM -0500, Luis Mochan wrote:
> Hi,
> I have used PDL::Graphics::Gnuplot to display the electric field
> resulting from a calculation for some system. I would like to overlay
> the image of the system over the field. I tried to use the 'png
> transparent' terminal and made the plots {with=>'rgbalpha'} to have an
> alpha channel, but it didn't work. Has anyone been succesful trying to
> do something similar?
> 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

--

  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

Re: [Pdl-general] conv2d

[Luis Mochan]

Hi,
I have used PDL::Graphics::Gnuplot to display the electric field
resulting from a calculation for some system. I would like to overlay
the image of the system over the field. I tried to use the 'png
transparent' terminal and made the plots {with=>'rgbalpha'} to have an
alpha channel, but it didn't work. Has anyone been succesful trying to
do something similar?
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-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

Re: [Pdl-devel] [Pdl-general] conv2d

[Luis Mochan]

Hi,
I have used PDL::Graphics::Gnuplot to display the electric field
resulting from a calculation for some system. I would like to overlay
the image of the system over the field. I tried to use the 'png
transparent' terminal and made the plots {with=>'rgbalpha'} to have an
alpha channel, but it didn't work. Has anyone been succesful trying to
do something similar?
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

Re: [Pdl-devel] [Pdl-general] conv2d

[Luis Mochan]

Hi Ed,

On Sun, Aug 21, 2022 at 05:52:11PM +, Ed . wrote:
> Hi Luis,
>
> The init_vars doesn’t do...
> I’ve now merged it to the main branch, thank you! Could you pull it and make 
> sure it works as you expect with your code, so you can at least not rely on a 
> local modification?


It seems to work fine, 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  | 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

Re: [Pdl-general] conv2d

[Luis Mochan]

Hi Ed,

On Sun, Aug 21, 2022 at 05:52:11PM +, Ed . wrote:
> Hi Luis,
>
> The init_vars doesn’t do...
> I’ve now merged it to the main branch, thank you! Could you pull it and make 
> sure it works as you expect with your code, so you can at least not rely on a 
> local modification?


It seems to work fine, 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  | moc...@fis.unam.mx   /\_/\__/
GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16  C2DF 5F0A C52B 791E B9EB


___
pdl-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

Re: [Pdl-general] conv2d

[Luis Mochan]

Done, at PDLPorters/pdl. I'm still unsure about removing 'tmp' from
'init_vars', as it seems to do more than just declaring the variable.

Regards,
Luis


On Mon, Aug 15, 2022 at 11:20:03PM +, Ed . wrote:
> Sorry that you had to add extra bits! Could you PR what you have, and add the 
> test code as a comment on the PR? (I’m happy to bend it into the .t)
>
> Best regards,
> Ed
>
> From: Luis Mochan<mailto:moc...@icf.unam.mx>
> Sent: 15 August 2022 20:23
> To: Ed .<mailto:ej...@hotmail.com>
> Cc: perldl<mailto:pdl-general@lists.sourceforge.net>; 
> perldl<mailto:pdl-de...@lists.sourceforge.net>
> Subject: Re: [Pdl-general] conv2d
>
> Thaks Ed,
> I modified conv2d as you suggested. The result became a CDouble, but
> the imaginary part disappeared. I could fix it by also changing the
> init_vars line (around l. 270), removing the variable tmp, which was
> declared as a double, and declaring it just before the start of the
> broadcastloop using
> $GENERIC() tmp;
> However, as I'm not familiar with init_vars, init_map, etc., I'm not
> sure what I did is correct. I checked with a few examples that it works for
> complex array with real mask, real array with complex mask, and complex
> array with complex mask.
> Regards,
> Luis
>
>
>
> On Mon, Aug 15, 2022 at 05:31:01PM +, Ed . wrote:
> > Hi Luis,
> >
> > For backward compatibility, operations default to supporting all real 
> > types, which is why you’re getting LDouble (the highest-numbered real type, 
> > but still below the complex ones). To make the various Image* operations 
> > work on native complex values, they just need telling to do so.
> >
> > Could you try patching Libtmp/Image2D/image2d.pd with this at the top 
> > (cribbed from Basic/Ops/ops.pd) before the pp_addpm:
> >
> > my $A = [ppdefs_all];
> >
> > Then add “GenericTypes => $A” to at least the pp_def of conv2d, around line 
> > 266?
> >
> > Please let us know if that works (you’d need to do a “make install”, or 
> > else a “make basic” then “perl -Mblib yourlocalscript.pl”). If it does, 
> > feel like PR-ing an update for all the Image* modules in Libtmp? :-)
> >
> > Best regards,
> > Ed
> >
> > From: Luis Mochan<mailto:moc...@icf.unam.mx>
> > Sent: 15 August 2022 17:39
> > To: perldl<mailto:pdl-general@lists.sourceforge.net>; 
> > perldl<mailto:pdl-de...@lists.sourceforge.net>
> > Subject: [Pdl-general] conv2d
> >
> > Hello,
> > I tried to use conv2d from PDL::Image2D to make a simple average, as in
> > $z->conv2d(ones(3,3))/9;
> > to take the arithmetic average a pixel with its neareast
> > neighbors. However, what I want to average is a component of an
> > electric field which is complex valued. It turns out that conv2d
> > doesn't work on complex quantities and the result I obtained was of
> > the LDouble type. Having looked further yet.
> > 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-general mailing list
> > pdl-general@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/pdl-general
> >
>
> --
>
>   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
>

--

  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-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

Re: [Pdl-devel] [Pdl-general] conv2d

[Luis Mochan]

Done, at PDLPorters/pdl. I'm still unsure about removing 'tmp' from
'init_vars', as it seems to do more than just declaring the variable.

Regards,
Luis


On Mon, Aug 15, 2022 at 11:20:03PM +, Ed . wrote:
> Sorry that you had to add extra bits! Could you PR what you have, and add the 
> test code as a comment on the PR? (I’m happy to bend it into the .t)
>
> Best regards,
> Ed
>
> From: Luis Mochan<mailto:moc...@icf.unam.mx>
> Sent: 15 August 2022 20:23
> To: Ed .<mailto:ej...@hotmail.com>
> Cc: perldl<mailto:pdl-gene...@lists.sourceforge.net>; 
> perldl<mailto:pdl-devel@lists.sourceforge.net>
> Subject: Re: [Pdl-general] conv2d
>
> Thaks Ed,
> I modified conv2d as you suggested. The result became a CDouble, but
> the imaginary part disappeared. I could fix it by also changing the
> init_vars line (around l. 270), removing the variable tmp, which was
> declared as a double, and declaring it just before the start of the
> broadcastloop using
> $GENERIC() tmp;
> However, as I'm not familiar with init_vars, init_map, etc., I'm not
> sure what I did is correct. I checked with a few examples that it works for
> complex array with real mask, real array with complex mask, and complex
> array with complex mask.
> Regards,
> Luis
>
>
>
> On Mon, Aug 15, 2022 at 05:31:01PM +, Ed . wrote:
> > Hi Luis,
> >
> > For backward compatibility, operations default to supporting all real 
> > types, which is why you’re getting LDouble (the highest-numbered real type, 
> > but still below the complex ones). To make the various Image* operations 
> > work on native complex values, they just need telling to do so.
> >
> > Could you try patching Libtmp/Image2D/image2d.pd with this at the top 
> > (cribbed from Basic/Ops/ops.pd) before the pp_addpm:
> >
> > my $A = [ppdefs_all];
> >
> > Then add “GenericTypes => $A” to at least the pp_def of conv2d, around line 
> > 266?
> >
> > Please let us know if that works (you’d need to do a “make install”, or 
> > else a “make basic” then “perl -Mblib yourlocalscript.pl”). If it does, 
> > feel like PR-ing an update for all the Image* modules in Libtmp? :-)
> >
> > Best regards,
> > Ed
> >
> > From: Luis Mochan<mailto:moc...@icf.unam.mx>
> > Sent: 15 August 2022 17:39
> > To: perldl<mailto:pdl-gene...@lists.sourceforge.net>; 
> > perldl<mailto:pdl-devel@lists.sourceforge.net>
> > Subject: [Pdl-general] conv2d
> >
> > Hello,
> > I tried to use conv2d from PDL::Image2D to make a simple average, as in
> > $z->conv2d(ones(3,3))/9;
> > to take the arithmetic average a pixel with its neareast
> > neighbors. However, what I want to average is a component of an
> > electric field which is complex valued. It turns out that conv2d
> > doesn't work on complex quantities and the result I obtained was of
> > the LDouble type. Having looked further yet.
> > 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-general mailing list
> > pdl-gene...@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/pdl-general
> >
>
> --
>
>   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
>

--

  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

Re: [Pdl-devel] [Pdl-general] conv2d

[Luis Mochan]

Thaks Ed,
I modified conv2d as you suggested. The result became a CDouble, but
the imaginary part disappeared. I could fix it by also changing the
init_vars line (around l. 270), removing the variable tmp, which was
declared as a double, and declaring it just before the start of the
broadcastloop using
$GENERIC() tmp;
However, as I'm not familiar with init_vars, init_map, etc., I'm not
sure what I did is correct. I checked with a few examples that it works for
complex array with real mask, real array with complex mask, and complex
array with complex mask.
Regards,
Luis



On Mon, Aug 15, 2022 at 05:31:01PM +, Ed . wrote:
> Hi Luis,
>
> For backward compatibility, operations default to supporting all real types, 
> which is why you’re getting LDouble (the highest-numbered real type, but 
> still below the complex ones). To make the various Image* operations work on 
> native complex values, they just need telling to do so.
>
> Could you try patching Libtmp/Image2D/image2d.pd with this at the top 
> (cribbed from Basic/Ops/ops.pd) before the pp_addpm:
>
> my $A = [ppdefs_all];
>
> Then add “GenericTypes => $A” to at least the pp_def of conv2d, around line 
> 266?
>
> Please let us know if that works (you’d need to do a “make install”, or else 
> a “make basic” then “perl -Mblib yourlocalscript.pl”). If it does, feel like 
> PR-ing an update for all the Image* modules in Libtmp? :-)
>
> Best regards,
> Ed
>
> From: Luis Mochan<mailto:moc...@icf.unam.mx>
> Sent: 15 August 2022 17:39
> To: perldl<mailto:pdl-gene...@lists.sourceforge.net>; 
> perldl<mailto:pdl-devel@lists.sourceforge.net>
> Subject: [Pdl-general] conv2d
>
> Hello,
> I tried to use conv2d from PDL::Image2D to make a simple average, as in
> $z->conv2d(ones(3,3))/9;
> to take the arithmetic average a pixel with its neareast
> neighbors. However, what I want to average is a component of an
> electric field which is complex valued. It turns out that conv2d
> doesn't work on complex quantities and the result I obtained was of
> the LDouble type. Having looked further yet.
> 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-general mailing list
> pdl-gene...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/pdl-general
>

--

  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

Re: [Pdl-general] conv2d

[Luis Mochan]

Thaks Ed,
I modified conv2d as you suggested. The result became a CDouble, but
the imaginary part disappeared. I could fix it by also changing the
init_vars line (around l. 270), removing the variable tmp, which was
declared as a double, and declaring it just before the start of the
broadcastloop using
$GENERIC() tmp;
However, as I'm not familiar with init_vars, init_map, etc., I'm not
sure what I did is correct. I checked with a few examples that it works for
complex array with real mask, real array with complex mask, and complex
array with complex mask.
Regards,
Luis



On Mon, Aug 15, 2022 at 05:31:01PM +, Ed . wrote:
> Hi Luis,
>
> For backward compatibility, operations default to supporting all real types, 
> which is why you’re getting LDouble (the highest-numbered real type, but 
> still below the complex ones). To make the various Image* operations work on 
> native complex values, they just need telling to do so.
>
> Could you try patching Libtmp/Image2D/image2d.pd with this at the top 
> (cribbed from Basic/Ops/ops.pd) before the pp_addpm:
>
> my $A = [ppdefs_all];
>
> Then add “GenericTypes => $A” to at least the pp_def of conv2d, around line 
> 266?
>
> Please let us know if that works (you’d need to do a “make install”, or else 
> a “make basic” then “perl -Mblib yourlocalscript.pl”). If it does, feel like 
> PR-ing an update for all the Image* modules in Libtmp? :-)
>
> Best regards,
> Ed
>
> From: Luis Mochan<mailto:moc...@icf.unam.mx>
> Sent: 15 August 2022 17:39
> To: perldl<mailto:pdl-general@lists.sourceforge.net>; 
> perldl<mailto:pdl-de...@lists.sourceforge.net>
> Subject: [Pdl-general] conv2d
>
> Hello,
> I tried to use conv2d from PDL::Image2D to make a simple average, as in
> $z->conv2d(ones(3,3))/9;
> to take the arithmetic average a pixel with its neareast
> neighbors. However, what I want to average is a component of an
> electric field which is complex valued. It turns out that conv2d
> doesn't work on complex quantities and the result I obtained was of
> the LDouble type. Having looked further yet.
> 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-general mailing list
> pdl-general@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/pdl-general
>

--

  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-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

[Pdl-devel] conv2d

[Luis Mochan]

Hello,
I tried to use conv2d from PDL::Image2D to make a simple average, as in
$z->conv2d(ones(3,3))/9;
to take the arithmetic average a pixel with its neareast
neighbors. However, what I want to average is a component of an
electric field which is complex valued. It turns out that conv2d
doesn't work on complex quantities and the result I obtained was of
the LDouble type. Having looked further yet.
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

[Pdl-general] conv2d

[Luis Mochan]

Hello,
I tried to use conv2d from PDL::Image2D to make a simple average, as in
$z->conv2d(ones(3,3))/9;
to take the arithmetic average a pixel with its neareast
neighbors. However, what I want to average is a component of an
electric field which is complex valued. It turns out that conv2d
doesn't work on complex quantities and the result I obtained was of
the LDouble type. Having looked further yet.
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-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

Re: [Pdl-devel] meigen sort criteria for eigenvalue and eigenvectors.

[Luis Mochan]

Dear Guillermo,
I guess the eigenvectors are the rows, not the columns, and they are
normalized!
Regards,
Luis


On Tue, Jul 05, 2022 at 03:05:16PM -0300, Guillermo P. Ortiz wrote:
> Dear PDL developers,
>
> Trying to use meigen() for eigenvalue problem with matrix 4x4 without
> threading for now, I realize that eigenvalues seems did not have any
> ordered output, is not it?
>
> In the first example below the second eigenvalue is larger than the first
>
> ===
> Matrix:
>
> [
>  [   010
>  0]
>  [1.192569864947420 -0.00449505340171719
>  0]
>  [   000
> -1]
>  [ 0.004495053401717190-1.20412391559198
>  0]
> ]
>
> Eigenvalue:
>
> [1.09134187427168 1.09802854880944 -1.09134187427168 -1.09802854880944]
>
> Right Eigenvector (tranposed matrix)
>
> [
>  [ 0.638990630564561  0.697357232402369  0.219312399660024
>  -0.23934480529599]
>  [ 0.218583370045276  0.240010780604692 -0.636866523154502
>  0.699297624204653]
>  [-0.638990630564568  0.697357232402378 -0.219312399660001
> -0.239344805295965]
>  [-0.218583370045231  0.240010780604642  0.636866523154517
> 0.69929762420467]
> ]
>
> In the second example, neither, and also the eigenvectors seem not be
> normalized
> Matrix:
>
> [
>  [0 1 0
> 0]
>  [ 1.18623905553229 0 -3.55105833627078e-10
> 0]
>  [0 0 0
>-1]
>  [ 3.55105833627078e-10 0 -1.21150887543497
> 0]
> ]
>
> [1.08914602121676 -1.08914602121676 1.10068563878838 -1.10068563878838]
>
>
> Thank you in advance.
> Regards
>
> --
>
>
> Dr. Guillermo P. Ortiz
> Electromagnetismo Aplicado
> Dto. Física, Facultad de Ciencias Exactas
> Universidad Nacional del Nordeste
> Avda Libertad 5460, W3404AAS Corrientes,
> Argentina.
> (+54) 379-4424678 interno 4613
> gortiz* at *unne edu ar


> ___
> pdl-devel mailing list
> pdl-devel@lists.sourceforge.net
> 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  | 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

Re: [Pdl-general] [Pdl-devel] meigen sort criteria for eigenvalue and eigenvectors.

[Luis Mochan]

Dear Guillermo,
I guess the eigenvectors are the rows, not the columns, and they are
normalized!
Regards,
Luis


On Tue, Jul 05, 2022 at 03:05:16PM -0300, Guillermo P. Ortiz wrote:
> Dear PDL developers,
>
> Trying to use meigen() for eigenvalue problem with matrix 4x4 without
> threading for now, I realize that eigenvalues seems did not have any
> ordered output, is not it?
>
> In the first example below the second eigenvalue is larger than the first
>
> ===
> Matrix:
>
> [
>  [   010
>  0]
>  [1.192569864947420 -0.00449505340171719
>  0]
>  [   000
> -1]
>  [ 0.004495053401717190-1.20412391559198
>  0]
> ]
>
> Eigenvalue:
>
> [1.09134187427168 1.09802854880944 -1.09134187427168 -1.09802854880944]
>
> Right Eigenvector (tranposed matrix)
>
> [
>  [ 0.638990630564561  0.697357232402369  0.219312399660024
>  -0.23934480529599]
>  [ 0.218583370045276  0.240010780604692 -0.636866523154502
>  0.699297624204653]
>  [-0.638990630564568  0.697357232402378 -0.219312399660001
> -0.239344805295965]
>  [-0.218583370045231  0.240010780604642  0.636866523154517
> 0.69929762420467]
> ]
>
> In the second example, neither, and also the eigenvectors seem not be
> normalized
> Matrix:
>
> [
>  [0 1 0
> 0]
>  [ 1.18623905553229 0 -3.55105833627078e-10
> 0]
>  [0 0 0
>-1]
>  [ 3.55105833627078e-10 0 -1.21150887543497
> 0]
> ]
>
> [1.08914602121676 -1.08914602121676 1.10068563878838 -1.10068563878838]
>
>
> Thank you in advance.
> Regards
>
> --
>
>
> Dr. Guillermo P. Ortiz
> Electromagnetismo Aplicado
> Dto. Física, Facultad de Ciencias Exactas
> Universidad Nacional del Nordeste
> Avda Libertad 5460, W3404AAS Corrientes,
> Argentina.
> (+54) 379-4424678 interno 4613
> gortiz* at *unne edu ar


> ___
> pdl-devel mailing list
> pdl-de...@lists.sourceforge.net
> 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  | moc...@fis.unam.mx   /\_/\__/
GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16  C2DF 5F0A C52B 791E B9EB


___
pdl-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

Re: [Pdl-general] How do you create a set of cdouble matrices from (real, imag) values?

[Luis Mochan]

On Fri, Jul 01, 2022 at 06:48:28PM -0700, Eric Wheeler wrote:
> Thanks Ed and Luis!
>
> I've merged your responses, please see below inline:
> ...
>
> Luis Mochan wrote:
>
> > use v5.12;
> > use PDL;
> > use PDL::Constants qw(PI);
> > use PDL::IO::Misc;
> > # read all data, skip first row
> > my ($f, $M11, $A11, $M21, $A21, $M12, $A12, $M22, $A22)=rcols "rem.s2p", 
> > {LINES=>"1:-1:1"};
> > my $rows=$f->nelem;
> > my $M=pdl($M11, $M12, $M21, $M22); # Indices: filerow, position
> > my $R=pdl($A11, $A12, $A21, $A22)*PI/180; #   filerow, position
> > my $S=$M*exp(i()*$R); #filerow, position
>
> Interesting that you used e^(i*theta) instead of cos and sin.  Is there a
> PDL performance benefit here, or just a simplified notation preference?

Just a simplified notation. My guess is that
cos($R)+i()*sin($R)
would be faster, as the arguments are real (but I'm not certain).
>
> > my $Sm=$S->mv(0,-1) # position, filerow
> >   ->reshape(2,2, $rows); # column, row, filerow
> > say $f, $Sm, $Sm->info;
> >
> > rcols would read all the data into columns. For each row $M and $R would
> > have the magnitudes and the angles in radians, and $S would have the
> > corresponding complex numbers. Then, for each row I rearrange the four
> > corresponding $S's into a 2x2 matrix by first getting the row index
> > out of the way and then doing a reshape. I ran it with a file
>
> The code example is very useful and `rcols` could be very helpful to read
> in the data.
>
> I have the same question as above: correct me if I'm wrong, but it looks
> like you and Ed both produced a (2,2,n) matrix where n is the file row:

Right.

> If I take two such $S matrixes and do some operation like add or multiply,
> will it properly multiply each 2x2 complex matrix at each frequency
> assuming the frequencies are aligned in order?

Yes. You could do $Sm1 + $Sm2 or $Sm1 x $Sm2  where $Sm1 and $Sm2 have
the same structure as $Sm in my example, provided the number of 2x2
matrices (the number of file rows) is the same for both matrices (or
that one of them has exactly one 2x2 matrices), and
assuming that the interpretation of $MagS12 as the magnitude of the entry
$Sm(1,0,$row) in the first row (i=0) second column (j=1) of the matrix
is correct, and multiplication is defined in the usual algebraic way
(through the inner product of rows of the left hand operand with
columns of the right hand operand).

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  | moc...@fis.unam.mx   /\_/\__/
GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16  C2DF 5F0A C52B 791E B9EB


___
pdl-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

Re: [Pdl-general] How do you create a set of cdouble matrices from (real, imag) values?

[Luis Mochan]

Hi,

I would do:

use v5.12;
use PDL;
use PDL::Constants qw(PI);
use PDL::IO::Misc;
# read all data, skip first row
my ($f, $M11, $A11, $M21, $A21, $M12, $A12, $M22, $A22)=rcols "rem.s2p",
{LINES=>"1:-1:1"};
my $rows=$f->nelem;
my $M=pdl($M11, $M12, $M21, $M22); # Indices: filerow, position
my $R=pdl($A11, $A12, $A21, $A22)*PI/180; #   filerow, position
my $S=$M*exp(i()*$R); #filerow, position
my $Sm=$S->mv(0,-1) # position, filerow
  ->reshape(2,2, $rows); # column, row, filerow
say $f, $Sm, $Sm->info;

rcols would read all the data into columns. For each row $M and $R would
have the magnitudes and the angles in radians, and $S would have the
corresponding complex numbers. Then, for each row I rearrange the four
corresponding $S's into a 2x2 matrix by first getting the row index
out of the way and then doing a reshape. I ran it with a file

rem2.s2p:
Freq(MHz)  MagS11  AngS11  MagS21  AngS21   MagS12  AngS12   MagS22  AngS22
100 0.588   50.208  0.770   -35.964  0.770   -35.964  0.588   50.208
200 0.589   51.209  1.771   -34.965  1.771   -34.965  1.589   51.209
300 1   0   1   45   1   90   1   135

and obtained

[100 200 300]
[
 [
  [0.376321423329891+0.451803260659953i 0.623227336287862-0.452203148268051i]
  [0.623227336287862-0.452203148268051i 0.376321423329891+0.451803260659953i]
 ]
 [
  [0.368997536067325+0.459088029005597i   1.45133851899712-1.01491748594417i]
  [  1.45133851899712-1.01491748594417i  0.995478921580609+1.23852441101849i]
 ]
 [
  [16.12323399573677e-17+i]
  [ 0.707106781186548+0.707106781186547i -0.707106781186547+0.707106781186548i]
 ]
]
PDL: CDouble D [2,2,3]

In this case, the filerow index is the last one and I assume that the
indices in the filecolumn labels are in the usual row-column order, so
that, for example, the S12 element corresponding to frequency 300MHz
would be $S->at(1,0,2) (permute the 12 to 21, as pdl uses column index
first, and substract 1 to make the indices zero-based).

Hope it helps.

Regards,
Luis


On Thu, Jun 30, 2022 at 11:59:39PM -0700, Eric Wheeler wrote:
> Hello all,
>
> I'm trying to read RF touchstone (.s2p) files that are in a format like so:
>
> Freq(MHz)  MagS11  AngS11  MagS21  AngS21   MagS12  AngS12   MagS22  AngS22
> 100 0.588   50.208  0.770   -35.964  0.770   -35.964  0.588   50.208
> ...
> 200 0.589   51.209  1.771   -34.965  1.771   -34.965  1.589   51.209
>
> There are thousands of these lines in a file, one line for each measured
> frequency.  Each line represents a complex scattering (S-parameter) matrix
> and the mag/angle format needs to be converted to a `cdouble` to work on
> the matrix mathematically.
>
> A single-line 2x2 complex matrix might look as follows, where S_ji is a
> complex value:
>
>  [ S11  S12 ]
>  [ S21  S22 ]
>
> Since we are provided values in magnitude-angle format (in this example)
> they must be converted to cdoubles so we can work on them.  There are
> several formats: RI, DB, and MA.  For the MA (mag-angle) format this is
> the transform where $a is mag and $b is angle:
>
>   $complex = cos($b*pi()/180) + $a*sin($b*pi()/180) * i
>
> I can generate a vector of 2x4 matrices holding mag-angle pairs by reading
> the file line by line like this:
>
> [
>   [
>[ S11mag S11ang S12mag S12ang ]
>[ S21mag S21ang S22mag S22ang ]
>   ]
>   ... for each line
> ]
>
> I'm new to using PDL and at this point I'm not sure how to convert them to
> a computable form. Since the mag/angle values need to be manipulated in
> parallel before creating a cdouble out of them I'm not sure how to go
> about this.
>
> Here are my questions:
>
> 1. How can I efficiently apply the
>  real = cos($b*pi()/180)
>  imag = $a*sin($b*pi()/180)
>transform to each mag/angle pair where $a is mag and $b is angle?
>
> 2. How can I then (or simultaneously) convert the 2x4 real-imag matrix
>from #1 into a 2x2 cdouble matrix to look something like this?
>
>   [
> [
>  [ S11  S12 ]
>  [ S21  S22 ]
> ]
> ... for each line where Sji are cdoubles
>   ]
>
> 3. Now that I've described the issue, is there a better way to do this?
>
>
> Once they are in a matrix format then PDL can convert them efficiently to
> other matrix types (T, A, Z, Y) to create parallel or series circuits with
> matrix arithmetic at each frequency.  We can then optimize the RF filter
> circuits using component models published by manufacturers from actual
> measurements.
>
> The resulting open-source tool will be comprised of Perl modules from this
> work and published on CPAN.
>
> Thanks for your help!
>
> --
> Eric Wheeler
> KJ7LNW
>
>
> ___
> pdl-general mailing list
> pdl-general@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/pdl-general
>

--

  

Re: [Pdl-general] PDL 2.078

[Luis Mochan]

On Tue, Apr 12, 2022 at 02:55:08PM +, Ed . wrote:
> Hi Luis!
>
> Glad to hear Minuit is still in use. If it were removed from main
> PDL, it would only be to make it available separately on CPAN as
> PDL::Minuit (somewhat similar to PDL::FFTW3).

That's a good option.


> I’m afraid I’m not very knowledgeable about mathematical
> optimisation, but I am aware of other options for PDL somewhat in
> that sphere:
>
>   *   https://metacpan.org/pod/PDL::Opt::NonLinear
>   *   https://metacpan.org/pod/PDL::Opt::QP
>   *   https://metacpan.org/pod/PDL::Opt::Simplex (in main PDL)
>   *   https://metacpan.org/pod/PDL::Fit::LM (in main PDL)
>   *   https://metacpan.org/pod/PDL::Fit::Levmar

Thanks! I wasn't aware of those.

> Also, once the OpenCV stuff is cracked, that will be an example of a
> PDL library using C++, which would then hopefully make a Minuit 2
> interface much easier.

> While I think of it, any chance to look at 
> https://github.com/wlmb/Photonic/pull/23? :-)

Sorry about the long delay!

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-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

Re: [Pdl-general] PDL 2.078

[Luis Mochan]

On Mon, Apr 11, 2022 at 04:12:43PM +, Ed . wrote:
> ...
> ...The Fortran code in those submodules (Minuit and Slatec) are
> written in Fortran 77, and are dramatically obsolete. We may or may
> not remove them into separate distributions, since I doubt anyone uses
> them.

I do... :(

What would be the recommended modules, alternative to minuit, to
optimize multiparameter functions using the current PDL?


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-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

Re: Re: bluetooth audio

[Luis Mochan]

Thanks!

-- 
WLM

bluetooth audio

[Luis Mochan]

After a recent update/upgrade in debian/bookworm my bluetooth
earphones and my bluetooth earphones stopped working.
I found a solution in the discussion of at

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=997862=no=no=no

related to bug #997862 which seemed to work for me, that is,
installing a package libspa-0.2-bluetooth.

I'm not sure what is happening, but I guess it should have been
installed automatically if it was required not to break my system (and I
guess others).

I would like to file a bug report, but I'm not sure the origin is in
the wireplumber package (I don't know why it got installed in my
system).

I will appreciate any advice.

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

Re: [Pdl-general] [Pdl-devel] benchmarks

[Luis Mochan]

Now I have run the C benchmark and Ed's. My results are:

   | Program  | # iterations | time (s) | speed (K/s) | factor |
   |--+--+--+-+|
   | ansi c   |150e6 |  133 |   1127.8195 | 1. |
   | perl |1.5e6 |   56 |   26.785714 |   42.1 |
   | my pdl   | 15e6 |   67 |   223.88060 |5.0 |
   | Ed's pdl | 15e6 |   16 |   937.5 |1.2 |
   | Ed's 4 cores | 15e6 |   11 |   1363.6364 |0.8 |

So, as Ed wrote, just by stting and environment variable,
perl+pdl+pp_def can be made faster than c.




On Sat, Oct 02, 2021 at 07:03:50PM -0500, Luis Mochan wrote:
> I made my own version of the ray-tracing program (as I tried to
> understand it). I didn't use pp_def, only Perl and ordinary PDL. I used
> ...

--

  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-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

Re: [Pdl-devel] benchmarks

[Luis Mochan]

Now I have run the C benchmark and Ed's. My results are:

   | Program  | # iterations | time (s) | speed (K/s) | factor |
   |--+--+--+-+|
   | ansi c   |150e6 |  133 |   1127.8195 | 1. |
   | perl |1.5e6 |   56 |   26.785714 |   42.1 |
   | my pdl   | 15e6 |   67 |   223.88060 |5.0 |
   | Ed's pdl | 15e6 |   16 |   937.5 |1.2 |
   | Ed's 4 cores | 15e6 |   11 |   1363.6364 |0.8 |

So, as Ed wrote, just by stting and environment variable,
perl+pdl+pp_def can be made faster than c.




On Sat, Oct 02, 2021 at 07:03:50PM -0500, Luis Mochan wrote:
> I made my own version of the ray-tracing program (as I tried to
> understand it). I didn't use pp_def, only Perl and ordinary PDL. I used
> ...

--

  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

Re: [Pdl-general] [Pdl-devel] benchmarks

[Luis Mochan]

urfaces than 4, or (as mentioned below) with a large number of 
> different ray heights. That could then benefit from pthreading.
>
> Comments very welcome on the design of the PP function and its use of 
> threading!
>
> Best regards,
> Ed
>
> From: Ed .<mailto:ej...@hotmail.com>
> Sent: 30 September 2021 16:38
> To: Luis Mochan<mailto:moc...@icf.unam.mx>; 
> perldl<mailto:pdl-general@lists.sourceforge.net>; 
> perldl<mailto:pdl-de...@lists.sourceforge.net>
> Subject: RE: [Pdl-devel] benchmarks
>
> Hi Luis,
>
> That was very interesting in the part about Raku, and I think I agree with 
> the author’s comments about that language.
>
> I have made a (so-far very naïve) PDL version, visible at 
> https://github.com/Fourmilab/floating_point_benchmarks/pull/1/files?diff=unified=1.
>  This caused some difficulties, exacerbated by John’s technique of functions’ 
> inputs and outputs being via globals(!), and the copying of those needing (in 
> PDL-land) to be a “->copy” not the normal PDL reference-copy.
>
> As a result of an initially-mistaken analysis of the differences actually 
> caused by the copying semantics, I have learned that Perl’s Math::Trig does 
> not use a C library function, but calculates the value in pure Perl. This is 
> almost certainly why Perl gets correct but slow answers in John’s benchmark 
> (20+ times slower than C).
>
> The current naïve PDL version is much slower than the pure-Perl (about 70 
> times), because it is using the PDL machinery to calculate single values, 
> which PDL isn’t for. For completeness, I will now make the PDL version have a 
> PP function will carry out the algorithm in C-land but in a PP-idiomatic way. 
> This would then be usable with PDL-threading (including pthreading) to 
> simultaneously calculate a large number of ray paths, perhaps for use in 
> making a graphical representation of light travelling through refraction 
> paths.
>
> By the way, the Python number of 2.6 times the time for C isn’t scipy, but 
> PyPy, a JIT compiler for Python. I won’t be investigating, but I’d assume 
> that NumPy/scipy would have the same performance difficulties in this 
> benchmark as PDL, and for similar reasons.
>
> Best regards,
> Ed
>
> From: Luis Mochan<mailto:moc...@icf.unam.mx>
> Sent: 28 September 2021 00:47
> To: perldl<mailto:pdl-general@lists.sourceforge.net>; 
> perldl<mailto:pdl-de...@lists.sourceforge.net>
> Subject: [Pdl-devel] benchmarks
>
> Hi all,
>
> I read today in a Raku newsletter about a floating point
> benchmark of several languages.
> 
> https://www.fourmilab.ch/scanalyzer/archives/2021/09/floating-point-benchmark-raku-perl-6-language-added.html
>
> Taking C=1 as a reference, Julia=1.5, Python=2.6-30, Perl=23,
> Raku=205-735, Mathematica=391.
>
> I guess Perl with PDL would be much faster, as Python with scipy.
>
> Are there any benchmarks that compare PDL's speed to others?
>
> 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<mailto:moc...@fis.unam.mx>   /\_/\__/
> GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16  C2DF 5F0A C52B 791E B9EB
>
>
> ___
> pdl-devel mailing list
> pdl-de...@lists.sourceforge.net<mailto:pdl-de...@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/pdl-devel
>
>
> ___
> pdl-devel mailing list
> pdl-de...@lists.sourceforge.net<mailto:pdl-de...@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/pdl-devel
>
>
> --
> Boyd Duffee
>Bring on a brand-new renaissance - The Tragically Hip
>
>


> ___
> pdl-devel mailing list
> pdl-de...@lists.sourceforge.net
> 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  | moc...@fis.unam.mx   /\_/\__/
GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16  C2DF 5F0A C52B 791E B9EB


___
pdl-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

Re: [Pdl-devel] benchmarks

[Luis Mochan]

urfaces than 4, or (as mentioned below) with a large number of 
> different ray heights. That could then benefit from pthreading.
>
> Comments very welcome on the design of the PP function and its use of 
> threading!
>
> Best regards,
> Ed
>
> From: Ed .<mailto:ej...@hotmail.com>
> Sent: 30 September 2021 16:38
> To: Luis Mochan<mailto:moc...@icf.unam.mx>; 
> perldl<mailto:pdl-gene...@lists.sourceforge.net>; 
> perldl<mailto:pdl-devel@lists.sourceforge.net>
> Subject: RE: [Pdl-devel] benchmarks
>
> Hi Luis,
>
> That was very interesting in the part about Raku, and I think I agree with 
> the author’s comments about that language.
>
> I have made a (so-far very naïve) PDL version, visible at 
> https://github.com/Fourmilab/floating_point_benchmarks/pull/1/files?diff=unified=1.
>  This caused some difficulties, exacerbated by John’s technique of functions’ 
> inputs and outputs being via globals(!), and the copying of those needing (in 
> PDL-land) to be a “->copy” not the normal PDL reference-copy.
>
> As a result of an initially-mistaken analysis of the differences actually 
> caused by the copying semantics, I have learned that Perl’s Math::Trig does 
> not use a C library function, but calculates the value in pure Perl. This is 
> almost certainly why Perl gets correct but slow answers in John’s benchmark 
> (20+ times slower than C).
>
> The current naïve PDL version is much slower than the pure-Perl (about 70 
> times), because it is using the PDL machinery to calculate single values, 
> which PDL isn’t for. For completeness, I will now make the PDL version have a 
> PP function will carry out the algorithm in C-land but in a PP-idiomatic way. 
> This would then be usable with PDL-threading (including pthreading) to 
> simultaneously calculate a large number of ray paths, perhaps for use in 
> making a graphical representation of light travelling through refraction 
> paths.
>
> By the way, the Python number of 2.6 times the time for C isn’t scipy, but 
> PyPy, a JIT compiler for Python. I won’t be investigating, but I’d assume 
> that NumPy/scipy would have the same performance difficulties in this 
> benchmark as PDL, and for similar reasons.
>
> Best regards,
> Ed
>
> From: Luis Mochan<mailto:moc...@icf.unam.mx>
> Sent: 28 September 2021 00:47
> To: perldl<mailto:pdl-gene...@lists.sourceforge.net>; 
> perldl<mailto:pdl-devel@lists.sourceforge.net>
> Subject: [Pdl-devel] benchmarks
>
> Hi all,
>
> I read today in a Raku newsletter about a floating point
> benchmark of several languages.
> 
> https://www.fourmilab.ch/scanalyzer/archives/2021/09/floating-point-benchmark-raku-perl-6-language-added.html
>
> Taking C=1 as a reference, Julia=1.5, Python=2.6-30, Perl=23,
> Raku=205-735, Mathematica=391.
>
> I guess Perl with PDL would be much faster, as Python with scipy.
>
> Are there any benchmarks that compare PDL's speed to others?
>
> 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<mailto: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<mailto:pdl-devel@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/pdl-devel
>
>
> ___
> pdl-devel mailing list
> pdl-devel@lists.sourceforge.net<mailto:pdl-devel@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/pdl-devel
>
>
> --
> Boyd Duffee
>Bring on a brand-new renaissance - The Tragically Hip
>
>


> ___
> pdl-devel mailing list
> pdl-devel@lists.sourceforge.net
> 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  | 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

[Pdl-general] benchmarks

[Luis Mochan]

Hi all,

I read today in a Raku newsletter about a floating point
benchmark of several languages.

https://www.fourmilab.ch/scanalyzer/archives/2021/09/floating-point-benchmark-raku-perl-6-language-added.html

Taking C=1 as a reference, Julia=1.5, Python=2.6-30, Perl=23,
Raku=205-735, Mathematica=391.

I guess Perl with PDL would be much faster, as Python with scipy.

Are there any benchmarks that compare PDL's speed to others?

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-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

[Pdl-devel] benchmarks

[Luis Mochan]

Hi all,

I read today in a Raku newsletter about a floating point
benchmark of several languages.

https://www.fourmilab.ch/scanalyzer/archives/2021/09/floating-point-benchmark-raku-perl-6-language-added.html

Taking C=1 as a reference, Julia=1.5, Python=2.6-30, Perl=23,
Raku=205-735, Mathematica=391.

I guess Perl with PDL would be much faster, as Python with scipy.

Are there any benchmarks that compare PDL's speed to others?

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

Re: [Pdl-general] [Pdl-devel] native complex and PDL::LinearAlgebra

[Luis Mochan]

On Mon, Sep 27, 2021 at 02:07:49PM +, Ed . wrote:
> ...If you can PR on PDL::LA with failing tests and maybe also fixes,
> that would be incredibly helpful!

I'll try asap.


--

  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-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

Re: [Pdl-devel] native complex and PDL::LinearAlgebra

[Luis Mochan]

On Mon, Sep 27, 2021 at 02:07:49PM +, Ed . wrote:
> ...If you can PR on PDL::LA with failing tests and maybe also fixes,
> that would be incredibly helpful!

I'll try asap.


--

  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

Re: [Pdl-general] [Pdl-devel] native complex and PDL::LinearAlgebra

[Luis Mochan]

Thanks!

I started looking around PDL::LinearAlgebra, and, as I suspected, many
of the routines should be modified to accomodate the native
complex'es.  For example, consider a 1x1 complex square matrix:

pdl> use PDL::LinearAlgebra
pdl> $a=pdl([[i()]])
pdl> p $a
[
 [i]
]
pdl> p $a->t
[
 [i]
]
pdl> p $a->issym
1

pdl> use PDL::Complex
Subroutine sumover redefined...
pdl> $b=pdl([[1]])*i()
pdl> p $b
[
 [i]
]
pdl> p $b->t
[
 [-i]
]
pdl> p $b->issym
0
pdl>



Thus, the 't' method transposes the matrix if it uses native complex
numbers, but transposes it *and* conjugates it (by default) if it uses
PDL::Complex numbers. Similarly, the issym function tests for symmetry
when acting on PDL's (even native complex ones), but test for Hermiticity
when acting on PDL::Complex's. The same happens for most other
routines that act differently on complex than on real numbers, but treat
PDL's as real and only PDL::Complex's as complex.

Regards,
Luis



On Sat, Sep 25, 2021 at 06:51:48PM +, Ed . wrote:
> Thank you. Now merged your change (thanks for adding tests too) and released 
> 0.23.
>
> From: Luis Mochan<mailto:moc...@icf.unam.mx>
> Sent: 25 September 2021 18:49
> To: perldl<mailto:pdl-general@lists.sourceforge.net>; 
> perldl<mailto:pdl-de...@lists.sourceforge.net>
> Subject: Re: [Pdl-devel] native complex and PDL::LinearAlgebra
>
> On Sat, Sep 25, 2021 at 03:33:29PM +, Ed . wrote:
> > Hi Luis,
> >
> > I’ll take a look shortly (in the final stages of getting the multi-C to 
> > work). Can you confirm whether this worked according to your expectation in 
> > 2.057?
>
> This failed in 2.057.
>
> Best regards,
> Luis
>
>
> > From: Luis Mochan<mailto:moc...@icf.unam.mx>
> > Sent: 25 September 2021 15:49
> > To: perldl<mailto:pdl-general@lists.sourceforge.net>; 
> > perldl<mailto:pdl-de...@lists.sourceforge.net>
> > Subject: [Pdl-devel] native complex and PDL::LinearAlgebra
> >
> >
> > Hi,
> >
> > Congrats on the new release.
> >
> > I found an error in PDL::LinearAlgebra.
> >
> > pdl> use PDL::LinearAlgebra
> > pdl> $a=(1+sequence(2,2))*i()
> > pdl> p $a
> > [
> >  [ i 2i]
> >  [3i 4i]
> > ]
> > pdl> p $a->mdet
> > 0# instead of 2
> >
>
>
> --
>
>   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-de...@lists.sourceforge.net
> 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  | moc...@fis.unam.mx   /\_/\__/
GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16  C2DF 5F0A C52B 791E B9EB


___
pdl-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

Re: [Pdl-devel] native complex and PDL::LinearAlgebra

[Luis Mochan]

Thanks!

I started looking around PDL::LinearAlgebra, and, as I suspected, many
of the routines should be modified to accomodate the native
complex'es.  For example, consider a 1x1 complex square matrix:

pdl> use PDL::LinearAlgebra
pdl> $a=pdl([[i()]])
pdl> p $a
[
 [i]
]
pdl> p $a->t
[
 [i]
]
pdl> p $a->issym
1

pdl> use PDL::Complex
Subroutine sumover redefined...
pdl> $b=pdl([[1]])*i()
pdl> p $b
[
 [i]
]
pdl> p $b->t
[
 [-i]
]
pdl> p $b->issym
0
pdl>



Thus, the 't' method transposes the matrix if it uses native complex
numbers, but transposes it *and* conjugates it (by default) if it uses
PDL::Complex numbers. Similarly, the issym function tests for symmetry
when acting on PDL's (even native complex ones), but test for Hermiticity
when acting on PDL::Complex's. The same happens for most other
routines that act differently on complex than on real numbers, but treat
PDL's as real and only PDL::Complex's as complex.

Regards,
Luis



On Sat, Sep 25, 2021 at 06:51:48PM +, Ed . wrote:
> Thank you. Now merged your change (thanks for adding tests too) and released 
> 0.23.
>
> From: Luis Mochan<mailto:moc...@icf.unam.mx>
> Sent: 25 September 2021 18:49
> To: perldl<mailto:pdl-gene...@lists.sourceforge.net>; 
> perldl<mailto:pdl-devel@lists.sourceforge.net>
> Subject: Re: [Pdl-devel] native complex and PDL::LinearAlgebra
>
> On Sat, Sep 25, 2021 at 03:33:29PM +, Ed . wrote:
> > Hi Luis,
> >
> > I’ll take a look shortly (in the final stages of getting the multi-C to 
> > work). Can you confirm whether this worked according to your expectation in 
> > 2.057?
>
> This failed in 2.057.
>
> Best regards,
> Luis
>
>
> > From: Luis Mochan<mailto:moc...@icf.unam.mx>
> > Sent: 25 September 2021 15:49
> > To: perldl<mailto:pdl-gene...@lists.sourceforge.net>; 
> > perldl<mailto:pdl-devel@lists.sourceforge.net>
> > Subject: [Pdl-devel] native complex and PDL::LinearAlgebra
> >
> >
> > Hi,
> >
> > Congrats on the new release.
> >
> > I found an error in PDL::LinearAlgebra.
> >
> > pdl> use PDL::LinearAlgebra
> > pdl> $a=(1+sequence(2,2))*i()
> > pdl> p $a
> > [
> >  [ i 2i]
> >  [3i 4i]
> > ]
> > pdl> p $a->mdet
> > 0# instead of 2
> >
>
>
> --
>
>   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
>

--

  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

Re: [Pdl-general] [Pdl-devel] native complex and PDL::LinearAlgebra

[Luis Mochan]

On Sat, Sep 25, 2021 at 03:33:29PM +, Ed . wrote:
> Hi Luis,
>
> I’ll take a look shortly (in the final stages of getting the multi-C to 
> work). Can you confirm whether this worked according to your expectation in 
> 2.057?

This failed in 2.057.

Best regards,
Luis


> From: Luis Mochan<mailto:moc...@icf.unam.mx>
> Sent: 25 September 2021 15:49
> To: perldl<mailto:pdl-general@lists.sourceforge.net>; 
> perldl<mailto:pdl-de...@lists.sourceforge.net>
> Subject: [Pdl-devel] native complex and PDL::LinearAlgebra
>
>
> Hi,
>
> Congrats on the new release.
>
> I found an error in PDL::LinearAlgebra.
>
> pdl> use PDL::LinearAlgebra
> pdl> $a=(1+sequence(2,2))*i()
> pdl> p $a
> [
>  [ i 2i]
>  [3i 4i]
> ]
> pdl> p $a->mdet
> 0# instead of 2
>


--

  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-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

Re: [Pdl-devel] native complex and PDL::LinearAlgebra

[Luis Mochan]

On Sat, Sep 25, 2021 at 03:33:29PM +, Ed . wrote:
> Hi Luis,
>
> I’ll take a look shortly (in the final stages of getting the multi-C to 
> work). Can you confirm whether this worked according to your expectation in 
> 2.057?

This failed in 2.057.

Best regards,
Luis


> From: Luis Mochan<mailto:moc...@icf.unam.mx>
> Sent: 25 September 2021 15:49
> To: perldl<mailto:pdl-gene...@lists.sourceforge.net>; 
> perldl<mailto:pdl-devel@lists.sourceforge.net>
> Subject: [Pdl-devel] native complex and PDL::LinearAlgebra
>
>
> Hi,
>
> Congrats on the new release.
>
> I found an error in PDL::LinearAlgebra.
>
> pdl> use PDL::LinearAlgebra
> pdl> $a=(1+sequence(2,2))*i()
> pdl> p $a
> [
>  [ i 2i]
>  [3i 4i]
> ]
> pdl> p $a->mdet
> 0# instead of 2
>


--

  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

[Pdl-general] native complex and PDL::LinearAlgebra

[Luis Mochan]

Hi,

Congrats on the new release.

I found an error in PDL::LinearAlgebra.

pdl> use PDL::LinearAlgebra
pdl> $a=(1+sequence(2,2))*i()
pdl> p $a
[
 [ i 2i]
 [3i 4i]
]
pdl> p $a->mdet
0# instead of 2

I believe the problem lies in the code that distinguishes which lapack
LU factorization routine to use. There is a complex routine cgetrf,
called when the object is a PDL::Complex, and a real routine geterf,
called when the object is a PDL. However, native complex types are of
the PDL type. I made a pull request. Nevertheless, I believe that this
kind of errors might appear elsewhere.

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-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

[Pdl-devel] sequence

[Luis Mochan]

Hi,

I just discovered a mistake in one of my codes as I misunderstood the
behavior of 'sequence':

 pdl> p sequence 5
 [0 1 2 3 4]
 pdl> p sequence pdl 5
 0
 pdl> p sequence zeroes(5)
 [0 1 2 3 4]
 pdl> p sequence(2,3)
 [
  [0 1]
  [2 3]
  [4 5]
 ]
 pdl> p sequence(pdl(2),pdl(3))
 0

Thus, it seems that sequence behaves like zeroes, ones, etc. when it
gets pdl scalars as arguments, ignoring their value.
The documentation suggests to 'see zeroes',

 pdl> help sequence
 Module  PDL::Basic
   sequence
 Create array filled with a sequence of values

  $w = sequence($y); $w = sequence [OPTIONAL TYPE], @dims;

 etc. see zeroes.

  pdl> p sequence(10)
  [0 1 2 3 4 5 6 7 8 9]
  pdl> p sequence(3,4)
  [
   [ 0  1  2]
   [ 3  4  5]
   [ 6  7  8]
   [ 9 10 11]
  ]


but maybe adding an example with a template argument such as
$pdl_scalar->sequence, sequence($pdl_scalar), $ndarray->sequence, and
sequence($ndarray) would help avoid surprises.

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

[Pdl-general] sequence

[Luis Mochan]

Hi,

I just discovered a mistake in one of my codes as I misunderstood the
behavior of 'sequence':

 pdl> p sequence 5
 [0 1 2 3 4]
 pdl> p sequence pdl 5
 0
 pdl> p sequence zeroes(5)
 [0 1 2 3 4]
 pdl> p sequence(2,3)
 [
  [0 1]
  [2 3]
  [4 5]
 ]
 pdl> p sequence(pdl(2),pdl(3))
 0

Thus, it seems that sequence behaves like zeroes, ones, etc. when it
gets pdl scalars as arguments, ignoring their value.
The documentation suggests to 'see zeroes',

 pdl> help sequence
 Module  PDL::Basic
   sequence
 Create array filled with a sequence of values

  $w = sequence($y); $w = sequence [OPTIONAL TYPE], @dims;

 etc. see zeroes.

  pdl> p sequence(10)
  [0 1 2 3 4 5 6 7 8 9]
  pdl> p sequence(3,4)
  [
   [ 0  1  2]
   [ 3  4  5]
   [ 6  7  8]
   [ 9 10 11]
  ]


but maybe adding an example with a template argument such as
$pdl_scalar->sequence, sequence($pdl_scalar), $ndarray->sequence, and
sequence($ndarray) would help avoid surprises.

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-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

[Pdl-general] [moc...@icf.unam.mx: Re: [Pdl-devel] P::G::Gnuplot 2.017]

[Luis Mochan]

- Forwarded message from Luis Mochan  -

Date: Wed, 11 Aug 2021 10:01:38 -0500
From: Luis Mochan 
To: "Ed ." 
Subject: Re: [Pdl-devel] P::G::Gnuplot 2.017

Hi,


On Wed, Aug 11, 2021 at 05:32:25AM +, Ed . wrote:
> Hi Luis,
>
> It will really help if you can give which version of PDL you have, and also 
> whether you’ve tried exactly the same script on different versions of PDL 
> and/or P:G:Gnuplot to make it easier/possible to track down what’s changed?

Sorry. I'm running PDL 2.056 and gnuplot 2.017. I haven't tried
different combinations, but I don't recall this behavior previously. I
tried this morning Zaki Mughal's proposed fix and it seems to work.

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

- 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  | moc...@fis.unam.mx   /\_/\__/
GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16  C2DF 5F0A C52B 791E B9EB


___
pdl-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

[Pdl-devel] [moc...@icf.unam.mx: Re: P::G::Gnuplot 2.017]

[Luis Mochan]

- Forwarded message from Luis Mochan  -

Date: Wed, 11 Aug 2021 10:01:38 -0500
From: Luis Mochan 
To: "Ed ." 
Subject: Re: [Pdl-devel] P::G::Gnuplot 2.017

Hi,


On Wed, Aug 11, 2021 at 05:32:25AM +, Ed . wrote:
> Hi Luis,
>
> It will really help if you can give which version of PDL you have, and also 
> whether you’ve tried exactly the same script on different versions of PDL 
> and/or P:G:Gnuplot to make it easier/possible to track down what’s changed?

Sorry. I'm running PDL 2.056 and gnuplot 2.017. I haven't tried
different combinations, but I don't recall this behavior previously. I
tried this morning Zaki Mughal's proposed fix and it seems to work.

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

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

[Pdl-general] P::G::Gnuplot 2.017

[Luis Mochan]

Hi,

I'm having some trouble with PDL::Graphics::Gnuplot, which is behaving
strangely lately. Consider:

 mochan@yapaque:~$ pdl
 perlDL shell v1.357
 ...
 pdl> use PDL::Graphics::Gnuplot
 pdl> $x=zeroes(50)->xlinvals(0, 7)
 pdl> $w=gpwin("pdfcairo", output=>"rem.pdf");
 pdl> $w->plot(with=>lines,$x,$x->sin)
 pdl> $w->close
 pdl> quit
 mochan@yapaque:~$ file rem.pdf
 rem.pdf: empty

So I try to plot into a pdf file, but the file is empty.

Any advice?

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  | moc...@fis.unam.mx   /\_/\__/
GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16  C2DF 5F0A C52B 791E B9EB


___
pdl-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

[Pdl-general] [moc...@icf.unam.mx: Re: [Pdl-devel] lu_backsub]

[Luis Mochan]

Hi Ed,

On Fri, Jun 11, 2021 at 06:30:51PM +, Ed . wrote:
> Hi Luis,
>
> Thank you for the kind words! I think your points are of course valid. 
> However, I’m hoping you can help me understand your expectations a bit 
> better, so the tests, and then the code (and maybe the docs!), can be made to 
> match them better.
>
> In terms of dimensions, my understanding was that where there are vectors in 
> linear algebra, they are actually (in row * column notation) a 1 * n matrix, 
> because I thought linear algebra was all about matrix multiplication, being 
> inherently x*n matrices to be multiplied by n*y matrices. If I’m wrong on 
> that, then could you clarify?

I think the problem we are discussing is just a matter of
convention. Thus, I insist that it is not very important how this is
solved, as long as it is consistent.

As I understand it, Linear Algebra is related to the
linear transformation of vectors. The transformations are represented
by matrices and the vectors by (linear) arrays. Then a transformation T
acting on a vector V is another vector W=T V which is represented by the
product of the matrix T_{ij} by the array V_j, i.e., W_i=T_{ij} V_j
(summing over the repeated index j), where T_{ij} is the element on
the i-th row and j-th column. This would correspond to the usual inner
product of PDL, i.e., $W=$T->inner($V). However, vectors could also be
represented by one-column matrices. Then the product would be given by
the ordinary matrix product, not the inner product, i.e., $Wc=$T x
$Vc. The advantage of this approach is that you represent matrices and
vectors alike. Furthermore, if you build a matrix $Vmc from many
columns, you can transform all columns simultaneously through the
matrix product and obtain a matrix $Wmc out of the resulting columns,
i.e., $Wmc=$T x $Vmc.


Thus, currently I believe that the ideal solution would be for lu_backsub
to mimic the behavior of the matrix product 'x'. If you feed it a 1D
array it should complain and refuse to work. This shouldn't be
troublesome as one can convert from vector to column matrix by adding a
dummy dimension. Then the solution of a system of equations would also
be a column matrix. If the right hand side of the equation has n
columns, it should correspond to n systems of equations with the same
coefficients. Then the answer would also have n columns, one for each
solution. This way, the expected matrix, lu decomposition, right hand
side and solutions would all be 2D matrices. Then, one could do
ordinary threading over any extra dimensions in the matrix of
coefficients, their lu decompositions and/or right the hand sides of
the system of equations.
pdl> $m=sequence(2,2)
pdl> $x=sequence(1,2)
pdl> p $x
=>[[0],[1]] #edited
pdl> p $m x $x
=>[[1],[3]]
pdl> p $m x $x->dummy(2,2)
=>[[[1],[3]],[[1],[3]]]
pdl> p $m->dummy(2,2) x $x
=>[[[1],[3]],[[1],[3]]]
pdl> p $m->dummy(2,2) x $x->dummy(2,2)
=>[[[1],[3]],[[1],[3]]]

Actually, that is the current behavior of lu_backsub, except that it
represents a set of vectors as a matrix with a row per vector instead
of a column per vector for both the input and output. Thus, the need
for transpositions.
pdl> p lu_backsub(lu_decomp($m), $x->transpose)->transpose
=>[[0.5],[0]] #edited
pdl> p lu_backsub(lu_decomp($m), $x->transpose->dummy(2))->transpose
=>[[[0.5],[0]]]
pdl> p lu_backsub(lu_decomp($m), $x->transpose->dummy(2,2))->transpose
=>[[[0.5],[0]],[[0.5],[0]]]
pdl> p lu_backsub(lu_decomp($m->dummy(2,2)), $x->transpose)->transpose
=>[[[0.5],[0]],[[0.5],[0]]]
pdl> p lu_backsub(lu_decomp($m->dummy(2,2)), 
$x->transpose->dummy(2,2))->transpose
=>[[[0.5],[0]],[[0.5],[0]]]


The problem with my original suggestion that 1D inputs should yield 1D
outputs would be that it would lead to an ambiguity in the
interpretation of a 2D or higher dimensional input. In
pdl> $m=random(3,3,4);
pdl> $y=random(3,4);
pdl> $x=lu_backsub(lu_decomp($m), $y)->transpose
should $x be interpreted as 4 1D vectors $x(:,($j)) $j=0..3
each of which obeys the system
$m(:,:,($j)) x $x(:,$j)->transpose=$y(:,$j)->transpose
(i.e., four systems of equations, each with a different 3x3 coefficients,
different 3-vector right hand sides and different 3-vector solutions for
each $j) or should it be interperted as a set of matrices $x(:,:,($j))
each of which obeys
$m(:,:,($j)) x $x(:,:,($j))->transpose=$y(:,:)->transpose
that is, four system of equations, each with different coefficients
matrix but with the same 3x4 matricial right hand
side and with four 3x4 matricial solutions.

By demanding that the input be 2D at least there would be no ambiguity
Thus my suggestion would be to keep the current behavior of lu_backsub
except that it should die if the input is a 1D vector, or complain, or
the documentation should say that 1D vectors would be converted to 2D
matrices. The documentation should also say that the second dimension
of the right hand side is not a threading dimension.

The signature should then look like
lu(m,m); perm(m); b(m,n); [o] 

[Pdl-devel] [moc...@icf.unam.mx: Re: [Pdl-general] lu_backsub]

[Luis Mochan]

Hi Ed,

On Fri, Jun 11, 2021 at 06:30:51PM +, Ed . wrote:
> Hi Luis,
>
> Thank you for the kind words! I think your points are of course valid. 
> However, I’m hoping you can help me understand your expectations a bit 
> better, so the tests, and then the code (and maybe the docs!), can be made to 
> match them better.
>
> In terms of dimensions, my understanding was that where there are vectors in 
> linear algebra, they are actually (in row * column notation) a 1 * n matrix, 
> because I thought linear algebra was all about matrix multiplication, being 
> inherently x*n matrices to be multiplied by n*y matrices. If I’m wrong on 
> that, then could you clarify?

I think the problem we are discussing is just a matter of
convention. Thus, I insist that it is not very important how this is
solved, as long as it is consistent.

As I understand it, Linear Algebra is related to the
linear transformation of vectors. The transformations are represented
by matrices and the vectors by (linear) arrays. Then a transformation T
acting on a vector V is another vector W=T V which is represented by the
product of the matrix T_{ij} by the array V_j, i.e., W_i=T_{ij} V_j
(summing over the repeated index j), where T_{ij} is the element on
the i-th row and j-th column. This would correspond to the usual inner
product of PDL, i.e., $W=$T->inner($V). However, vectors could also be
represented by one-column matrices. Then the product would be given by
the ordinary matrix product, not the inner product, i.e., $Wc=$T x
$Vc. The advantage of this approach is that you represent matrices and
vectors alike. Furthermore, if you build a matrix $Vmc from many
columns, you can transform all columns simultaneously through the
matrix product and obtain a matrix $Wmc out of the resulting columns,
i.e., $Wmc=$T x $Vmc.


Thus, currently I believe that the ideal solution would be for lu_backsub
to mimic the behavior of the matrix product 'x'. If you feed it a 1D
array it should complain and refuse to work. This shouldn't be
troublesome as one can convert from vector to column matrix by adding a
dummy dimension. Then the solution of a system of equations would also
be a column matrix. If the right hand side of the equation has n
columns, it should correspond to n systems of equations with the same
coefficients. Then the answer would also have n columns, one for each
solution. This way, the expected matrix, lu decomposition, right hand
side and solutions would all be 2D matrices. Then, one could do
ordinary threading over any extra dimensions in the matrix of
coefficients, their lu decompositions and/or right the hand sides of
the system of equations.
pdl> $m=sequence(2,2)
pdl> $x=sequence(1,2)
pdl> p $x
=>[[0],[1]] #edited
pdl> p $m x $x
=>[[1],[3]]
pdl> p $m x $x->dummy(2,2)
=>[[[1],[3]],[[1],[3]]]
pdl> p $m->dummy(2,2) x $x
=>[[[1],[3]],[[1],[3]]]
pdl> p $m->dummy(2,2) x $x->dummy(2,2)
=>[[[1],[3]],[[1],[3]]]

Actually, that is the current behavior of lu_backsub, except that it
represents a set of vectors as a matrix with a row per vector instead
of a column per vector for both the input and output. Thus, the need
for transpositions.
pdl> p lu_backsub(lu_decomp($m), $x->transpose)->transpose
=>[[0.5],[0]] #edited
pdl> p lu_backsub(lu_decomp($m), $x->transpose->dummy(2))->transpose
=>[[[0.5],[0]]]
pdl> p lu_backsub(lu_decomp($m), $x->transpose->dummy(2,2))->transpose
=>[[[0.5],[0]],[[0.5],[0]]]
pdl> p lu_backsub(lu_decomp($m->dummy(2,2)), $x->transpose)->transpose
=>[[[0.5],[0]],[[0.5],[0]]]
pdl> p lu_backsub(lu_decomp($m->dummy(2,2)), 
$x->transpose->dummy(2,2))->transpose
=>[[[0.5],[0]],[[0.5],[0]]]


The problem with my original suggestion that 1D inputs should yield 1D
outputs would be that it would lead to an ambiguity in the
interpretation of a 2D or higher dimensional input. In
pdl> $m=random(3,3,4);
pdl> $y=random(3,4);
pdl> $x=lu_backsub(lu_decomp($m), $y)->transpose
should $x be interpreted as 4 1D vectors $x(:,($j)) $j=0..3
each of which obeys the system
$m(:,:,($j)) x $x(:,$j)->transpose=$y(:,$j)->transpose
(i.e., four systems of equations, each with a different 3x3 coefficients,
different 3-vector right hand sides and different 3-vector solutions for
each $j) or should it be interperted as a set of matrices $x(:,:,($j))
each of which obeys
$m(:,:,($j)) x $x(:,:,($j))->transpose=$y(:,:)->transpose
that is, four system of equations, each with different coefficients
matrix but with the same 3x4 matricial right hand
side and with four 3x4 matricial solutions.

By demanding that the input be 2D at least there would be no ambiguity
Thus my suggestion would be to keep the current behavior of lu_backsub
except that it should die if the input is a 1D vector, or complain, or
the documentation should say that 1D vectors would be converted to 2D
matrices. The documentation should also say that the second dimension
of the right hand side is not a threading dimension.

The signature should then look like
lu(m,m); perm(m); b(m,n); [o] 

Re: [Pdl-general] [Pdl-devel] lu_backsub

[Luis Mochan]

Hi Ed,

On Tue, Jun 01, 2021 at 12:57:51AM +, Ed . wrote:
> That is what I was aiming to achieve (and have captured in hopefully-thorough 
> tests). My thinking is that the linear algebra stuff is founded on matrices, 
> with at least 2 dimensions. Therefore, getting something back that has at 
> least 2 dimensions (and always at least 2) seems to me the least surprising 
> outcome (especially given your previous note was apparently prompted by 
> surprise).
>
> What do you (and others) think?

I believe the most important thing is consistency. However, linear algebra is
about both matrices and vectors. Vectors may be represented by
matrices,  which makes the current behavior reasonable, but they may
be represented as 1D arrays. I would have expected a 1D input to
return a 1D output. My surprise was that lu_backsub returned 1D or
2D's depending on the entries of the matrix (on the value of the
permutations array), so it was not a consistent behavior. Now it seems
to be consistent when solving a single system of equations, which is
very good. Nevertheless, I haven't tested but I worry about the
behavior for other cases. For example, if instead of feeding lu_decomp
a single matrix, it is fed with an array of matrices (as an ndarray of
dimension >= 3), what output should I expect if I feed lu_backsub a
single 1D vector, a matrix with a single row, a matrix with several
rows? For example, a 3x3 matrix and a 3 vector currently return a 3x1
one row matrix. A 3x3x1 matrix and a 3 vector would also return a 3x1
matrix or a 3x1x1 matrix? A 3x3x2 matrix and a 3 vector, or a 3x1
vector, or a 3x2 matrix with two rows? The documentation says that
lu_backsub takes a matrix and a vector and that it threads as usual,
which seems not to be the case currently.

So, in summary, I think any decision would be appropriate if it is
clear, consistent and consistent with the documentation. But,
everything else being equal, I would prefer that a 2D matrix and 1D
vector yield a 1D output+the usual threading rules for additional
dimensions.

Best regards,
Luis
ps. And thanks for the enormous effort you are doing.



>
> Best regards,
> Ed
>
> From: Luis Mochan<mailto:moc...@icf.unam.mx>
> Sent: 01 June 2021 01:46
> To: perldl<mailto:pdl-general@lists.sourceforge.net>
> Subject: Re: [Pdl-general] [Pdl-devel] lu_backsub
>
> I tested the new version and it seems to be consistent.
>
> So  the current behavior is that if you feed lu_backsub
> with a 1D n-vector you consistently get out a 2D nX1 row
> matrix-vector, the same as if the input vector got an additional dummy
> dimension. Is this the expected behavior?
>
> Best regards,
> Luis
>
>
> On Mon, May 31, 2021 at 09:55:30PM +, Ed . wrote:
> > Hi Luis,
> >
> > The difference you’re seeing is due to a sort of mirage; when you transpose 
> > both outputs (suitable for matrix-multiplication) you’ll get the correct 
> > results, which are a 1x2 column vector.
> >
> > However, the lu_backsub code was quite complicated and in ascertaining the 
> > above, and also making it work “inplace” (did you know that the current 
> > “copy” method when “inplace” just turns off “inplace” and returns the given 
> > ndarray?) with tests, I had to make some fixes and changes. Now the dims of 
> > the results will all be the same.
> >
> > As soon as I’m confident these changes haven’t broken any other stuff, I’ll 
> > be releasing them. Thanks for the report!
> >
> > Best regards,
> > Ed
> >
> > From: Luis Mochan<mailto:moc...@icf.unam.mx>
> > Sent: 29 May 2021 20:28
> > To: perldl<mailto:pdl-general@lists.sourceforge.net>; 
> > perldl<mailto:pdl-de...@lists.sourceforge.net>
> > Subject: [Pdl-devel] lu_backsub
> >
> > I found a strange behavior in lu_backsub from PDL::MatrixOps:
> >
> > pdl> my $M=pdl([1,2],[3,4]);
> > pdl> my $M1=pdl([3,4],[1,2]); # interchange two rows
> > pdl> my $y=pdl(1,1);
> > pdl> my $x=lu_backsub($M->copy->lu_decomp, $y);
> > pdl> my $x1=lu_backsub($M1->copy->lu_decomp, $y);
> > pdl> p $x->info;
> > PDL: Double D [2,1]
> > pdl> p $x1->info;
> > PDL: Double D [2]
> >
> > In both cases I'm solving the same 2x2 system of equations using a 1D
> > vector as the right hand side, but in the second case I interchanged
> > rows, so I expected the same solution.  In the first case I get back a 'row
> > vector', i.e., a matrix with one row. However, in the second case I
> > got a real 1D vector, not a matrix.
> >
> > My guess is that the problem is related to the code around line 1298
> > of matrixops.pd, which contains some warnin

Re: [Pdl-general] [Pdl-devel] PDL 2.049 released

[Luis Mochan]

One detail to be aware of:

pdl> p i()->info
PDL: CDouble D []
pdl> use PDL::Complex
pdl> p i()->info
PDL::Complex: Double D [2]

Thus, the function i() is modified when loading PDL::Complex!

Regards,
Luis



On Mon, May 31, 2021 at 11:20:47PM +, Ed . wrote:
> Dear PDL folks,
>
> PDL 2.049 has just been released. Notable changes:
>
> Matrix stuff:
> - MatrixOps::identity now preserves higher dims on multi-dim input
> - MatrixOps::lu_decomp now preserves inplace flag on input
> - MatrixOps::lu_backsub now gets output dims right including inplace - thanks 
> @wlmb for report
>
> Complex numbers:
> - PDL::Complex->from_native / as_native
> - parse simple complex-number strings e.g. ‘[1+i 2-3i]’
> - replace PDL::Complex stringification with native-complex version
> - PDL::r2C able to take Perl scalars
> - add PDL::i2C
> - replace creal, cimag with re, im, for easier PDL::Complex -> native 
> transition
> - change default r2C and i2C input types to D from F
> - add czip($re, $im) -> native complex
> - i() as function (not constant) like nan()
> - ci() removed
> - add abs2
> - pdl([native-complex]) now creates a native-complex ndarray
> - sumover/prodover now also process native complex
> - comparing PDL::Complex and native complex other than for equality now a 
> fatal error, can == with real
> - PDL::Complex slices that affect 0-th dim get re-blessed as PDL
> - PDL::Complex can assign real values and threading won't also assign to imag
> - PDL::Constants only loads PDL::Complex on demand
>
> General stuff:
> - copy now copies ndarray and leaves original ndarray's inplace alone
> - SvPDLV gives more comprehensible error if given a hash without "PDL" key
> - Inline now not a dep but if installed gets updated to suitable version
> - new pdlperl.h for Perl-specific functions/macros
> - $PDL::undefval can be ndarray
> - overloading now done in PDL::Ops/Primitive where functions defined
> - overloading honours subclass methods
>
> As usual, please give it a try and report problems.
>
> Best regards,
> Ed


> ___
> pdl-devel mailing list
> pdl-de...@lists.sourceforge.net
> 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  | moc...@fis.unam.mx   /\_/\__/
GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16  C2DF 5F0A C52B 791E B9EB


___
pdl-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

Re: [Pdl-devel] PDL 2.049 released

[Luis Mochan]

One detail to be aware of:

pdl> p i()->info
PDL: CDouble D []
pdl> use PDL::Complex
pdl> p i()->info
PDL::Complex: Double D [2]

Thus, the function i() is modified when loading PDL::Complex!

Regards,
Luis



On Mon, May 31, 2021 at 11:20:47PM +, Ed . wrote:
> Dear PDL folks,
>
> PDL 2.049 has just been released. Notable changes:
>
> Matrix stuff:
> - MatrixOps::identity now preserves higher dims on multi-dim input
> - MatrixOps::lu_decomp now preserves inplace flag on input
> - MatrixOps::lu_backsub now gets output dims right including inplace - thanks 
> @wlmb for report
>
> Complex numbers:
> - PDL::Complex->from_native / as_native
> - parse simple complex-number strings e.g. ‘[1+i 2-3i]’
> - replace PDL::Complex stringification with native-complex version
> - PDL::r2C able to take Perl scalars
> - add PDL::i2C
> - replace creal, cimag with re, im, for easier PDL::Complex -> native 
> transition
> - change default r2C and i2C input types to D from F
> - add czip($re, $im) -> native complex
> - i() as function (not constant) like nan()
> - ci() removed
> - add abs2
> - pdl([native-complex]) now creates a native-complex ndarray
> - sumover/prodover now also process native complex
> - comparing PDL::Complex and native complex other than for equality now a 
> fatal error, can == with real
> - PDL::Complex slices that affect 0-th dim get re-blessed as PDL
> - PDL::Complex can assign real values and threading won't also assign to imag
> - PDL::Constants only loads PDL::Complex on demand
>
> General stuff:
> - copy now copies ndarray and leaves original ndarray's inplace alone
> - SvPDLV gives more comprehensible error if given a hash without "PDL" key
> - Inline now not a dep but if installed gets updated to suitable version
> - new pdlperl.h for Perl-specific functions/macros
> - $PDL::undefval can be ndarray
> - overloading now done in PDL::Ops/Primitive where functions defined
> - overloading honours subclass methods
>
> As usual, please give it a try and report problems.
>
> Best regards,
> Ed


> ___
> pdl-devel mailing list
> pdl-devel@lists.sourceforge.net
> 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  | 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

Re: [Pdl-general] [Pdl-devel] lu_backsub

[Luis Mochan]

I tested the new version and it seems to be consistent.

So  the current behavior is that if you feed lu_backsub
with a 1D n-vector you consistently get out a 2D nX1 row
matrix-vector, the same as if the input vector got an additional dummy
dimension. Is this the expected behavior?

Best regards,
Luis


On Mon, May 31, 2021 at 09:55:30PM +, Ed . wrote:
> Hi Luis,
>
> The difference you’re seeing is due to a sort of mirage; when you transpose 
> both outputs (suitable for matrix-multiplication) you’ll get the correct 
> results, which are a 1x2 column vector.
>
> However, the lu_backsub code was quite complicated and in ascertaining the 
> above, and also making it work “inplace” (did you know that the current 
> “copy” method when “inplace” just turns off “inplace” and returns the given 
> ndarray?) with tests, I had to make some fixes and changes. Now the dims of 
> the results will all be the same.
>
> As soon as I’m confident these changes haven’t broken any other stuff, I’ll 
> be releasing them. Thanks for the report!
>
> Best regards,
> Ed
>
> From: Luis Mochan<mailto:moc...@icf.unam.mx>
> Sent: 29 May 2021 20:28
> To: perldl<mailto:pdl-general@lists.sourceforge.net>; 
> perldl<mailto:pdl-de...@lists.sourceforge.net>
> Subject: [Pdl-devel] lu_backsub
>
> I found a strange behavior in lu_backsub from PDL::MatrixOps:
>
> pdl> my $M=pdl([1,2],[3,4]);
> pdl> my $M1=pdl([3,4],[1,2]); # interchange two rows
> pdl> my $y=pdl(1,1);
> pdl> my $x=lu_backsub($M->copy->lu_decomp, $y);
> pdl> my $x1=lu_backsub($M1->copy->lu_decomp, $y);
> pdl> p $x->info;
> PDL: Double D [2,1]
> pdl> p $x1->info;
> PDL: Double D [2]
>
> In both cases I'm solving the same 2x2 system of equations using a 1D
> vector as the right hand side, but in the second case I interchanged
> rows, so I expected the same solution.  In the first case I get back a 'row
> vector', i.e., a matrix with one row. However, in the second case I
> got a real 1D vector, not a matrix.
>
> My guess is that the problem is related to the code around line 1298
> of matrixops.pd, which contains some warnings:
>
>   if($nontrivial) {
>  if($y->is_inplace) {
> $y .= $y->dummy(1,$y->dim(0))->index($perm->dummy(1,1))->sever;   
> # TODO: check threading
> $out = $y;
>  } else {
> $out = $y->dummy(1,$y->dim(0))->index($perm->dummy(1,1))->sever;  
> # TODO: check threading
>  }
>   } else {
>  # should check for more matrix dims to thread over
>  # but ignore the issue for now
>  $out = ($y->is_inplace ? $y : $y->copy);
>   }
>   print STDERR "lu_backsub: starting with \$out" . pdl($out->dims) . "\n" 
> if $PDL::debug;
>
>
> 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  | moc...@fis.unam.mx   /\_/\__/
> GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16  C2DF 5F0A C52B 791E B9EB
>
>
> ___
> pdl-devel mailing list
> pdl-de...@lists.sourceforge.net
> 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  | moc...@fis.unam.mx   /\_/\__/
GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16  C2DF 5F0A C52B 791E B9EB


___
pdl-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

Re: [Pdl-general] [Pdl-devel] PDL 2.049 released

[Luis Mochan]

Congrats!
Luis



On Mon, May 31, 2021 at 11:20:47PM +, Ed . wrote:
> Dear PDL folks,
>
> PDL 2.049 has just been released. Notable changes:
>
> Matrix stuff:
> - MatrixOps::identity now preserves higher dims on multi-dim input
> - MatrixOps::lu_decomp now preserves inplace flag on input
> - MatrixOps::lu_backsub now gets output dims right including inplace - thanks 
> @wlmb for report
>
> Complex numbers:
> - PDL::Complex->from_native / as_native
> - parse simple complex-number strings e.g. ‘[1+i 2-3i]’
> - replace PDL::Complex stringification with native-complex version
> - PDL::r2C able to take Perl scalars
> - add PDL::i2C
> - replace creal, cimag with re, im, for easier PDL::Complex -> native 
> transition
> - change default r2C and i2C input types to D from F
> - add czip($re, $im) -> native complex
> - i() as function (not constant) like nan()
> - ci() removed
> - add abs2
> - pdl([native-complex]) now creates a native-complex ndarray
> - sumover/prodover now also process native complex
> - comparing PDL::Complex and native complex other than for equality now a 
> fatal error, can == with real
> - PDL::Complex slices that affect 0-th dim get re-blessed as PDL
> - PDL::Complex can assign real values and threading won't also assign to imag
> - PDL::Constants only loads PDL::Complex on demand
>
> General stuff:
> - copy now copies ndarray and leaves original ndarray's inplace alone
> - SvPDLV gives more comprehensible error if given a hash without "PDL" key
> - Inline now not a dep but if installed gets updated to suitable version
> - new pdlperl.h for Perl-specific functions/macros
> - $PDL::undefval can be ndarray
> - overloading now done in PDL::Ops/Primitive where functions defined
> - overloading honours subclass methods
>
> As usual, please give it a try and report problems.
>
> Best regards,
> Ed


> ___
> pdl-devel mailing list
> pdl-de...@lists.sourceforge.net
> 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  | moc...@fis.unam.mx   /\_/\__/
GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16  C2DF 5F0A C52B 791E B9EB


___
pdl-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

Re: [Pdl-devel] PDL 2.049 released

[Luis Mochan]

Congrats!
Luis



On Mon, May 31, 2021 at 11:20:47PM +, Ed . wrote:
> Dear PDL folks,
>
> PDL 2.049 has just been released. Notable changes:
>
> Matrix stuff:
> - MatrixOps::identity now preserves higher dims on multi-dim input
> - MatrixOps::lu_decomp now preserves inplace flag on input
> - MatrixOps::lu_backsub now gets output dims right including inplace - thanks 
> @wlmb for report
>
> Complex numbers:
> - PDL::Complex->from_native / as_native
> - parse simple complex-number strings e.g. ‘[1+i 2-3i]’
> - replace PDL::Complex stringification with native-complex version
> - PDL::r2C able to take Perl scalars
> - add PDL::i2C
> - replace creal, cimag with re, im, for easier PDL::Complex -> native 
> transition
> - change default r2C and i2C input types to D from F
> - add czip($re, $im) -> native complex
> - i() as function (not constant) like nan()
> - ci() removed
> - add abs2
> - pdl([native-complex]) now creates a native-complex ndarray
> - sumover/prodover now also process native complex
> - comparing PDL::Complex and native complex other than for equality now a 
> fatal error, can == with real
> - PDL::Complex slices that affect 0-th dim get re-blessed as PDL
> - PDL::Complex can assign real values and threading won't also assign to imag
> - PDL::Constants only loads PDL::Complex on demand
>
> General stuff:
> - copy now copies ndarray and leaves original ndarray's inplace alone
> - SvPDLV gives more comprehensible error if given a hash without "PDL" key
> - Inline now not a dep but if installed gets updated to suitable version
> - new pdlperl.h for Perl-specific functions/macros
> - $PDL::undefval can be ndarray
> - overloading now done in PDL::Ops/Primitive where functions defined
> - overloading honours subclass methods
>
> As usual, please give it a try and report problems.
>
> Best regards,
> Ed


> ___
> pdl-devel mailing list
> pdl-devel@lists.sourceforge.net
> 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  | 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

[Pdl-general] lu_backsub

[Luis Mochan]

I found a strange behavior in lu_backsub from PDL::MatrixOps:

pdl> my $M=pdl([1,2],[3,4]);
pdl> my $M1=pdl([3,4],[1,2]); # interchange two rows
pdl> my $y=pdl(1,1);
pdl> my $x=lu_backsub($M->copy->lu_decomp, $y);
pdl> my $x1=lu_backsub($M1->copy->lu_decomp, $y);
pdl> p $x->info;
PDL: Double D [2,1]
pdl> p $x1->info;
PDL: Double D [2]

In both cases I'm solving the same 2x2 system of equations using a 1D
vector as the right hand side, but in the second case I interchanged
rows, so I expected the same solution.  In the first case I get back a 'row
vector', i.e., a matrix with one row. However, in the second case I
got a real 1D vector, not a matrix.

My guess is that the problem is related to the code around line 1298
of matrixops.pd, which contains some warnings:

  if($nontrivial) {
 if($y->is_inplace) {
$y .= $y->dummy(1,$y->dim(0))->index($perm->dummy(1,1))->sever;   # 
TODO: check threading
$out = $y;
 } else {
$out = $y->dummy(1,$y->dim(0))->index($perm->dummy(1,1))->sever;  # 
TODO: check threading
 }
  } else {
 # should check for more matrix dims to thread over
 # but ignore the issue for now
 $out = ($y->is_inplace ? $y : $y->copy);
  }
  print STDERR "lu_backsub: starting with \$out" . pdl($out->dims) . "\n" 
if $PDL::debug;


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  | moc...@fis.unam.mx   /\_/\__/
GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16  C2DF 5F0A C52B 791E B9EB


___
pdl-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

[Pdl-devel] lu_backsub

[Luis Mochan]

I found a strange behavior in lu_backsub from PDL::MatrixOps:

pdl> my $M=pdl([1,2],[3,4]);
pdl> my $M1=pdl([3,4],[1,2]); # interchange two rows
pdl> my $y=pdl(1,1);
pdl> my $x=lu_backsub($M->copy->lu_decomp, $y);
pdl> my $x1=lu_backsub($M1->copy->lu_decomp, $y);
pdl> p $x->info;
PDL: Double D [2,1]
pdl> p $x1->info;
PDL: Double D [2]

In both cases I'm solving the same 2x2 system of equations using a 1D
vector as the right hand side, but in the second case I interchanged
rows, so I expected the same solution.  In the first case I get back a 'row
vector', i.e., a matrix with one row. However, in the second case I
got a real 1D vector, not a matrix.

My guess is that the problem is related to the code around line 1298
of matrixops.pd, which contains some warnings:

  if($nontrivial) {
 if($y->is_inplace) {
$y .= $y->dummy(1,$y->dim(0))->index($perm->dummy(1,1))->sever;   # 
TODO: check threading
$out = $y;
 } else {
$out = $y->dummy(1,$y->dim(0))->index($perm->dummy(1,1))->sever;  # 
TODO: check threading
 }
  } else {
 # should check for more matrix dims to thread over
 # but ignore the issue for now
 $out = ($y->is_inplace ? $y : $y->copy);
  }
  print STDERR "lu_backsub: starting with \$out" . pdl($out->dims) . "\n" 
if $PDL::debug;


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

Re: [Pdl-general] Feedback on PDL-Graphics-Gnuplot pause_until_close functionality

[Luis Mochan]

Hello,

On Fri, May 21, 2021 at 12:29:02PM -0400, Zakariyya Mughal wrote:
> Hello all,
>
> I've added a method to help wait for the Gnuplot window to close before
> continuing execution in this PR 
> . This is
> equivalent to `waitfor(H)` in Matlab/Octave.
>
> I've tested this so far on Linux and "gnuplot 5.2 patchlevel 6".
>
> I'd like to hear from any other PDL::Graphics::Gnuplot users if this PR
> works on their systems (especially if different from mine) and any other
> feedback. There is an example script in the PR.

It works on my system: Debian/testing, Gnuplot 5.4 patchlevel 1, and
seems useful.

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-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

Re: [Pdl-general] [Pdl-devel] PDL 2.037 released

[Luis Mochan]

Thanks! This is great news!
Regards,
Luis


On Fri, Apr 16, 2021 at 06:07:40PM +, Ed . wrote:
> Dear PDL folks,
>
> PDL 2.037 has just been uploaded to CPAN. Key features since the last 
> announcement:
>
>   *   New type qualifiers for pp_def Pars: “real” and “complex”, motivated by 
> PDL::FFTW3 so it can return the real or complex version of the input 
> floating-point data type (so “real” = cfloat->float, “complex” = 
> float->cfloat, etc) as necessary
>   *   Bad value support is now always on, and no longer configurable to off, 
> which simplified a fair bit of code
>   *   To help with maximum reproducibility, support for ~/.perldl.conf has 
> been removed (and the whole perldl.conf will go away in due course)
>   *   pthread detection now works better, and works on MacOS and Windows
>   *   GenericTypes in pp_def functions defaults if not specified to only the 
> real datatypes, for backwards-compatibility; functions have to “opt in” by 
> specifying complex datatypes
>   *   The Proj4 modules work again, by using the CPAN Alien::Proj4 module – 
> needed because general Linux distributions now package versions of proj that 
> are not compatible with v4 anymore
>   *   Makefile.PL only prints when things don’t work/aren’t available, which 
> makes developing nicer
>
> As usual, please give it a try and let me/us know of any problems.
>
> Next steps:
>
>   *   I intend to permanently enable the “badval per pdl” feature, and also 
> incorporate the ability to use NaN as the badvalue, so those two 
> configuration options will also disappear
>   *   I intend to stop calling PDL objects “piddles”, because that’s terribly 
> unclear what it actually means, and update all the docs to call them 
> “ndarrays”
>   *   Similarly, I intend to rename “threading” to “broadcasting” to 
> eliminate unnecessary confusion
>   *   oodler577 on the #pdl channel is helping towards PDL supporting OpenMP
>   *   Better integration of native complex numbers
>
> Thoughts welcome on any and all of the above!
>
> Best regards,
> Ed
>


> ___
> pdl-devel mailing list
> pdl-de...@lists.sourceforge.net
> 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  | moc...@fis.unam.mx   /\_/\__/
GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16  C2DF 5F0A C52B 791E B9EB


___
pdl-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

Re: [Pdl-devel] PDL 2.037 released

[Luis Mochan]

Thanks! This is great news!
Regards,
Luis


On Fri, Apr 16, 2021 at 06:07:40PM +, Ed . wrote:
> Dear PDL folks,
>
> PDL 2.037 has just been uploaded to CPAN. Key features since the last 
> announcement:
>
>   *   New type qualifiers for pp_def Pars: “real” and “complex”, motivated by 
> PDL::FFTW3 so it can return the real or complex version of the input 
> floating-point data type (so “real” = cfloat->float, “complex” = 
> float->cfloat, etc) as necessary
>   *   Bad value support is now always on, and no longer configurable to off, 
> which simplified a fair bit of code
>   *   To help with maximum reproducibility, support for ~/.perldl.conf has 
> been removed (and the whole perldl.conf will go away in due course)
>   *   pthread detection now works better, and works on MacOS and Windows
>   *   GenericTypes in pp_def functions defaults if not specified to only the 
> real datatypes, for backwards-compatibility; functions have to “opt in” by 
> specifying complex datatypes
>   *   The Proj4 modules work again, by using the CPAN Alien::Proj4 module – 
> needed because general Linux distributions now package versions of proj that 
> are not compatible with v4 anymore
>   *   Makefile.PL only prints when things don’t work/aren’t available, which 
> makes developing nicer
>
> As usual, please give it a try and let me/us know of any problems.
>
> Next steps:
>
>   *   I intend to permanently enable the “badval per pdl” feature, and also 
> incorporate the ability to use NaN as the badvalue, so those two 
> configuration options will also disappear
>   *   I intend to stop calling PDL objects “piddles”, because that’s terribly 
> unclear what it actually means, and update all the docs to call them 
> “ndarrays”
>   *   Similarly, I intend to rename “threading” to “broadcasting” to 
> eliminate unnecessary confusion
>   *   oodler577 on the #pdl channel is helping towards PDL supporting OpenMP
>   *   Better integration of native complex numbers
>
> Thoughts welcome on any and all of the above!
>
> Best regards,
> Ed
>


> ___
> pdl-devel mailing list
> pdl-devel@lists.sourceforge.net
> 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  | 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

Re: [Pdl-devel] [Pdl-general] PDL 2.029 released

[Luis Mochan]

I started playing with the new complex numbers. I find it nice
and useful that creal and cimag can be applied to real pdl's, but the
results are promoted to complex:

pdl> $x=pdl(1)
pdl> p $x
1
pdl> p $x->creal
1+0i
pdl> p $x->cimag
0+0i

Equality and inequality comparisons do work but they also return
complex values:

pdl> p $x==1
1
pdl> p $x->creal==1
1+0i
pdl> p $x->creal==2
0+0i
pdl> p $x->creal!=2
1+0i

This is troublesome, as their boolean interpretation is not correct:

pdl> print +($x->creal==1)?'yes':'no'
yes
pdl> print +($x->creal==2)?'yes':'no'
yes
pdl> print +($x==2)?'yes':'no'
no

On the other hand, greater than, lower than, etc. do compare the real
parts only and return a real value.

pdl> $y=ci
pdl> p $y<1
1
pdl> p $y p $y<=0.01*ci
1

Regards,
Luis






On Mon, Mar 15, 2021 at 04:00:13PM +0100, Ingo Schmid wrote:
> Hi,
>
> I also noticed that complex comparisons don't throw errors but compare
> the real part. I must say, I don't like the behaviour, although I did
> not catch it.
>
> At the bottom of this, I think, is the implicit type conversion. When an
> operation is not defined for a given type, pdl implicitly converts (to
> double) until it can do it.
>
> This is useful in may situations, but in others not. This breaks, of
> course, some of the symmetry in ops.pd (maybe primitive and ufunc,
> amongst others). Especially biops would need revisions.
>
> I think this is a fundamental design decision. Whatever is established
> now will have impact. I tried to raise awareness to this in the other
> thread.
>
> Ingo
>
> On 15.03.21 13:56, Ingo Schmid wrote:
> >
> > So, I figured the code bit ($TCG), but have no elegant solution ready.
> > There's no macro to match a complex' and real basic type, no? Ingo
> >
> > Ingo
> >
> > On 15.03.21 12:01, Ingo Schmid wrote:
> > >
> > > Hi Ed,
> > >
> > > creal, etc. including carg, do not cast onto their real-valued
> > > counter part. I think they should, no?
> > >
> > > pdl> p $x
> > > 1+1i
> > >
> > > pdl> p abs $x
> > > 1.41421354+0i
> > >
> > > pdl> p creal $x
> > > 1+0i
> > >
> > > pdl> p cimag $x
> > > 1+0i
> > >
> > > pdl> p carg $y
> > > 0.78539816339744828+0i
> > >
> > > That leaves conj (complex conjugate) which should return a complex
> > > number.
> > >
> > > I think these are all.
> > >
> > > I think you introduced cfunc in ops.pd with a codestring that's
> > > beyound me.  Where does  $TCG come from? I assume it means handling
> > > types C and G, I don't get the T, at the moment.
> > >
> > > Let me know what you think.
> > >
> > > Best
> > >
> > > Ingo
> > >
> > > On 12.03.21 19:25, Ed . wrote:
> > > >
> > > > Dear PDL folks,
> > > >
> > > > PDL 2.029 has just been released. Following Monday’s dev-release,
> > > > the CPAN Testers results show no test failures at all, and only a
> > > > few build-failures which appear to be caused by an older
> > > > ExtUtils::F77 erroneously adding “-lquadmath” on a Windows platform
> > > > that didn’t have it.
> > > >
> > > > This version’s only changes from 2.028 are to fix a few remaining
> > > > test failures for “native complex” numbers on platforms with buggy
> > > > libm, and to incorporate some material improvements made to PDLA.
> > > >
> > > > The next steps will be to solidify the native complex support by
> > > > adding to PDL::Complex ways translate/have data flow between the two
> > > > ways of accessing the information. As an early approach I will be
> > > > enhancing PDL::FFTW3 to correctly support native complex numbers. I
> > > > still want to make PDL’s “from string” capability support “i” as a
> > > > value, but haven’t done so yet. Ingo, your updates (or even pointers
> > > > on doing so) to the PDL docs will be very helpful, I hope you’ll
> > > > find time to take a look :-)
> > > >
> > > > After the above, the next stages will be to start “splitting the
> > > > iceberg” of PDL, starting by extracting a minimal (but not too
> > > > minimal) PDL::Core distribution, which I will be checking against
> > > > the main PDLPorters other PDL::* distros by making them depend on
> > > > only PDL::Core, and ensuring they still work. I am in two minds on
> > > > whether to have a true “PDL::Core” with a separate
> > > > “PDL::Interactive” which has a bit more (the interactive shells for
> > > > instance), but have the feeling that the interactive shells etc are
> > > > so small and minimal in terms of build that this would not help.
> > > > Anyone else have views?
> > > >
> > > > Please try this version with all your code, and report problems with
> > > > PRs, GitHub issues, or at least email reports!
> > > >
> > > > Best regards,
> > > >
> > > > Ed
> > > >
> > > >
> > > >
> > > > ___
> > > > pdl-general mailing list
> > > > pdl-gene...@lists.sourceforge.net
> > > > https://lists.sourceforge.net/lists/listinfo/pdl-general
> > >
> > >
> > > ___
> > > pdl-devel mailing list
> > > 

Re: [Pdl-devel] data flow, conversion & dimensions in complex numbers

[Luis Mochan]

Hi Ingo and all,

On Mon, Mar 08, 2021 at 09:07:11PM +0100, Ingo Schmid wrote:
> ...
> The native way treats complex numbers as scalars of native complex
> types. This solves the dimensions issue, obviously.

I think it is a good idea not having access explicitly to an
additional index at the beginning of complex pdl's to select its real
or imaginary part. With PDL::Complex, operations like sumover had
to sum over the second, not the first index, something that has produced
some confusion (the first dimension had to be moved
temporarily out of the way before applying some vector operators that
are not complex aware, but not others). So being able to treat a
complex number as a scalar is a very good step forward.

> E.g,. creal and
> cimag can be either seen as slice() where data flow would be welcome or
> as aggregate, where it would not. I think either case can be argued for.

I'm not sure I understand the 'aggregate' alternative.
pdl> my $x=ci
pdl> help $x
This variable is CDouble D []   P0.02KB
pdl> $r=$x->creal
pdl> help $r
This variable is CDouble D []   P0.02KB
pdl> use PDL::Complex
pdl> $x1=i
pdl> help $x1
This variable is Double D [2]  P0.02KB
pdl> $r1=$x1->re
pdl> help $r1
This variable is Double D []   -C   0.00KB
In this example $r1 is connected to $x1, but $r is not connected to
$x. What would be the downside of allowing the sharing of data between
$x and $r?

> I guess treating these casts as slicing

I'm not sure if creal and cimag should be called 'casts', or just real
valued functions of complex argument.

> with data flow intact has the
> advantage that there are always sever() and copy() if this is not
> desired.

I think so.

> Can we maintain data flow when changing to abs/arg representation?

I wouldn't try that. As the native format is an array of real, imag
parts, some processing of the data would be necessary for the abs/arg
representation, so it might be more complicated and maybe slow. But
data flow to the real and imaginary parts and/or conversion from a
complex to and from the corresponding real [2] array would be useful
and maybe relatively simple. Something analogous to the real and
cplx functions of PDL::Complex.

>
> On the other hand, any other type cast, I think, breaks data flow. This
> would mean unexpected behaviour to at least some degree, no?
>
> The third issue is automatic conversion with data loss. I think this
> should throw an exception, if you ask me, maybe as a build option for
> those relying on old code?

I agree.

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

Re: [Pdl-general] [Pdl-devel] PDL 2.027 released

[Luis Mochan]

On Mon, Mar 08, 2021 at 03:28:09PM +, Ed . wrote:
> Hi folks,
>
> I added the warning because I found the behaviour surprising when adding 
> tests. My plan now is that ci() will go away, so my proposal is to use it as 
> “ci()” for now, bearing in mind it’s only temporary. How does that sound?

Sounds good to me.
The warning is not in 2.028_01, is it?

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  | moc...@fis.unam.mx   /\_/\__/
GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16  C2DF 5F0A C52B 791E B9EB


___
pdl-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

Re: [Pdl-general] [Pdl-devel] PDL 2.027 released

[Luis Mochan]

Hi Ingo,
On Mon, Mar 08, 2021 at 09:49:06AM +0100, Ingo Schmid wrote:
> ...
> is it not doing  ci() + $x (expected behaviour) rather than ci( +$x) ?

No. For example:
$ pdl2
...
pdl> $x=1+0*ci # initialize a complex variable with a real value
pdl> p $x
1+0i
pdl> p ci()+$x # this works as expected
1+1i
pdl> p ci+$x # this doesn't

pdl> p $x # and the value of $x has been changed
0+1i

Curiously,
pdl> p ci-$x
doesn't print anything either, but it doesn't change $x (I guess -$x
is assigned to a temporary variable and that is what gets modified by
ci; in ci+$x a temporary variable is not necessary so $x itself gets
modified).

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-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

Re: [Pdl-general] [Pdl-devel] PDL 2.027 released

[Luis Mochan]

Hi Ed,

> ...However, are you seeing a use for it that adds anything to simply using 
> i2C from PDL::Complex?

No.

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  | moc...@fis.unam.mx   /\_/\__/
GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16  C2DF 5F0A C52B 791E B9EB


___
pdl-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

Re: [Pdl-devel] PDL 2.027 released

[Luis Mochan]

Hi Ed,

> ...However, are you seeing a use for it that adds anything to simply using 
> i2C from PDL::Complex?

No.

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

Re: [Pdl-general] [Pdl-devel] PDL 2.027 released

[Luis Mochan]

Hello,

I'm intrigued by ci. What is the reason for its behavior?
I found that ci was defined through pp_def with one output argument.
Thus, ci+$x is interpreted as ci(+$x) which actually assigns
complex i to each element of $x if $x is a complex pdl. If $x is real,
then it assigns 0 (I guess it type-converts i though its real part).

Is there a case where you would expect a call to ci with an actual
argument? Would it be reasonable to flag an error if it is called with
a non-null argument? Would this be costly?  My guess is that ci+$x or
ci*$x would become a frequenct headache with the actual
behavior. Or maybe one can keep the current function ci and include an
actual constant
   use constant CI=>ci;
and encourage the use of the constant CI unless there is a good reason
to use ci directly.

The conversion back and forth between pairs of real numbers and
complex numbers without requiring actual multiplication with ci would
also be convenient. Given that C99 complex numbers are an array of two
reals, it might be simple.

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-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

Re: [Pdl-devel] PDL 2.027 released

[Luis Mochan]

Hello,

I'm intrigued by ci. What is the reason for its behavior?
I found that ci was defined through pp_def with one output argument.
Thus, ci+$x is interpreted as ci(+$x) which actually assigns
complex i to each element of $x if $x is a complex pdl. If $x is real,
then it assigns 0 (I guess it type-converts i though its real part).

Is there a case where you would expect a call to ci with an actual
argument? Would it be reasonable to flag an error if it is called with
a non-null argument? Would this be costly?  My guess is that ci+$x or
ci*$x would become a frequenct headache with the actual
behavior. Or maybe one can keep the current function ci and include an
actual constant
   use constant CI=>ci;
and encourage the use of the constant CI unless there is a good reason
to use ci directly.

The conversion back and forth between pairs of real numbers and
complex numbers without requiring actual multiplication with ci would
also be convenient. Given that C99 complex numbers are an array of two
reals, it might be simple.

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

Re: [Pdl-general] [Pdl-devel] PDL 2.027 released

[Luis Mochan]

Hi Ed,


> The problem you identified is due to a logic error in the bifuncs in P::Ops – 
> they weren’t handling complex inputs correctly because the code to do so was 
> behind a check for unsigned-handling. Now that’s corrected, and there’s a 
> test to guard against regressions. As soon as the tests have passed on the 
> CI, there will be a 2.028 on its way to CPAN.

I installed it from github and seems to work! Thanks.

Will FFTW3 work with the new complex? I believe it only works
currently with [2,N] real pdl's and not with actual PDL::Complex
pdl's. It would be nice if it could admit the three kinds. According
to http://fftw.org/fftw3_doc/Complex-numbers.html it seems possible to
use the fftw libraries with C99 complex numbers.

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  | moc...@fis.unam.mx   /\_/\__/
GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16  C2DF 5F0A C52B 791E B9EB


___
pdl-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general

Re: [Pdl-devel] PDL 2.027 released

[Luis Mochan]

Hi Ed,


> The problem you identified is due to a logic error in the bifuncs in P::Ops – 
> they weren’t handling complex inputs correctly because the code to do so was 
> behind a check for unsigned-handling. Now that’s corrected, and there’s a 
> test to guard against regressions. As soon as the tests have passed on the 
> CI, there will be a 2.028 on its way to CPAN.

I installed it from github and seems to work! Thanks.

Will FFTW3 work with the new complex? I believe it only works
currently with [2,N] real pdl's and not with actual PDL::Complex
pdl's. It would be nice if it could admit the three kinds. According
to http://fftw.org/fftw3_doc/Complex-numbers.html it seems possible to
use the fftw libraries with C99 complex numbers.

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

Re: [Pdl-general] [Pdl-devel] PDL 2.027 released

[Luis Mochan]

Well, so far, I have found that ** invokes the function PDL::power
which seems not to work with the new complex types. I don't know the
reason for having both a 'pow' and a 'power' function.


On the other hand, would it be feasible to enable data flow back to
the real and imaginary parts of a new complex? (I understand it may go
against their philosophy)
pdl> $a=1+2*ci #make a new complex
pdl> p $a
1+2i
pdl> $b=$a->cimag
pdl> p $b
2
pdl> $b.=3 # modifying $b
pdl> p $a # doesn't modify the imaginary part of $a
1+2i

Best regards,
Luis



On Sat, Mar 06, 2021 at 05:12:40PM -0600, Luis Mochan wrote:
> And pow also works. So it seems the problem is related to the
> translation from the binary operator version '**'.
>
> pdl> p +(1+ci)->ipow(2)
> 0+2i
> pdl> p +(1+ci)->pow(2)
> 1.2246467991473532e-16+2i
> pdl> p +(1+ci)**2
> 1+0i
> pdl>
>
>
> On Sat, Mar 06, 2021 at 05:03:49PM -0600, Luis Mochan wrote:
> > > So powers of complex numbers are not working. I haven't looked yet at
> > > the P::Ops code. I'll try later.
> >
> > ipow does work though.
> >
> >
> > --
> >
> >   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-de...@lists.sourceforge.net
> > 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  | moc...@fis.unam.mx   /\_/\__/
> GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16  C2DF 5F0A C52B 791E B9EB
>
>
> ___
> pdl-devel mailing list
> pdl-de...@lists.sourceforge.net
> 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  | moc...@fis.unam.mx   /\_/\__/
GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16  C2DF 5F0A C52B 791E B9EB


___
pdl-general mailing list
pdl-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general