Home/ Questions/Q 8570929
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-11T18:40:14+00:00

I’ve been reading book about Erlang to evaluate if it’s suitable for my project,

  • 0

I’ve been reading book about Erlang to evaluate if it’s suitable for my project, and struble upon the bit syntax part of Learn You Some Erlang for Great Book.

Simply put, here’s the code:

1> Color = 16#F09A29.
15768105
2> Pixel = <<Color:24>>.
<<240,154,41>>

What’s confusing me is this: the Color variable is 24 bits, but how could Erlang knows that it has to divide the variable (in line 2) into three segments? How is the rule read?

I’ve tried to read the rest of the chapter, but it’s getting more and more confusing me, because I don’t understand how it divides the numbers. Could you please explain how the bit syntax works? How can it know that it’s 3 segments, and how can it becomes <<154, 41>> when I do this:

1> Color = 16#F09A29.
15768105
2> Pixel = <<Color:16>>.
<<154,41>>

Thanks before.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Color = 16#F09A29 is an integer that can be written as 15768105 in decimal representation, as well as

    00000000111100001001101000101001

    in binary representation.

    when you define a binary Pixel = << Color:24 >>. it just means that you say “Match the 24 less significant bits of Color with the binary Pixel”. so Pixel is bounded to

    111100001001101000101001,

    without any split! when the shell prints it out, it does it byte per byte in decimal representation that is:

    11110000 = 15*16 = 240, 10011010 = 9 * 16 + 10 = 154, 00101001 = 2 *
    16 + 9 = 41 => << 240,154,41 >>

    in the same way, when you define Pixel = << Color:16 >>, it takes only the 16 less significant bits and assign them to the binary =

    1001101000101001,

    which is printed 10011010 =

    9 * 16 + 10 = 154, 00101001 = 2 * 16 + 9 = 41 => << 154,41 >>.

    In the case of <> the binary equals now

    100001001101000101001

    ( the 21 less significant bits) and when the shell prints them, it starts as usual, dividing the binary into bytes so

    10000100 = 8*16 + 4 = 132, 11010001 = 13 *16 +1 = 209, as it remains only 5 bits 01001, the last chunk of data is printed 5:9 to tell us that the size of the last value is not 8 bits = 1 byte as usual, but only 5 bits =>

    << 132,209,5:9 >>.

    The nice thing with binaries, is that you can “decode” them using size specification (maybe it is more clear with the example bellow).

    (exec@WXFRB1824L)43> Co=16#F09A29.
15768105
(exec@WXFRB1824L)44> Pi = <<Co:24>>.
<<240,154,41>>
(exec@WXFRB1824L)45> <<R:8,V:8,B:8>> = Pi.
<<240,154,41>>
(exec@WXFRB1824L)46> R.
240
    • 0