Re^2: perl bit matrix transposition / weak typing problem

Yes, my mistake on the transpose function with no return value. I have updated it correctly. I had trimmed it down to avoid warlording and posting a million lines of irrelevant code, and inadvertently chopped the return line as well :)

Anyway, the pack/unpack method above converts to a bitstring, then back again, does it not? Using a sequence of ascii '1's and '0's was precisely what I was trying to avoid... and I *know* perl can accomplish this task in that way. But, that method increases the memory requirements of the implementation eight-fold, adds internal conversion overhead, and doesn't fall into the design requirements of the original question :>

I hope this isn't misconstrued, but remember, this function has to transpose *every* $BUFSIZE bytes, and quickly, with low memory requirements, to be able to sit at the position in the protocol stack that it does.

Thanks,
Jason

Comment on Re^2: perl bit matrix transposition / weak typing problem

Replies are listed 'Best First'.
Re^3: perl bit matrix transposition / weak typing problem by ysth (Canon) on Dec 13, 2004 at 12:31 UTC
I'm not sure what you are saying; does your original example work for you but is not fast enough? I see you have `return $out` now, but I don't see you setting $out. Update: I reread your original post and now see where you talk about trying to avoid the very kind of approach you present there. But I don't see where the trampling you describe comes into it. Do see BrowserUk's suggestion of using vec, which is perl's builtin way of dealing with data by bits without conversion.	[reply] [d/l]
Re^4: perl bit matrix transposition / weak typing problem by infi (Acolyte) on Dec 13, 2004 at 13:16 UTC
Well, $out is getting set by: `for my $col (0..($BUFSIZE-1)) { $out[$newrow] \|= (1 << $col) if ($in[7 - $col] >> $row & 1); } $newrow++;` [download] This is setting the actual bit in $out[$newrow] if the corresponding bit from the transposition source matrix is set. At any rate, BrowserUk's solution appears to be ideal and small, and exactly fits the requirements; the lack of thorough awareness of the vec() function made this difficult at best. In addition, it makes possible arbitrary matrix sizes, which solved another challenge I had thought of but didn't mention in the original post. Thanks, Jason	[reply] [d/l]