Buddha Buck wrote:
> I think that once you have LOL's automagically padded to size, and that
> size stored as an intrinsic part of the LOL, you no longer have a
> traditional LOL. You have something that looks, walks, and quacks like
> a matrix and doesn't walk or quack like an LOL. Why not call
> Karl Glazebrook wrote:
> > There is a difference between a List of Lists and a multi-dimensional
> array - the
> > latter is rectangular, e.g. the rows are all the same size so you don't
> have to
> > store the sizes of individual ones. So the latter needs much less storage
> overhead.
> > How w
Karl Glazebrook wrote:
> There is a difference between a List of Lists and a multi-dimensional
array - the
> latter is rectangular, e.g. the rows are all the same size so you don't
have to
> store the sizes of individual ones. So the latter needs much less storage
overhead.
> How would you be prop
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> On Wed, 30 Aug 2000, Christian Soeller wrote:
>> A second related question: would I be able to return a list of arrays
>> from a function, e.g.
>>
>> (@fit,@corr) = fitit @x, @y;
>>
>> How could I find out if the user wants just one arr
At 01:47 PM 8/30/00 -0400, Karl Glazebrook wrote:
> > If you do a plain
> >
> > my int @foo;
> >
> > it'll end up with a contiguous block of memory anyway. :compact seems to
> > me more an attribute for sparse arrays than anything else.
> >
>
>Uhm do you mean a contiguous block of 4 byte integer
> If you do a plain
>
> my int @foo;
>
> it'll end up with a contiguous block of memory anyway. :compact seems to
> me more an attribute for sparse arrays than anything else.
>
Uhm do you mean a contiguous block of 4 byte integers or a countiguous
block of perl scalar structures? It is the f
Jeremy Howard wrote:
>
> Karl Glazebrook wrote:
> > Dan Sugalski wrote:
> > This is my view.
> >
> Ditto. As I said yesterday, my current preferred option is that a list ref
> of list refs will also support a multidimensional indexing syntax.
> Furthermore, if it has a single basic data type and
Dan Sugalski wrote:
> On Wed, 30 Aug 2000, Jeremy Howard wrote:
> > Furthermore, if it has a single basic data type and is declared
':compact'
> > it should be stored in a contiguous block of memory.
>
> If you do a plain
>
> my int @foo;
>
> it'll end up with a contiguous block of memory anyway
On Wed, 30 Aug 2000, Jeremy Howard wrote:
> Karl Glazebrook wrote:
> > Dan Sugalski wrote:
> >
> > > On the other hand, just extending out arrays to be multidimensional may
> > > well be good enough.
> > >
> >
> > This is my view.
> >
> Ditto. As I said yesterday, my current preferred option is t
On Wed, 30 Aug 2000, Jeremy Howard wrote:
> I think as long as we specify the features we need in our language RFCs, the
> internals folks will identify the common threads needed to implement them.
> This means that we should ensure that efficiency goals should be spelled out
> in each RFC where
On Wed, 30 Aug 2000, Christian Soeller wrote:
> A second related question: would I be able to return a list of arrays
> from a function, e.g.
>
> (@fit,@corr) = fitit @x, @y;
>
> How could I find out if the user wants just one array or two?
If this feature goes in, there'll be some sort of w
Christian Soeller wrote:
> Jeremy Howard wrote:
> > >
> > Ditto. As I said yesterday, my current preferred option is that a list
ref
> > of list refs will also support a multidimensional indexing syntax.
> > Furthermore, if it has a single basic data type and is declared
':compact'
> > it should b
Jeremy Howard wrote:
> >
> Ditto. As I said yesterday, my current preferred option is that a list ref
> of list refs will also support a multidimensional indexing syntax.
> Furthermore, if it has a single basic data type and is declared ':compact'
> it should be stored in a contiguous block of mem
Karl Glazebrook wrote:
> Dan Sugalski wrote:
>
> > On the other hand, just extending out arrays to be multidimensional may
> > well be good enough.
> >
>
> This is my view.
>
Ditto. As I said yesterday, my current preferred option is that a list ref
of list refs will also support a multidimensiona
Christian Soeller wrote:
> Chaim Frenkel wrote:
>
> >
> > The current thinking in -internals is that list flattening will be
delayed
> > to as late as possible.
> >
> > One possiblity would be that only @_ would do any flattening. It would
> > walk each argument with an appropriate iterator to ret
Baris wrote:
> My motivation was to give more freedom to the developers of pdl so that
> they can freely create the syntax without worrying about the workarounds.
> Matlab, in my opinion, is much more natural to code than current pdl.
It'd be interesting to hear what you dislike in particular.
Chaim Frenkel wrote:
>
> > "CS" == Christian Soeller <[EMAIL PROTECTED]> writes:
>
> CS> The other problem with arrays is: how do we deal with functions that
> CS> take multiple piddle arguments if they are arrays:
>
> CS>@result = integrate @x, @y, @bounds;
>
> CS> Won't those all be
Chaim Frenkel wrote:
>
> The current thinking in -internals is that list flattening will be delayed
> to as late as possible.
>
> One possiblity would be that only @_ would do any flattening. It would
> walk each argument with an appropriate iterator to return the flattened
> list.
>
> A param
> "CS" == Christian Soeller <[EMAIL PROTECTED]> writes:
CS> The other problem with arrays is: how do we deal with functions that
CS> take multiple piddle arguments if they are arrays:
CS>@result = integrate @x, @y, @bounds;
CS> Won't those all be clumped into one big input array? Does i
At 12:42 PM 8/29/00 -0400, Karl Glazebrook wrote:
>Dan Sugalski wrote:
> >
> > At 12:28 PM 8/29/00 -0400, Karl Glazebrook wrote:
> >
> > >But scalars are not compact.
> >
> > Since scalars are singular things, how would you compact them anyway?
> >
>
>If I say $a = ones(float,10,10) in PDL then ea
Hello,
First of all I am not really sure if there is a need for a new data type,
and I am not really in a position to decide for it. Mine was just an idea
(maybe not a very good one since I am not very experienced with pdl), and
sometimes the ideas are useful but half of the time they are not corr
Dan Sugalski wrote:
>
> At 12:28 PM 8/29/00 -0400, Karl Glazebrook wrote:
>
> >But scalars are not compact.
>
> Since scalars are singular things, how would you compact them anyway?
>
If I say $a = ones(float,10,10) in PDL then each element of $a
is a 4 byte floating point number.
This is no
At 12:28 PM 8/29/00 -0400, Karl Glazebrook wrote:
>But scalars are not compact.
Since scalars are singular things, how would you compact them anyway?
Dan
--"it's like this"---
Dan Sugalski
Dan Sugalski wrote:
> On the other hand, just extending out arrays to be multidimensional may
> well be good enough.
>
This is my view.
Karl
But scalars are not compact.
Nathan Wiger wrote:
> To avoid anyone getting yelled at by TomC or someone else: Yes. Anything
> individual in Perl is a scalar. By definition. Please don't try to
> change this.
>
> For more details on this, please read this email:
>
> http://www.mail-archive.co
At 04:58 PM 8/28/00 -0600, Doug Hunt wrote:
>What I meant to say (but failed, alas) was that I support the idea for a
>new perl variable type called compact array:
>
>$foo -- scalar
>@foo -- array
>%foo -- hash
>^foo -- compact array (or whatever notation)
This isn't really needed--a compact arra
Baris wrote:
>
> Hi,
> > ^foo = ([1, 2], [3, 4]); # I know, it's taken, I helped :-)
> > $foo[0,0];# uh-oh
> >
> >Then adding a new fundamental type and syntax is not only unnecessary,
> >but silly.
>
> Why do you think that individual elements are perl scalars?
To
Baris wrote:
> Hi,
> > ^foo = ([1, 2], [3, 4]); # I know, it's taken, I helped :-)
> > $foo[0,0];# uh-oh
> >
> >Then adding a new fundamental type and syntax is not only unnecessary,
> >but silly.
>
> Why do you think that individual elements are perl scalars? since w
Hi,
> ^foo = ([1, 2], [3, 4]); # I know, it's taken, I helped :-)
> $foo[0,0];# uh-oh
>
>Then adding a new fundamental type and syntax is not only unnecessary,
>but silly.
Why do you think that individual elements are perl scalars? since we don't keep
strings in pidd
Christian Soeller wrote:
> Jeremy Howard wrote:
>
> > Basically, I want to be able to create a list ref of list refs, specify
a
> > data type (eg 'int') and attributes of ':compact' or ':sparse', and have
the
>
> As Dan Sugalski suggested it seems not a good idea to bring in the list
> of list ref
Jeremy Howard wrote:
> Basically, I want to be able to create a list ref of list refs, specify a
> data type (eg 'int') and attributes of ':compact' or ':sparse', and have the
As Dan Sugalski suggested it seems not a good idea to bring in the list
of list ref into the proposal. Why does it have
Buddha Buck wrote:
> > I think the better way is to take Buddha's idea (soon to be RFC'ed, by
> > the sounds of it), and make current arrays a little more flexible. It
> > sounds like we'll just have to add an extra dimension somehow, and then
> > "arrays of compact arrays" will simply be "arrays
> I think the better way is to take Buddha's idea (soon to be RFC'ed, by
> the sounds of it), and make current arrays a little more flexible. It
> sounds like we'll just have to add an extra dimension somehow, and then
> "arrays of compact arrays" will simply be "arrays with some compact
> elemen
Christian Soeller wrote:
>
> The other problem with arrays is: how do we deal with functions that
> take multiple piddle arguments if they are arrays:
>
>@result = integrate @x, @y, @bounds;
>
> Won't those all be clumped into one big input array?
This should be overrideable by prototypes.
Doug Hunt wrote:
>
> What I meant to say (but failed, alas) was that I support the idea for a
> new perl variable type called compact array:
>
> $foo -- scalar
> @foo -- array
> %foo -- hash
> ^foo -- compact array (or whatever notation)
>
> Given this notation, you could have hashes of compa
> > ^foo -- compact array (or whatever notation)
>
> I seem to remember that ^ was in the process of being highjacked by some
> other RFC already. Was it higher-order functions?
Yes: RFC 23 (v4): Higher order functions
Damian
Doug Hunt wrote:
> What I meant to say (but failed, alas) was that I support the idea for a
> new perl variable type called compact array:
>
> $foo -- scalar
> @foo -- array
> %foo -- hash
> ^foo -- compact array (or whatever notation)
I seem to remember that ^ was in the process of being hig
Christian: You are right, it would not be best to confuse normal perl
lists with compact arrays--they both have their purposes and can be
combined usefully.
What I meant to say (but failed, alas) was that I support the idea for a
new perl variable type called compact array:
$foo -- scalar
@foo
Doug Hunt wrote:
> But I would like to speak up in support of Baris' idea. I have long
> found it
> confusing (both to myself and to those I must explain my code to) the
> mix of
> pdl multi-dimensional lists (lists of refs to lists) and PDLs, which
> appear to be scalars. I was even asked once
Karl, all: I have just been auditing this list so far ;)
But I would like to speak up in support of Baris' idea. I have long
found it
confusing (both to myself and to those I must explain my code to) the
mix of
pdl multi-dimensional lists (lists of refs to lists) and PDLs, which
appear to be sc
At 10:48 AM 8/28/00 -0400, Karl Glazebrook wrote:
>Using semicolons is an interesting idea. But consider:
>
>@a[10:20; 30:40];
>
>The ":"s and ";" are awfully hard to visually distinguish.
True, but @a[10..20; 30..40]; isn't hard to distinguish.
Even so, you might get such things as:
@a[10..20
Using semicolons is an interesting idea. But consider:
@a[10:20; 30:40];
The ":"s and ";" are awfully hard to visually distinguish.
c.f.
@a[10:20, 30:40];
What do people feel about the whole replacing ".." by ":"
issue?
Karl
Buddha Buck wrote:
>
> $matrix[$x,$y,$z] already has a reasonable meaning. If we
> appropriate that syntax, how do you take slices of a matrix?
My point too, only someone else pointed out that this is actually
@matrix[$x,$y,$z].
STILL, the fact that I've been hacking Perl since 4 and missed th
> Not being a PDL'er myself, but interested in learning more about it and
> making sure Perl 6 doesn't suck, I'd love to see a bulleted list of what
> doesn't work right, even assuming that @arrays were made more flexible.
> For example, if you could do this:
>
>@c = @a * @b;
>@c = @a +
Baris wrote:
>
> Suppose I am a newcomer to perl and my aim is to multiply two matrices
> and I don't really care about regex's or references in perl. Currently
> I have to learn a lot about perl language to begin working with matrix
> multiplication. This seems to me aginst the perl culture. I k
Hi Karl,
Thanks for your comments.
I still think it would be a good idea to have a new type for both functional and
promotional purposes. I know that Nathan Torkington answered that perl6 will support
the requirements of PDL but I am hoping that having a new type for multidimentional
arrays let
Karl Glazebrook wrote:
> The key from my point of view is to have enough syntactical
> hooks in the core so that using it is not like wading through
> treacle. Hence the PDL RFCs - especially on [] overloading and ranges.
>
> The Numerical Python people seem to have accomplished this, and we can
Nathan Torkington wrote:
>
> Karl Glazebrook writes:
> > I agree with your sentiments. Most people in PDL DO come from the
> > number crunching/scientific background.
>
> Whereas the rest of Perl users don't, and will probably never need the
> matrix manipulation stuff. I think a happy medium w
Karl Glazebrook writes:
> I agree with your sentiments. Most people in PDL DO come from the
> number crunching/scientific background.
Whereas the rest of Perl users don't, and will probably never need the
matrix manipulation stuff. I think a happy medium would be to provide
core support for oper
Hi Baris,
I agree with your sentiments. Most people in PDL DO come from the
number crunching/scientific background.
I would say that a matrix is just a special case of a general
N-dimensional compact array which obeys various rules. PDL
supplies a matrix-mult operator ("x") and other matrix ops
I am little bit confused and probably very ignorant but one thing seems to
me very useful. Why doesn't perl support a new data type matrix. If perl
wants to become a real "programming language" not just a scripting language
it should support number crunching internally in a more intuitive way. I
d
51 matches
Mail list logo
