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
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
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
This is a copy of the RFC I sent to the Librarian. I don't know when the
Librarian will publish it, but I don't want to wait any longer... We can
discuss it while he is compiling/classifying/publishing it.
--
=head1 TITLE
Proposed syntax for matrix element
Hello,
On 8/29/00 at 2:31 PM Jeremy Howard wrote:
>The role of this list is to try and create the features necessary to make
>Perl the best language for data crunching around, while keeping it
Perlish.
"Easy things should be easy".
PDL has a great and powerful built-in multidimentional support
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
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
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
Yes that is a good point, which I had forgotten about in my
concern over syntax.
Some guidance is needed about what the default passing is likely
to be in perl6.
Will
(@x,@y) = mysub @a, @b
implicitly pass by reference?
Karl
Christian Soeller wrote:
> In summary, I doubt that having PDLs b
You should have a look at the PDL RFC 117 before submitting this.
It would be bad to have multiple RFCs suggesting the same thing.
Much better to come to some agreement HERE on what the syntax
should be first, then submit consensus RFCs.
My view: I am pretty flexible I like most suggestions as
Dan Sugalski wrote:
> On the other hand, just extending out arrays to be multidimensional may
> well be good enough.
>
This is my view.
Karl
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
At 12:33 PM 8/29/00 -0400, Karl Glazebrook wrote:
>You should have a look at the PDL RFC 117 before submitting this.
>
>It would be bad to have multiple RFCs suggesting the same thing.
Nope, it wouldn't be.
Don't assume that any particular RFC will be accepted in its entirety
either--it's alwa
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
Dan Sugalski wrote:
> >It would be bad to have multiple RFCs suggesting the same thing.
>
> Nope, it wouldn't be.
>
> Don't assume that any particular RFC will be accepted in its entirety
> either--it's always possible that Larry'll take the good bits and leave the
> rest...
>
>
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
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
At 12:43 PM 8/29/00 -0400, Karl Glazebrook wrote:
>Dan Sugalski wrote:
>
> > >It would be bad to have multiple RFCs suggesting the same thing.
> >
> > Nope, it wouldn't be.
> >
> > Don't assume that any particular RFC will be accepted in its entirety
> > either--it's always possible that Larry'll
At 12:33 PM 8/29/00 -0400, Karl Glazebrook wrote:
>You should have a look at the PDL RFC 117 before submitting this.
>
>It would be bad to have multiple RFCs suggesting the same thing.
I just read PDL RFC 117, and your current argument with Dan aside...
I don't see a problem.
Here is the core
IMHO if the perl6 core only allow access to the parser, than a module can do just
about anything including all of those things proposed in RFC 115 - 117.
Maybe this is an over simplification, but it seems that if the statement:
use Python;
caused the subsequent source to go through my Python:
At 06:05 PM 8/29/00 +, Jim Edwards wrote:
>IMHO if the perl6 core only allow access to the parser, than a module can
>do just about anything including all of those things proposed in RFC 115 - 117.
That's sort of on the list of things to allow (I think Damian RFC'd it) but
whether it happe
>
>
> Regardless, you can already do this in perl 5, and will undoubtedly be able
> to do it in perl 6, with source filters.
So why do we have to do
$ip1=$i+1;# my pdl pet peave
$f->slice("(0),$ip1,$i");
instead of
$f((0),$i+1,$i); # substitute your favorite syntax
At 06:21 PM 8/29/00 +, Jim Edwards wrote:
> >
> >
> > Regardless, you can already do this in perl 5, and will undoubtedly be able
> > to do it in perl 6, with source filters.
>
>So why do we have to do
>$ip1=$i+1;# my pdl pet peave
>$f->slice("(0),$ip1,$i");
>
>instead
> "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
Aren't RFC 90 (zip/unzip) and RFC 148 (reshape) really the same?
Isn't reshaping the basic operation of interest?
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
I'm moving this to perl6-language-data
Bart Lateur wrote:
>
> On Tue, 29 Aug 2000 20:21:39 +0800, Kenneth Lee wrote:
>
> >oday this just came up to my mind, we could have a pragma that disable
> >`autovivification' of hash and array keys. Consider the follow code snippet:
> >
> > @arr = ( 0.
> 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?
if strongly typed bareword
Dan Sugalski wrote:
> >Meanwhile we all go rambling around on cross-threads and come up
> >with no coherent set of proposals.
>
> So? If the idea has merit, it'll make it into one or more RFCs, and Larry's
> rather good at making things coherent. If it just putters around for a
> while on the li
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
"David L. Nicol" wrote:
>
> > 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
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
Baris Sumengen wrote:
>
> Hello,
>
> On 8/29/00 at 2:31 PM Jeremy Howard wrote:
>
> >The role of this list is to try and create the features necessary to make
> >Perl the best language for data crunching around, while keeping it
> Perlish.
>
> "Easy things should be easy".
>
> For example to
Dan Sugalski wrote:
>
> Because source filters are:
>
> 1) Relatively new (5.005 IIRC, but I could be mis-remembering)
> 2) A bloody pain in the neck to write
>
> Lots of things could use 'em if they were easier to do. That's one of the
> goals of perl 6, I think.
>
Are there any docs in per
> Regardless, you can already do this in perl 5, and will undoubtedly
> be able to do it in perl 6, with source filters. (If Damian can
> write perl that looks like Latin or Klingon, then python ought to
> be simple... :)
I have a module (Language::Pythonesque) on that... :-)
Damian
Christian Soeller wrote:
> Dan Sugalski wrote:
>
> >
> > Because source filters are:
> >
> > 1) Relatively new (5.005 IIRC, but I could be mis-remembering)
> > 2) A bloody pain in the neck to write
> >
> > Lots of things could use 'em if they were easier to do. That's one of the
> > goals of perl
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:
> Aren't RFC 90 (zip/unzip) and RFC 148 (reshape) really the same?
>
Yes. RFC 148 can also partition (RFC 91). I've updated RFC 91 to also allow
a 3rd argument that gives a step size--I haven't checked whether reshape()
can do this. The updated RFCs 90 and 91 don't seem to hav
Damian Conway wrote:
>
>> Regardless, you can already do this in perl 5, and will undoubtedly
>> be able to do it in perl 6, with source filters. (If Damian can
>> write perl that looks like Latin or Klingon, then python ought to
>> be simple... :)
>
> I have a module (Language::
> Damian Conway wrote:
> >
> >> Regardless, you can already do this in perl 5, and will undoubtedly
> >> be able to do it in perl 6, with source filters. (If Damian can
> >> write perl that looks like Latin or Klingon, then python ought to
> >> be simple... :)
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
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
If you can no longer grow hashes or arrays on demand, does this
extend to strings not being able to get bigger, and to integers not
being able to become floats?
--tom
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
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
This RFC is a good start. Here's some thoughts on ways to decrease the
amount of new syntax and avoid the HOF ambiguity... Also, I suggest multiple
RFCs for the different ideas contained within.
Buddha Buck wrote:
> I propose the use of ';' as a separator for index terms when accessing
> multi-di
Jeremy Howard wrote:
>
> I prefer the syntax I suggested yesterday:
>
> $a[[$i,$j,$k]];
>
> which also allows multiple elements:
>
> $a[[$i,$j,$k], [$x,$y,$z]];
The problem I have with the above is how similar it is to this:
@a[$i,$j,$k];
A little too close for comfort, personally. Bu
Nathan Wiger wrote:
> And I'm assuming this only returns one element, right? Because if it
> returns a list it's not a $scalar. I think by this:
>
>$a[[$i,$j,$k], [$x,$y,$z]];
>
> You might actually mean this:
>
>@a[[$i,$j,$k], [$x,$y,$z]];
>
Yes, that's what I meant--sorry for the con
>but surely wouldn't warrant a new data type.
There is no relation between my proposal in this email for special 2-d
syntax and having a new type for pdl's.
Baris.
*** REPLY SEPARATOR ***
On 8/30/00 at 8:06 AM Christian Soeller wrote:
>Baris Sumengen wrote:
>>
>> Hello,
>>
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
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, 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
Tom Christiansen wrote:
>
> If you can no longer grow hashes or arrays on demand, does this
> extend to strings not being able to get bigger, and to integers not
> being able to become floats?
>
> --tom
Exactly. What do you think :closed should do, Tom?
--
David Ni
>Tom Christiansen wrote:
>>
>> If you can no longer grow hashes or arrays on demand, does this
>> extend to strings not being able to get bigger, and to integers not
>> being able to become floats?
>>
>> --tom
>Exactly. What do you think :closed should do, Tom?
Something more like old :ronly
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
Boy, there are a lot of people on that CC: list... Anyone want off
this ride?
Jeremy Howard said:
> This RFC is a good start. Here's some thoughts on ways to decrease the
> amount of new syntax and avoid the HOF ambiguity... Also, I suggest multiple
> RFCs for the different ideas contained with
> Builtins: merge() and demerge()
Still think C and C are cuter. :-)
And if we have to make up an antonym to C, let's choose C,
by analogy to C, C, C.
(And yes Tom, I *know* I'm advocating grafting a Germanic prefix to a
Latinate word and that "no good can come of it" ;-)
Damian
>Still think C and C are cuter. :-)
Except that that pair looks like "munge" and "emunge" (and probably
sounds like them too in certain accents :-), which are actually
synonyms of each other. :-(
--tom
> >Still think C and C are cuter. :-)
>
> Except that that pair looks like "munge" and "emunge"...
Not to mention "mail" and "email" ;-)
Damian
- Original Message -
From: "Perl6 RFC Librarian" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, August 29, 2000 10:06 PM
Subject: RFC 169 (v1) Proposed syntax for matrix element access and slicing.
> I propose the use of ';' as a separator for index te
This post attempts to consolidate and summarise my proposals which I hope
provides a platform for n-dim matrices/tensors. I have repeated parts of
earlier posts to avoid confusion--sorry for the redundancy. I've also fixed
some areas from earlier posts--hopefully the examples here are correct and
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Proposed syntax for matrix element access and slicing.
=head1 VERSION
Maintainer: Buddha Buck <[EMAIL PROTECTED]>
Date: 29 August 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 169
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Builtins: merge() and demerge()
=head1 VERSION
Maintainer: Jeremy Howard <[EMAIL PROTECTED]>
Date: 10 August 2000
Last modified: 29 August 2000
Mailing List: [EMAIL PROTECTED]
Version: 2
Number:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Builtin: part
=head1 VERSION
Maintainer: Jeremy Howard <[EMAIL PROTECTED]>
Date: 10 August 2000
Last Modified: 29 August 2000
Mailing List: [EMAIL PROTECTED]
Version: 2
Number: 91
Status: Deve
63 matches
Mail list logo
