On Fri, 19 Sep 2008, Craig DeForest wrote:
> PDL::Complex was never fully implemented, in the sense of overloading all the
> basic operators. Hence many operations will "fall through" to the PDL
> implementation that is under the hood. PDL::Complex places the
> (real,imaginary) component in the 0 dimension, which is why your 3x3
> PDL::Complex object turns out to be a 2x3x3 PDL under the hood.
>
> To be fair, there is no non-surprising way to implement the "at" method for
> PDL::Complex objects, because PDL::at returns a Perl scalar and Perl doesn't
> implement a complex scalar type.
Then it could return a reference. PDLs are not native perl types as
such, but we can cope with that. Perl does have a Math::Complex
type, and it conflicts with the present arrangement. Maybe it came
along later.
>
> You will find that the more familiar slicing operators don't work quite right
> either:
Could that....
>
> perldl> print $cz->((0),(0))
> [0 0 0]
>
> I don't think there is strong enough interest in PDL::Complex among the
> current developers that it is likely to get fixed soon. Your best options
...and that...
> are:
> (1) become a developer (not that hard) and add more overlain operators
> to PDL::Complex;
> (2) use the existing PDL::Complex, which mainly handles basic
> operations like multiplication and printing, and expect that you'll see the
> underlying structure a fair amount;
> (3) Just use regular PDLs and treat the complex operations explicitly.
>
> I think PDL::Complex is likely to be pulled out of the main distribution at
> the next major release (which will be the main development goal once we get
...and that be displayed more prominently in the docs so people don't
waste hours of debugging as I have? Sending a patch is possible, but
I don't know what the source form of these pages is, and some of them
(Eg Dockbook) I'm not familiar with.
> the long-delayed 2.4.4 minor point release out the door). It will then become
> a separate CPAN module.
>
> Cheers,
> Craig
As to (1):
Short form:
I'm sorry, that is not going to happen, for various sensible
reasons.
Long form:
"Not that hard": no, just requiring decent familiarity with the
code base which takes time to pick up. Why don't programmers
like maintenance programming? Because understanding other
people's code is more difficult that writing your own. I'm
clearly not in a position to do anything useful if I'm running
into problems like this.
It's not like I don't contribute to projects I use, I have
recently sent off a number of patches to various Ruby projects,
for example, and in the past to various others I could name.
These days I'm more fluent in Ruby than Perl, so my contributions
wold probably be less useful anyway. And I have other things
that I'm trying to get done so don't have enough time. There are
plenty of valid reasons for not being a contributor to any given
project, and I'm afraid I can't contribute to everything. So
this line of reasoning is beginning to wear pretty thin. Adding
more programmers to a project has been shown to slow it down in
enough cases for it to be significant [Brooks, "The Mythical Man
Month"], so sometimes diving in can be a hindrance, especially
with code which doesn't fit the existing structures, due to
insufficient familiarity with the code base.
Thank you,
Hugh
>
>
> On Sep 19, 2008, at 5:17 AM, Hugh Sasse wrote:
>
> > I'm using Perldl 2.4.3 under cygwin.
> >
> > perldl> $z = zeroes(3,3)
> >
> > perldl> $cz = &PDL::Complex::r2C($z);
> >
> > perldl> print $cz
> >
> > [
> > [0+0i 0+0i 0+0i]
> > [0+0i 0+0i 0+0i]
> > [0+0i 0+0i 0+0i]
> > ]
> >
> > Fair enough, a 3 by 3 array of complex. Well, maybe.
> > perldl> print ref($cz)
> > PDL::Complex
> >
> > So it knows it holds complex numbers.
> >
> > perldl> print $cz->at(1,1)
> > Invalid position at /usr/lib/perl5/site_perl/5.10/i686-cygwin/PDL
> > /Core.pm line 2377.
> >
> > So what does it think the dimensions are?
> >
> > perldl> print $cz->dims()
> > 2 3 3
> > perldl>
> >
> > Now, complex numbers are supposed to interact correctly with "normal"
> > reals, but I can't access elements of arrays of Complex and arrays
> > of reals in the same way in the code, so I need two paths through my
> > code.
> >
> > Is there something like this (rough sketch) already?:
> >
> > package PDL::Complex;
> >
> > sub at {
> > my $self = shift;
> > my $x = shift;
> > my $y = shift;
> >
> > return &PDL::at($self,0,$x,$y) + &PDL::at($self,1,$x,$y) * i;
> > }
> >
> > Is there a reason I would not want to add that to my code, if not?
> > Alternatively, why is my expectation on this wrong? What should I
> > be looking for, to pluck a complex value from a 2D array of numbers,
> > in a complx/real agnostic way?
> >
> > Thank you,
> > Hugh
> >
> > _______________________________________________
> > Perldl mailing list
> > [email protected]
> > http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
>
_______________________________________________
Perldl mailing list
[email protected]
http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
