[comp.lang.perl] vec

stergios@portia.Stanford.EDU (stergios marinopoulos) (08/11/90)

can someone explain the behavior of vec to me?  I've been playing with
the example below, followed by its output.  I understand the first
line of output when the offset is 0; the value printed is from the
i-th bit to the first..  When I give a nonzero offset, however, I dont
quite understand whats happening.  What is the offset applied to, the
string or the bitfield?

thanks

sm

**********************************************************************

$string = sprintf ("%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c", 
		   255,255,255,255, 255,255,255,255,
		   255,255,255,255, 255,255,255,255 );

foreach $j (0,1,2,3) {
	for($i=1 ; $i <= 8 ; $i++) { 
		printf "%5d ", vec($string,$j,$i) ;
	}	
		print "\n" ;
}

**********************************************************************
    1     3     7    15    31    63   127   255
    1     3     7    15     7     3     1   255
    1     3     3    15    31    15     3   255
    1     3     7    15     1    63     7   255
**********************************************************************

stergios@portia.Stanford.EDU (stergios marinopoulos) (08/11/90)

can someone explain the behavior of vec to me?  I've been playing with
the example below, followed by its outpet.  I understand the first
line of output when the offset is 0; the value printed is from the
i-th bit to the first..  When I give a nonzero offset, however, I dont
quite understand whats happening.  What is the offset applied to, the
string or the bitfield?

thanks

sm

**********************************************************************

$string = sprintf ("%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c", 
		   255,255,255,255, 255,255,255,255,
		   255,255,255,255, 255,255,255,255 );

foreach $j (0,1,2,3) {
	for($i=1 ; $i <= 8 ; $i++) { 
		printf "%5d ", vec($string,$j,$i) ;
	}	
		print "\n" ;
}

**********************************************************************
    1     3     7    15    31    63   127   255
    1     3     7    15     7     3     1   255
    1     3     3    15    31    15     3   255
    1     3     7    15     1    63     7   255
**********************************************************************

lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) (08/11/90)

In article <STERGIOS.90Aug10120735@sunsweet.Stanford.EDU> stergios@jessica.stanford.edu writes:
: 
: can someone explain the behavior of vec to me?  I've been playing with
: the example below, followed by its output.  I understand the first
: line of output when the offset is 0; the value printed is from the
: i-th bit to the first..  When I give a nonzero offset, however, I dont
: quite understand whats happening.  What is the offset applied to, the
: string or the bitfield?
: 
: thanks
: 
: sm
: 
: **********************************************************************
: 
: $string = sprintf ("%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c", 
: 		   255,255,255,255, 255,255,255,255,
: 		   255,255,255,255, 255,255,255,255 );

A little easier to write "\377" x 16, by the way, and it computes it
at compile time...

: foreach $j (0,1,2,3) {
: 	for($i=1 ; $i <= 8 ; $i++) { 
: 		printf "%5d ", vec($string,$j,$i) ;
: 	}	
: 		print "\n" ;
: }
: 
: **********************************************************************
:     1     3     7    15    31    63   127   255
:     1     3     7    15     7     3     1   255
:     1     3     3    15    31    15     3   255
:     1     3     7    15     1    63     7   255
: **********************************************************************

What's going on here is only the values 1, 2, 4 and 8 are documented
to be valid as the 3rd argument of vec.  The other values happen
to work when the offset is 0 because the bitfield doesn't cross a byte
boundary.  The code doesn't attempt to decode bitfields across byte
boundaries because the situation never arises if the number of bits is
a power of 2.

Larry

bagchi@eecs.umich.edu (Ranjan Bagchi) (06/20/91)

	I'd been needing to see the bits of 32-bit ints on
a Sparc.  I hadn't been having much luck, so I tried the following
script: 

#!/usr/bin/perl --
for (1,2,4,8,16,32) {
    $word = "\0" x 32;
    print "BITS = ",$_,":\n";
    vec($word,0,$_) = 1;
    print unpack("b32",$word),"\n";
    print "1234567890" x 4;
    print "\n";
}

__END__
gives: 
BITS = 1:
10000000000000000000000000000000
1234567890123456789012345678901234567890
BITS = 2:
10000000000000000000000000000000
1234567890123456789012345678901234567890
BITS = 4:
10000000000000000000000000000000
1234567890123456789012345678901234567890
BITS = 8:
10000000000000000000000000000000
1234567890123456789012345678901234567890
BITS = 16:
00000000100000000000000000000000
1234567890123456789012345678901234567890
BITS = 32:
00000000000000000000000010000000
1234567890123456789012345678901234567890

but shouldn't it be:
BITS = 1:
10000000000000000000000000000000
1234567890123456789012345678901234567890
BITS = 2:
10000000000000000000000000000000
1234567890123456789012345678901234567890
BITS = 4:
10000000000000000000000000000000
1234567890123456789012345678901234567890
BITS = 8:
10000000000000000000000000000000
1234567890123456789012345678901234567890
BITS = 16:
10000000000000000000000000000000
1234567890123456789012345678901234567890
BITS = 32:
10000000000000000000000000000000
1234567890123456789012345678901234567890

perl -version gves me:
This is perl, version 4.0

$RCSfile: perl.c,v $$Revision: 4.0.1.1 $$Date: 91/04/11 17:49:05 $
Patch level: 3

Copyright (c) 1989, 1990, 1991, Larry Wall

Perl may be copied only under the terms of the GNU General Public License,
a copy of which can be found with the Perl 4.0 distribution kit.

Can anyone explain this? 
 
	-rj
--
--------------------------------------------------------------------------------
Ranjan Bagchi - asleep......  |    v,i,j,k,l,s,a[99];
bagchi@eecs.umich.edu         |    main()   {
-------------------------------       for(scanf("%d",&s);*a-s;v=a[j*=v]-a[i],k=i<s,j+=(v=j<s&&(!k&&!!printf(2+"\n\n%c"-(!l<<!j)," #Q"[l^v?(l^j)&1:2])&&++l||a[i]<s&&v&&v-i+j&&v+i-j))&&!(l%=s),v||(i==j?a[i+=k]=0:++a[i])>=s*k&&++a[--i]) ;
					}  /* Osovlanski and Nissenbaum */
--------------------------------------------------------------------------------