actually, there is a difference - Base.decode16!/1 expects an even number of “digits” - consider:
iex> "F" |> Base.decode16!()
** (ArgumentError) odd-length string
(elixir 1.13.0) lib/base.ex:349: Base.decode16!/2
vs
iex> << ("F" |> String.to_integer(16))::integer-size(1)-unit(4) >>
<<15::size(4)>>
I had this error because I did not strip the final "\n" from the input. But once done, Base.decode16!/1 works as expected.
Anybody want to help me understand this part of the prompt:
For example, here is an operator packet (hexadecimal string
38006F45291200) with length type ID0that contains two sub-packets:
00111000000000000110111101000101001010010001001000000000
VVVTTTILLLLLLLLLLLLLLLAAAAAAAAAAABBBBBBBBBBBBBBBB
V (001) are the packet version, 1.T (110) are the packet type ID, 6, which means the packet is an operator.I (0) is the length type ID, which indicates that the length is a 15-bit number representing the number of bits in the sub-packets.L (000000000011011) contain the length of the sub-packets in bits, 27.A contain the first sub-packet, a literal value representing the number 10.B contain the second sub-packet, a literal value representing the number 20.Specifically my understanding from the earlier instructions was that literal values would be 5 bit subunits, with the first bit of each subunit denoting whether it was the last subunit of the literal. So in this case the 11 bits they’ve labeled as A 11010001010 would be divided up as 11010, first bit is 1 so keep going, 00101, first bit is 0 so it’s the last subunit. Why is the next zero tacked on? Then for B, the very first subunit starts with zero so shouldn’t it stop right there?
Each sub packet starts with a 6 bit header. So A would be divided up as:
11010001010
VVVTTTAAAAA
I hope the next day will expand on that new format like intcode in 2019. We were building a VM from for CPU-like instructions.
This time it is basically an AST that we are working with, so we may end up building an interpretor. And if we do, then I we could try to rewrite the binary decoder to output Elixir AST instead of custom packet formats, and eval it with Code.eval_quoted 
Nice!
I propose to use a different way of iterating on values. Instead of having Enum.reduce/3 everywhere you could to this:
defp ast_helper(values, type_id) do
case type_id do
0 -> quote(do: Enum.sum(unquote(values)))
1 -> quote(do: Enum.product(unquote(values)))
2 -> quote(do: Enum.min(unquote(values)))
3 -> quote(do: Enum.max(unquote(values)))
5 -> ast_if(values, :>)
6 -> ast_if(values, :<)
7 -> ast_if(values, :==)
end
end
defp ast_if([val_a, val_b], op) do
quote do
if unquote(op)(unquote(val_a), unquote(val_b)),
do: 1,
else: 0
end
end
Oh and note that you can directly use len in the function head!
defp make_ast(<<_version::3, type_id::3, 0::1, len::15, values::bitstring-size(len), rest::bitstring>>) do
ast =
values
|> parse_values()
|> ast_helper(type_id)
{ast, rest}
end
Magic