pdl-general — PDL Users Question and Discussion

Re: [Pdl-general] virtual workshop

[Boyd D. <boy...@gm...>]

It's on my todo list - Issue #33 ;)

I was hoping it would uncover more PDL talks that I hadn't found on
Youtube. If you know of any or have one sitting on disk somewhere, let me
know and I'll put them up.

In the meantime if you're a user of Harvard's ADS, I've resuscitated the
Astro::ADS module on CPAN and it currently implements the Search and
Metrics endpoints with the others on the roadmap.

cheers,
Boyd

https://github.com/PDLPorters/pdlporters.github.com/issues/33



On Mon, 10 Nov 2025 at 23:17, Karl Glazebrook <kar...@ma...>
wrote:

> Can we add this link to one of the perl.pdl.org web pages?
>
> Karl
>
>
> On 9 Sep 2025, at 7:09 am, Boyd Duffee <boy...@gm...> wrote:
>
> I was putting together a page embedding all the youtube uploads of PDL
> talks I could find and I was thinking that this might be an easy way of
> assembling a PDL workshop. So far, it consists of 5 introductions, 2 talks
> on plotting and visualization and 2 on statistics and data.
>
> https://perldatascience.wordpress.com/virtual-conference/
>
> I've tried to keep the descriptions short but engaging, minimizing
> clutter. Any comments or additions are welcome, like ... does the comment
> box at the bottom make the page look like a cheap blog post?
>
> A suggestion for those who attend conferences, it would be nice to see
> more PDL topics covered. Zaki teased the audience with a quick demo of
> PDL::OpenCV at the end of his intro talk. I think we're at the stage where
> we can just say PDL is numpy for Perl, point to the docs and then get on
> with the chewy bits.
>
> How do you feel about telling people how _you_ use PDL? ;)
>
> best,
> --
> Boyd Duffee
>
> “I wasn’t particularly close to my dad before he died… which was lucky,
> because he trod on a land mine” Olaf Falafel
>
> MAGA is a rehab facility for charlatans and the cancelled
> Trump is a moron whose bankruptcy was bailed out by Putin who is now
> pulling his strings.
> _______________________________________________
> pdl-general mailing list
> pdl...@li...
> https://lists.sourceforge.net/lists/listinfo/pdl-general
>
>
>

Re: [Pdl-general] virtual workshop

[Karl G. <kar...@ma...>]

Can we add this link to one of the perl.pdl.org <http://perl.pdl.org/> web pages?

Karl


> On 9 Sep 2025, at 7:09 am, Boyd Duffee <boy...@gm...> wrote:
> 
> I was putting together a page embedding all the youtube uploads of PDL talks I could find and I was thinking that this might be an easy way of assembling a PDL workshop. So far, it consists of 5 introductions, 2 talks on plotting and visualization and 2 on statistics and data.
> 
> https://perldatascience.wordpress.com/virtual-conference/
> 
> I've tried to keep the descriptions short but engaging, minimizing clutter. Any comments or additions are welcome, like ... does the comment box at the bottom make the page look like a cheap blog post?
> 
> A suggestion for those who attend conferences, it would be nice to see more PDL topics covered. Zaki teased the audience with a quick demo of PDL::OpenCV at the end of his intro talk. I think we're at the stage where we can just say PDL is numpy for Perl, point to the docs and then get on with the chewy bits.
> 
> How do you feel about telling people how _you_ use PDL? ;)
> 
> best,
> --
> Boyd Duffee
> “I wasn’t particularly close to my dad before he died… which was lucky, because he trod on a land mine” Olaf Falafel
> MAGA is a rehab facility for charlatans and the cancelled
> Trump is a moron whose bankruptcy was bailed out by Putin who is now pulling his strings.
> _______________________________________________
> pdl-general mailing list
> pdl...@li...
> https://lists.sourceforge.net/lists/listinfo/pdl-general

[Pdl-general] Winter Perl Community Conference - Dec 17-18 Austin, TX / Virtual

[Brett E. <bre...@gm...>]

 Hi,

I am just sending a note to let you know we'd love to get have some PDL
related talks, better even some paper-based talks suitable for the Science
Track and Science Perl Journal Summer Issue.

This is a hybrid conference located in Austin, TX. We encourage virtual
presentations for those who can't travel for some reason.

PDL is a critical part of any science done using Perl, as you know. In the
past we've thoroughly enjoyed talks that featured PDL, such as the work by
Dr. Luis Mochán and Dr. Christos Argyropoulos.

And some of you have already contributed to our conferences and SPJ issues
in the past; for this we're greatly appreciative and want to encourage
continued engagement. To submit a talk (paper-based or otherwise), please
see the following:

https://www.papercall.io/cfps/6395/submissions/new

Talks to not have to be paper based as in the past, but we are still
encouraging those especially those engaged in scientific work.

Cheers,
Brett Estrade
Science Perl Committee Chairman

https://science.perlcommunity.org

-- 
This email message is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. Any unauthorized use or
disclosure is prohibited. If you are not the intended recipient, please
contact the sender by reply email and destroy all copies of the original
message. Thank you.

[Pdl-general] pdl2 shell requirement

[Ingo S. <in...@gm...>]

Hi,

I needed a new perlbrew environment and now PDL installed without the 
pdl2 shell. I have Devel::REPL, and most other useful stuff installed, 
what am I missing?

I get no clue from make output (including the perl Makefile.PL stage). 
The Makefile is apparently not created or updated.

It must be something trivial which I seem to miss.

It is on linux, perl-5.42.0, both latest master and cpanm (PDL-2.100)

Many thanks,

Ingo

Re: [Pdl-general] Fwd: turn off warnings

[David M. <dcm...@gm...>]

Oh, I just realized this is in a module! In that case you should almost
certainly use "local" because you don't know if other uses of conv1d would
issue useful warnings.

 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan

On Thu, Oct 16, 2025, 9:09 AM David Mertens <dcm...@gm...>
wrote:

> If it works, it works. But a few comments:
>
> 1) The BEGIN block wrapper is unnecessary here. Just put it somewhere near
> the top of your code, before you invoke conv1d.
> 2) If your use of conv1d is inside a block, you can preface the hash
> assignment with "local" and your override will be discarded when your code
> exits the block. (Note: you can do this for any hash assignment, even with
> entries of hashes declared as "my %hash".) This makes the override
> lexically scoped, minimizing action-at-a-distance and the extraordinary
> confusion it can cause. I'm thinking about a student who sees this
> technique, then applies it wantonly in their own code to suppress unwanted
> warnings, unwittingly and silently suppressing useful warnings and making
> the debug process 5x harder than it should be.
>
> David
>
>  "Debugging is twice as hard as writing the code in the first place.
>   Therefore, if you write the code as cleverly as possible, you are,
>   by definition, not smart enough to debug it." -- Brian Kernighan
>
> On Thu, Oct 16, 2025, 8:43 AM Ingo Schmid via pdl-general <
> pdl...@li...> wrote:
>
>>
>> Hi,
>>
>> may thanks!
>>
>> I've placed this in the respective module, which does the job. But I
>> guess it is not local?
>>
>>
>> BEGIN {
>>     $SIG{__WARN__} = sub {
>>         my $warn = shift;
>>         return if $warn =~ /PDL::Primitive::conv1d does not handle bad
>> values at/;
>>         warn $warn;
>>     };
>> }
>>
>> Ingo
>> On 16.10.25 2:29 PM, David Mertens wrote:
>>
>> There is an official way for a module to establish warnings that callers
>> can enable or disable using warnings::register (see
>> https://perldoc.perl.org/warnings#Reporting-Warnings-from-a-Module). I
>> don't think PDL has done this.
>>
>> The other approach is to set a warnings handler. brian d foy covers that
>> in an article about overriding warnings (
>> https://www.effectiveperlprogramming.com/2011/09/intercept-module-warnings-with-a-warn-handler/).
>> You will almost certainly want to use the "local" override since that'll be
>> reset after you exit the current block, just like a lexically scoped "no
>> 'warnings'" statement.
>>
>> David
>>
>>  "Debugging is twice as hard as writing the code in the first place.
>>   Therefore, if you write the code as cleverly as possible, you are,
>>   by definition, not smart enough to debug it." -- Brian Kernighan
>>
>> On Thu, Oct 16, 2025, 6:43 AM Ingo Schmid via pdl-general <
>> pdl...@li...> wrote:
>>
>>> Hi,
>>>
>>> in my code, I use conv1d (PDL::Primitive) a lot, which generates a BAD
>>> values warning every time. Is there a way to suppress this selectively?
>>>
>>> Thanks
>>>
>>> Ingo
>>> _______________________________________________
>>> pdl-general mailing list
>>> pdl...@li...
>>> https://lists.sourceforge.net/lists/listinfo/pdl-general
>>>
>> _______________________________________________
>> pdl-general mailing list
>> pdl...@li...
>> https://lists.sourceforge.net/lists/listinfo/pdl-general
>>
>>

Re: [Pdl-general] Fwd: turn off warnings

[David M. <dcm...@gm...>]

If it works, it works. But a few comments:

1) The BEGIN block wrapper is unnecessary here. Just put it somewhere near
the top of your code, before you invoke conv1d.
2) If your use of conv1d is inside a block, you can preface the hash
assignment with "local" and your override will be discarded when your code
exits the block. (Note: you can do this for any hash assignment, even with
entries of hashes declared as "my %hash".) This makes the override
lexically scoped, minimizing action-at-a-distance and the extraordinary
confusion it can cause. I'm thinking about a student who sees this
technique, then applies it wantonly in their own code to suppress unwanted
warnings, unwittingly and silently suppressing useful warnings and making
the debug process 5x harder than it should be.

David

 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan

On Thu, Oct 16, 2025, 8:43 AM Ingo Schmid via pdl-general <
pdl...@li...> wrote:

>
> Hi,
>
> may thanks!
>
> I've placed this in the respective module, which does the job. But I guess
> it is not local?
>
>
> BEGIN {
>     $SIG{__WARN__} = sub {
>         my $warn = shift;
>         return if $warn =~ /PDL::Primitive::conv1d does not handle bad
> values at/;
>         warn $warn;
>     };
> }
>
> Ingo
> On 16.10.25 2:29 PM, David Mertens wrote:
>
> There is an official way for a module to establish warnings that callers
> can enable or disable using warnings::register (see
> https://perldoc.perl.org/warnings#Reporting-Warnings-from-a-Module). I
> don't think PDL has done this.
>
> The other approach is to set a warnings handler. brian d foy covers that
> in an article about overriding warnings (
> https://www.effectiveperlprogramming.com/2011/09/intercept-module-warnings-with-a-warn-handler/).
> You will almost certainly want to use the "local" override since that'll be
> reset after you exit the current block, just like a lexically scoped "no
> 'warnings'" statement.
>
> David
>
>  "Debugging is twice as hard as writing the code in the first place.
>   Therefore, if you write the code as cleverly as possible, you are,
>   by definition, not smart enough to debug it." -- Brian Kernighan
>
> On Thu, Oct 16, 2025, 6:43 AM Ingo Schmid via pdl-general <
> pdl...@li...> wrote:
>
>> Hi,
>>
>> in my code, I use conv1d (PDL::Primitive) a lot, which generates a BAD
>> values warning every time. Is there a way to suppress this selectively?
>>
>> Thanks
>>
>> Ingo
>> _______________________________________________
>> pdl-general mailing list
>> pdl...@li...
>> https://lists.sourceforge.net/lists/listinfo/pdl-general
>>
> _______________________________________________
> pdl-general mailing list
> pdl...@li...
> https://lists.sourceforge.net/lists/listinfo/pdl-general
>
>

[Pdl-general] Fwd: turn off warnings

[Ingo S. <in...@gm...>]

Hi,

may thanks!

I've placed this in the respective module, which does the job. But I 
guess it is not local?


BEGIN {
     $SIG{__WARN__} = sub {
         my $warn = shift;
         return if $warn =~ /PDL::Primitive::conv1d does not handle bad 
values at/;
         warn $warn;
     };
}

Ingo

On 16.10.25 2:29 PM, David Mertens wrote:
> There is an official way for a module to establish warnings that 
> callers can enable or disable using warnings::register (see 
> https://perldoc.perl.org/warnings#Reporting-Warnings-from-a-Module). I 
> don't think PDL has done this.
>
> The other approach is to set a warnings handler. brian d foy covers 
> that in an article about overriding warnings 
> (https://www.effectiveperlprogramming.com/2011/09/intercept-module-warnings-with-a-warn-handler/). 
> You will almost certainly want to use the "local" override since 
> that'll be reset after you exit the current block, just like a 
> lexically scoped "no 'warnings'" statement.
>
> David
>
>  "Debugging is twice as hard as writing the code in the first place.
>   Therefore, if you write the code as cleverly as possible, you are,
>   by definition, not smart enough to debug it." -- Brian Kernighan
>
> On Thu, Oct 16, 2025, 6:43 AM Ingo Schmid via pdl-general 
> <pdl...@li...> wrote:
>
>     Hi,
>
>     in my code, I use conv1d (PDL::Primitive) a lot, which generates a
>     BAD values warning every time. Is there a way to suppress this
>     selectively?
>
>     Thanks
>
>     Ingo
>
>     _______________________________________________
>     pdl-general mailing list
>     pdl...@li...
>     https://lists.sourceforge.net/lists/listinfo/pdl-general
>

[Pdl-general] turn off warnings

[Ingo S. <in...@gm...>]

Hi,

in my code, I use conv1d (PDL::Primitive) a lot, which generates a BAD 
values warning every time. Is there a way to suppress this selectively?

Thanks

Ingo

Re: [Pdl-general] PDL::Transform matrix

[Ingo S. <in...@gm...>]

Hi Craig,

please look at the docs, it explicitly says so that it won't calculate 
the inverse if the matrix isn't square.

"    m, matrix, Matrix
        The transformation matrix. It does not even have to be square, 
if you
        want to change the dimensionality of your input. If it is invertible
        (note: must be square for that), then you automagically get an
        inverse transform too.
"

I guess the real issue here is that trying to decompose the non-square 
matrix leads to an error instead of an undefined inverse - in MatrixOps?

Ingo


On 25.09.25 5:37 PM, DeForest, Craig E. wrote:
> I think the concern is that Transform::Linear is trying to produce an 
> inverse matrix, which of course doesn’t exist.  Using a pseudoinverse, 
> projecting to a 2-D plane, is probably the right answer in this context.
>
>> On Sep 25, 2025, at 8:31 AM, Ingo Schmid via pdl-general 
>> <pdl...@li...> wrote:
>>
>> [EXTERNAL EMAIL]
>>
>> Hi,
>>
>> I need coordinate transformations from pixel space to real 3D space. 
>> PDL::Transform is great for this kind of operations. I've got the two 
>> vectors (and hence a 2x3) matrix, let's call it $tm, of the x and y axes.
>>
>> Unfortunately, t_linear(m=>$tm) complains that the matrix is not 
>> square. The docs explicitly say that this should work.
>>
>> Tested on 2.079 and 2.100.
>>
>> pdl> $tm=ones(3,2); # That would also scale
>>
>> pdl> t_linear(matrix=>$tm);
>> Runtime error: lu_decomp requires a square (2D) PDL
>>  at matrixops.pd line 897.
>> PDL::MatrixOps::lu_decomp(PDL=SCALAR(0x55929b90eb70)) called at 
>> matrixops.pd line 337
>>     PDL::MatrixOps::det(PDL=SCALAR(0x55929b90eb70), 
>> HASH(0x55929b910d88)) called at transform.pd line 2769
>> PDL::Transform::Linear::new("PDL::Transform::Linear", "matrix", 
>> PDL=SCALAR(0x55929ba84d30)) called at transform.pd line 2639
>>     PDL::Transform::t_linear("matrix", PDL=SCALAR(0x55929ba84d30)) 
>> called at (eval 472) line
>>
>> It would be great to restore that feature.
>>
>> Ingo
>>
>>
>> _______________________________________________
>> pdl-general mailing list
>> pdl...@li...
>> https://lists.sourceforge.net/lists/listinfo/pdl-general
>

[Pdl-general] PDL::Transform matrix

[Ingo S. <in...@gm...>]

Hi,

I need coordinate transformations from pixel space to real 3D space. 
PDL::Transform is great for this kind of operations. I've got the two 
vectors (and hence a 2x3) matrix, let's call it $tm, of the x and y axes.

Unfortunately, t_linear(m=>$tm) complains that the matrix is not square. 
The docs explicitly say that this should work.

Tested on 2.079 and 2.100.

pdl> $tm=ones(3,2); # That would also scale

pdl> t_linear(matrix=>$tm);
Runtime error: lu_decomp requires a square (2D) PDL
  at matrixops.pd line 897.
     PDL::MatrixOps::lu_decomp(PDL=SCALAR(0x55929b90eb70)) called at 
matrixops.pd line 337
     PDL::MatrixOps::det(PDL=SCALAR(0x55929b90eb70), 
HASH(0x55929b910d88)) called at transform.pd line 2769
     PDL::Transform::Linear::new("PDL::Transform::Linear", "matrix", 
PDL=SCALAR(0x55929ba84d30)) called at transform.pd line 2639
     PDL::Transform::t_linear("matrix", PDL=SCALAR(0x55929ba84d30)) 
called at (eval 472) line

It would be great to restore that feature.

Ingo

[Pdl-general] virtual workshop

[Boyd D. <boy...@gm...>]

I was putting together a page embedding all the youtube uploads of PDL
talks I could find and I was thinking that this might be an easy way of
assembling a PDL workshop. So far, it consists of 5 introductions, 2 talks
on plotting and visualization and 2 on statistics and data.

https://perldatascience.wordpress.com/virtual-conference/

I've tried to keep the descriptions short but engaging, minimizing clutter.
Any comments or additions are welcome, like ... does the comment box at the
bottom make the page look like a cheap blog post?

A suggestion for those who attend conferences, it would be nice to see more
PDL topics covered. Zaki teased the audience with a quick demo of
PDL::OpenCV at the end of his intro talk. I think we're at the stage where
we can just say PDL is numpy for Perl, point to the docs and then get on
with the chewy bits.

How do you feel about telling people how _you_ use PDL? ;)

best,
-- 
Boyd Duffee

“I wasn’t particularly close to my dad before he died… which was lucky,
because he trod on a land mine” Olaf Falafel

MAGA is a rehab facility for charlatans and the cancelled
Trump is a moron whose bankruptcy was bailed out by Putin who is now
pulling his strings.

[Pdl-general] FastRaw

[Luis M. <mo...@ic...>]

Hi,
I just found a mistake in one of my programs which reveals what I
guess is an error in the PDL::IO::FastRaw.

    $ pdl
    ...
    pdl> # create a small ndarray and map it to disk
    pdl> use PDL::IO::FastRaw;
    pdl> $a=mapfraw("rem.dat", {Datatype=>cdouble, Dims=>[10], Creat=>1});
    pdl> q # quit pdl
    $ ...  # do whatever
    $ pdl  # and come back to pdl
    ...
    pdl> # Create a large ndarray and map it to the now existing file
    pdl> $b=mapfraw("rem.dat", {Datatype=>cdouble, Dims=>[1000]});
    pdl> # There is no complain about incompatible dimensions
    pdl> p $b((-1));  # Try to print the last element
    Bus error
    $

mapfraw allowed me to create an ndarray and map it to an existing file
even though the dimensions were incompatible, but then, there was a
bus error with no diagnostic information about the cause.

I guess mapfraw should died on the spot alerting me on the discrepancy
instead of continuing with the execution.

Best regards,
Luis


-- 
                                                                  o
W. Luis Mochán,                      | tel:(52)(777)329-1734     /<(*)
Instituto de Ciencias Físicas, UNAM  | fax:(52)(777)317-5388     `>/   /\
Av. Universidad s/n CP 62210         |                           (*)/\/  \
Cuernavaca, Morelos, México          | mo...@fi...   /\_/\__/
GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16  C2DF 5F0A C52B 791E B9EB

Re: [Pdl-general] confusion with dummies

[Luis M. <mo...@ic...>]

Thanks! I was not aware of the padding vs. replicating behavior, but I
guess it is due to the possibility of pdl accepting non-ndarray
arguments.

Regards,
Luis



On Thu, Aug 21, 2025 at 11:36:29AM +0000, Jörg Sommrey wrote:
> The "pdl" constructor does not replicate values to match dimensions but pads
> them instead.  In contrary, "cat" works as expected:
>
> pdl> do_print 1
> 1
>
> pdl> $v = sequence 2
> [0 1]
>
> pdl> cat $v(,*1), $v(*1,)
>
> [
>  [
>   [0 1]
>   [0 1]
>  ]
>  [
>   [0 0]
>   [1 1]
>  ]
> ]
>
> Best regards,
> -jo
>
> On Tue 19 Aug 2025 07:09:32 PM CEST, Luis Mochan <mo...@ic...> wrote:
>
> > I'm confused by variations of the following program:
> > use v5.36;
> > use PDL;
> > use PDL::NiceSlice;
> > my $v=sequence(2);
> > my $m=pdl($v->slice(":,*2"), $v->slice("*2,:"));
> > say $m;
> >
> > The output is
> >
> >    [
> >     [
> >      [0 1]
> >      [0 1]
> >     ]
> >     [
> >      [0 0]
> >      [1 1]
> >     ]
> >    ]
> >
> > which is what I expected. But after a small change:
> >
> > use v5.36;
> > use PDL;
> > use PDL::NiceSlice;
> > my $v=sequence(2);
> > my $m=pdl($v->slice(":,*"), $v->slice("*,:"));
> > say $m;
> >
> > the output becomes
> >
> >
> > [
> >  [
> >   [0 1]
> >   [0 0]
> >  ]
> >  [
> >   [0 0]
> >   [1 0]
> >  ]
> > ]
> >
> > The same if I replace * by *1. Was I wrong to expect the same output?
> > I expected the dummy dimension of size 1 (or unspecified size) would
> > lead to  the initial array [0 1] being replicated as many times as
> > required by the actual dimensions of the other arrays.
> >
> > Best regards,
> > Luis
>
>
>

-- 

                                                                  o
W. Luis Mochán,                      | tel:(52)(777)329-1734     /<(*)
Instituto de Ciencias Físicas, UNAM  | fax:(52)(777)317-5388     `>/   /\
Av. Universidad s/n CP 62210         |                           (*)/\/  \
Cuernavaca, Morelos, México          | mo...@fi...   /\_/\__/
GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16  C2DF 5F0A C52B 791E B9EB

Re: [Pdl-general] confusion with dummies

[Jörg S. <jo...@so...>]

The "pdl" constructor does not replicate values to match dimensions  
but pads them instead.  In contrary, "cat" works as expected:

pdl> do_print 1
1

pdl> $v = sequence 2
[0 1]

pdl> cat $v(,*1), $v(*1,)

[
  [
   [0 1]
   [0 1]
  ]
  [
   [0 0]
   [1 1]
  ]
]

Best regards,
-jo

On Tue 19 Aug 2025 07:09:32 PM CEST, Luis Mochan <mo...@ic...> wrote:

> I'm confused by variations of the following program:
> use v5.36;
> use PDL;
> use PDL::NiceSlice;
> my $v=sequence(2);
> my $m=pdl($v->slice(":,*2"), $v->slice("*2,:"));
> say $m;
>
> The output is
>
>    [
>     [
>      [0 1]
>      [0 1]
>     ]
>     [
>      [0 0]
>      [1 1]
>     ]
>    ]
>
> which is what I expected. But after a small change:
>
> use v5.36;
> use PDL;
> use PDL::NiceSlice;
> my $v=sequence(2);
> my $m=pdl($v->slice(":,*"), $v->slice("*,:"));
> say $m;
>
> the output becomes
>
>
> [
>  [
>   [0 1]
>   [0 0]
>  ]
>  [
>   [0 0]
>   [1 0]
>  ]
> ]
>
> The same if I replace * by *1. Was I wrong to expect the same output?
> I expected the dummy dimension of size 1 (or unspecified size) would
> lead to  the initial array [0 1] being replicated as many times as
> required by the actual dimensions of the other arrays.
>
> Best regards,
> Luis

[Pdl-general] Subject: Collaboration Opportunity: EEG-Based Schizophrenia Diagnosis with PDL

[נתי ש. <ns...@gm...>]

Dear PDL Users Mailing List,

My name is Netanel Stern, and I am a software developer and AI researcher
specializing in Perl-based machine learning and AI applications. I am
currently working on a project focused on EEG analysis for schizophrenia
(SCZ) diagnosis, leveraging Perl and PDL to build, train, and evaluate
models on EEG datasets.

I am reaching out to explore potential collaboration with the PDL
community. Specifically, I am interested in contributing by:

- Designing model architectures tailored for EEG signal analysis using PDL.
- Implementing preprocessing and feature extraction pipelines for EEG data.
- Sharing evaluation benchmarks and anonymized, privacy-compliant datasets
for SCZ detection.

I believe that combining my domain expertise in EEG-based SCZ diagnostics
with PDL’s powerful numeric computing capabilities could lead to impactful
solutions for the neuroscience and mental health research community.

I would greatly appreciate the opportunity to discuss collaboration or
contribution opportunities and learn how I can best support PDL projects
while advancing research in EEG-based mental health diagnostics.

Thank you for your time and consideration. I look forward to your response.

Best regards,
Netanel Stern

[Pdl-general] confusion with dummies

[Luis M. <mo...@ic...>]

I'm confused by variations of the following program:
use v5.36;
use PDL;
use PDL::NiceSlice;
my $v=sequence(2);
my $m=pdl($v->slice(":,*2"), $v->slice("*2,:"));
say $m;

The output is

   [
    [
     [0 1]
     [0 1]
    ]
    [
     [0 0]
     [1 1]
    ]
   ]

which is what I expected. But after a small change:

use v5.36;
use PDL;
use PDL::NiceSlice;
my $v=sequence(2);
my $m=pdl($v->slice(":,*"), $v->slice("*,:"));
say $m;

the output becomes


[
 [
  [0 1]
  [0 0]
 ]
 [
  [0 0]
  [1 0]
 ]
]

The same if I replace * by *1. Was I wrong to expect the same output?
I expected the dummy dimension of size 1 (or unspecified size) would
lead to  the initial array [0 1] being replicated as many times as
required by the actual dimensions of the other arrays.

Best regards,
Luis



-- 

                                                                  o
W. Luis Mochán,                      | tel:(52)(777)329-1734     /<(*)
Instituto de Ciencias Físicas, UNAM  | fax:(52)(777)317-5388     `>/   /\
Av. Universidad s/n CP 62210         |                           (*)/\/  \
Cuernavaca, Morelos, México          | mo...@fi...   /\_/\__/
GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16  C2DF 5F0A C52B 791E B9EB

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

[Luis M. <mo...@ic...>]

On Sun, Jul 27, 2025 at 11:58:28PM +0000, Ed . wrote:
> My take on this is that magnover has the following needs:
>   * Accept all input types, real or complex
>   * Avoid input conversion of inputs
>   * Promote output to floating-point (similar in style to sumover)
      to avoid loss for many of a small integer type
>   * Constrain the output type to be real-only since that is
      mathematically correct
> ...
> I think this is a real problem (if you'll forgive the pun). I propose an additional type-qualifier realfloatthat would have the effect of combining points 3 and 4, and change these two operations to use that. What do people think?

I think it would be useful, maybe for other operations also.
I'm not too sure about the name realfloat, but maybe it is consistent
with the other qualifiers. I find it difficult to remember the meaning
of the different output qualifiers. Would it be possible to have some
kind of list of alternative params, to express: if input is of such a
type output should be of such other type, else if input is of that
different type then output should be of type... As PP generates
many alternative routines, maybe it wouldn't be too difficult to
cope with more than one PARS specification (I have no idea how the
magical PP code works).

>
> Luis, I will note that your code as written is vulnerable not only to what I believe is a bug in magnover; it wouldn't work when broadcasting, since comparison of multi-element ndarrays is forbidden. That may not be a problem for your application.

You are right, but in my case magnover produced a scalar.

Regards,
Luis

>
> Best regards,
> Ed
> ________________________________
> From: Jörg Sommrey via pdl-devel <pdl...@li...>
> Sent: 24 July 2025 21:44
> To: Luis Mochan <mo...@ic...>
> Cc: perldl <pdl...@li...>; perldl <pdl...@li...>
> Subject: Re: [Pdl-devel] magnover
>
> Hi Luis,
>
> I'm not a PDL expert, just a hobbyist.  In my understanding, reducing
> the set of GenericTypes will limit the generated type-loop to this set
> and will cause any input arguments outside of this type set to be
> converted first.  This would mean that a large integer vector will be
> converted to float first and a large ndarray of higher dimensions
> would be converted vector-wise.
>
> An authoritative answer can be given by an expert only.
>
> Regards,
> -jo
>
>
> On Thu 24 Jul 2025 10:08:03 PM CEST, Luis Mochan <mo...@ic...> wrote:
>
> > Hi Jörg,
> > Thanks. It does work. I have a question: if the input is some large
> > vector of some kind of integers, is it first converted to a float
> > vector with this solution? Should the possible space wasted be a
> > concern?
> > Regards,
> > Luis
> >
> >
> >
> > I guess, is that
> >
> > On Thu, Jul 24, 2025 at 07:19:50PM +0000, Jörg Sommrey wrote:
> >> Hello Luis,
> >>
> >> probably this does the trick:
> >>
> >> pp_def('magnover',
> >>   HandleBad => 1,
> >>   Pars => "a(n); real [o]b();",
> >>   GenericTypes => [qw(H C G E D F)],
> >>
> >>
> >> Then in t/ufunc.t (line 106) the expected type just needs to be changed from
> >> 'cdouble' to 'double'.
> >>
> >> Integer types will be promoted to float and complex types to their real
> >> counterparts:
> >>
> >> say cdouble('[1+i, 1-i, -1+i, -1-i]')->magnover->info;
> >> say sequence($_, 4)->magnover->info for byte, long, float, double;
> >>
> >> PDL: Double D []
> >> PDL: Float D []
> >> PDL: Float D []
> >> PDL: Float D []
> >> PDL: Double D []
> >>
> >> Regards,
> >> -jo
> >>
> >>
> >> On Thu 24 Jul 2025 06:36:39 PM CEST, Luis Mochan <mo...@ic...> wrote:
> >>
> >> > On Wed, Jul 23, 2025 at 11:56:00AM +0000, Jörg Sommrey wrote:
> >> > > Hello Luis,
> >> > >
> >> > > the results look fine when the expected types in the two
> >> failing tests are
> >> > > adjusted. Don't know if it would break any "real" code, maybe
> >> "is_pdl" is
> >> > > just too strict here.
> >> >
> >> > I believe there are good reasons for the qualifier float+ in the case
> >> > of, for example, a vector of bytes: on one hand, the euclidean
> >> > magnitude of a vector of integers is not necessarily integer: (3,4)->5
> >> > but (1,1)->1.4142... On the other hand, the magnitude of a large
> >> > vector of bytes may overflow a byte. Nevertheless, I expect the
> >> > magnitude of a complex to be real, not a complex. A complex with a
> >> > zero imaginary part works but wastes some time and space. Thus,
> >> it would be
> >> > ideal if one could specify both, float+ and real as qualifiers of the
> >> > output of magnover, but that doesn't work. Is there an alternative for
> >> > a more flexible way to determine the correct type of an output
> >> > parameter based on that of the inputs? Meanwhile, I can simply
> >> > take the real part of the magnitudes :)
> >> >
> >> > Regards,
> >> > Luis
> >> >
> >> >
> >> > >
> >> > > t/ufunc.t:
> >> > > is_pdl $empty->magnover, sbyte('BAD'), "bad flag gets set on empty
> >> > > magnover";
> >> > > is_pdl +(sequence(4)+i())->magnover, double(4.242640),
> >> 'magnover correct for
> >> > > complex';
> >> > >
> >> > > Best regards,
> >> > > -jo
> >> > >
> >> > >
> >> > > On Wed 23 Jul 2025 04:52:24 AM CEST, Luis Mochan
> >> <mo...@ic...> wrote:
> >> > >
> >> > > > Hello,
> >> > > >
> >> > > > In some of my programs I used the code such as
> >> > > >
> >> > > >     $abs=$cvec->abs2->sumover->sqrt;
> >> > > >
> >> > > > to get the magnitude of a vector $cvec. I just replaced it to
> >> the cleaner
> >> > > >
> >> > > >     $abs=$cvec->magnover;
> >> > > >
> >> > > > But then my program failed when I made the comparison
> >> > > >
> >> > > >    if($abs > 0){...}
> >> > > >
> >> > > > with the message
> >> > > >
> >> > > >     Can't compare complex numbers at lib/PDL/PP.pm line 1445.
> >> > > >
> >> > > > It is true that we shouldn't compare complex numbers, except for
> >> > > > equality, but, shouldn't the magnitude of a complex vector be a real
> >> > > > number instead of a complex number (with zero imaginary part)?
> >> > > >
> >> > > > I tried to fix it by replacing the qualifier 'float+' in the pp_def of
> >> > > > magnover in Ufunc.pd by the qualifier 'real', but then the tests fail
> >> > > > as bytes are not converted to floats.
> >> > > >
> >> > > > Best regards,
> >> > > >
> >> > > > Luis
> >> > >
> >> > >
> >> > >
> >>
> >>
> >>
>
>
>
>
> _______________________________________________
> pdl-devel mailing list
> pdl...@li...
> https://lists.sourceforge.net/lists/listinfo/pdl-devel

-- 

                                                                  o
W. Luis Mochán,                      | tel:(52)(777)329-1734     /<(*)
Instituto de Ciencias Físicas, UNAM  | fax:(52)(777)317-5388     `>/   /\
Av. Universidad s/n CP 62210         |                           (*)/\/  \
Cuernavaca, Morelos, México          | mo...@fi...   /\_/\__/
GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16  C2DF 5F0A C52B 791E B9EB

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

[Ed . <ej...@ho...>]

My take on this is that magnover has the following needs:

  *
Accept all input types, real or complex
  *
Avoid input conversion of inputs
  *
Promote output to floating-point (similar in style to sumover) to avoid loss for many of a small integer type
  *
Constrain the output type to be real-only since that is mathematically correct

Currently magnover is:
pp_def('magnover',
  HandleBad => 1,
  Pars => "a(n); float+ [o]b();",
  GenericTypes => $A,

Which fails the last point.

abs2 is:
pp_def('abs2',
  GenericTypes=>$A,
  HandleBad => 1,
  Pars => 'a(); real [o]b()',

Which fails the third point, so could lose information for e.g. an 8-bit integer.

I think this is a real problem (if you'll forgive the pun). I propose an additional type-qualifier realfloatthat would have the effect of combining points 3 and 4, and change these two operations to use that. What do people think?

Luis, I will note that your code as written is vulnerable not only to what I believe is a bug in magnover; it wouldn't work when broadcasting, since comparison of multi-element ndarrays is forbidden. That may not be a problem for your application.

Best regards,
Ed
________________________________
From: Jörg Sommrey via pdl-devel <pdl...@li...>
Sent: 24 July 2025 21:44
To: Luis Mochan <mo...@ic...>
Cc: perldl <pdl...@li...>; perldl <pdl...@li...>
Subject: Re: [Pdl-devel] magnover

Hi Luis,

I'm not a PDL expert, just a hobbyist.  In my understanding, reducing
the set of GenericTypes will limit the generated type-loop to this set
and will cause any input arguments outside of this type set to be
converted first.  This would mean that a large integer vector will be
converted to float first and a large ndarray of higher dimensions
would be converted vector-wise.

An authoritative answer can be given by an expert only.

Regards,
-jo


On Thu 24 Jul 2025 10:08:03 PM CEST, Luis Mochan <mo...@ic...> wrote:

> Hi Jörg,
> Thanks. It does work. I have a question: if the input is some large
> vector of some kind of integers, is it first converted to a float
> vector with this solution? Should the possible space wasted be a
> concern?
> Regards,
> Luis
>
>
>
> I guess, is that
>
> On Thu, Jul 24, 2025 at 07:19:50PM +0000, Jörg Sommrey wrote:
>> Hello Luis,
>>
>> probably this does the trick:
>>
>> pp_def('magnover',
>>   HandleBad => 1,
>>   Pars => "a(n); real [o]b();",
>>   GenericTypes => [qw(H C G E D F)],
>>
>>
>> Then in t/ufunc.t (line 106) the expected type just needs to be changed from
>> 'cdouble' to 'double'.
>>
>> Integer types will be promoted to float and complex types to their real
>> counterparts:
>>
>> say cdouble('[1+i, 1-i, -1+i, -1-i]')->magnover->info;
>> say sequence($_, 4)->magnover->info for byte, long, float, double;
>>
>> PDL: Double D []
>> PDL: Float D []
>> PDL: Float D []
>> PDL: Float D []
>> PDL: Double D []
>>
>> Regards,
>> -jo
>>
>>
>> On Thu 24 Jul 2025 06:36:39 PM CEST, Luis Mochan <mo...@ic...> wrote:
>>
>> > On Wed, Jul 23, 2025 at 11:56:00AM +0000, Jörg Sommrey wrote:
>> > > Hello Luis,
>> > >
>> > > the results look fine when the expected types in the two
>> failing tests are
>> > > adjusted. Don't know if it would break any "real" code, maybe
>> "is_pdl" is
>> > > just too strict here.
>> >
>> > I believe there are good reasons for the qualifier float+ in the case
>> > of, for example, a vector of bytes: on one hand, the euclidean
>> > magnitude of a vector of integers is not necessarily integer: (3,4)->5
>> > but (1,1)->1.4142... On the other hand, the magnitude of a large
>> > vector of bytes may overflow a byte. Nevertheless, I expect the
>> > magnitude of a complex to be real, not a complex. A complex with a
>> > zero imaginary part works but wastes some time and space. Thus,
>> it would be
>> > ideal if one could specify both, float+ and real as qualifiers of the
>> > output of magnover, but that doesn't work. Is there an alternative for
>> > a more flexible way to determine the correct type of an output
>> > parameter based on that of the inputs? Meanwhile, I can simply
>> > take the real part of the magnitudes :)
>> >
>> > Regards,
>> > Luis
>> >
>> >
>> > >
>> > > t/ufunc.t:
>> > > is_pdl $empty->magnover, sbyte('BAD'), "bad flag gets set on empty
>> > > magnover";
>> > > is_pdl +(sequence(4)+i())->magnover, double(4.242640),
>> 'magnover correct for
>> > > complex';
>> > >
>> > > Best regards,
>> > > -jo
>> > >
>> > >
>> > > On Wed 23 Jul 2025 04:52:24 AM CEST, Luis Mochan
>> <mo...@ic...> wrote:
>> > >
>> > > > Hello,
>> > > >
>> > > > In some of my programs I used the code such as
>> > > >
>> > > >     $abs=$cvec->abs2->sumover->sqrt;
>> > > >
>> > > > to get the magnitude of a vector $cvec. I just replaced it to
>> the cleaner
>> > > >
>> > > >     $abs=$cvec->magnover;
>> > > >
>> > > > But then my program failed when I made the comparison
>> > > >
>> > > >    if($abs > 0){...}
>> > > >
>> > > > with the message
>> > > >
>> > > >     Can't compare complex numbers at lib/PDL/PP.pm line 1445.
>> > > >
>> > > > It is true that we shouldn't compare complex numbers, except for
>> > > > equality, but, shouldn't the magnitude of a complex vector be a real
>> > > > number instead of a complex number (with zero imaginary part)?
>> > > >
>> > > > I tried to fix it by replacing the qualifier 'float+' in the pp_def of
>> > > > magnover in Ufunc.pd by the qualifier 'real', but then the tests fail
>> > > > as bytes are not converted to floats.
>> > > >
>> > > > Best regards,
>> > > >
>> > > > Luis
>> > >
>> > >
>> > >
>>
>>
>>




_______________________________________________
pdl-devel mailing list
pdl...@li...
https://lists.sourceforge.net/lists/listinfo/pdl-devel

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

[Jörg S. <jo...@so...>]

Hi Luis,

I'm not a PDL expert, just a hobbyist.  In my understanding, reducing  
the set of GenericTypes will limit the generated type-loop to this set  
and will cause any input arguments outside of this type set to be  
converted first.  This would mean that a large integer vector will be  
converted to float first and a large ndarray of higher dimensions  
would be converted vector-wise.

An authoritative answer can be given by an expert only.

Regards,
-jo


On Thu 24 Jul 2025 10:08:03 PM CEST, Luis Mochan <mo...@ic...> wrote:

> Hi Jörg,
> Thanks. It does work. I have a question: if the input is some large
> vector of some kind of integers, is it first converted to a float
> vector with this solution? Should the possible space wasted be a
> concern?
> Regards,
> Luis
>
>
>
> I guess, is that
>
> On Thu, Jul 24, 2025 at 07:19:50PM +0000, Jörg Sommrey wrote:
>> Hello Luis,
>>
>> probably this does the trick:
>>
>> pp_def('magnover',
>>   HandleBad => 1,
>>   Pars => "a(n); real [o]b();",
>>   GenericTypes => [qw(H C G E D F)],
>>
>>
>> Then in t/ufunc.t (line 106) the expected type just needs to be changed from
>> 'cdouble' to 'double'.
>>
>> Integer types will be promoted to float and complex types to their real
>> counterparts:
>>
>> say cdouble('[1+i, 1-i, -1+i, -1-i]')->magnover->info;
>> say sequence($_, 4)->magnover->info for byte, long, float, double;
>>
>> PDL: Double D []
>> PDL: Float D []
>> PDL: Float D []
>> PDL: Float D []
>> PDL: Double D []
>>
>> Regards,
>> -jo
>>
>>
>> On Thu 24 Jul 2025 06:36:39 PM CEST, Luis Mochan <mo...@ic...> wrote:
>>
>> > On Wed, Jul 23, 2025 at 11:56:00AM +0000, Jörg Sommrey wrote:
>> > > Hello Luis,
>> > >
>> > > the results look fine when the expected types in the two  
>> failing tests are
>> > > adjusted. Don't know if it would break any "real" code, maybe  
>> "is_pdl" is
>> > > just too strict here.
>> >
>> > I believe there are good reasons for the qualifier float+ in the case
>> > of, for example, a vector of bytes: on one hand, the euclidean
>> > magnitude of a vector of integers is not necessarily integer: (3,4)->5
>> > but (1,1)->1.4142... On the other hand, the magnitude of a large
>> > vector of bytes may overflow a byte. Nevertheless, I expect the
>> > magnitude of a complex to be real, not a complex. A complex with a
>> > zero imaginary part works but wastes some time and space. Thus,  
>> it would be
>> > ideal if one could specify both, float+ and real as qualifiers of the
>> > output of magnover, but that doesn't work. Is there an alternative for
>> > a more flexible way to determine the correct type of an output
>> > parameter based on that of the inputs? Meanwhile, I can simply
>> > take the real part of the magnitudes :)
>> >
>> > Regards,
>> > Luis
>> >
>> >
>> > >
>> > > t/ufunc.t:
>> > > is_pdl $empty->magnover, sbyte('BAD'), "bad flag gets set on empty
>> > > magnover";
>> > > is_pdl +(sequence(4)+i())->magnover, double(4.242640),  
>> 'magnover correct for
>> > > complex';
>> > >
>> > > Best regards,
>> > > -jo
>> > >
>> > >
>> > > On Wed 23 Jul 2025 04:52:24 AM CEST, Luis Mochan  
>> <mo...@ic...> wrote:
>> > >
>> > > > Hello,
>> > > >
>> > > > In some of my programs I used the code such as
>> > > >
>> > > >     $abs=$cvec->abs2->sumover->sqrt;
>> > > >
>> > > > to get the magnitude of a vector $cvec. I just replaced it to  
>> the cleaner
>> > > >
>> > > >     $abs=$cvec->magnover;
>> > > >
>> > > > But then my program failed when I made the comparison
>> > > >
>> > > >    if($abs > 0){...}
>> > > >
>> > > > with the message
>> > > >
>> > > >     Can't compare complex numbers at lib/PDL/PP.pm line 1445.
>> > > >
>> > > > It is true that we shouldn't compare complex numbers, except for
>> > > > equality, but, shouldn't the magnitude of a complex vector be a real
>> > > > number instead of a complex number (with zero imaginary part)?
>> > > >
>> > > > I tried to fix it by replacing the qualifier 'float+' in the pp_def of
>> > > > magnover in Ufunc.pd by the qualifier 'real', but then the tests fail
>> > > > as bytes are not converted to floats.
>> > > >
>> > > > Best regards,
>> > > >
>> > > > Luis
>> > >
>> > >
>> > >
>>
>>
>>

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

[Luis M. <mo...@ic...>]

Hi Jörg,
Thanks. It does work. I have a question: if the input is some large
vector of some kind of integers, is it first converted to a float
vector with this solution? Should the possible space wasted be a
concern?
Regards,
Luis



I guess, is that

On Thu, Jul 24, 2025 at 07:19:50PM +0000, Jörg Sommrey wrote:
> Hello Luis,
>
> probably this does the trick:
>
> pp_def('magnover',
>   HandleBad => 1,
>   Pars => "a(n); real [o]b();",
>   GenericTypes => [qw(H C G E D F)],
>
>
> Then in t/ufunc.t (line 106) the expected type just needs to be changed from
> 'cdouble' to 'double'.
>
> Integer types will be promoted to float and complex types to their real
> counterparts:
>
> say cdouble('[1+i, 1-i, -1+i, -1-i]')->magnover->info;
> say sequence($_, 4)->magnover->info for byte, long, float, double;
>
> PDL: Double D []
> PDL: Float D []
> PDL: Float D []
> PDL: Float D []
> PDL: Double D []
>
> Regards,
> -jo
>
>
> On Thu 24 Jul 2025 06:36:39 PM CEST, Luis Mochan <mo...@ic...> wrote:
>
> > On Wed, Jul 23, 2025 at 11:56:00AM +0000, Jörg Sommrey wrote:
> > > Hello Luis,
> > >
> > > the results look fine when the expected types in the two failing tests are
> > > adjusted. Don't know if it would break any "real" code, maybe "is_pdl" is
> > > just too strict here.
> >
> > I believe there are good reasons for the qualifier float+ in the case
> > of, for example, a vector of bytes: on one hand, the euclidean
> > magnitude of a vector of integers is not necessarily integer: (3,4)->5
> > but (1,1)->1.4142... On the other hand, the magnitude of a large
> > vector of bytes may overflow a byte. Nevertheless, I expect the
> > magnitude of a complex to be real, not a complex. A complex with a
> > zero imaginary part works but wastes some time and space. Thus, it would be
> > ideal if one could specify both, float+ and real as qualifiers of the
> > output of magnover, but that doesn't work. Is there an alternative for
> > a more flexible way to determine the correct type of an output
> > parameter based on that of the inputs? Meanwhile, I can simply
> > take the real part of the magnitudes :)
> >
> > Regards,
> > Luis
> >
> >
> > >
> > > t/ufunc.t:
> > > is_pdl $empty->magnover, sbyte('BAD'), "bad flag gets set on empty
> > > magnover";
> > > is_pdl +(sequence(4)+i())->magnover, double(4.242640), 'magnover correct for
> > > complex';
> > >
> > > Best regards,
> > > -jo
> > >
> > >
> > > On Wed 23 Jul 2025 04:52:24 AM CEST, Luis Mochan <mo...@ic...> wrote:
> > >
> > > > Hello,
> > > >
> > > > In some of my programs I used the code such as
> > > >
> > > >     $abs=$cvec->abs2->sumover->sqrt;
> > > >
> > > > to get the magnitude of a vector $cvec. I just replaced it to the cleaner
> > > >
> > > >     $abs=$cvec->magnover;
> > > >
> > > > But then my program failed when I made the comparison
> > > >
> > > >    if($abs > 0){...}
> > > >
> > > > with the message
> > > >
> > > >     Can't compare complex numbers at lib/PDL/PP.pm line 1445.
> > > >
> > > > It is true that we shouldn't compare complex numbers, except for
> > > > equality, but, shouldn't the magnitude of a complex vector be a real
> > > > number instead of a complex number (with zero imaginary part)?
> > > >
> > > > I tried to fix it by replacing the qualifier 'float+' in the pp_def of
> > > > magnover in Ufunc.pd by the qualifier 'real', but then the tests fail
> > > > as bytes are not converted to floats.
> > > >
> > > > Best regards,
> > > >
> > > > Luis
> > >
> > >
> > >
>
>
>

-- 

                                                                  o
W. Luis Mochán,                      | tel:(52)(777)329-1734     /<(*)
Instituto de Ciencias Físicas, UNAM  | fax:(52)(777)317-5388     `>/   /\
Av. Universidad s/n CP 62210         |                           (*)/\/  \
Cuernavaca, Morelos, México          | mo...@fi...   /\_/\__/
GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16  C2DF 5F0A C52B 791E B9EB

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

[Jörg S. <jo...@so...>]

Hello Luis,

probably this does the trick:

pp_def('magnover',
   HandleBad => 1,
   Pars => "a(n); real [o]b();",
   GenericTypes => [qw(H C G E D F)],


Then in t/ufunc.t (line 106) the expected type just needs to be  
changed from 'cdouble' to 'double'.

Integer types will be promoted to float and complex types to their  
real counterparts:

say cdouble('[1+i, 1-i, -1+i, -1-i]')->magnover->info;
say sequence($_, 4)->magnover->info for byte, long, float, double;

PDL: Double D []
PDL: Float D []
PDL: Float D []
PDL: Float D []
PDL: Double D []

Regards,
-jo


On Thu 24 Jul 2025 06:36:39 PM CEST, Luis Mochan <mo...@ic...> wrote:

> On Wed, Jul 23, 2025 at 11:56:00AM +0000, Jörg Sommrey wrote:
>> Hello Luis,
>>
>> the results look fine when the expected types in the two failing tests are
>> adjusted. Don't know if it would break any "real" code, maybe "is_pdl" is
>> just too strict here.
>
> I believe there are good reasons for the qualifier float+ in the case
> of, for example, a vector of bytes: on one hand, the euclidean
> magnitude of a vector of integers is not necessarily integer: (3,4)->5
> but (1,1)->1.4142... On the other hand, the magnitude of a large
> vector of bytes may overflow a byte. Nevertheless, I expect the
> magnitude of a complex to be real, not a complex. A complex with a
> zero imaginary part works but wastes some time and space. Thus, it would be
> ideal if one could specify both, float+ and real as qualifiers of the
> output of magnover, but that doesn't work. Is there an alternative for
> a more flexible way to determine the correct type of an output
> parameter based on that of the inputs? Meanwhile, I can simply
> take the real part of the magnitudes :)
>
> Regards,
> Luis
>
>
>>
>> t/ufunc.t:
>> is_pdl $empty->magnover, sbyte('BAD'), "bad flag gets set on empty  
>> magnover";
>> is_pdl +(sequence(4)+i())->magnover, double(4.242640), 'magnover correct for
>> complex';
>>
>> Best regards,
>> -jo
>>
>>
>> On Wed 23 Jul 2025 04:52:24 AM CEST, Luis Mochan <mo...@ic...> wrote:
>>
>> > Hello,
>> >
>> > In some of my programs I used the code such as
>> >
>> >     $abs=$cvec->abs2->sumover->sqrt;
>> >
>> > to get the magnitude of a vector $cvec. I just replaced it to the cleaner
>> >
>> >     $abs=$cvec->magnover;
>> >
>> > But then my program failed when I made the comparison
>> >
>> >    if($abs > 0){...}
>> >
>> > with the message
>> >
>> >     Can't compare complex numbers at lib/PDL/PP.pm line 1445.
>> >
>> > It is true that we shouldn't compare complex numbers, except for
>> > equality, but, shouldn't the magnitude of a complex vector be a real
>> > number instead of a complex number (with zero imaginary part)?
>> >
>> > I tried to fix it by replacing the qualifier 'float+' in the pp_def of
>> > magnover in Ufunc.pd by the qualifier 'real', but then the tests fail
>> > as bytes are not converted to floats.
>> >
>> > Best regards,
>> >
>> > Luis
>>
>>
>>

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

[Luis M. <mo...@ic...>]

On Wed, Jul 23, 2025 at 11:56:00AM +0000, Jörg Sommrey wrote:
> Hello Luis,
>
> the results look fine when the expected types in the two failing tests are
> adjusted. Don't know if it would break any "real" code, maybe "is_pdl" is
> just too strict here.

I believe there are good reasons for the qualifier float+ in the case
of, for example, a vector of bytes: on one hand, the euclidean
magnitude of a vector of integers is not necessarily integer: (3,4)->5
but (1,1)->1.4142... On the other hand, the magnitude of a large
vector of bytes may overflow a byte. Nevertheless, I expect the
magnitude of a complex to be real, not a complex. A complex with a
zero imaginary part works but wastes some time and space. Thus, it would be
ideal if one could specify both, float+ and real as qualifiers of the
output of magnover, but that doesn't work. Is there an alternative for
a more flexible way to determine the correct type of an output
parameter based on that of the inputs? Meanwhile, I can simply
take the real part of the magnitudes :)

Regards,
Luis


>
> t/ufunc.t:
> is_pdl $empty->magnover, sbyte('BAD'), "bad flag gets set on empty magnover";
> is_pdl +(sequence(4)+i())->magnover, double(4.242640), 'magnover correct for
> complex';
>
> Best regards,
> -jo
>
>
> On Wed 23 Jul 2025 04:52:24 AM CEST, Luis Mochan <mo...@ic...> wrote:
>
> > Hello,
> >
> > In some of my programs I used the code such as
> >
> >     $abs=$cvec->abs2->sumover->sqrt;
> >
> > to get the magnitude of a vector $cvec. I just replaced it to the cleaner
> >
> >     $abs=$cvec->magnover;
> >
> > But then my program failed when I made the comparison
> >
> >    if($abs > 0){...}
> >
> > with the message
> >
> >     Can't compare complex numbers at lib/PDL/PP.pm line 1445.
> >
> > It is true that we shouldn't compare complex numbers, except for
> > equality, but, shouldn't the magnitude of a complex vector be a real
> > number instead of a complex number (with zero imaginary part)?
> >
> > I tried to fix it by replacing the qualifier 'float+' in the pp_def of
> > magnover in Ufunc.pd by the qualifier 'real', but then the tests fail
> > as bytes are not converted to floats.
> >
> > Best regards,
> >
> > Luis
>
>
>

-- 

                                                                  o
W. Luis Mochán,                      | tel:(52)(777)329-1734     /<(*)
Instituto de Ciencias Físicas, UNAM  | fax:(52)(777)317-5388     `>/   /\
Av. Universidad s/n CP 62210         |                           (*)/\/  \
Cuernavaca, Morelos, México          | mo...@fi...   /\_/\__/
GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16  C2DF 5F0A C52B 791E B9EB

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

[Jörg S. <jo...@so...>]

Hello Luis,

the results look fine when the expected types in the two failing tests  
are adjusted. Don't know if it would break any "real" code, maybe  
"is_pdl" is just too strict here.

t/ufunc.t:
is_pdl $empty->magnover, sbyte('BAD'), "bad flag gets set on empty magnover";
is_pdl +(sequence(4)+i())->magnover, double(4.242640), 'magnover  
correct for complex';

Best regards,
-jo


On Wed 23 Jul 2025 04:52:24 AM CEST, Luis Mochan <mo...@ic...> wrote:

> Hello,
>
> In some of my programs I used the code such as
>
>     $abs=$cvec->abs2->sumover->sqrt;
>
> to get the magnitude of a vector $cvec. I just replaced it to the cleaner
>
>     $abs=$cvec->magnover;
>
> But then my program failed when I made the comparison
>
>    if($abs > 0){...}
>
> with the message
>
>     Can't compare complex numbers at lib/PDL/PP.pm line 1445.
>
> It is true that we shouldn't compare complex numbers, except for
> equality, but, shouldn't the magnitude of a complex vector be a real
> number instead of a complex number (with zero imaginary part)?
>
> I tried to fix it by replacing the qualifier 'float+' in the pp_def of
> magnover in Ufunc.pd by the qualifier 'real', but then the tests fail
> as bytes are not converted to floats.
>
> Best regards,
>
> Luis

[Pdl-general] magnover

[Luis M. <mo...@ic...>]

Hello,

In some of my programs I used the code such as

    $abs=$cvec->abs2->sumover->sqrt;

to get the magnitude of a vector $cvec. I just replaced it to the cleaner

    $abs=$cvec->magnover;

But then my program failed when I made the comparison

   if($abs > 0){...}

with the message

    Can't compare complex numbers at lib/PDL/PP.pm line 1445.

It is true that we shouldn't compare complex numbers, except for
equality, but, shouldn't the magnitude of a complex vector be a real
number instead of a complex number (with zero imaginary part)?

I tried to fix it by replacing the qualifier 'float+' in the pp_def of
magnover in Ufunc.pd by the qualifier 'real', but then the tests fail
as bytes are not converted to floats.

Best regards,

Luis

-- 

                                                                  o
W. Luis Mochán,                      | tel:(52)(777)329-1734     /<(*)
Instituto de Ciencias Físicas, UNAM  | fax:(52)(777)317-5388     `>/   /\
Av. Universidad s/n CP 62210         |                           (*)/\/  \
Cuernavaca, Morelos, México          | mo...@fi...   /\_/\__/
GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16  C2DF 5F0A C52B 791E B9EB

[Pdl-general] Summer Perl Community Conference - CFP

[Brett E. <bre...@gm...>]

We'd love to get have some PDL related talks, better even some paper-based
talks suitable for the Science Track and Science Perl Journal Summer Issue.

PDL is a critical part of any science done using Perl, as you know. And
some of you have already contributed to our conferences and SPJ issues in
the past; for this we're greatly appreciative and want to encourage
continued enagement. To submit a talk (paper-based or otherwise), please
see the following:

https://blogs.perl.org/users/oodler_577/2025/05/call-for-papers---perl-community-conference-summer-2025.html

This is a hybrid conference - even for speakers, if it is not feasible for
you to travel to Austin, TX on July 3rd/4th.

Cheers,
Brett Estrade

-- 
This email message is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. Any unauthorized use or
disclosure is prohibited. If you are not the intended recipient, please
contact the sender by reply email and destroy all copies of the original
message. Thank you.