pdl-general — PDL Users Question and Discussion

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

[Pdl-general] PDL::Stats 0.854 released

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

Dear PDL folks,

PDL::Stats 0.854 has just been released. Significant changes in recent times:

  *   https://rt.cpan.org/Ticket/Display.html?id=97925 has been fixed: now anova_rptd works with mixed-model designs
  *   There's now a demo at https://pdl.perl.org/?page=demos/stats
  *   The plotting functions now use PDL::Graphics::Simple<https://metacpan.org/pod/PDL%3A%3AGraphics%3A%3ASimple> (which facilitates generating the above)
  *   The plotting functions have also had a tidy-up, and now include plotting categorical anova data with stripcharts
  *   It uses the new PDL 2.096+ "lib/*.pd" format so it builds quicker

Any problems, please let us know by opening a GitHub issue, joining the IRC channel (both linked on the PDL::Stats<https://metacpan.org/pod/PDL%3A%3AStats> page) or emailing the pdl-general list.

Best regards,
Ed

Re: [Pdl-general] [Pdl-devel] conditional inline

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

Hi Ed,
Was this the official announcement of PDL2.099?


On Fri, Jan 24, 2025 at 12:17:05AM +0000, Ed . wrote:
> That does look more simple! PDL 2.099 is out now with the ND_both functions, announcement to follow soon. Luis, I moved csqrt* to PDL::Math, as I felt the other c* functions sat there more naturally.

Sounds reasonable.

> Take a look at the automatically generated docs (the "signature" with types, the "usage" section at the top, and the notes on broadcasting etc at the bottom) on https://metacpan.org/pod/PDL::Math#csqrt, I think they're pretty neat.

Indeed. Magical.

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] conditional inline

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

That does look more simple! PDL 2.099 is out now with the ND_both functions, announcement to follow soon. Luis, I moved csqrt* to PDL::Math, as I felt the other c* functions sat there more naturally. Take a look at the automatically generated docs (the "signature" with types, the "usage" section at the top, and the notes on broadcasting etc at the bottom) on https://metacpan.org/pod/PDL::Math#csqrt, I think they're pretty neat.

Another thing I didn't think of to mention: that magnover usage makes me think you're "really" doing https://metacpan.org/pod/PDL::Basic#rvals with a specified centre. That might make things more concise, and/or provide more options when exploring similar problems.

Best regards,
Ed


________________________________
From: Guillermo P. Ortiz <go...@ex...>
Sent: 23 January 2025 19:59
To: Boyd Duffee <boy...@gm...>
Cc: Ed . <ej...@ho...>; pdl...@li... <pdl...@li...>; perldl <pdl...@li...>
Subject: Re: [Pdl-devel] conditional inline

Hi Boyd,
thank you very much for your suggestions.
Using that idea we might obtain a simpler solution.

pdl> $r=zeroes(3,3)->ndcoords/2-pdl(0.5,0.5)

pdl> $rr=$r->magnover

pdl> $mask= $rr<0.4

pdl> $x= $r->slice("(0)")

pdl> $f = ($x+5) * $mask + $x*2 * (! $mask )

pdl> p $rr

[
 [       0.70710678               0.5        0.70710678]
 [              0.5                 0               0.5]
 [       0.70710678               0.5        0.70710678]
]


pdl> p $mask

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


pdl> p $x

[
 [-0.5    0  0.5]
 [-0.5    0  0.5]
 [-0.5    0  0.5]
]


pdl> p $f

[
 [-1  0  1]
 [-1  5  1]
 [-1  0  1]
]

Best regards



El mié, 22 ene 2025 a las 14:46, Boyd Duffee (<boy...@gm...<mailto:boy...@gm...>>) escribió:
I'll throw some confusion into the mix with a different approach, which may not suit you. I would think of the conditional as applying a series of binary masks to your ndarray. Maybe something like

$r = rvals(9,9)
$mask = $r > 2
$r2 = $r**2 * $mask + $r * (! $mask)

where $mask is the binary value of the conditional you wanted the square and the (! $mask) is everywhere else. To build up multiple conditionals, you would create several masks, one for each conditional. You combine the masks by multiplying together for AND and adding together for OR.

It's prettier, but does it work for you?  (maybe if you draw the problem and upload it as a gist on github or similar, we can see what else you could try)

saludos,
Boyd

On Wed, 22 Jan 2025 at 16:24, Guillermo P. Ortiz <go...@ex...<mailto:go...@ex...>> wrote:
Hello again,
I find some a not pretty solution using whereND


$r=(zeroes(3,3)->ndcoords/2-pdl(0.5,0.5))->r2C
$rr=($r**2)->sumover->sqrt
($r1,$r2)=whereND($r->slice("(0)"),$r->slice("(1)"),$rr->abs<0.2)
($r3,$r4)=whereND($r->slice("(0)"),$r->slice("(1)"),$rr->abs>=0.2)

Then. modifying
$r1.= f($r1)
$r3.= f($r2,$r4)
...

Perform back dataflow to $r that I am looking for
Maybe a better solution is possible?

Best regards











El mié, 22 ene 2025 a las 12:39, Guillermo P. Ortiz (<go...@ex...<mailto:go...@ex...>>) escribió:
Hello,
the complex number in the case 1D can be obtained as expected
doing first $r=$r->r2C

But in 2D case I still did not have succeeded to match with
dataflow on $r in the sense of the mask

For example, If I do

$r=(zeroes(3,3)->ndcoords/2-pdl(0.5,0.5))->r2C;
$rr=($r**2)->sumover->sqrt;
($r1,$r2)=where_both($rr,$rr->abs<0.2)

I obtain the expected result in $r1 and $r2 in agreement
with the mask of the vectors lengths

But, how to pass from that the respective length in the $r1
and $r2 to the vectors in $r ? It would be some index indirection that
manage these facts?

Regards
















El mar, 21 ene 2025 a las 20:35, Guillermo P. Ortiz (<go...@ex...<mailto:go...@ex...>>) escribió:
Hi Ed,
yes, just I was trying with where_both
But I get unexpected behaviour for me in 2D case

1) first in 1D

pdl> $r=zeroes(3)->ndcoords/2-pdl(0.5)
pdl> p $r
[
 [-0.5]
 [   0]
 [ 0.5]
]

pdl> ($r1,$r2)=where_both($r,$r->abs < 0.2)

pdl> p $r1
[0]

pdl> p $r2
[-0.5 0.5]

now, trying to modify $r following that condition

pdl> $r1.=$r1+1

pdl> $r2.=$r2+3

pdl> p $r

[
 [2.5]
 [  1]
 [3.5]
]

But this seem did not work for complex number

pdl> $r1.=$r1*(1+i)

pdl> $r2.=$r2-(1+i)

pdl> p $r

[
 [1.5]
 [  1]
 [2.5]
]

And, seem did not work in 2D for real case neither

pdl> $r=zeroes(3,3)->ndcoords/2-pdl(0.5,0.5)

pdl> p $r

[
 [
  [-0.5 -0.5]
  [   0 -0.5]
  [ 0.5 -0.5]
 ]
 [
  [-0.5    0]
  [   0    0]
 [ 0.5    0]
 ]
 [
  [-0.5  0.5]
  [   0  0.5]
  [ 0.5  0.5]
]
]

pdl> ($r1,$r2)=where_both($r,($r**2)->sumover->sqrt < 0.2)

pdl> p $r1
[0.5]

pdl> p $r2
[-0.5 -0.5 0 -0.5 -0.5 -0.5 0 0]

what I doing wrong here?

Regards






















El mar., 21 de enero de 2025 19:42, Ed . <ej...@ho...<mailto:ej...@ho...>> escribió:
Hi Guillermo,

That does feel to me like you'd want to not do something on the whole ndarray, but instead do something on a $pdl->where(condition...). What do you think?

Best regards,
Ed

________________________________
From: Guillermo P. Ortiz <go...@ex...<mailto:go...@ex...>>
Sent: 21 January 2025 19:07
To: Ed . <ej...@ho...<mailto:ej...@ho...>>
Cc: pdl...@li...<mailto:pdl...@li...> <pdl...@li...<mailto:pdl...@li...>>; perldl <pdl...@li...<mailto:pdl...@li...>>
Subject: Re: [Pdl-devel] conditional inline

For instance, I am trying with $r, like below

$r=(zeroes(2*$N+1,2*$N+1)->ndcoords-pdl($N,$N))/(2*$N+1)

Regards

El mar, 21 ene 2025 a las 14:39, Guillermo P. Ortiz (<go...@ex...<mailto:go...@ex...>>) escribió:
Yes Ed, you are right.
I want to perform different operations on $r
depending on its distance to a point $r0 in 2D.
Then, I guess that first, and because for further
manipulation, I decide to center $r-=$r0 in
such a point.

Then in false code,

if ( length ($r)  < $a)
 { return f($r)}
 else
{ return g($r) }

where "length" I am not sure, but it could be inner($r,$r)->sqrt.
Maybe no ternary expression but some subroutine will be fine also.

Regards












El mar, 21 ene 2025 a las 14:16, Ed . (<ej...@ho...<mailto:ej...@ho...>>) escribió:
Hi Guillermo,

That conditional will, for the case you've given, always be false, because it has values more than 0.2 away from 0.5. When you use all, you are asking a question about the entire ndarray, in other words for every single value in it.

I believe that there's some real problem you're trying to solve, but I'm afraid I still have absolutely no idea what it is. Please help me help you!

Best regards,
Ed

________________________________
From: Guillermo P. Ortiz <go...@ex...<mailto:go...@ex...>>
Sent: 21 January 2025 01:19
To: Ed . <ej...@ho...<mailto:ej...@ho...>>
Cc: pdl...@li...<mailto:pdl...@li...> <pdl...@li...<mailto:pdl...@li...>>; perldl <pdl...@li...<mailto:pdl...@li...>>
Subject: Re: [Pdl-devel] conditional inline

Ok, Ed,
That example did not work for me.
The conditional results seems to be allways false. I mean, that it give $x also when $x is near to 0.5 than 0.2, where I is expecting the $x**2 result.

Regates



El El lun, 20 ene 2025 a la(s) 20:39, Ed . <ej...@ho...<mailto:ej...@ho...>> escribió:
Hi Guillermo,

You may still be having a problem, but you have yet to tell us what it is. The code you sent works fine, including as many dimensions as you like (because all acts on the whole ndarray at once).

If there's a problem in there, please share it :-)

Best regards,
Ed

________________________________
From: Guillermo P. Ortiz <go...@ex...<mailto:go...@ex...>>
Sent: 20 January 2025 23:35
To: Ed . <ej...@ho...<mailto:ej...@ho...>>
Cc: pdl...@li...<mailto:pdl...@li...> <pdl...@li...<mailto:pdl...@li...>>; perldl <pdl...@li...<mailto:pdl...@li...>>
Subject: Re: [Pdl-devel] conditional inline

Thanks Ed,
Using ternary conditional expression
I still have some problem with múltiple disensión case.
See my example in message befare


El El lun, 20 ene 2025 a la(s) 19:31, Ed . <ej...@ho...<mailto:ej...@ho...>> escribió:
Hi Guillermo,

You can do that indeed, that's just Perl. If you wanted to do operations on a subset of that ndarray, then you'd do e.g.

$pdl->where(($pdl-0.5)->abs < 0.2) *= 5;

An observation is that the above condition could be a bit shorter by using the recently-added approx_artol: (which would also mean it ran quicker)

$pdl->approx_artol(0.5, 0.2)

Best regards,
Ed

________________________________
From: Guillermo P. Ortiz <go...@ex...<mailto:go...@ex...>>
Sent: 20 January 2025 19:39
To: pdl...@li...<mailto:pdl...@li...> <pdl...@li...<mailto:pdl...@li...>>; perldl <pdl...@li...<mailto:pdl...@li...>>
Subject: [Pdl-devel] conditional inline

Hello !

I am not sure, but maybe It is possible to do with perl PDL something
like this?

$ndarray= condition on $ndarray ? assign when true : assign when false

for example:

$x=zeroes(20)->xlinvals(0,1);

$y=(all abs($x-0.5)<0.2)?$x**2:$x;

Thanks in advance

Regards

--


Dr. Guillermo P. Ortiz
Electromagnetismo Aplicado
Dto. Física, Facultad de Ciencias Exactas
Universidad Nacional del Nordeste
Avda Libertad 5460<https://www.google.com/maps/search/Avda+Libertad+5460?entry=gmail&source=g>, Campus UNNE.
W3404AAS Corrientes, Argentina.
(+54) 379-4424678 interno 4613
gortiz at unne edu ar
_______________________________________________
pdl-devel mailing list
pdl...@li...<mailto:pdl...@li...>
https://lists.sourceforge.net/lists/listinfo/pdl-devel