comp.lang.ada
 help / color / mirror / Atom feed
From: mark_lundquist@my-deja.com
Subject: Re: bitstreams
Date: Mon, 15 Jan 2001 19:56:23 GMT
Date: 2001-01-15T19:56:23+00:00	[thread overview]
Message-ID: <93vkl3$1j$1@nnrp1.deja.com> (raw)
In-Reply-To: 3A622CE5.89C9378E@worldnet.att.net

In article <3A622CE5.89C9378E@worldnet.att.net>,
  srini <r.srinivasan@worldnet.att.net> wrote:
>
> I do not know much about mp3 etc but I have developed a bit stream
> package which allows you to perform reads in terms of bits. I use
these
> in my own compression/decompression test software. The spec is
attached.

> ----------------------------------------------------------------------
> package Bits_Io is
>
>    type File_Type is limited private;
>    type File_Mode is (In_File, Out_File, Append_File);
>
>    type Vector_type is array (natural range <>) of boolean ;
>    pragma pack( Vector_Type ) ;
.
.
.

Beware, though... this is implementation-dependent. If the compiler
doesn't represent a packed array of boolean as a bit vector, it doesn't
work.

The package is called Bits_Io, why not define a proper type Bit and
then define Bit_Vector in terms of that?  Is Boolean used so that you
can be able to have the logical operations on arrays of Boolean?  Note
that the rationale for including that feature in Ada was in order to
implement sets efficiently (I think that goes back to Steelman).  So
the idea of "and" on Boolean arrays in Ada is not the idea of a
bitmask, it's the idea of a set intersection.

To me, it's confusing whenever Boolean is used for something other than
truth value.

A couple of thoughts for the original poster...

Bitstream is probably the wrong abstraction for all but a small handful
of applications... specifically, compression and encryption, where you
are going to do math on the bits but you have no awareness of the bits
_representing_ something.  MP3 is an application where you most
certainly *do* care what the bits represent!  So while it may lay on
the disk as a sequence of bits (as does everything else), that seems
irrelevant because you must immediately cease dealing with it as
snippets of bits as soon as you get your hands on the snippets.  You
want the interpretation to be immediate, you don't want to have to be
involved in dealing with the bits.

You can desperately say, "if only I can just get my hands on the bits,
then I can shift/mask/unchecked-convert my way to the answer", but you
probably won't end up with a very good program.

What you probably want to do is declare types for all the fields in the
MP3 format, then define the Stream attributes for those types.

Mark Lundquist



Sent via Deja.com
http://www.deja.com/



  reply	other threads:[~2001-01-15 19:56 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-01-14 14:47 bitstreams Daniel Nilsson
2001-01-14 15:10 ` bitstreams Larry Kilgallen
2001-01-14 16:15 ` bitstreams tmoran
2001-01-14 19:46 ` bitstreams srini
2001-01-15 19:56   ` mark_lundquist [this message]
2001-01-15 21:54     ` bitstreams Tucker Taft
2001-01-16  0:41       ` bitstreams Robert Dewar
2001-01-16  0:39     ` bitstreams Robert Dewar
2001-01-16 23:26       ` bitstreams Rajagopalan Srinivasan
2001-01-15 19:21 ` bitstreams mark_lundquist
2001-01-15 20:43   ` bitstreams Pat Rogers
2001-01-15 21:15     ` bitstreams mark_lundquist
2001-01-16  0:59   ` bitstreams Robert Dewar
2001-01-16 17:36     ` bitstreams mark_lundquist
2001-01-16 20:08       ` bitstreams Pat Rogers
2001-01-17  2:15         ` bitstreams Robert Dewar
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox