... start diking out and rearranging code.
A 2.4.3 release (even if not perfect) will go a long way toward
usability, since 2.4.2 was so evidently flawed. Folks have been very
kindly testing on different platforms, and I think we have even more
stability and breadth now than when 2.4.2 was
(Sorry, I was traveling -- which is why I dropped out of the
discussion for a few hours) The SSL stuff is my fault. I added it
to overcome the symmetric-matrices-only problem. I may not have
tested it with larger matrices. I'll have a chance to fix this over
the long weekend.
Cheers,
I'm not sure what you want that to do...
Zeroes and simialr constructors act differently depending on whether
the first argument is a PDL or not:
perldl $p = pdl(5);
perldl $a = zeroes($p,2,2); print $a;
perldl $b = zeroes($p-list,2,2); print $b;
[
[
PDL 2.4.3 and Tk seem to play well together -- but you have to load
Tk *before* PDL, I guess because of some of the strangeness that Tk
uses in its load process. (PDL is pretty strange too but it doesn't
hold a candle to the involuted module loading that Tk does).
I agree with Jarle that
The problem is that you are missing the netpbm package that is used to read
and save images. The cartography demo uses rpic(), which in turn uses netpbm
to read and translate the included JPEG images of the Earth.
Cheers,
Craig
On Tuesday 20 July 2004 06:08, [EMAIL PROTECTED] wrote:
Hi
Uh, sorry for the spam -- just noticed this was from *2004*. I'm
using a new mail client (kmail) and somehow it marked Ycrux's ancient
note as unread...
On Mar 24, 2007, at 1:50 PM, Craig DeForest wrote:
The problem is that you are missing the netpbm package that is used
to read
and save
Interesting -- Deaglan seems to have written to several of us
individually. I am unable to reproduce his problem; have asked him to
try a test script:
use PDL;
use PDL::Graphics::PGPLOT::Window;
$w = pgwin(xs); # Deaglan, I asked for xw since I thought you
weretyping into
Hadn't thought of that -- I bet you're right, Pete! On Macs in
particular I've had to rebuild the grfont.dat file. Suns may be the
same way -- the one that ships with pgplot itself is in little-endian
order, and rebuilding it is necessary on a big-endian machine.
I remember having a
I tend to cite PDL with http://pdl.perl.org, and to include the
version number. I also list all the contributors (in the current web
page), like so:
K. Glazebrook, J. Brinchmann, J. Cerney, C. DeForest, D. Hunt, T.
Jenness, T. Luka, R. Schwebel, and C. Soeller 2006: The Perl Data
.
As a last note, maybe Craig DeForest will chime in on this thread.
He is
responsible for the general PDL::Transform code, whereas I just
added an
interface between that and a more general interface to the Proj4
library. I'll still help as best as I can, however.
-Judd
On Thu, 2007-09-20 at 15
Very interesting. It would be helpful to have a copy of the original
and mangled data file, or at least of their FITS headers if you can
strip them out with your favorite text editor.
Cheers,
Craig
On Oct 2, 2007, at 3:13 PM, Matthew Kenworthy wrote:
I've been trying to copy the FITS
The routine you want is indexND, which will return a collection of
points from your source PDL, but stacked up suitably for threaded
assignment. I'll send an example when I'm at a real kbd and not a phone.
Craig DeForest
On Jan 3, 2008, at 12:02 PM, [EMAIL PROTECTED] wrote:
I'm new to PDL
Hey, January,
You can assign elements between piddles en masse using the computed
assignment operator, .=, as in
$pdl2 .= $pdl1
which will take every single element of $pdl1, cast it to whatever
type $pdl2 has, and copy it into the corresponding element of $pdl2.
(The two piddles have
Is YAML common enough these days that we should consider implementing
it directly for PDL? There's a big speed hit with moving back into
Perl variables. (Then again, people who care about speed probably
aren't using large ASCIIfied interchange formats...)
On Feb 28, 2008, at 9:13 AM,
You can use range for that:
$a = sequence(5)
$b = pdl(1);
$c = $a-range($b,[$a-dims],'p');
On Apr 9, 2008, at 3:00 PM, Art Davis wrote:
I haven't been able to make shiftleft work the way I want it. It may
not even be the right command, I can't understand the POD
documentation for it.
You are looping because you are not trusting the threading engine.
The strategy is to push your unused dimensions above the active
dimensions of your operator, and then let them ride along. Matrix
multiplication has two active dimensions, so you have to add dummy
dimensions to make your
There is a caveat about whichND: for historical reasons it does
different things in list and scalar contexts.
In list context it gives back a list of pdls each of which contains
one component of each vector into the source array. You almost always
want scalar context.
On Apr 21, 2008, at
Aha, now I understand. You want to search your image for a particular
color vector -- you want something like collapse-by-comparison. Try
this:
perldl $im = sequence(8,8,3); # an 8x8x3 RGB image
perldl $rgb = $im-mv(-1,0); # a 3x8x8 RGB image
perldl $xylist = whichND( ($rgb ==
$coords = whichND( ($colors==$rgb)-all );
I'm assuming your array is called $colors, and is sized so that the
(RGB) index is dim 0, X is dim 1, and Y is dim 2. $rgb is a 3-PDL
containing your test color vector. The key is to use all, which
will collapse by logical AND. The expression
The problem is that you need to use the apply method rather than
simple multiplication. The Transform stuff embodies arbitrary
transformations, so multiplication with '*' (or even matrix
multiplication with 'x') is not appropriate. Finally, I prefer to use
t_linear instead -- t_rot
, Apr 30, 2008 at 8:52 AM, Craig DeForest
[EMAIL PROTECTED] wrote:
That would be the part in NOTES where it says
Composition works OK but should probably be done in a more
sophisticated
way so that, for example, linear transformations are combined
at the
matrix level instead
based, then range will
be more what you are looking for.
Cheers,
Jarle.
Quoting Craig DeForest [EMAIL PROTECTED]:
Hmmm, I couldn't parse exactly what you want -- it would be easier if
you could also describe the algorithm in a sentence or two
[
[0 1 1 0 0 0 0 2 2 2]
[0 1 1 1 0 0 0 2 2 2]
[0 0 0 0 0 0 0 0 2 0]
]
If on the other hand the selection is value based, then range will
be more
what you are looking for.
Cheers,
Jarle.
Quoting Craig DeForest [EMAIL PROTECTED]:
Hmmm, I
,
Craig
On May 11, 2008, at 1:35 PM, Craig DeForest wrote:
Ah, that should be all($mrgn_max==$mctr).
On May 11, 2008, at 12:57 PM, Florin A. wrote:
You guys are amazing! Thank you
Jarle, the cc8compt does exactly what I wanted here. Now I need to
move on to using larger neighborhoods
Very interesting. This looks like a failure of the PP engine for
multiple dataflow types. Would you mind filing it as a bug? (A
workaround is to set $bb=$b-copy, then work with ranges of $bb and
expliticly set $b .= $bb)
Nesting ranges works OK:
$a = sequence(10,10);
Hi, Chris,
As you surmised in your offline e-mail to me, this is not a bug at all
but rather a side-effect of how PDL handles multiply-valued mappings.
On the other hand, it does reveal a hidden bug in the PP code. Your
example:
$a = sequence(2,3);
$rolled = $image-range(pdl($image-dims)/2, [$image-dims],'p');
On May 22, 2008, at 1:37 PM, Hugh Sasse wrote:
I'm trying to move the origin of a 2D FFT created with Perldl so
that it is in the centre of the image. I'm after a shift with
wraparound on both axes, like a machine language ROL
Yep -- For PGPLOT stuff I generally make eps files and/or oversized
output, and then convert and/or scale to match what I want. That's
overkill but for a few figures it's OK.
Cheers,
Craig
On May 23, 2008, at 9:44 AM, Doug Hunt wrote:
Hi all: As far as I can tell, nice-looking,
I generally roll my own fitting loops - I am silly enough to use
amoeba, and my amoeba code accepts a code ref to calculate the
heuristic's value. (I would be happy to post it if anyone else is
foolish enough to want it.)
I think that the fitting stuff in the distro Also handles code refs
OK, all,
We've been talking intermittently about a 2.4.4 release. Let's plan
on issuing 2.4.4 release for the 4th of July. That gives two weeks to
tackle outstanding bugs and two weeks for testing. Even the current
CVS is significantly better than 2.4.3, but it would be good if we can
That is enough of a glitch that it should probably be listed as a bug
and made to work smoothly. The problem is that the constructor is
expecting to be called like a method when it is called in its own
package. The exported constructor (just pdl()) expects to be called
like a subroutine,
The current version of Transform just applies the two matrices one
after the other. That is considered a bug as it is slower than
combining the two. There has been a patch submitted that combines
adjacent linear operations, but it has not yet been applied in cvs.
On Jun 27, 2008, at 9:13
Hi, Edward,
You can test for PDLness with UNIVERSAL::isa($foo,'PDL'), but that's
a bit awkward. I generally test with ref($foo) eq 'PDL', but that
will break if someone hands you a PDL subclass.
For most stuff, you can just check definedness.
Cheers,
Craig
On Jul 1, 2008, at 5:19 PM,
Hi, Hernan,
It would help if you could report here exactly where your
opengl,glx,glu, and glut libraries live. We might be able to put an
appropriate switch into the makefile scripts for 2.4.4. Also: what's
your LIBPATH?
Cheers,
Craig
On Jul 9, 2008, at 6:49 AM, Hernán De Angelis wrote:
On Wed, 9 Jul 2008, Craig DeForest wrote:
Hey, Doug,
I'm finishing up my pass through the bugs database on PDL for the
2.4.4 release. I'd like to try to clear up as many as possible,
but the PLPlot stuff is beyond my ken. Would you kindly have a
look at as many of the following as you
I have had this problem too. There are linker issues for PGPLOT on 64-
bit architectures (which are the norm these days). I think the big
deal is making the linker recognize libcpgplot.a, which looks like a
32-bit library even if compiled under 64 bits.
Some combination of adding -fPIC to
of the input array.)
Best
Craig
On Sep 9, 2008, at 3:32 PM, Bruno Picard [EMAIL PROTECTED] wrote:
Hello Craig,
I cannot try your examples: do you use the same $x?
the error line says
index out-of-bounds in range at
Bruno.
Craig DeForest a écrit :
Hello, Bruno,
It is not quite clear what
Hi, Steve,
$PDL::BIGPDL is a global variable that disables a safety/sanity check
in the PDL engine. Setting the variable to 1 lets you declare a PDL as
large as you want; otherwise the engine won't let you work with any
single variable larger than 1GB. (When PDL was written 12 years ago,
::BIGPDL=1) is
$c=$a==$b-dummy
where
$b is Double D [500]
$a is Double D [48]
On Sun, Sep 14, 2008 at 3:41 PM, Craig DeForest [EMAIL PROTECTED]
wrote:
Steve,
Are you sure you sent us the exact expression you used below? For
example, if you masked
your very large data set
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
At the moment, no. That is planned for v2.5.
On Sep 20, 2008, at 2:49 AM, Rahman Amanullah wrote:
Hi,
I'm sure this have been up before, but I couldn't find anything in the
email archive.
These days multiple core CPUs are becoming standard on all PCs. A lot
of the code that I'm running
I think PDL::GSL::RNG can do it.
On Sep 29, 2008, at 1:22 PM, Derek Lamb wrote:
Steve Cicala wrote:
Can anyone point me to the function in PDL that returns values from
the standard normal distribution?
i.e.
0.5=pnorm(0)
Thanks,
Steve
As far as I know there is no such thing. There
Chris, you rock.
Thanks very much for seeing this through. Your diligence is both
making 2.4.4 a great release and also laying good groundwork for the
major overhauls we've been discussing on perldl-porters.
Cheers,
Craig
On Nov 4, 2008, at 7:54 PM, Chris Marshall wrote:
PDL Developers
Your best bet is to edit Makefile and search for the string
CCFLAGS. Add -fPIC at the end of the line.
You will have to do this in your FFTW compilation directory, because
it is libfftw.a that is not being compiled correctly.
Best,
Craig
On Jan 13, 2009, at 11:09 AM, m...@farma.ku.dk
convolveND() does indeed use Fourier transformation for large arrays.
I believe it has a superset of the functionality of convolve() and
fftconvolve(). I have not looked closely enough at fftconvolve,
conv1d, or conv2d to know if they should be deprecated like
convolve(), but you ought
from spherical
coordinates to an Aitoff projection. Scaling by 180/pi does not seem
to help. (Also, what are the limits of the two axes? 0-360, or
-180-180? Does it matter?)
David Whysong
On Mon, Feb 2, 2009 at 12:28 PM, Craig DeForest
defor...@boulder.swri.edu wrote:
I think
No worries, glad to see it is working.
Most of the transformations are defined only over the range (-180 -
180) in degrees longitude, that might be your problem. Try:
$coords -= 360*($coords180);
just before the transformation.
Threading in PDL generally keeps the active dimensions
I think that we have definitively determined that fftconvolve is
broken. Would you be so kind as to submit a bug report to Sourceforge?
Meanwhile, it is suggested that you use convolveND instead - it
normally chooses direct or FFT processing depending on a speed
heuristic, but has an
Hmmm, I'll have to investigate that -- the BAD stuff used to work,
though I didn't make a formal test procedure for it (bad craig!)
There is a well known all-NaN/all-BAD problem with most FFT methods -
if even one pixel is NaN/BAD in either input array, it will poison the
whole output,
Hmmm... What version are you running, and on what platform? It works
fine for me on MacOS...
On Feb 22, 2009, at 2:17 PM, hernan gonzalez wrote:
I may be doing something silly, but...
this code:
my $w= (sequence 10)/4;
print $w,\n;
print floor($w) ,\n;
print ceil ($w) ,\n;
print rint
Thanks for pointing out PIIU, Derek.
As the author, I must apologize that PIIU is woefully out of date --
it still works, for what it is, but I have been meaning for years(!)
to add some how-to sections to it.
For image processing, things you'll want to think about (off the top
of my head)
(cc to TJP in case you're interested; context at bottom)
Sorry to duck out of the thread for a day or so -- here are my current
thoughts on PGPLOT bit rot.
The PGPLOT bit rot is actually quite advanced. I wrote the RGB
bitmap patch against the then-current PGPLOT (5.2.2) five years ago;
Hi, Edward,
You're right, PDL doesn't have a ulong type -- only a ushort. Since
your values aren't likely to be larger than 2**31, you are probably OK
just using long rather than ulong. That might be the source of
your readflex error, too; why not try it with long instead of ulong?
it
(provided that nobody pipes up and complains). Certainly I'm open to
making the built-ins behave more like fftw if there's a desire to do so.
Cheers,
Craig
On Mar 27, 2009, at 10:29 AM, Hugh Sasse wrote:
On Fri, 27 Mar 2009, Craig DeForest wrote:
I've been meaning to overhaul the internal FFT
On Mar 27, 2009, at 12:11 PM, Hugh Sasse wrote:
Well, since I primarily interested in N dimensional FFTs I'm capable
of getting myself in enough knots dimensionally without having to
track which slices are not actually slices, but what would be, in
an Object Oriented perspective, properties
Hey, all,
Thanks, Derek, for the nice explanation. Sorry to have been out for a
couple of days. I do have a couple of minor things to add about
neighborhood-based calculations:
For neighborhood-based computing on moderately sized arrays (less than
a few hundred million elements) range()
Hi, Cliff,
One problem is that you're using where(), when you want which(). The
former returns the actual elements that match the mask criterion, in
this case the elements of $a that correspond to the places where your
mask $a(0)==1 is true. This is doubly wrong, because the thing
Hi, Maggie,
To get your 5x2 matrix you want the threading engine to work across
both input parameters' thread dimensions (the extras after the active
dimension of the operator is lopped off the left side of the dimension
list). To do that you have to put the (5) and the (2) in different
Oops. Yep, the active dim size is 10, not 5 as I typed. Er, I was
just testing you... (actually not enough coffee).
On Apr 20, 2009, at 10:10 AM, Maggie J. Xiong wrote:
Thank you!! It certainly worked. Just to make sure I understand it
correctly,
On Mon, Apr 20, 2009 at 11:46 AM, Craig
There's no universal way to do it. If your data are not yet ordered,
I suggest triangulating them using one of the Delaunay triangulation
codes (for which you can Google). That will give you a tiling of the
plane into triangles defined by nearby data points. Once you've done
that, it's
Hi, Gabor,
I'm not familiar anymore with the Matlab syntax, but I believe Gnu
Octave was intended as a work-similar replacement for it. PDL is, as
you say, aimed at small to medium sized tasks - defined as smaller
than the main memory of your computer, which is a moving target. PDL
Slatec's polyfit is giving absolutely crazy answers.
perldl $x = xvals(50)
perldl $y = 15.2 + $x*3.14 + $x*$x/3.14 + ($x*$x*$x); # some random
cubic
perldl use PDL::Slatec;
perldl ($ndeg,$r,$ierr,$a) = polyfit($x,$y,ones($x),pdl(4),
$eps=zeroes($x));
perldl p $ndeg
[4 4 4 4 4 4 4 4 4 4 4 4 4
The problem with the Perl logicals is that, being short-circuiting
operators (which explicitly don't evaluate their second argument if
that argument can't affect the outcome), they don't have deterministic
behavior in a threaded expression. The bitwise Booleans work well as
, Craig DeForest wrote:
The problem with the Perl logicals is that, being short-circuiting
operators (which explicitly don't evaluate their second argument if
that argument can't affect the outcome), they don't have
deterministic
behavior in a threaded expression. The bitwise Booleans work well
Holy cow, Chris, I'd forgotten about indadd(). Nicely done.
On Jul 1, 2009, at 9:57 PM, Chris Marshall wrote:
Does this do what you want?
perldl $this=pdl(3,4,5,5,5,5,5,5,5,5)
perldl p $this
[3 4 5 5 5 5 5 5 5 5]
perldl $that = sequence(11)
perldl p $this
[3 4 5 5 5 5 5 5 5 5]
perldl
In fact, you can even just say
indadd(1, $this, $that)
and the 1 is automatically promoted to PDL and then threaded over.
Again, nicely done, Chris.
On Jul 1, 2009, at 9:57 PM, Chris Marshall wrote:
Does this do what you want?
perldl $this=pdl(3,4,5,5,5,5,5,5,5,5)
perldl p $this
: 361-8170
Nortel Core RF Field Support: All information is Nortel
confidential.
-Original Message-
From: Craig DeForest [mailto:defor...@boulder.swri.edu]
Sent: June 30, 2009 9:18 AM
To: Hernán De Angelis
Cc: perldl
Subject: Re: [Perldl] Compute a distribution function from
Er, I fixed TriD on the mac a while ago but failed miserably at
committing my fixes to the git repository. I'll try to get it checked
in this weekend, maybe tonight.
On Aug 28, 2009, at 10:25 PM, P Kishor wrote:
a damn! From perldl.conf
# Try to build Graphics/TriD
#
# There are
I'm not sure whether Snow Leopard breaks the linker the same way that
Leopard did - but shared library linking is a pain in the tuchus these
days: you have to send a bunch of arcane runes to gcc to get shared
libraries to compile right. (see Apple Tech Note at
Hi, Adithya,
It would help if you could send the actual compilation error message.
Cheers,
Craig
On Oct 5, 2009, at 12:33 AM, adithya wrote:
hi,
im trying to get some PDL::PP code working. But even the sample sumit
example from the PDL::PP documentation doesnt compile properly.
This is my
It is a slice: $a-(-1:0:-1). From last element to first element,
stepping by-1.
(Mobile)
On Oct 9, 2009, at 8:09 AM, Maggie Xiong maggie...@users.sourceforge.net
wrote:
Maybe I've missed the obvious--is there something similar to perl
reverse in PDL? It seems trivial but handy to have
, Chris Marshall wrote:
Craig DeForest wrote:
This has to do with which PGPLOT module you have loaded -- Karl
kindly put it into one version (.20, I think) but I believe he
backed it out when TJP was completely unresponsive and RGB images
were not integrated into the pgplot mainstream
also keep meaning to split it off from the main starlink tree and
have it as a standalone git repository.
Tim
On Oct 28, 2009, at 3:29 PM, Chris Marshall wrote:
Craig DeForest wrote:
This has to do with which PGPLOT module you have loaded -- Karl
kindly
put it into one version (.20, I
This has to do with which PGPLOT module you have loaded -- Karl kindly
put it into one version (.20, I think) but I believe he backed it out
when TJP was completely unresponsive and RGB images were not
integrated into the pgplot mainstream.
I suppose we could patch Karl's module again, but
Yep. The only real question remaining for Tim J is whether they got a
viral Free style license (e.g. the right to bundle it with Starlink
under the GPL), in which case forks are explicitly allowed.
(Mobile)
On Oct 28, 2009, at 8:22 PM, Frossie f.econo...@jach.hawaii.edu wrote:
Tim
David:
I think splitting PDL out into multiple modules is a good idea,
provided that it is also maintained as a bundle. To some degree this
has started to happen -- there are many PDL:: modules in CPAN that are
not part of the PDL distro -- but sometime in the not-too-distant
future
This looks like the best argument I've yet seen for breaking up the
PDL distribution -- perhaps making the stuff in Basic the actual PDL
module, and putting Graphics, IO, and Lib into their own module trees.
On Oct 30, 2009, at 9:27 AM, David Mertens wrote:
Ilya Z, author of
On Oct 30, 2009, at 1:45 PM, Tim Jenness wrote:
Ilya is also notoriously impatient...
Is he also hubristic?
___
Perldl mailing list
Perldl@jach.hawaii.edu
http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
On Nov 8, 2009, at 5:33 AM, Gabor Szabo wrote:
On Wed, Nov 4, 2009 at 3:12 PM, Matthew Kenworthy wrote:
I'd also add that once I 'got' PDL threading, it completely
transformed the language for me. It's one of those things that make
you go 'huh?' at the start, and then when the light bulb
The real question is whether Java has a means of invoking a Perl
interpreter. (The converse is true -- cf. Inline::Java).
On Nov 8, 2009, at 10:19 PM, adithya wrote:
java 2 enterprise edition - Enterprise Java Bean
sorry for the acronymns... :)
Craig DeForest wrote:
Er, what's a j2ee ejb
PDL has the same precision at Matlab -- they both use double-precision
IEEE floating point (on all the usual platforms).
On Nov 9, 2009, at 7:11 AM, Gabor Szabo wrote:
I don't recall I ever had to deal with numbers in perl that were too
big or too smal
for perl but I guess with real
Hmmm... I think the diagonal(n,n) cases are a bug. One could make a
case either for a barf or for diagonal(0,0) to yield [1 2] and diagonal
(1,1) to yield [1 3], but both giving [1 2] is spurious.
But diagonal(n,m)==diagonal(m,n) is correct. The difference between
the two operations is a
p $q-range([1,0],3,'t'); # shift left
p $q-range([-1,1],3,'t'); # shift right and down
p $q-range([-1,-1],3,'pt'); # roll left and shift up
On Nov 12, 2009, at 8:59 AM, Gabor Szabo wrote:
Now that I know how to rotate with a wrap - thank you all for your
help -
I'd like to rotate (or shift
the plot.
Anyway, for any index tricks involving boundary conditions in the
original PDL, range() is your friend.
On Nov 12, 2009, at 9:05 AM, Craig DeForest wrote:
p $q-range([1,0],3,'t'); # shift left
p $q-range([-1,1],3,'t'); # shift right and down
p $q-range([-1,-1],3,'pt'); # roll left
There is an open-source project that parses quasi-Matlab. I believe
it is called Octave.
On Nov 15, 2009, at 8:36 AM, Chris Marshall wrote:
I think PDL will get more traction with Matlab users if we fix
PDL to be more of a 1-click install and use experience and if
we provide basic 2D and
Hey, David,
Very nice writeup. Contributions like this are a big part of why I
like working with such an active user/developer community. It's great
to have so many fine examples lain out where people can get to them.
I probably should (have?) put something in range's documentation about
There's a little bit in the PP documentation, but it's mainly a black
art.
It's helpful to realize that slicing operations maintain dataflow, so
they have to set up callback routines.
There are three major pieces:
* MakeComp - when you invoke a slicing method, it only sets up the
This sounds like a Perl bug - some well-meaning person probably
noticed this wart, figured that there's no reason anyone would ever do
that, and put a roadblock into the new Perl interpreter. It probably
needs to be submitted as a Perl bug and removed from the next bugfix
release of
Exactly. This is a problem with lvalue subroutines in general. I'm
submitting a perl bug now; cc in a moment.
On Dec 10, 2009, at 11:42 AM, Doug Hunt wrote:
Hi again: Poking at this problem a bit more, it seems it is not a
source
filter/NiceSlice issue.
I replaced the offending line
From the convolveND docs:
The kernel's origin is taken to be at the kernel's center. If your
kernel has a dimension of even order then the origin's coordinates get
rounded up to the next higher pixel (e.g. (1,2) for a 3x4 kernel).
This mimics the behavior of the earlier convolve and
It is not clear what you are doing here. It appears that $data
contains a value that is defined at a particular (theta,phi)
controlled by the index, yes? If that is the case, you are using the
wrong transformation method. PDL::Transform::apply() is used to
transform a single vector (or,
Sorry to miss this comment the first time. I agree with Chris on the
list() thing, but given that your fundamental unit is a row you may
want to combine it with dog(), which is the opposite of cat().
Are your rows assembled from a single PDL? Or from multiple?
Assuming a single PDL, and
I tentatively support a standard repository arrangement, with some
cautions. This has been tried, with some success, in the solar
physics community with the SolarSoft (http://www.lmsal.com/solarsoft)
scientific software library for IDL. I say some because SolarSoft,
which was a great
Thanks, everyone, this is pretty interesting. I see three classes of
solution emerging:
(A) find an appropriate existing routine specifically for rescaling
- rescale2d in PDL::Image2D (Mattew's original solution)
$out = zeroes( ( pdl($in-dims) * $n )-list);
The problem there is that it includes NiceSlice syntax, which modifies
the language syntax with a preprocessor. You need to say use
PDL::NiceSlice; at the top of your script to make that work.
Otherwise you can use slice instead:
$b = $a-slice('*5,:,*5,:');
On Apr 16, 2010, at
On Apr 16, 2010, at 2:07 PM, Douglas Burke wrote:
On 4/16/10 1:09 PM, P Kishor wrote:
consistently direct_indexing is the slowest, and clumping is the
fastest.
Given the indexing shenanighans that the PDL internals do here, I
wonder
if this is a fair comparison. Could direct_indexing be
I just pushed a new FITS.pm that supports variable-length arrays for
writing and that supports the TDIM field for binary tables. Variable
length array support is a little cumbersome because, after all, PDLs
are structured arrays and not lists-of-lists; but (A) it lets you pack
files more
Yes, there is. It's an unfortunate hangover from Perl 5 (like the
.= wart).
NiceSlice actually changes the syntax of the parser. How, I hear
you not asking, does it do that, when Perl 5 doesn't give you access
to the parser?. When you Use NiceSlice, the remainder of your code
gets
On May 4, 2010, at 3:43 PM, Daniel Carrera wrote:
Craig DeForest defor...@boulder.swri.edu wrote:
~ $ perldl myprogram.pdl
Already been done :-) In fact, the pdl executable exists only to
chain into perl so you can run pdl scripts from the command line:
Interesting. Two questions:
1
A good question to ask: are you running out of memory, or of address
space? If you are on a 32bit machine then MMAP likely will not help
you as it still uses addresses.
(Mobile)
On May 6, 2010, at 5:18 AM, Matthew Kenworthy kenwor...@strw.leidenuniv.nl
wrote:
A separate question for
1 - 100 of 392 matches
Mail list logo
