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
> OK here is a basic question: how do we specify element access in
> PDL type arrays?
>
> $a[$i][$j][$k] or $a[$i,$j,$k]
Both of these already have firm meaning in Perl. The second one is used
to bite off selected elements of an array. So if you want a different
syntax you'll have to use some ot
[I am not subscribed to the perl6-language-data list, so I would appreciate
it if responses are CC'd to me.]
On Thu, Aug 24, 2000 at 08:45:50AM -0700, Nathan Wiger wrote:
> How is RFC 122 different from RFC 15? Seems like they accomplish a
> similar thing but RFC 15 is a much more Perlish approac
David Corbin wrote:
>
> "int" and "float", vary greatly per
> machine, though I believe ALL the numeric types can vary from one
> machine to another.
not _SPECIFYING_ just DECLARING.
I imagine we'd default to "use native" for the internals
of what the types meant, but "use java" would be one
Tom Christiansen wrote:
>
> >Tom Christiansen wrote:
>
> >> C type declarations are pretty universally despised.
>
> >By whom?
>
> >This is news to me. I have always thought that the C type declaration
> >is a concise and platform-independent way of declaring a packed
> >structure, and effect
Tom Christiansen wrote:
> printf "uid %d logged on from %s on %s.\n",
> $him->ut_uid, $him->ut_host, scalar local $him->ut_date;
>
>
Is ut_uid a scaler value here? It occured to me when I read this that it would
be nice to get rid of the distinction between
$him->{ut_uid}
$him->[ut
Here was my old demo/proposal, such as it was.
--tom
$buff = "\0" x rusage->sizeof();
syscall(&SYS_getrusage, &RUSAGE_SELF, $buff) && die "getrusage: $!";
$ru = rusage->new_from_buffer($buff);
# or
$ru = rusage->new();
$ru->unpack($buff);
# or
@fields = rusage->unp
>Tom Christiansen wrote:
>> C type declarations are pretty universally despised.
>By whom?
>This is news to me. I have always thought that the C type declaration
>is a concise and platform-independent way of declaring a packed
>structure, and effectively hiding implementation details (offsets
>The existing pack and unpack methods depend upon a simple
>grammar which leads to opaque format specifications,
Well, can lead. "f c4" is easy, but the big ones aren't.
>which are
>often difficult to get right, and which carry no information
>regarding variable names.
>A more descriptive gra
Tom Christiansen wrote:
> C type declarations are pretty universally despised.
By whom?
This is news to me. I have always thought that the C type declaration
is a concise and platform-independent way of declaring a packed
structure, and effectively hiding implementation details (offsets into i
Ssshh don't mention RFC 109!
To give some background:
RFC 109 comes from me, and caused some "interesting" debate on
perl6-language. It's not that relevant to PDL.
RFC 115-117 are key RFCs from the PDL-Porters - things we really
want to see to make Perl better for numerics. These are the
main
=head1 TITLE
Default methods for objects
=head1 VERSION
Maintainer: pdl-porters team <[EMAIL PROTECTED]>
Date: 16 August 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 115
=head1 ABSTRACT
This RFC proposes syntactic support for default methods
that can be defined for blesse
=head1 TITLE
Enhanced Pack/Unpack
=head1 VERSION
Maintainer: Edwin Wiles <[EMAIL PROTECTED]>
Date: 22 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 142
=head1 ABSTRACT
Pack and Unpack are percieved as being difficult to use, and
possibly missing desirable featu
=head1 TITLE
Perl syntax support for ranges
=head1 VERSION
Maintainer: pdl-porters team <[EMAIL PROTECTED]>
Date: 16 August 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 117
=head1 ABSTRACT
This RFC proposes syntactic support for ranges. Range objects
would be especially u
=head1 TITLE
Efficient numerics with perl
=head1 VERSION
Maintainer: pdl-porters team <[EMAIL PROTECTED]>
Date: 16 August 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 116
=head1 ABSTRACT
This RFC describes basic requirements of a numerical object/variable
type for perl. A
=head1 TITLE
Default methods for objects
=head1 VERSION
Maintainer: pdl-porters team <[EMAIL PROTECTED]>
Date: 16 August 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 115
=head1 ABSTRACT
This RFC proposes syntactic support for default methods
that can be defined for blesse
=head1 TITLE
Less line noise - let's get rid of @%
=head1 VERSION
Maintainer: Karl Glazebrook <[EMAIL PROTECTED]>
Date: 15 August 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 109
=head1 ABSTRACT
This RFC proposes that C<$x>, C<@x>, and C<%x> be ditched and
replaced with C
=head1 TITLE
Apply operators component-wise in a list context
=head1 VERSION
Maintainer: Jeremy Howard <[EMAIL PROTECTED]>
Created: 10 August 2000
Last modified: 16 August 2000
Version: 2
Mailing List: [EMAIL PROTECTED]
Number: 82
=head1 ABSTRACT
It is proposed that in a list cont
=head1 TITLE
Standardise Handling Of Abnormal Numbers Like Infinities And NaNs
=head1 VERSION
Maintainer: Jarkko Hietaniemi <[EMAIL PROTECTED]>
Date: 05 Aug 2000
Version: 2
Mailing List: [EMAIL PROTECTED]
Number: 38
=head1 ABSTRACT
The handling of various abnormal numeric entities l
According to the ( very quickly hacked together ) RFC searcher I wrote, the
following RFC's have mention to PDL:
RFC number 38 matches 1 time(s):http://dev.perl.org/rfc/38.pod
RFC number 82 matches 1 time(s):http://dev.perl.org/rfc/82.pod
RFC number 109 matches 4 time(s): ht
>We adopt C base types, and C structure syntax.
THE HORROR! THE HORROR!
C type declarations are pretty universally despised. And why
do you want to get so unnaturally chummy with the machine? That
seems pretty hamstringly.
In Class::Struct there's already a more perlish way of doing
"struct
There is already a reshape() in PDL.
Obviously that only applies to PDL arrays.
But if PDL style arrays get in to the core, then that sort of
functionality ought to arise.
OK here is a basic question: how do we specify element access in
PDL type arrays?
$a[$i][$j][$k] or $a[$i,$j,$k]
Most nu
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Add reshape() for multi-dimensional array reshaping
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 24 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 148
Sta
How is RFC 122 different from RFC 15? Seems like they accomplish a
similar thing but RFC 15 is a much more Perlish approach. The problem
with RFC 15 is that it's titled "stronger typing though tie", which
implies that tie should be used, but it probably shouldn't be.
As to the struct syntax, I be
Someone said:
> Um, to clarify... While I'm here, I'm mostly a lurker and learner.
> If you don't here from me, that's because I'm watching, not talking.
I'm here because:
* I think the PDL folks have valid needs
* I think a lot of people are having trouble making suggestions for
language c
ad1 TITLE
types and structures
=head1 VERSION
Maintainer: David Nicol <[EMAIL PROTECTED]>
Date: 17 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 122
=head1 ABSTRACT
We adopt C base types, and C structure syntax.
=head1 DESCRIPTION
the C programming language has a
Karl Glazebrook writes:
: Who is here anyway?
Don't ask me. I only work here.
Larry
On Thu, Aug 24, 2000 at 10:04:27AM -0400, Buddha Buck wrote:
> At 10:00 AM 8/24/00 -0400, Buddha Buck wrote:
> >At 09:53 AM 8/24/00 -0400, Karl Glazebrook wrote:
> >
> >>Well the PDL RFCs seem to have been totally ignored on perl6-language.
> >>
> >>Maybe we should discuss them here, come to some
Casey R. Tweten writes:
> Who is the chair of this group? We need an RFC or two to work on.
The chair is Jeremy Howard <[EMAIL PROTECTED]>. See dev.perl.org/lists
for a master list of all mailing lists.
All RFCs are available on dev.perl.org/rfc/, including several that
are appropriate for -da
Today around 8:13am, Larry Wall hammered out this masterpiece:
: Karl Glazebrook writes:
: : Who is here anyway?
:
: Don't ask me. I only work here.
Who is the chair of this group? We need an RFC or two to work on.
--
print(join(' ', qw(Casey R. Tweten)));my $sig={mail=>'[EMAIL PROTECTED]',
At 09:53 AM 8/24/00 -0400, Karl Glazebrook wrote:
>Well the PDL RFCs seem to have been totally ignored on perl6-language.
I think it's more that most of the -language folks don't have much
familiarity with PDL or fancier math in general.
>Maybe we should discuss them here, come to some conclus
Christian can you repost them here then?
Karl
Buddha Buck wrote:
> I'm here... I thought the formation of perl6-language-data was to discuss
> the PDL RFCs anyway...
>
> >Karl
At 10:00 AM 8/24/00 -0400, Buddha Buck wrote:
>At 09:53 AM 8/24/00 -0400, Karl Glazebrook wrote:
>
>>Well the PDL RFCs seem to have been totally ignored on perl6-language.
>>
>>Maybe we should discuss them here, come to some conclusions and
>>present them with a fait accompli. "These are the recom
Today around 10:00am, Buddha Buck hammered out this masterpiece:
: At 09:53 AM 8/24/00 -0400, Karl Glazebrook wrote:
: >Well the PDL RFCs seem to have been totally ignored on perl6-language.
: >
: >Maybe we should discuss them here, come to some conclusions and
: >present them with a fait accompl
At 09:53 AM 8/24/00 -0400, Karl Glazebrook wrote:
>Well the PDL RFCs seem to have been totally ignored on perl6-language.
>
>Maybe we should discuss them here, come to some conclusions and
>present them with a fait accompli. "These are the recommendations
>of perl6-data".
>
>Who is here anyway?
Well the PDL RFCs seem to have been totally ignored on perl6-language.
Maybe we should discuss them here, come to some conclusions and
present them with a fait accompli. "These are the recommendations
of perl6-data".
Who is here anyway?
Karl
36 matches
Mail list logo
