Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>You don't provide some important details, but under some reasonable assumptions it is 4 and 5 that are broken, while 1-3 are fairly OK.</p> <p>I assume that you are insisting on the use of bigger intermediate integral type because you want to avoid overflow on addition. It is also not clear whether you are working with signed on unsigned types and why your are mixing them like that. </p> <p>Anyway, the minimal proper way to perform the addition and shift would be</p> <pre><code>bucket = ((long) ADCBUF0 + ADCBUF7) &gt;&gt; 1; </code></pre> <p>Switching to bigger type in just one operand is sufficient. Of course, you can keep both casts if you like the more "symmetrical" look better.</p> <p>Or you can do it without any casts at all (assuming that <code>bucket</code> is declared with "bigger" type)</p> <pre><code>bucket = ADCBUF0; bucket = (bucket + ADCBUF7) &gt;&gt; 1; </code></pre> <p>As for the final assignment, if the recipient is an <code>unsigned int</code> by itself (this is completely unclear from your question), there's no real need for any cast, unless you are trying to suppress the compiler warnings. I assume that it is an <code>unsigned int</code>. In that case just</p> <pre><code>rem_volt = bucket; </code></pre> <p>will work. If it is not an <code>unsigned int</code>, then the explicit cast might make a difference, but there no way to say, until you provide this important detail.</p> <p>It doesn't matter where you do the shift in your case (in the first or in the second statement), again, if <code>bucket</code> has "bigger" type. If <code>bucket</code> is declared with the same type as the <code>ADC...</code> variables, then the shift must be done early (in the first expression).</p> <p>As for your variants: 1 is OK, but the second cast is technically redundant (matter of style). 2 is OK, with two excessive casts. 3 is also OK, with an excessive cast. 4 is broken, since it doesn't protect from overflow (if that was your intent). 5 is broken in the same way. </p> <p>In other words, out of all your variants number 1 looks the best (again, assuming that the cast to <code>unsigned int</code> is redundant).</p> <p>P.S. If you want to divide something by 2, the most reasonable way to do it is to use the division operator <code>/</code> and the constant <code>2</code> as a divisor. There's no meaningful reason to bring any shifts into the picture.</p> <hr> <p>Also Matthew Slattery in his answer provided a non-overflowing way to calculate the average using bit-twiddling operations. It can also be done in another, (arguably) more readable way through</p> <pre><code>average = ADCBUF0 / 2 + ADCBUF7 / 2 + (ADCBUF0 % 2 &amp; ADCBUF7 % 2); </code></pre> <p>or, if you prefer the bit-twiddling approach</p> <pre><code>average = (ADCBUF0 &gt;&gt; 1) + (ADCBUF7 &gt;&gt; 1) + (ADCBUF0 &amp; ADCBUF7 &amp; 1); </code></pre>
    singulars
    1. This table or related slice is empty.
    1. POCasting numeric data types in C
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USAnT
    1. USAnT
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POCasting numeric data types in C
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    1. COI don't think `ADCBUF0` is intended to be a hex constant because `U` isn't a hex digit.
      singulars
      1. PO
      1. USPaul Stephenson
    2. COOh, right! I'll fix it.
      singulars
      1. PO
      1. USAnT
    3. COYou might want to mention that the "without any casts" way assumes that `bucket` is of type `long`.
      singulars
      1. PO
      1. UScaf
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload