Re: Some PDL issues (was Re: Test)
At 12:38 PM 8/25/00 -0600, Nathan Torkington wrote: Dan Sugalski writes: The operative word in that last sentence is "Currently"... The problem is that you can tie() an array, but an object is a scalar. Also, there are many array operations (push, pop, etc) still not supported by tie. tie makes assumptions about arrays that are perhaps not valid with pdls. Tie will have a more comprehensive implementation in perl 6, I expect. And it may not be the method used to do this magic. (variable vtable functions should be writable in perl) Yes, but you're handwaving. If we don't come up with a way to address these issues by saying "this is what we want to be possible, this is how it might be done", this list will just spin and talk and discuss and debate without any idea of when it's done. Sure, it's handwaving, but it's handwaving with a purpose. What I don't want is for people to get bogged down by the limits of what perl 5 provides, or what looks to be some sort of reasonable extrapolation of those features. If a fully working tie's what you need, then ask for it. If full overloading on non-objects is what you need, then ask for it. If making objects look like non-objects is what you need, then ask for it. Basically if you want to be able to say: my Matrix @foo, @bar, @baz : bounds(5,5,5); # init foo and bar here @baz = @foo * @bar; to make foo and bar 5x5x5 matricies that you casn multiply to get baz then, well, say it. If that means you need to define a way to provide overridden operators in the Matrix package, then go for it and say that. Let the -internals folks worry about the Weird Magic needed to implement what you want. (This is a variation of my standard "Don't get hung up on the implementation, that's my job" speech) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Some PDL issues (was Re: Test)
Dan Sugalski writes: Sure, it's handwaving, but it's handwaving with a purpose. What I don't want is for people to get bogged down by the limits of what perl 5 provides, or what looks to be some sort of reasonable extrapolation of those features. If a fully working tie's what you need, then ask for it. If full overloading on non-objects is what you need, then ask for it. If making objects look like non-objects is what you need, then ask for it. Heh, we're on the same page here. I'm just setting the framework for that discussion. I don't think the PDL folks yet know what they want, other than "better support for numerical structures". I'm trying to see what's wrong with the existing systems so that we can either fix them or replace them. Walking before we run, etc. Relax, I'm not trying to base the discussion around perl5's shortcomings. I just want to try and understand the problems and possible directions. Nat
Re: Some PDL issues (was Re: Test)
Tom Christiansen writes: Also, there are many array operations (push, pop, etc) still not supported by tie. Eh? Either that's no longer true, or we're doing the time warp again. Right you are. I'm still living in the 20th century :-) Nat
Re: Some PDL issues (was Re: Test)
Right you are. I'm still living in the 20th century :-) So are all of us -- just give it a few months, though. :-) --tom
Re: Some PDL issues (was Re: Test)
Nathan Torkington wrote:
(1) The current
$pdl-slice("0:$n,(0)");
syntax sucks.
Would:
$pdl-[0:$n][0][:]
suffice? I figure this would translate into something like:
$pdl-subscript( 0, $n )
-subscript( 0 )
-subscript( undef, undef )
That is, you can overload [] on objects but instead of being @{}
as it currently is (where your overload sub returns an array ref)
you get to handle the subscript operation yourself.
Some comments:
"-" really sucks as something to routinely type in to a interactive shell
all the time. I hate it.
$pdl[0:$n][0][:]
would be fine as a syntax
BUT we really want the subscription operation to be fast and efficient -
which means doing it with one subroutine call not 3. This is where the
$pdl[0:$n,0,:] form wins as you can imaging the subroutine just seeing
"0:$n,0,:" in one arg.
Also another common idiom in PDL is:
$pdl[0:$n,(0),:]
where the () means - lose this dimension of size unity. I.e. make the result
MxN rather than Mx1xN. How would this be handled?
(2) We see the need for a multidimensional, packed and typed array.
The question is: should such an array type be part of perl6 or should it
be left to a module to implement such types?
I vote module.
I guess having true multidim arrays in the core would lead to a [a,b,c[
slicing syntax.
Karl
Re: Some PDL issues (was Re: Test)
At 01:11 PM 8/25/00 -0600, Nathan Torkington wrote: Heh, we're on the same page here. I'm just setting the framework for that discussion. I don't think the PDL folks yet know what they want, other than "better support for numerical structures". I'm trying to see what's wrong with the existing systems so that we can either fix them or replace them. Walking before we run, etc. Gotcha. Different approaches and all, I expect. I tend to figure out what I want and then try and shoehorn it into what I already have. :) It looks like we need to be able to override operations on arrays, have multi-dimensional arrays, and do some rather odd slicing operations that give values still linked to the original matrices. Has anyone asked for complex number support yet? Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Some PDL issues (was Re: Test)
Dan Sugalski wrote: to make foo and bar 5x5x5 matricies that you casn multiply to get baz then, well, say it. If that means you need to define a way to provide overridden operators in the Matrix package, then go for it and say that. Let the -internals folks worry about the Weird Magic needed to implement what you want. (This is a variation of my standard "Don't get hung up on the implementation, that's my job" speech) Although there is one point that is crucial in a useful implementation -- packed and typed for the reasons I mentioned before. Since we are on language-data speed and efficiency on large chunks of data is essential and can not be completely left to druids/wizards and their weird magic ;) Christian
