pdl-general — PDL Users Question and Discussion

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

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

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

Hi Guillermo,

I've only just created whichND_both, so it's only on git master so far. If you're brave enough to install from that, then you can get ahead of everyone else and give it a go!

Thank you for explaining the rest of the problem. Another thing I should have mentioned, but forgot: there's a magnover (as of 2.090) which takes the magnitude of vectors, so you'd be able to say:

      pdl> $rr=$r->magnover
      pdl> ($r1,$r2)=whereND($r->using(0,1),$rr < 0.3)
      pdl> ($r3,$r4)=whereND($r->using(0,1),$rr >= 0.3)

Best regards,
Ed

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

OK Ed,
in my version PDL2.098 still there does not exist whichND_both.
But, let me resume here the problem that I finally solve for a toy example:

pdl> $r=(zeroes(3,3)->ndcoords/2-pdl(0.5,0.5))->r2C
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> $rr=($r**2)->sumover->sqrt
pdl> ($r1,$r2)=whereND($r->using(0,1),$rr->abs < 0.3)
pdl> ($r3,$r4)=whereND($r->using(0,1),$rr->abs >= 0.3)

Here we have $r1 and $r2 the x and y coordinates for vectors
that are shorter than 0.3. In $r3 and $r4 the respective coordinates for
vectors that are larger than 0,3

pdl> $r1.=$r1+(1+i)
pdl> $r3.=$r3*(1+i)+$r4
pdl> p $r1
[
 [1+i]
]
pdl> p $r3
[
 [  -1-0.5i      -0.5      0.5i -0.5-0.5i  0.5+0.5i     -0.5i       0.5    1+0.5i]
]

We are only interested in the x coordinates of $r but of course the modification
depends on y coordinates also. Then, in this example in one case of condition
imposed for the mask we add 1+i and in the complement we multiply for 1+i and
add the y coordinates

pdl> p $r
[
 [
  [-1-0.5i    -0.5]
  [   -0.5    -0.5]
  [   0.5i    -0.5]
 ]
 [
  [-0.5-0.5i         0]
  [      1+i         0]
  [ 0.5+0.5i         0]
 ]
 [
  [ -0.5i    0.5]
  [   0.5    0.5]
  [1+0.5i    0.5]
 ]
]

Obtaining the desired results in $r thanks to dataflow.

Thanks, I hope to be clear now and thanks again for your
patience

Regards





El mié, 22 ene 2025 a las 18:09, Ed . (<ej...@ho...<mailto:ej...@ho...>>) escribió:
Hi Guillermo,

I thought you did, but it seemed worth spelling out in case people read the mailing-list archive later on :-)

I'm not sure the solution you sent earlier is actually ugly! "If it's stupid but it works, it's not stupid." But I am interested to know if whichND_both is helpful.

Best regards,
Ed

________________________________
From: Guillermo P. Ortiz <go...@ex...<mailto:go...@ex...>>
Sent: 22 January 2025 21:06
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

Hi Ed,
yes I realize that problem and use r2C on $r before to apply the mask, this work fine.
Also yes for your comment on where_both about. Then, I try with whereND and obtain
a ugly solution to my problem I guess

Regards



El mié, 22 ene 2025 a las 17:51, Ed . (<ej...@ho...<mailto:ej...@ho...>>) escribió:
There's some quite complicated stuff going on here!

This is a bit flawed conceptually:
      $r1.=$r1*(1+i);
If you say .=, you're telling PDL to take the right-hand side (which will have complex type), and assign it into the existing $r1, which is real-typed. The only thing it can do is convert the complex-typed data into real data. If you change .= to =, you're making the $r1 Perl variable have the complex-typed ndarray, which is probably what you'd want here.

This is also:
      ($r1,$r2)=where_both($r,($r**2)->sumover->sqrt < 0.2)
Because where_both does not work n-dimensionally; it takes ($data, $mask), calls which_both on the mask (which for a multi-dimensional input will broadcast), then indexes (using index1d) a flattened version of $data with that.

Do those points make sense?

Best regards,
Ed

________________________________
From: Guillermo P. Ortiz <go...@ex...<mailto:go...@ex...>>
Sent: 21 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

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

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

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

Hi Guillermo,

I thought you did, but it seemed worth spelling out in case people read the mailing-list archive later on :-)

I'm not sure the solution you sent earlier is actually ugly! "If it's stupid but it works, it's not stupid." But I am interested to know if whichND_both is helpful.

Best regards,
Ed

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

Hi Ed,
yes I realize that problem and use r2C on $r before to apply the mask, this work fine.
Also yes for your comment on where_both about. Then, I try with whereND and obtain
a ugly solution to my problem I guess

Regards



El mié, 22 ene 2025 a las 17:51, Ed . (<ej...@ho...<mailto:ej...@ho...>>) escribió:
There's some quite complicated stuff going on here!

This is a bit flawed conceptually:
      $r1.=$r1*(1+i);
If you say .=, you're telling PDL to take the right-hand side (which will have complex type), and assign it into the existing $r1, which is real-typed. The only thing it can do is convert the complex-typed data into real data. If you change .= to =, you're making the $r1 Perl variable have the complex-typed ndarray, which is probably what you'd want here.

This is also:
      ($r1,$r2)=where_both($r,($r**2)->sumover->sqrt < 0.2)
Because where_both does not work n-dimensionally; it takes ($data, $mask), calls which_both on the mask (which for a multi-dimensional input will broadcast), then indexes (using index1d) a flattened version of $data with that.

Do those points make sense?

Best regards,
Ed

________________________________
From: Guillermo P. Ortiz <go...@ex...<mailto:go...@ex...>>
Sent: 21 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

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

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

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

There's some quite complicated stuff going on here!

This is a bit flawed conceptually:
      $r1.=$r1*(1+i);
If you say .=, you're telling PDL to take the right-hand side (which will have complex type), and assign it into the existing $r1, which is real-typed. The only thing it can do is convert the complex-typed data into real data. If you change .= to =, you're making the $r1 Perl variable have the complex-typed ndarray, which is probably what you'd want here.

This is also:
      ($r1,$r2)=where_both($r,($r**2)->sumover->sqrt < 0.2)
Because where_both does not work n-dimensionally; it takes ($data, $mask), calls which_both on the mask (which for a multi-dimensional input will broadcast), then indexes (using index1d) a flattened version of $data with that.

Do those points make sense?

Best regards,
Ed

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

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

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

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

Hi Guillermo,

Two observations:

This idiom:
      ($r->slice("(0)"),$r->slice("(1)")
is more concisely expressed (though it's actually implemented with that) as:
      ($r->using(0,1))

Also, I've just added whichND_both (with a digression because I discovered whichND had a subtle bug in its use of dummy: if you're using it to "inflate" something you intend to mutate, you need to sever that, make_physical is not a valid alternative because of dataflow). That would then allow this (possibly the first line would need adjusting for dimensions on the mask, given you're doing a sumover):

      ($ind_true, $ind_false) = whichND_both(($r**2)->sumover->sqrt->abs<0.2);
      $r->indexND($ind_true) .= f(...);
      $r->indexND($ind_false) .= f(...);

Finally, I'm just adding whereND_both, for completeness.

Best regards,
Ed

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

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

Re: [Pdl-general] [Pdl-devel] pdl scripts

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

On Wed, Jan 22, 2025 at 04:18:41PM +0000, Ed . wrote:
> Hi Luis,
>
> I agree that in a sense, the system was buggy (albeit only misleading rather than actually operating wrongly), which is why I fixed it and that will be reflected in the next version.

Great!

> In the meantime, there is the workaround (or actual solution, depending on your point of view) of adding to the cpanm invocation.

Good to know (I wasn't aware that cpanm can install suggested packages
automatically).

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

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

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...>
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...>) 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...>) 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...> 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...>
>>>> *Sent:* 21 January 2025 19:07
>>>> *To:* Ed . <ej...@ho...>
>>>> *Cc:* pdl...@li... <pdl...@li...>;
>>>> perldl <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...>) 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...>) 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...>
>>>> *Sent:* 21 January 2025 01:19
>>>> *To:* Ed . <ej...@ho...>
>>>> *Cc:* pdl...@li... <pdl...@li...>;
>>>> perldl <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...>
>>>> 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...>
>>>> *Sent:* 20 January 2025 23:35
>>>> *To:* Ed . <ej...@ho...>
>>>> *Cc:* pdl...@li... <pdl...@li...>;
>>>> perldl <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...>
>>>> 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...>
>>>> *Sent:* 20 January 2025 19:39
>>>> *To:* pdl...@li... <pdl...@li...>;
>>>> perldl <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...
> https://lists.sourceforge.net/lists/listinfo/pdl-devel
>

Re: [Pdl-general] [Pdl-devel] pdl scripts

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

It's annoyed me for a while that do_print was only in pdl2, not in perldl. I've just added it to perldl, with the bonus feature that if you have ; as the last character in your expression, it still won't print (like MATLAB, sort of).

Please give it a go (on master) and report any problems!

Best regards,
Ed

________________________________
From: Jörg Sommrey <jo...@so...>
Sent: 22 January 2025 15:33
To: Ed . <ej...@ho...>
Cc: Luis Mochan <mo...@ic...>; perldl <pdl...@li...>; perldl <pdl...@li...>
Subject: Re: [Pdl-devel] pdl scripts


On Wed 22 Jan 2025 03:55:20 PM CET, "Ed ." <ej...@ho...> wrote:

> Hi Jörg,
>
> Can you please spell out what happens when you run "pdl" (which is
> the compiled C executable that runs perldl)? It's supposed to work.

Yes it actually does work - my fault. It was 'do_print 1;' in .perldlrc
that caused 'pdl' to fail. I should have read the error message explaining
the error.  The 'perl>' prompt just rang a bell.

It's a bit strange: I have been using 'do_print' for a long time now and
I was not aware it was available in 'pdl2' only.

-jo

>
> pdl2 won't work "out of the box", since it got removed due to its
> very heavy dependencies. To run that now, you'll need to do cpanm
> PDL::Perldl2 (and then wait for Moose et al to get installed).
>
> Best regards,
> Ed
>
> ________________________________
> From: Jörg Sommrey <jo...@so...>
> Sent: 22 January 2025 14:30
> To: Luis Mochan <mo...@ic...>
> Cc: Ed . <ej...@ho...>; perldl
> <pdl...@li...>; perldl
> <pdl...@li...>
> Subject: Re: [Pdl-devel] pdl scripts
>
> Hi Luis,
>
> you might try 'pdl2' instead of 'pdl'. The latter doesn't work for me
> neither after upgrading PDL lately.
> Just a guess.
>
> -jo
>
> On Wed 22 Jan 2025 04:46:09 AM CET, Luis Mochan <mo...@ic...> wrote:
>
>> Hi Ed,
>>
>> Maybe I didn't explain the issue, maybe I don't quite understand
>> it. And maybe I didn't quite understand your answer:
>>
>> 1. I made a new account in my laptop
>> 2. I installed perlbrew
>> 3. I installed perl-5.40.1
>> 4. In installed cpanm
>> 5. I installed PDL with cpanm
>> 6. I ran pdl
>> 7. I obtained the answer:
>>
>>      perlDL shell v1.357
>>       PDL comes with ABSOLUTELY NO WARRANTY. For details, see the file
>>       'COPYING' in the PDL distribution. This is free software and you
>>       are welcome to redistribute it under certain conditions, see
>>       the same file for details.
>>      ReadLines, NiceSlice, MultiLines  enabled
>>      Reading PDL/default.perldlrc...
>> *    WARNING: Error loading PDL: 'Can't locate Term/ReadKey.pm in
>> @INC (you may need to install the Term::ReadKey module) (@INC
>> entries checked:
>> /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/site_perl/5.40.1/x86_64-linux /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/site_perl/5.40.1 /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/5.40.1/x86_64-linux /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/5.40.1) at /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/site_perl/5.40.1/x86_64-linux/PDL/Doc/Perldl.pm
>> line
>> 52.
>>      BEGIN failed--compilation aborted at
>> /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/site_perl/5.40.1/x86_64-linux/PDL/Doc/Perldl.pm
>> line
>> 52.
>>      Compilation failed in require at
>> /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/site_perl/5.40.1/x86_64-linux/PDL/default.perldlrc
>> line
>> 37.
>>      BEGIN failed--compilation aborted at
>> /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/site_perl/5.40.1/x86_64-linux/PDL/default.perldlrc
>> line
>> 37.
>>      Compilation failed in require at (eval 13) line 1.
>>      ' - trying blib.
>>      WARNING: PDL startup not found only plain perl available
>>
>>      Note: AutoLoader not enabled ('use PDL::AutoLoader' recommended)
>> **   perl>
>>
>> The line marked with an * above says: 'WARNING: Error loading PDL:
>> 'Can't locate Term/ReadKey.pm in @INC (you may need to install the
>> Term::ReadKey module)...'
>>
>> So it is not that I (or my students) care about Term::ReadKey, it is
>> that the advice we got is that we'd better install it.
>>
>> Also, the line marked with ** shows we obtained the prompt 'perl>'
>> instead of the expected prompt 'pdl>'.
>>
>> In my previous installations, I hadn't had this problem, as I
>> installed manually many required and optional pre-requisites,
>> including Term::ReadLine::Gnu, which I guess is the readline you
>> mention in your answer. However, installing Term::Readline::Gnu didn't
>> help with the problem above. I obtained again:
>>
>>     $ pdl
>>     perlDL shell v1.357
>>      PDL comes with ABSOLUTELY NO WARRANTY. For details, see the file
>>      'COPYING' in the PDL distribution. This is free software and you
>>      are welcome to redistribute it under certain conditions, see
>>      the same file for details.
>>     ReadLines, NiceSlice, MultiLines  enabled
>>     Reading PDL/default.perldlrc...
>>     WARNING: Error loading PDL: 'Can't locate Term/ReadKey.pm in
>> @INC (you may need to install the Term::ReadKey module) (@INC
>> entries checked:
>> /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/site_perl/5.40.1/x86_64-linux /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/site_perl/5.40.1 /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/5.40.1/x86_64-linux /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/5.40.1) at /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/site_perl/5.40.1/x86_64-linux/PDL/Doc/Perldl.pm
>> line
>> 52.
>>     BEGIN failed--compilation aborted at
>> /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/site_perl/5.40.1/x86_64-linux/PDL/Doc/Perldl.pm
>> line
>> 52.
>>     Compilation failed in require at
>> /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/site_perl/5.40.1/x86_64-linux/PDL/default.perldlrc
>> line
>> 37.
>>     BEGIN failed--compilation aborted at
>> /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/site_perl/5.40.1/x86_64-linux/PDL/default.perldlrc
>> line
>> 37.
>>     Compilation failed in require at (eval 11) line 1.
>>     ' - trying blib.
>>     WARNING: PDL startup not found only plain perl available
>>
>>     Note: AutoLoader not enabled ('use PDL::AutoLoader' recommended)
>>
>>     perl>
>>
>> But after installing ReadKey things started behaving as usual:
>>
>>     $ cpanm Term::ReadKey
>>     --> Working on Term::ReadKey
>>     Fetching
>> http://www.cpan.org/authors/id/J/JS/JSTOWE/TermReadKey-2.38.tar.gz
>> ... OK
>>     Configuring TermReadKey-2.38 ... OK
>>     Building and testing TermReadKey-2.38 ... OK
>>     Successfully installed TermReadKey-2.38
>>     1 distribution installed
>>     $ pdl
>>     perlDL shell v1.357
>>      PDL comes with ABSOLUTELY NO WARRANTY. For details, see the file
>>      'COPYING' in the PDL distribution. This is free software and you
>>      are welcome to redistribute it under certain conditions, see
>>      the same file for details.
>>     ReadLines, NiceSlice, MultiLines  enabled
>>     Reading PDL/default.perldlrc...
>>     Found docs database
>> /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/site_perl/5.40.1/x86_64-linux/PDL/pdldoc.db
>>     Type 'help' for online help
>>     Type 'demo' for online demos
>>     Loaded PDL v2.098 (supports bad values)
>>
>>     Note: AutoLoader not enabled ('use PDL::AutoLoader' recommended)
>>
>>     pdl>
>>
>> So, what is the user expected to do? The installation of PDL was declared
>> succesful, a program ('pdl') distributed with PDL was installed, the
>> program didn't run smoothly and sent error messages asking the user to
>> install another package: Term::ReadKey. How would you interpret this
>> situation as a new user? Wouldn't you be confused? Wouldn't you
>> conclude there is something wrong?
>>
>> I don't know what is the correct solution. I suggested adding
>> Term::ReadKey to the required packages, so it would be installed
>> automatically. Maybe that is not the correct solution, but then, I
>> don't know, what would be the correct solution?
>>
>> Best regards,
>> Luis
>>
>>
>>
>>
>> On Tue, Jan 21, 2025 at 10:40:32PM +0000, Ed . wrote:
>>> Hi Luis,
>>>
>>> PDL isn't just an interactive environment. "Required" would be
>>> wrong. I use the interactive part very heavily (which isn't very
>>> surprising), and wouldn't want to use it without readline (which I
>>> have faced when debugging in a qemu environment on a weird
>>> architecture). I am not going to make any of the Term::* be
>>> "required" for PDL. I hope you understand.
>>>
>>> If it helps, the REPL script was installed, but not all of the
>>> components. It does sound like you're asking me to make a separate
>>> PDL::REPL repo where that stuff would live, but I don't want to do
>>> that.
>>>
>>> Best regards,
>>> Ed
>>>
>>> ________________________________
>>> From: Luis Mochan <mo...@ic...>
>>> Sent: 21 January 2025 20:07
>>> To: Ed . <ej...@ho...>
>>> Cc: perldl <pdl...@li...>; perldl
>>> <pdl...@li...>
>>> Subject: Re: [Pdl-devel] pdl scripts
>>>
>>> Hi Ed,
>>>
>>> On Tue, Jan 21, 2025 at 05:13:09PM +0000, Ed . wrote:
>>> > Hi Luis,
>>> >
>>> > That's a really good question!
>>> >
>>> > PDL's "requirements" (when you say e.g. cpanm PDL) are hard
>>> requirements for PDL to run: largely File::Map and File::Which.
>>> CPAN has a mechanism to "recommend" other modules, including
>>> Term::ReadKey. It has done so for a long time. cpanm can be told to
>>> install recommended modules.
>>>
>>> The doubt I have now is, should Term::ReadKey be recommended or should
>>> it be required? The problem is that the repl's were installed, but
>>> they didn't work without it.
>>>
>>> > The demos will be sparse...
>>>
>>> Ok, thanks. I'll pass that info to the students.
>>>
>>> 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] pdl scripts

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

Hi Luis,

I agree that in a sense, the system was buggy (albeit only misleading rather than actually operating wrongly), which is why I fixed it and that will be reflected in the next version. In the meantime, there is the workaround (or actual solution, depending on your point of view) of adding to the cpanm invocation.

Best regards,
Ed

________________________________
From: Luis Mochan <mo...@ic...>
Sent: 22 January 2025 15:38
To: Ed . <ej...@ho...>
Cc: perldl <pdl...@li...>; perldl <pdl...@li...>
Subject: Re: [Pdl-devel] pdl scripts

Hi Ed,

On Wed, Jan 22, 2025 at 02:50:41PM +0000, Ed . wrote:
> Hi Luis,
>
> The suggestion I made in my first reply: "cpanm can be told to install recommended modules" is the one I am still making.

I understand. My worry is about the new users. They may just turn away
if they believe the system is buggy :( (My students didn't; I
convinced them to stay, or else... :)
>
> Please install PDL with `cpanm --with-suggests` (the "suggests" will also bring in Sys::SigAction which means you can use ctrl-C to abort a partly typed-in command, which I find very handy).

Ok.


> Clearly, perldl should give a better error message than the one it does now, which is very misleading - it says it couldn't load "PDL", but that's not correct. I've just pushed a commit to master that makes it tolerate T:RK not being there - it was being used only for apropos and a couple of other places to get the screen width.

Ok, I'll try again later.

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] pdl scripts

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

Hi Jo,

I recall it didn't work either, nor perldl (but I don't trust my
memory). I would have to start again to test them. As I wrote before,
my worry is the impression it might cause to new users to have a
program installed and then find out it sends error messages
(erroneous, as Ed explained above) when first tried.

Regards,
Luis

On Wed, Jan 22, 2025 at 02:30:01PM +0000, Jörg Sommrey wrote:
> Hi Luis,
>
> you might try 'pdl2' instead of 'pdl'. The latter doesn't work for me
> neither after upgrading PDL lately.
> Just a guess.
>
> -jo
>
> On Wed 22 Jan 2025 04:46:09 AM CET, Luis Mochan <mo...@ic...> wrote:
>
> > Hi Ed,
> >
> > Maybe I didn't explain the issue, maybe I don't quite understand
> > it. And maybe I didn't quite understand your answer:
> >
> > 1. I made a new account in my laptop
> > 2. I installed perlbrew
> > 3. I installed perl-5.40.1
> > 4. In installed cpanm
> > 5. I installed PDL with cpanm
> > 6. I ran pdl
> > 7. I obtained the answer:
> >
> >      perlDL shell v1.357
> >       PDL comes with ABSOLUTELY NO WARRANTY. For details, see the file
> >       'COPYING' in the PDL distribution. This is free software and you
> >       are welcome to redistribute it under certain conditions, see
> >       the same file for details.
> >      ReadLines, NiceSlice, MultiLines  enabled
> >      Reading PDL/default.perldlrc...
> > *    WARNING: Error loading PDL: 'Can't locate Term/ReadKey.pm in @INC
> > (you may need to install the Term::ReadKey module) (@INC entries
> > checked: /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/site_perl/5.40.1/x86_64-linux
> > /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/site_perl/5.40.1
> > /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/5.40.1/x86_64-linux
> > /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/5.40.1) at /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/site_perl/5.40.1/x86_64-linux/PDL/Doc/Perldl.pm
> > line 52.
> >      BEGIN failed--compilation aborted at /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/site_perl/5.40.1/x86_64-linux/PDL/Doc/Perldl.pm
> > line 52.
> >      Compilation failed in require at /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/site_perl/5.40.1/x86_64-linux/PDL/default.perldlrc
> > line 37.
> >      BEGIN failed--compilation aborted at /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/site_perl/5.40.1/x86_64-linux/PDL/default.perldlrc
> > line 37.
> >      Compilation failed in require at (eval 13) line 1.
> >      ' - trying blib.
> >      WARNING: PDL startup not found only plain perl available
> >
> >      Note: AutoLoader not enabled ('use PDL::AutoLoader' recommended)
> > **   perl>
> >
> > The line marked with an * above says: 'WARNING: Error loading PDL:
> > 'Can't locate Term/ReadKey.pm in @INC (you may need to install the
> > Term::ReadKey module)...'
> >
> > So it is not that I (or my students) care about Term::ReadKey, it is
> > that the advice we got is that we'd better install it.
> >
> > Also, the line marked with ** shows we obtained the prompt 'perl>'
> > instead of the expected prompt 'pdl>'.
> >
> > In my previous installations, I hadn't had this problem, as I
> > installed manually many required and optional pre-requisites,
> > including Term::ReadLine::Gnu, which I guess is the readline you
> > mention in your answer. However, installing Term::Readline::Gnu didn't
> > help with the problem above. I obtained again:
> >
> >     $ pdl
> >     perlDL shell v1.357
> >      PDL comes with ABSOLUTELY NO WARRANTY. For details, see the file
> >      'COPYING' in the PDL distribution. This is free software and you
> >      are welcome to redistribute it under certain conditions, see
> >      the same file for details.
> >     ReadLines, NiceSlice, MultiLines  enabled
> >     Reading PDL/default.perldlrc...
> >     WARNING: Error loading PDL: 'Can't locate Term/ReadKey.pm in @INC
> > (you may need to install the Term::ReadKey module) (@INC entries
> > checked: /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/site_perl/5.40.1/x86_64-linux
> > /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/site_perl/5.40.1
> > /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/5.40.1/x86_64-linux
> > /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/5.40.1) at /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/site_perl/5.40.1/x86_64-linux/PDL/Doc/Perldl.pm
> > line 52.
> >     BEGIN failed--compilation aborted at /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/site_perl/5.40.1/x86_64-linux/PDL/Doc/Perldl.pm
> > line 52.
> >     Compilation failed in require at /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/site_perl/5.40.1/x86_64-linux/PDL/default.perldlrc
> > line 37.
> >     BEGIN failed--compilation aborted at /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/site_perl/5.40.1/x86_64-linux/PDL/default.perldlrc
> > line 37.
> >     Compilation failed in require at (eval 11) line 1.
> >     ' - trying blib.
> >     WARNING: PDL startup not found only plain perl available
> >
> >     Note: AutoLoader not enabled ('use PDL::AutoLoader' recommended)
> >
> >     perl>
> >
> > But after installing ReadKey things started behaving as usual:
> >
> >     $ cpanm Term::ReadKey
> >     --> Working on Term::ReadKey
> >     Fetching
> > http://www.cpan.org/authors/id/J/JS/JSTOWE/TermReadKey-2.38.tar.gz ...
> > OK
> >     Configuring TermReadKey-2.38 ... OK
> >     Building and testing TermReadKey-2.38 ... OK
> >     Successfully installed TermReadKey-2.38
> >     1 distribution installed
> >     $ pdl
> >     perlDL shell v1.357
> >      PDL comes with ABSOLUTELY NO WARRANTY. For details, see the file
> >      'COPYING' in the PDL distribution. This is free software and you
> >      are welcome to redistribute it under certain conditions, see
> >      the same file for details.
> >     ReadLines, NiceSlice, MultiLines  enabled
> >     Reading PDL/default.perldlrc...
> >     Found docs database /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/site_perl/5.40.1/x86_64-linux/PDL/pdldoc.db
> >     Type 'help' for online help
> >     Type 'demo' for online demos
> >     Loaded PDL v2.098 (supports bad values)
> >
> >     Note: AutoLoader not enabled ('use PDL::AutoLoader' recommended)
> >
> >     pdl>
> >
> > So, what is the user expected to do? The installation of PDL was declared
> > succesful, a program ('pdl') distributed with PDL was installed, the
> > program didn't run smoothly and sent error messages asking the user to
> > install another package: Term::ReadKey. How would you interpret this
> > situation as a new user? Wouldn't you be confused? Wouldn't you
> > conclude there is something wrong?
> >
> > I don't know what is the correct solution. I suggested adding
> > Term::ReadKey to the required packages, so it would be installed
> > automatically. Maybe that is not the correct solution, but then, I
> > don't know, what would be the correct solution?
> >
> > Best regards,
> > Luis
> >
> >
> >
> >
> > On Tue, Jan 21, 2025 at 10:40:32PM +0000, Ed . wrote:
> > > Hi Luis,
> > >
> > > PDL isn't just an interactive environment. "Required" would be
> > > wrong. I use the interactive part very heavily (which isn't very
> > > surprising), and wouldn't want to use it without readline (which I
> > > have faced when debugging in a qemu environment on a weird
> > > architecture). I am not going to make any of the Term::* be
> > > "required" for PDL. I hope you understand.
> > >
> > > If it helps, the REPL script was installed, but not all of the
> > > components. It does sound like you're asking me to make a separate
> > > PDL::REPL repo where that stuff would live, but I don't want to do
> > > that.
> > >
> > > Best regards,
> > > Ed
> > >
> > > ________________________________
> > > From: Luis Mochan <mo...@ic...>
> > > Sent: 21 January 2025 20:07
> > > To: Ed . <ej...@ho...>
> > > Cc: perldl <pdl...@li...>; perldl
> > > <pdl...@li...>
> > > Subject: Re: [Pdl-devel] pdl scripts
> > >
> > > Hi Ed,
> > >
> > > On Tue, Jan 21, 2025 at 05:13:09PM +0000, Ed . wrote:
> > > > Hi Luis,
> > > >
> > > > That's a really good question!
> > > >
> > > > PDL's "requirements" (when you say e.g. cpanm PDL) are hard
> > > requirements for PDL to run: largely File::Map and File::Which. CPAN
> > > has a mechanism to "recommend" other modules, including
> > > Term::ReadKey. It has done so for a long time. cpanm can be told to
> > > install recommended modules.
> > >
> > > The doubt I have now is, should Term::ReadKey be recommended or should
> > > it be required? The problem is that the repl's were installed, but
> > > they didn't work without it.
> > >
> > > > The demos will be sparse...
> > >
> > > Ok, thanks. I'll pass that info to the students.
> > >
> > > 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
>
>
>

-- 

                                                                  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] pdl scripts

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

Hi Ed,

On Wed, Jan 22, 2025 at 02:50:41PM +0000, Ed . wrote:
> Hi Luis,
>
> The suggestion I made in my first reply: "cpanm can be told to install recommended modules" is the one I am still making.

I understand. My worry is about the new users. They may just turn away
if they believe the system is buggy :( (My students didn't; I
convinced them to stay, or else... :)
>
> Please install PDL with `cpanm --with-suggests` (the "suggests" will also bring in Sys::SigAction which means you can use ctrl-C to abort a partly typed-in command, which I find very handy).

Ok.


> Clearly, perldl should give a better error message than the one it does now, which is very misleading - it says it couldn't load "PDL", but that's not correct. I've just pushed a commit to master that makes it tolerate T:RK not being there - it was being used only for apropos and a couple of other places to get the screen width.

Ok, I'll try again later.

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] pdl scripts

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

On Wed 22 Jan 2025 03:55:20 PM CET, "Ed ." <ej...@ho...> wrote:

> Hi Jörg,
>
> Can you please spell out what happens when you run "pdl" (which is  
> the compiled C executable that runs perldl)? It's supposed to work.

Yes it actually does work - my fault. It was 'do_print 1;' in .perldlrc
that caused 'pdl' to fail. I should have read the error message explaining
the error.  The 'perl>' prompt just rang a bell.

It's a bit strange: I have been using 'do_print' for a long time now and
I was not aware it was available in 'pdl2' only.

-jo

>
> pdl2 won't work "out of the box", since it got removed due to its  
> very heavy dependencies. To run that now, you'll need to do cpanm  
> PDL::Perldl2 (and then wait for Moose et al to get installed).
>
> Best regards,
> Ed
>
> ________________________________
> From: Jörg Sommrey <jo...@so...>
> Sent: 22 January 2025 14:30
> To: Luis Mochan <mo...@ic...>
> Cc: Ed . <ej...@ho...>; perldl  
> <pdl...@li...>; perldl  
> <pdl...@li...>
> Subject: Re: [Pdl-devel] pdl scripts
>
> Hi Luis,
>
> you might try 'pdl2' instead of 'pdl'. The latter doesn't work for me
> neither after upgrading PDL lately.
> Just a guess.
>
> -jo
>
> On Wed 22 Jan 2025 04:46:09 AM CET, Luis Mochan <mo...@ic...> wrote:
>
>> Hi Ed,
>>
>> Maybe I didn't explain the issue, maybe I don't quite understand
>> it. And maybe I didn't quite understand your answer:
>>
>> 1. I made a new account in my laptop
>> 2. I installed perlbrew
>> 3. I installed perl-5.40.1
>> 4. In installed cpanm
>> 5. I installed PDL with cpanm
>> 6. I ran pdl
>> 7. I obtained the answer:
>>
>>      perlDL shell v1.357
>>       PDL comes with ABSOLUTELY NO WARRANTY. For details, see the file
>>       'COPYING' in the PDL distribution. This is free software and you
>>       are welcome to redistribute it under certain conditions, see
>>       the same file for details.
>>      ReadLines, NiceSlice, MultiLines  enabled
>>      Reading PDL/default.perldlrc...
>> *    WARNING: Error loading PDL: 'Can't locate Term/ReadKey.pm in
>> @INC (you may need to install the Term::ReadKey module) (@INC
>> entries checked:
>> /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/site_perl/5.40.1/x86_64-linux /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/site_perl/5.40.1 /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/5.40.1/x86_64-linux /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/5.40.1) at /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/site_perl/5.40.1/x86_64-linux/PDL/Doc/Perldl.pm  
>> line
>> 52.
>>      BEGIN failed--compilation aborted at
>> /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/site_perl/5.40.1/x86_64-linux/PDL/Doc/Perldl.pm  
>> line
>> 52.
>>      Compilation failed in require at
>> /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/site_perl/5.40.1/x86_64-linux/PDL/default.perldlrc  
>> line
>> 37.
>>      BEGIN failed--compilation aborted at
>> /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/site_perl/5.40.1/x86_64-linux/PDL/default.perldlrc  
>> line
>> 37.
>>      Compilation failed in require at (eval 13) line 1.
>>      ' - trying blib.
>>      WARNING: PDL startup not found only plain perl available
>>
>>      Note: AutoLoader not enabled ('use PDL::AutoLoader' recommended)
>> **   perl>
>>
>> The line marked with an * above says: 'WARNING: Error loading PDL:
>> 'Can't locate Term/ReadKey.pm in @INC (you may need to install the
>> Term::ReadKey module)...'
>>
>> So it is not that I (or my students) care about Term::ReadKey, it is
>> that the advice we got is that we'd better install it.
>>
>> Also, the line marked with ** shows we obtained the prompt 'perl>'
>> instead of the expected prompt 'pdl>'.
>>
>> In my previous installations, I hadn't had this problem, as I
>> installed manually many required and optional pre-requisites,
>> including Term::ReadLine::Gnu, which I guess is the readline you
>> mention in your answer. However, installing Term::Readline::Gnu didn't
>> help with the problem above. I obtained again:
>>
>>     $ pdl
>>     perlDL shell v1.357
>>      PDL comes with ABSOLUTELY NO WARRANTY. For details, see the file
>>      'COPYING' in the PDL distribution. This is free software and you
>>      are welcome to redistribute it under certain conditions, see
>>      the same file for details.
>>     ReadLines, NiceSlice, MultiLines  enabled
>>     Reading PDL/default.perldlrc...
>>     WARNING: Error loading PDL: 'Can't locate Term/ReadKey.pm in
>> @INC (you may need to install the Term::ReadKey module) (@INC
>> entries checked:
>> /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/site_perl/5.40.1/x86_64-linux /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/site_perl/5.40.1 /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/5.40.1/x86_64-linux /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/5.40.1) at /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/site_perl/5.40.1/x86_64-linux/PDL/Doc/Perldl.pm  
>> line
>> 52.
>>     BEGIN failed--compilation aborted at
>> /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/site_perl/5.40.1/x86_64-linux/PDL/Doc/Perldl.pm  
>> line
>> 52.
>>     Compilation failed in require at
>> /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/site_perl/5.40.1/x86_64-linux/PDL/default.perldlrc  
>> line
>> 37.
>>     BEGIN failed--compilation aborted at
>> /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/site_perl/5.40.1/x86_64-linux/PDL/default.perldlrc  
>> line
>> 37.
>>     Compilation failed in require at (eval 11) line 1.
>>     ' - trying blib.
>>     WARNING: PDL startup not found only plain perl available
>>
>>     Note: AutoLoader not enabled ('use PDL::AutoLoader' recommended)
>>
>>     perl>
>>
>> But after installing ReadKey things started behaving as usual:
>>
>>     $ cpanm Term::ReadKey
>>     --> Working on Term::ReadKey
>>     Fetching
>> http://www.cpan.org/authors/id/J/JS/JSTOWE/TermReadKey-2.38.tar.gz
>> ... OK
>>     Configuring TermReadKey-2.38 ... OK
>>     Building and testing TermReadKey-2.38 ... OK
>>     Successfully installed TermReadKey-2.38
>>     1 distribution installed
>>     $ pdl
>>     perlDL shell v1.357
>>      PDL comes with ABSOLUTELY NO WARRANTY. For details, see the file
>>      'COPYING' in the PDL distribution. This is free software and you
>>      are welcome to redistribute it under certain conditions, see
>>      the same file for details.
>>     ReadLines, NiceSlice, MultiLines  enabled
>>     Reading PDL/default.perldlrc...
>>     Found docs database
>> /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/site_perl/5.40.1/x86_64-linux/PDL/pdldoc.db
>>     Type 'help' for online help
>>     Type 'demo' for online demos
>>     Loaded PDL v2.098 (supports bad values)
>>
>>     Note: AutoLoader not enabled ('use PDL::AutoLoader' recommended)
>>
>>     pdl>
>>
>> So, what is the user expected to do? The installation of PDL was declared
>> succesful, a program ('pdl') distributed with PDL was installed, the
>> program didn't run smoothly and sent error messages asking the user to
>> install another package: Term::ReadKey. How would you interpret this
>> situation as a new user? Wouldn't you be confused? Wouldn't you
>> conclude there is something wrong?
>>
>> I don't know what is the correct solution. I suggested adding
>> Term::ReadKey to the required packages, so it would be installed
>> automatically. Maybe that is not the correct solution, but then, I
>> don't know, what would be the correct solution?
>>
>> Best regards,
>> Luis
>>
>>
>>
>>
>> On Tue, Jan 21, 2025 at 10:40:32PM +0000, Ed . wrote:
>>> Hi Luis,
>>>
>>> PDL isn't just an interactive environment. "Required" would be
>>> wrong. I use the interactive part very heavily (which isn't very
>>> surprising), and wouldn't want to use it without readline (which I
>>> have faced when debugging in a qemu environment on a weird
>>> architecture). I am not going to make any of the Term::* be
>>> "required" for PDL. I hope you understand.
>>>
>>> If it helps, the REPL script was installed, but not all of the
>>> components. It does sound like you're asking me to make a separate
>>> PDL::REPL repo where that stuff would live, but I don't want to do
>>> that.
>>>
>>> Best regards,
>>> Ed
>>>
>>> ________________________________
>>> From: Luis Mochan <mo...@ic...>
>>> Sent: 21 January 2025 20:07
>>> To: Ed . <ej...@ho...>
>>> Cc: perldl <pdl...@li...>; perldl
>>> <pdl...@li...>
>>> Subject: Re: [Pdl-devel] pdl scripts
>>>
>>> Hi Ed,
>>>
>>> On Tue, Jan 21, 2025 at 05:13:09PM +0000, Ed . wrote:
>>> > Hi Luis,
>>> >
>>> > That's a really good question!
>>> >
>>> > PDL's "requirements" (when you say e.g. cpanm PDL) are hard
>>> requirements for PDL to run: largely File::Map and File::Which.
>>> CPAN has a mechanism to "recommend" other modules, including
>>> Term::ReadKey. It has done so for a long time. cpanm can be told to
>>> install recommended modules.
>>>
>>> The doubt I have now is, should Term::ReadKey be recommended or should
>>> it be required? The problem is that the repl's were installed, but
>>> they didn't work without it.
>>>
>>> > The demos will be sparse...
>>>
>>> Ok, thanks. I'll pass that info to the students.
>>>
>>> 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] pdl scripts

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

Hi Jörg,

Can you please spell out what happens when you run "pdl" (which is the compiled C executable that runs perldl)? It's supposed to work.

pdl2 won't work "out of the box", since it got removed due to its very heavy dependencies. To run that now, you'll need to do cpanm PDL::Perldl2 (and then wait for Moose et al to get installed).

Best regards,
Ed

________________________________
From: Jörg Sommrey <jo...@so...>
Sent: 22 January 2025 14:30
To: Luis Mochan <mo...@ic...>
Cc: Ed . <ej...@ho...>; perldl <pdl...@li...>; perldl <pdl...@li...>
Subject: Re: [Pdl-devel] pdl scripts

Hi Luis,

you might try 'pdl2' instead of 'pdl'. The latter doesn't work for me
neither after upgrading PDL lately.
Just a guess.

-jo

On Wed 22 Jan 2025 04:46:09 AM CET, Luis Mochan <mo...@ic...> wrote:

> Hi Ed,
>
> Maybe I didn't explain the issue, maybe I don't quite understand
> it. And maybe I didn't quite understand your answer:
>
> 1. I made a new account in my laptop
> 2. I installed perlbrew
> 3. I installed perl-5.40.1
> 4. In installed cpanm
> 5. I installed PDL with cpanm
> 6. I ran pdl
> 7. I obtained the answer:
>
>      perlDL shell v1.357
>       PDL comes with ABSOLUTELY NO WARRANTY. For details, see the file
>       'COPYING' in the PDL distribution. This is free software and you
>       are welcome to redistribute it under certain conditions, see
>       the same file for details.
>      ReadLines, NiceSlice, MultiLines  enabled
>      Reading PDL/default.perldlrc...
> *    WARNING: Error loading PDL: 'Can't locate Term/ReadKey.pm in
> @INC (you may need to install the Term::ReadKey module) (@INC
> entries checked:
> /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/site_perl/5.40.1/x86_64-linux /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/site_perl/5.40.1 /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/5.40.1/x86_64-linux /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/5.40.1) at /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/site_perl/5.40.1/x86_64-linux/PDL/Doc/Perldl.pm line
> 52.
>      BEGIN failed--compilation aborted at
> /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/site_perl/5.40.1/x86_64-linux/PDL/Doc/Perldl.pm line
> 52.
>      Compilation failed in require at
> /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/site_perl/5.40.1/x86_64-linux/PDL/default.perldlrc line
> 37.
>      BEGIN failed--compilation aborted at
> /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/site_perl/5.40.1/x86_64-linux/PDL/default.perldlrc line
> 37.
>      Compilation failed in require at (eval 13) line 1.
>      ' - trying blib.
>      WARNING: PDL startup not found only plain perl available
>
>      Note: AutoLoader not enabled ('use PDL::AutoLoader' recommended)
> **   perl>
>
> The line marked with an * above says: 'WARNING: Error loading PDL:
> 'Can't locate Term/ReadKey.pm in @INC (you may need to install the
> Term::ReadKey module)...'
>
> So it is not that I (or my students) care about Term::ReadKey, it is
> that the advice we got is that we'd better install it.
>
> Also, the line marked with ** shows we obtained the prompt 'perl>'
> instead of the expected prompt 'pdl>'.
>
> In my previous installations, I hadn't had this problem, as I
> installed manually many required and optional pre-requisites,
> including Term::ReadLine::Gnu, which I guess is the readline you
> mention in your answer. However, installing Term::Readline::Gnu didn't
> help with the problem above. I obtained again:
>
>     $ pdl
>     perlDL shell v1.357
>      PDL comes with ABSOLUTELY NO WARRANTY. For details, see the file
>      'COPYING' in the PDL distribution. This is free software and you
>      are welcome to redistribute it under certain conditions, see
>      the same file for details.
>     ReadLines, NiceSlice, MultiLines  enabled
>     Reading PDL/default.perldlrc...
>     WARNING: Error loading PDL: 'Can't locate Term/ReadKey.pm in
> @INC (you may need to install the Term::ReadKey module) (@INC
> entries checked:
> /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/site_perl/5.40.1/x86_64-linux /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/site_perl/5.40.1 /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/5.40.1/x86_64-linux /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/5.40.1) at /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/site_perl/5.40.1/x86_64-linux/PDL/Doc/Perldl.pm line
> 52.
>     BEGIN failed--compilation aborted at
> /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/site_perl/5.40.1/x86_64-linux/PDL/Doc/Perldl.pm line
> 52.
>     Compilation failed in require at
> /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/site_perl/5.40.1/x86_64-linux/PDL/default.perldlrc line
> 37.
>     BEGIN failed--compilation aborted at
> /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/site_perl/5.40.1/x86_64-linux/PDL/default.perldlrc line
> 37.
>     Compilation failed in require at (eval 11) line 1.
>     ' - trying blib.
>     WARNING: PDL startup not found only plain perl available
>
>     Note: AutoLoader not enabled ('use PDL::AutoLoader' recommended)
>
>     perl>
>
> But after installing ReadKey things started behaving as usual:
>
>     $ cpanm Term::ReadKey
>     --> Working on Term::ReadKey
>     Fetching
> http://www.cpan.org/authors/id/J/JS/JSTOWE/TermReadKey-2.38.tar.gz
> ... OK
>     Configuring TermReadKey-2.38 ... OK
>     Building and testing TermReadKey-2.38 ... OK
>     Successfully installed TermReadKey-2.38
>     1 distribution installed
>     $ pdl
>     perlDL shell v1.357
>      PDL comes with ABSOLUTELY NO WARRANTY. For details, see the file
>      'COPYING' in the PDL distribution. This is free software and you
>      are welcome to redistribute it under certain conditions, see
>      the same file for details.
>     ReadLines, NiceSlice, MultiLines  enabled
>     Reading PDL/default.perldlrc...
>     Found docs database
> /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/site_perl/5.40.1/x86_64-linux/PDL/pdldoc.db
>     Type 'help' for online help
>     Type 'demo' for online demos
>     Loaded PDL v2.098 (supports bad values)
>
>     Note: AutoLoader not enabled ('use PDL::AutoLoader' recommended)
>
>     pdl>
>
> So, what is the user expected to do? The installation of PDL was declared
> succesful, a program ('pdl') distributed with PDL was installed, the
> program didn't run smoothly and sent error messages asking the user to
> install another package: Term::ReadKey. How would you interpret this
> situation as a new user? Wouldn't you be confused? Wouldn't you
> conclude there is something wrong?
>
> I don't know what is the correct solution. I suggested adding
> Term::ReadKey to the required packages, so it would be installed
> automatically. Maybe that is not the correct solution, but then, I
> don't know, what would be the correct solution?
>
> Best regards,
> Luis
>
>
>
>
> On Tue, Jan 21, 2025 at 10:40:32PM +0000, Ed . wrote:
>> Hi Luis,
>>
>> PDL isn't just an interactive environment. "Required" would be
>> wrong. I use the interactive part very heavily (which isn't very
>> surprising), and wouldn't want to use it without readline (which I
>> have faced when debugging in a qemu environment on a weird
>> architecture). I am not going to make any of the Term::* be
>> "required" for PDL. I hope you understand.
>>
>> If it helps, the REPL script was installed, but not all of the
>> components. It does sound like you're asking me to make a separate
>> PDL::REPL repo where that stuff would live, but I don't want to do
>> that.
>>
>> Best regards,
>> Ed
>>
>> ________________________________
>> From: Luis Mochan <mo...@ic...>
>> Sent: 21 January 2025 20:07
>> To: Ed . <ej...@ho...>
>> Cc: perldl <pdl...@li...>; perldl
>> <pdl...@li...>
>> Subject: Re: [Pdl-devel] pdl scripts
>>
>> Hi Ed,
>>
>> On Tue, Jan 21, 2025 at 05:13:09PM +0000, Ed . wrote:
>> > Hi Luis,
>> >
>> > That's a really good question!
>> >
>> > PDL's "requirements" (when you say e.g. cpanm PDL) are hard
>> requirements for PDL to run: largely File::Map and File::Which.
>> CPAN has a mechanism to "recommend" other modules, including
>> Term::ReadKey. It has done so for a long time. cpanm can be told to
>> install recommended modules.
>>
>> The doubt I have now is, should Term::ReadKey be recommended or should
>> it be required? The problem is that the repl's were installed, but
>> they didn't work without it.
>>
>> > The demos will be sparse...
>>
>> Ok, thanks. I'll pass that info to the students.
>>
>> 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] pdl scripts

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

Hi Luis,

you might try 'pdl2' instead of 'pdl'. The latter doesn't work for me  
neither after upgrading PDL lately.
Just a guess.

-jo

On Wed 22 Jan 2025 04:46:09 AM CET, Luis Mochan <mo...@ic...> wrote:

> Hi Ed,
>
> Maybe I didn't explain the issue, maybe I don't quite understand
> it. And maybe I didn't quite understand your answer:
>
> 1. I made a new account in my laptop
> 2. I installed perlbrew
> 3. I installed perl-5.40.1
> 4. In installed cpanm
> 5. I installed PDL with cpanm
> 6. I ran pdl
> 7. I obtained the answer:
>
>      perlDL shell v1.357
>       PDL comes with ABSOLUTELY NO WARRANTY. For details, see the file
>       'COPYING' in the PDL distribution. This is free software and you
>       are welcome to redistribute it under certain conditions, see
>       the same file for details.
>      ReadLines, NiceSlice, MultiLines  enabled
>      Reading PDL/default.perldlrc...
> *    WARNING: Error loading PDL: 'Can't locate Term/ReadKey.pm in  
> @INC (you may need to install the Term::ReadKey module) (@INC  
> entries checked:  
> /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/site_perl/5.40.1/x86_64-linux /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/site_perl/5.40.1 /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/5.40.1/x86_64-linux /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/5.40.1) at /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/site_perl/5.40.1/x86_64-linux/PDL/Doc/Perldl.pm line  
> 52.
>      BEGIN failed--compilation aborted at  
> /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/site_perl/5.40.1/x86_64-linux/PDL/Doc/Perldl.pm line  
> 52.
>      Compilation failed in require at  
> /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/site_perl/5.40.1/x86_64-linux/PDL/default.perldlrc line  
> 37.
>      BEGIN failed--compilation aborted at  
> /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/site_perl/5.40.1/x86_64-linux/PDL/default.perldlrc line  
> 37.
>      Compilation failed in require at (eval 13) line 1.
>      ' - trying blib.
>      WARNING: PDL startup not found only plain perl available
>
>      Note: AutoLoader not enabled ('use PDL::AutoLoader' recommended)
> **   perl>
>
> The line marked with an * above says: 'WARNING: Error loading PDL:
> 'Can't locate Term/ReadKey.pm in @INC (you may need to install the
> Term::ReadKey module)...'
>
> So it is not that I (or my students) care about Term::ReadKey, it is
> that the advice we got is that we'd better install it.
>
> Also, the line marked with ** shows we obtained the prompt 'perl>'
> instead of the expected prompt 'pdl>'.
>
> In my previous installations, I hadn't had this problem, as I
> installed manually many required and optional pre-requisites,
> including Term::ReadLine::Gnu, which I guess is the readline you
> mention in your answer. However, installing Term::Readline::Gnu didn't
> help with the problem above. I obtained again:
>
>     $ pdl
>     perlDL shell v1.357
>      PDL comes with ABSOLUTELY NO WARRANTY. For details, see the file
>      'COPYING' in the PDL distribution. This is free software and you
>      are welcome to redistribute it under certain conditions, see
>      the same file for details.
>     ReadLines, NiceSlice, MultiLines  enabled
>     Reading PDL/default.perldlrc...
>     WARNING: Error loading PDL: 'Can't locate Term/ReadKey.pm in  
> @INC (you may need to install the Term::ReadKey module) (@INC  
> entries checked:  
> /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/site_perl/5.40.1/x86_64-linux /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/site_perl/5.40.1 /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/5.40.1/x86_64-linux /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/5.40.1) at /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/site_perl/5.40.1/x86_64-linux/PDL/Doc/Perldl.pm line  
> 52.
>     BEGIN failed--compilation aborted at  
> /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/site_perl/5.40.1/x86_64-linux/PDL/Doc/Perldl.pm line  
> 52.
>     Compilation failed in require at  
> /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/site_perl/5.40.1/x86_64-linux/PDL/default.perldlrc line  
> 37.
>     BEGIN failed--compilation aborted at  
> /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/site_perl/5.40.1/x86_64-linux/PDL/default.perldlrc line  
> 37.
>     Compilation failed in require at (eval 11) line 1.
>     ' - trying blib.
>     WARNING: PDL startup not found only plain perl available
>
>     Note: AutoLoader not enabled ('use PDL::AutoLoader' recommended)
>
>     perl>
>
> But after installing ReadKey things started behaving as usual:
>
>     $ cpanm Term::ReadKey
>     --> Working on Term::ReadKey
>     Fetching  
> http://www.cpan.org/authors/id/J/JS/JSTOWE/TermReadKey-2.38.tar.gz  
> ... OK
>     Configuring TermReadKey-2.38 ... OK
>     Building and testing TermReadKey-2.38 ... OK
>     Successfully installed TermReadKey-2.38
>     1 distribution installed
>     $ pdl
>     perlDL shell v1.357
>      PDL comes with ABSOLUTELY NO WARRANTY. For details, see the file
>      'COPYING' in the PDL distribution. This is free software and you
>      are welcome to redistribute it under certain conditions, see
>      the same file for details.
>     ReadLines, NiceSlice, MultiLines  enabled
>     Reading PDL/default.perldlrc...
>     Found docs database  
> /home/mochan2/perl5/perlbrew/perls/perl-5.40.1/lib/site_perl/5.40.1/x86_64-linux/PDL/pdldoc.db
>     Type 'help' for online help
>     Type 'demo' for online demos
>     Loaded PDL v2.098 (supports bad values)
>
>     Note: AutoLoader not enabled ('use PDL::AutoLoader' recommended)
>
>     pdl>
>
> So, what is the user expected to do? The installation of PDL was declared
> succesful, a program ('pdl') distributed with PDL was installed, the
> program didn't run smoothly and sent error messages asking the user to
> install another package: Term::ReadKey. How would you interpret this
> situation as a new user? Wouldn't you be confused? Wouldn't you
> conclude there is something wrong?
>
> I don't know what is the correct solution. I suggested adding
> Term::ReadKey to the required packages, so it would be installed
> automatically. Maybe that is not the correct solution, but then, I
> don't know, what would be the correct solution?
>
> Best regards,
> Luis
>
>
>
>
> On Tue, Jan 21, 2025 at 10:40:32PM +0000, Ed . wrote:
>> Hi Luis,
>>
>> PDL isn't just an interactive environment. "Required" would be  
>> wrong. I use the interactive part very heavily (which isn't very  
>> surprising), and wouldn't want to use it without readline (which I  
>> have faced when debugging in a qemu environment on a weird  
>> architecture). I am not going to make any of the Term::* be  
>> "required" for PDL. I hope you understand.
>>
>> If it helps, the REPL script was installed, but not all of the  
>> components. It does sound like you're asking me to make a separate  
>> PDL::REPL repo where that stuff would live, but I don't want to do  
>> that.
>>
>> Best regards,
>> Ed
>>
>> ________________________________
>> From: Luis Mochan <mo...@ic...>
>> Sent: 21 January 2025 20:07
>> To: Ed . <ej...@ho...>
>> Cc: perldl <pdl...@li...>; perldl  
>> <pdl...@li...>
>> Subject: Re: [Pdl-devel] pdl scripts
>>
>> Hi Ed,
>>
>> On Tue, Jan 21, 2025 at 05:13:09PM +0000, Ed . wrote:
>> > Hi Luis,
>> >
>> > That's a really good question!
>> >
>> > PDL's "requirements" (when you say e.g. cpanm PDL) are hard  
>> requirements for PDL to run: largely File::Map and File::Which.  
>> CPAN has a mechanism to "recommend" other modules, including  
>> Term::ReadKey. It has done so for a long time. cpanm can be told to  
>> install recommended modules.
>>
>> The doubt I have now is, should Term::ReadKey be recommended or should
>> it be required? The problem is that the repl's were installed, but
>> they didn't work without it.
>>
>> > The demos will be sparse...
>>
>> Ok, thanks. I'll pass that info to the students.
>>
>> 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