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


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

Reply via email to