# Block number conversion during bit operations

**URL:** <https://discourse.julialang.org/t/block-number-conversion-during-bit-operations/73640>\
**Category:** Performance\
**Created:** [December 26, 2021, 10:25am UTC](https://discourse.julialang.org/t/block-number-conversion-during-bit-operations/73640 "2021-12-26T10:25:41Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Jakub\_Mitura](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jakub_mitura/32/19496_2.png) [@Jakub\_Mitura](https://discourse.julialang.org/u/Jakub_Mitura)\
**Post date:** [December 26, 2021, 10:25am UTC](https://discourse.julialang.org/t/block-number-conversion-during-bit-operations/73640/1 "2021-12-26T10:25:41Z")

</div>

Hello I am working on problem when I use UInt32 as a bitAttay of 32 entries - (I can not use Bitarray for some reasons) problem is that sometimes (once every couple hundred iterations) when I modify the first bit it leads to Julia trying to convert it to diffrent number type and gives inexact error - How can I avoid automatic number class promotion?

`@inbounds shmemblockData[x,y,1] = (shmemblockData[x,y,1] | shmemblockData[x,y,2] )`

shmemblockData is UInt32 array of shape (32,32,2) x and y can by any integer between 1 and 32 information is encoded in bits - in most cases all works well but when I started benchmarking and fire the function thousands of times sometimes modyfing first bit will lead to ineaxact error which crash my program - how can I avoid it?

Thanks!!

---

<div class="post-metadata">

**Author:** ![mikmoore](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mikmoore/32/31109_2.png) [@mikmoore](https://discourse.julialang.org/u/mikmoore)\
**Post date:** [December 27, 2021, 2:15am UTC](https://discourse.julialang.org/t/block-number-conversion-during-bit-operations/73640/2 "2021-12-27T02:15:02Z")

</div>

From the symptoms you describe it sounds like your `UInt32` is getting converted to a `Int` or `Int32` somewhere along the way, gaining a negative sign, and then it’s getting upset when it tries to assign a negative number to a `UInt32` location. But the line you’re showing shouldn’t cause that issue. I’d take a careful look and make sure that `Int`s aren’t getting accidentally introduced (perhaps via an integer literal like `2`?)

If nothing else, `reinterpret(UInt32,x)` will convert `x` to a `UInt32` without being angry about a negative sign. Note that if `x` is not 32 bits then it will throw a different error (but `reinterpret(Uint32,Int32(x))` will work for any width `x` that can be converted). But at that point it’s definitely a sign that some promotions are happening that you aren’t intending.