Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Writing single bits to a file

Reply
Thread Tools

Writing single bits to a file

 
 
Charlie Gordon
Guest
Posts: n/a
 
      10-29-2007
"Charlie Gordon" <(E-Mail Removed)> a écrit dans le message de news:
4725f246$0$6594$(E-Mail Removed)...
> "cr88192" <(E-Mail Removed)> a écrit dans le message de news:
> 3e9c2$4725ebe1$ca8010a3$(E-Mail Removed)...
>>
>> "Keith Thompson" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)...
>>> "cr88192" <(E-Mail Removed)> writes:
>>>> "Charlie Gordon" <(E-Mail Removed)> wrote in message
>>>> news:472541c8$0$14483$(E-Mail Removed)...
>>> [...]
>>>>> for exponentiation, I would suggest you do use ** as in Fortran. It
>>>>> is not ambiguous because a ** b has no meaning for b scalar or
>>>>> struct type. You would need to bend the grammar a bit, but at least
>>>>> the precedence would be much better suited than that of ^
>>>>
>>>> I had a '**' operator at one time before, but it kept clashing with
>>>> pointers handling. as a result, if it existed, it would have to be
>>>> parsed specially, and have rules to avoid accidentally mis-parsing a
>>>> pointer operation:
>>>> "i**s++", where the intention was actually "i*(*s++)". provably
>>>> disambiguating this would require more info than the parser has
>>>> available (the only real option would be, for example, requiring
>>>> spaces...).
>>>>
>>>> 'a^.b' could be another option (where '^.', is given a high rather
>>>> than a low precedence).
>>> [...]
>>>
>>> "**" can be unambiguous if you allow parsing to be affected by
>>> semantic analysis. But typically the source is tokenized before it's
>>> parsed and analyzed (even though all these things theoretically happen
>>> in translation phase 7). If you see ``x**y'', you can't tell whether
>>> it's ``x ** y'' (an exponentiation) or ``x * *y'' without knowing the
>>> type of y.

>>
>> knowing the type of y is the problem, though theoretically it could be
>> handled by parse-tree tweaking, if I had the parse tree at the same point
>> I was doing type handling (in my compiler, I do not, since these are
>> handled as different stages).
>>
>> a later frontend may also make type info available in more of the upper
>> compiler, such that such inferences can be made...

>
> Probably your best option.
>
>>> I can imagine ways to tweak the grammar, perhaps requiring white space
>>> between a binary "*" operator and a unary "*" operator, but I wouldn't
>>> recommend it; the result would be incompatible with C. And any such
>>> solution would be complicated to define and to implement, and
>>> therefore complicated to use in at least some cases.

>>
>> yeah, I considered, but did not accept these ideas...
>> it matters to me that compatibility not be broken.

>
> Wise choice.
>
>>> You might consider ^^ as an exponentiation operator. It's not likely
>>> that a future C standard will introduce a short-circuit xor operator.

>>
>> however, I may at some point add such an operator (after all, my last
>> script language had such an operator...).

>
> short circuit xor does not get much usage IMHO.
>
>> '^.' still seems like a better option IMO, since it resembles '^', but is
>> a different operator...
>> (I can just make it have a very different precedence than '^').
>>
>> ok, this drops the precedence-similarity idea (if the new operators have
>> different precedences than the old ones they resemble).
>>
>> '&.', '|.', and '^.' might be made tightly binding (slightly more tightly
>> than '*' and '/').
>> '*.' and '/.' will be the same as '*' and '/'.
>> '+.' and '-.' will be the same as '+' and '-'.
>>
>> '*.' could thus be an alternative for dot product, and maybe an
>> additional multiply form (is some other cases).
>> '/.' could be used for a 'reverse divide' for types with non-communitive
>> multiplication and division (such as quaternions, which currently use a
>> builtin function for this). potentially, it could also serve as a
>> shorthand for dividing ints and getting a float (aka: cast-free).

>
> No, these tokens are really problematic. I pointed at ``1.^2'' that would
> become ambiguous if you attach semantics to ^ for floating point values
> (as you may have), as is unequivically parsed as 1. ^ 2. ; at least the
> .^ and more generally . prefixed arithmetic operators you are considering
> would not cause incompatibilities with current C syntax, just parsing
> surprises for programmers trying to use your extensions. Adding tokens
> with a trailing . do create incompatibilites with the current C syntax as
> it would cause legitimate expressions to be parsed differently. Consider
> these:
>
> .5==x^.5==y // x equals 0.5 or y equals 0.5 but not both.
> .8<x&.9>x
> 1.1==x|.9==y
> x/.1
> y*.2
> z-.2
> ...
>
> I always put around binary operators but a lot of programmers don't.


I always put *spaces* around binary operators but a lot of programmers
don't.

--
Chqrlie.


 
Reply With Quote
 
 
 
 
Kenneth Brody
Guest
Posts: n/a
 
      10-29-2007
Eric Sosman wrote:
[...]
> gets worse: Some of the best compressors encode their output
> in fractions of bits; if a file length of 10007 bits is bad,
> a length of 10006.59029663+ bits is *really* bad!

[...]

I've never heard of that. What's a fraction of a bit? Is it
something that needs to hold less than two states?

What would you call those states? "True" and "Fal"?

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <(E-Mail Removed)>


 
Reply With Quote
 
 
 
 
Ben Bacarisse
Guest
Posts: n/a
 
      10-29-2007
"Charlie Gordon" <(E-Mail Removed)> writes:
<snip>
>> I always put around binary operators but a lot of programmers don't.

>
> I always put *spaces* around binary operators but a lot of programmers
> don't.


I found your original version delightfully self-referential -- to the
point where if you had written "I put around operators but many put."
I would have though it deliberate!

--
Ben.
 
Reply With Quote
 
Walter Roberson
Guest
Posts: n/a
 
      10-29-2007
In article <(E-Mail Removed)>,
Kenneth Brody <(E-Mail Removed)> wrote:
>Eric Sosman wrote:


>> gets worse: Some of the best compressors encode their output
>> in fractions of bits; if a file length of 10007 bits is bad,
>> a length of 10006.59029663+ bits is *really* bad!


>I've never heard of that. What's a fraction of a bit? Is it
>something that needs to hold less than two states?


[OT]

See "Arithmetic encoding".
http://en.wikipedia.org/wiki/Arithmetic_coding
--
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      10-29-2007
"Charlie Gordon" <(E-Mail Removed)> writes:
[...]
> Of course, I'm not proposing ** to be a token, but x * *y to be
> reinterpreted as fexp(x, y) if y is a numeric type. This trick can be
> played on the parse tree if you have one, at code generation time, or on the
> fly if you generate code directly. The programmer would be more inclined to
> write x ** y or x**y, but it is parsed as x * *y. This trick would be more
> difficult to play in an interpreter with dynamic typing, but still possible,
> by sticking the appropriate behaviour to fexp(x, y) for y pointer type.

[...]

My gut reaction to this idea is: Ick.

If I were designing a new language with a "**" operator, I'd just make
"**" a token. If "*" is also a unary operator, then "x * *y" would
require a space. The kind of special-case treatment you suggest is,
in my opinion, just too convoluted.

I like the way tokenization and analysis are separated in C. It makes
the language easier to implement and, more importantly, easier to
describe. A more complicated definition might allow "x+++++y" to be
legal, but at the cost of creating odd corner cases that couldn't be
resolved without detailed analysis of the standard.

And if you're adding extensions to the language, it's not unlikely
that you'd eventually want to add operator overloading. How do you
overload "**" if it' a composite of "*" and "*", and how do you
interpret "x**y" if either interpretation could be correct?

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      10-29-2007
"cr88192" <(E-Mail Removed)> writes:
> "Keith Thompson" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...

[...]
>> You might consider ^^ as an exponentiation operator. It's not likely
>> that a future C standard will introduce a short-circuit xor operator.

>
> however, I may at some point add such an operator (after all, my last
> script language had such an operator...).


Um, a short-circuit xor operator is logically impossible; you have to
know the values of both operands to determine the result.

On the other hand, a logical xor might make sense (it would yield 0 or
1 rather than the bitwise result), and "^^" would be a sensible symbol
for it.

Objective-C, if i recall correctly, uses the "@" character for all its
extensions to C, which avoids any incompatibilities. You might
consider a similar approach. For example, you might make "@**" a
token and use it as an exponentiation operator.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
=?iso-2022-kr?q?=1B=24=29CHarald_van_D=0E=29=26=0Fk?=
Guest
Posts: n/a
 
      10-29-2007
On Mon, 29 Oct 2007 15:06:56 +1000, cr88192 wrote:
> I had a '**' operator at one time before, but it kept clashing with
> pointers handling. as a result, if it existed, it would have to be
> parsed specially, and have rules to avoid accidentally mis-parsing a
> pointer operation: "i**s++", where the intention was actually
> "i*(*s++)". provably disambiguating this would require more info than
> the parser has available (the only real option would be, for example,
> requiring spaces...).


Wouldn't you be able to define the ** operator as either accepting two
arithmetic types, or accepting an arithmetic left operand and a pointer
right operand? This would mean you could write a * *p to mean a * (*p),
but not to mean pow(a, p), and that you could write a**b to mean either
a * (*b) or pow(a, b). Additionally, it would mean you don't have parsing
problems: a**b is always two operands for one operator, regardless of
whether this operator performs one operation or two.
 
Reply With Quote
 
cr88192
Guest
Posts: n/a
 
      10-29-2007

"Charlie Gordon" <(E-Mail Removed)> wrote in message
news:4725f246$0$6594$(E-Mail Removed)...
> "cr88192" <(E-Mail Removed)> a écrit dans le message de news:
> 3e9c2$4725ebe1$ca8010a3$(E-Mail Removed)...
>>
>> "Keith Thompson" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)...
>>> "cr88192" <(E-Mail Removed)> writes:
>>>> "Charlie Gordon" <(E-Mail Removed)> wrote in message
>>>> news:472541c8$0$14483$(E-Mail Removed)...
>>> [...]
>>>>> for exponentiation, I would suggest you do use ** as in Fortran. It
>>>>> is not ambiguous because a ** b has no meaning for b scalar or
>>>>> struct type. You would need to bend the grammar a bit, but at least
>>>>> the precedence would be much better suited than that of ^
>>>>
>>>> I had a '**' operator at one time before, but it kept clashing with
>>>> pointers handling. as a result, if it existed, it would have to be
>>>> parsed specially, and have rules to avoid accidentally mis-parsing a
>>>> pointer operation:
>>>> "i**s++", where the intention was actually "i*(*s++)". provably
>>>> disambiguating this would require more info than the parser has
>>>> available (the only real option would be, for example, requiring
>>>> spaces...).
>>>>
>>>> 'a^.b' could be another option (where '^.', is given a high rather
>>>> than a low precedence).
>>> [...]
>>>
>>> "**" can be unambiguous if you allow parsing to be affected by
>>> semantic analysis. But typically the source is tokenized before it's
>>> parsed and analyzed (even though all these things theoretically happen
>>> in translation phase 7). If you see ``x**y'', you can't tell whether
>>> it's ``x ** y'' (an exponentiation) or ``x * *y'' without knowing the
>>> type of y.

>>
>> knowing the type of y is the problem, though theoretically it could be
>> handled by parse-tree tweaking, if I had the parse tree at the same point
>> I was doing type handling (in my compiler, I do not, since these are
>> handled as different stages).
>>
>> a later frontend may also make type info available in more of the upper
>> compiler, such that such inferences can be made...

>
> Probably your best option.
>
>>> I can imagine ways to tweak the grammar, perhaps requiring white space
>>> between a binary "*" operator and a unary "*" operator, but I wouldn't
>>> recommend it; the result would be incompatible with C. And any such
>>> solution would be complicated to define and to implement, and
>>> therefore complicated to use in at least some cases.

>>
>> yeah, I considered, but did not accept these ideas...
>> it matters to me that compatibility not be broken.

>
> Wise choice.
>
>>> You might consider ^^ as an exponentiation operator. It's not likely
>>> that a future C standard will introduce a short-circuit xor operator.

>>
>> however, I may at some point add such an operator (after all, my last
>> script language had such an operator...).

>
> short circuit xor does not get much usage IMHO.
>


has more use, but more as a 'logical xor', since it is not possible to
short-cicuit like is possible with '&&' or '||'.

>> '^.' still seems like a better option IMO, since it resembles '^', but is
>> a different operator...
>> (I can just make it have a very different precedence than '^').
>>
>> ok, this drops the precedence-similarity idea (if the new operators have
>> different precedences than the old ones they resemble).
>>
>> '&.', '|.', and '^.' might be made tightly binding (slightly more tightly
>> than '*' and '/').
>> '*.' and '/.' will be the same as '*' and '/'.
>> '+.' and '-.' will be the same as '+' and '-'.
>>
>> '*.' could thus be an alternative for dot product, and maybe an
>> additional multiply form (is some other cases).
>> '/.' could be used for a 'reverse divide' for types with non-communitive
>> multiplication and division (such as quaternions, which currently use a
>> builtin function for this). potentially, it could also serve as a
>> shorthand for dividing ints and getting a float (aka: cast-free).

>
> No, these tokens are really problematic. I pointed at ``1.^2'' that would
> become ambiguous if you attach semantics to ^ for floating point values
> (as you may have), as is unequivically parsed as 1. ^ 2. ; at least the
> .^ and more generally . prefixed arithmetic operators you are considering
> would not cause incompatibilities with current C syntax, just parsing
> surprises for programmers trying to use your extensions. Adding tokens
> with a trailing . do create incompatibilites with the current C syntax as
> it would cause legitimate expressions to be parsed differently. Consider
> these:
>
> .5==x^.5==y // x equals 0.5 or y equals 0.5 but not both.
> .8<x&.9>x
> 1.1==x|.9==y
> x/.1
> y*.2
> z-.2
> ...
>
> I always put around binary operators but a lot of programmers don't.
>


odd, I always thought the preceeding decimal digits were required.
at least in my parser, the number will not be recognized as a number, unless
it starts with a decimal digit, say, '0'...


> --
> Chqrlie.
>


 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      10-29-2007
Harald van D©¦k <(E-Mail Removed)> writes:
> On Mon, 29 Oct 2007 15:06:56 +1000, cr88192 wrote:
>> I had a '**' operator at one time before, but it kept clashing with
>> pointers handling. as a result, if it existed, it would have to be
>> parsed specially, and have rules to avoid accidentally mis-parsing a
>> pointer operation: "i**s++", where the intention was actually
>> "i*(*s++)". provably disambiguating this would require more info than
>> the parser has available (the only real option would be, for example,
>> requiring spaces...).

>
> Wouldn't you be able to define the ** operator as either accepting two
> arithmetic types, or accepting an arithmetic left operand and a pointer
> right operand? This would mean you could write a * *p to mean a * (*p),
> but not to mean pow(a, p), and that you could write a**b to mean either
> a * (*b) or pow(a, b). Additionally, it would mean you don't have parsing
> problems: a**b is always two operands for one operator, regardless of
> whether this operator performs one operation or two.


Interesting idea, but it would change operator precedence in ways that
I don't want to think about.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      10-29-2007
"cr88192" <(E-Mail Removed)> writes:
> "Charlie Gordon" <(E-Mail Removed)> wrote in message
> news:4725f246$0$6594$(E-Mail Removed)...

[...]
>> .5==x^.5==y // x equals 0.5 or y equals 0.5 but not both.
>> .8<x&.9>x
>> 1.1==x|.9==y
>> x/.1
>> y*.2
>> z-.2
>> ...
>>
>> I always put around binary operators but a lot of programmers don't.

>
> odd, I always thought the preceeding decimal digits were required.
> at least in my parser, the number will not be recognized as a number,
> unless it starts with a decimal digit, say, '0'...


Take a look at the syntax for a floating-constant, C99 6.4.4.2.

Just as a matter of style, I never use a leading or trailing decimal
point (I at least prepend or append a 0), but it's permitted.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Writing single bits to a file riva Java 2 10-27-2007 08:11 PM
shifting bits, shift 32 bits on 32 bit int GGG C++ 10 07-06-2006 06:09 AM
8 bits/ch vs 16 bits/ch in PS Terry Digital Photography 5 01-21-2004 06:59 PM
8-Bits vs 12 or 16 bits/pixel; When does more than 8 bits count ? Al Dykes Digital Photography 3 12-29-2003 07:08 PM
win XP 32 bits on a 64 bits processor.. Abbyss Computer Support 3 11-13-2003 12:39 AM



Advertisments