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

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

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

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 a

Re: [Pdl-devel] naming conventions

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 a

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

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

Re: [Pdl-devel] naming conventions

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

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

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

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

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

Re: [Pdl-devel] naming conventions

(@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, > E

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

(@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, > E

[Pdl-general] 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

[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

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

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

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

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

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

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

Re: [Pdl-general] rotate matrix

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

Re: [Pdl-general] rotate matrix

os($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 1

Re: [Pdl-general] rotate matrix

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

[Pdl-general] emacs, perl and jupyter

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

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

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

Re: [Pdl-general] Trid demo

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"

[Pdl-devel] strange bug in gnuplot

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?";

[Pdl-general] strange bug in gnuplot

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?";

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

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

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

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

Re: [Pdl-devel] PDL 2.082 released

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

Re: [Pdl-devel] inconsistent determinant

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

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

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

[Pdl-general] 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: #

[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: #

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

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$_"

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

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

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

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

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

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

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

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

Re: [Pdl-general] conv2d

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

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

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

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

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

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

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

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

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

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

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

Re: [Pdl-general] conv2d

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

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

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

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

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

Re: [Pdl-general] conv2d

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

Re: [Pdl-general] conv2d

; 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@li

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

; 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

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

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

Re: [Pdl-general] conv2d

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

[Pdl-devel] 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

[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

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

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

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

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

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

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

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

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

Re: [Pdl-general] PDL 2.078

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

Re: [Pdl-general] PDL 2.078

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

Re: Re: bluetooth audio

Thanks! -- WLM

bluetooth audio

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

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

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.

Re: [Pdl-devel] benchmarks

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.

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

ction. It’s about > twice as slow as pure-Perl (rather than 70 times with the naïve version). The > way this would benefit performance-wise would be to trace rays through many > more surfaces than 4, or (as mentioned below) with a large number of > different ray heights. That

Re: [Pdl-devel] benchmarks

ction. It’s about > twice as slow as pure-Perl (rather than 70 times with the naïve version). The > way this would benefit performance-wise would be to trace rays through many > more surfaces than 4, or (as mentioned below) with a large number of > different ray heights. That

[Pdl-general] 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,

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

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

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

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

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

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

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

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

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

Re: [Pdl-general] [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 >

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 >

[Pdl-general] 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 I believe the problem lies in the code that distinguishes

[Pdl-devel] sequence

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-general] sequence

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-general] [moc...@icf.unam.mx: Re: [Pdl-devel] P::G::Gnuplot 2.017]

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

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

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

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

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-general] [moc...@icf.unam.mx: Re: [Pdl-devel] lu_backsub]

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

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

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

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

egards, 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_bac

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

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

Re: [Pdl-devel] PDL 2.049 released

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

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

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 Ma

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

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

Re: [Pdl-devel] PDL 2.049 released

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

[Pdl-general] 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

[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

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

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

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

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 >

Re: [Pdl-devel] PDL 2.037 released

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 >

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

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

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

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

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

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

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

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 #

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

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

Re: [Pdl-devel] PDL 2.027 released

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

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

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

Re: [Pdl-devel] PDL 2.027 released

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

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

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

Re: [Pdl-devel] PDL 2.027 released

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

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

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

  1   2   3   4   5   6   >