Reading chapter 2 of Hacker's Delight and trying ti implement bit manipulation in Erlang.
I'm stuck on this one:
Use the following formula to create a word with 0's at the positions of the trailing 1's in x, and 1's elsewhere, producing all 1's if none (e.g. 10100111 => 11111000):
¬ x | (x + 1)
Here is what I tried:
(bnot X) bor (X + 2#01)
But the result is -1000 for some reason, and not 2#11111000.
What's strange is that not 2#10100111 is -10101000 (base 2).
Any idea what's going on?
You have to limit the width oh the numbers manipulated (problem of sign, problem of bignum and integer representation).
The next example use 8 bits but it would work the same with 128 bits, in this case the result would be 340282366920938463463374607431768211448 instead of 248 for your test case.
1> Msk = fun(X) -> X band 2#11111111 end. % limit to 8 bits
#Fun<erl_eval.6.52032458>
2> Op = fun(X) -> Msk(bnot(X)) bor Msk(X+1) end.
#Fun<erl_eval.6.52032458>
3> Op(2#10100111).
248
4> 2#11111000.
248
Related
I've just been doing some validation on value to see it is a product of three. Great use the modulus function. I want to pipe to it. Great use a partial application. But apparently not.
This is an example from my fsi in vs code.
> 27 % 3
-
- ;;
val it : int = 0
> (%) 3 27
- ;;
val it : int = 3
I really didn't expect to get a different result from an infix vs a partial.
Here is the operation in a pipe for context:
...
|> Seq.length // 27
|> (%) 3 // 3
Because you have the operands flipped. (%) 3 27 actually means 3 % 27, not 27 % 3, i.e. you want (%) 27 3.
Partial application of an infix doesn't work as I expected. The statement in my qustion is incorrect and this isn't a bug. It might be a fairly common missunderstanding for beginers so its worth a good explaination.
(%) x y = x % y
Therefore
(%) 27 3
= 27 % 3
= 0
The confusion comes when piping in the final value, the y.
you should not expect
y
|> (%) x
to result in
y % x
but rather
x % y
This is a little bit confusing particularly if you have used an infix operator, which does treats inputs symetrically (e.g +,=,<>,*), without questioning too deeply. You must take care that order of values supplied to an infix opperator are correct, even if it looks right at first inspection.
The clearest and most verbose way to handle an infix opperator, which accepts values in the opposite order to which you wish to supply them, is to just write out a lambda. However, there is also the option to back pipe '<|'.
Here is a snippet of code which was causing me a bug due to my misuse of the partially applied infix.
...
|> Seq.length // 27
|> (%) 3 // 3 % 27 = 3
It could be written with a backpipe to perform as expected
...
|> Seq.length // 27
|> (%) <|3 // 27 % 3 = 0
or more clearly with a lambda
...
|> Seq.length // 27
|> (fun x -> x % 3 // 27 % 3 = 0
I need to make tons of simple computations and present each step in my report with predefined manner:
(for ex i got B=2, C=3):
A=B+12-6/C^2; A=2+12-6/3^2=13.333;
I can get 1st block and answer like this:
B:2$ C:3$
A:'(B+12-6/C^2)$
print("A=",A,"; ","A= ??? =",ev(A, numer) );
and get:
6
A= (- --) + B + 12 ; A= ??? = 13.33333333333333
2
C
What i need instead of '???' to get desired output?
Maxima distinguishes two parts of figuring out a result: evaluation and simplification. Evaluation = substituting one thing (the value) for another thing (a variable or a function). Simplification = applying mathematical identities to get a "simpler", equivalent result.
In your problem, it appears you want to postpone simplification. You can say simp: false to do that. Here's one possible approach. I'll disable simplification, substitute values into the expression, print the substituted expression, and then re-enable simplification to get the final result.
(%i2) expr: A=B+12-6/C^2;
6
(%o2) A = (- --) + B + 12
2
C
(%i3) simp: false $
(%i4) subst ([B = 2, C = 3], expr);
- 2
(%o4) A = 12 + 2 + (- 6) 3
(%i5) simp: true $
(%i6) %o4;
40
(%o6) A = --
3
Note that many operations in Maxima happen by simplification (e.g. adding numbers together), so in general, Maxima will act noticeably different when simp is false. But in this case that's what you want.
EDIT: OP points out that the result after substitution is displayed in a somewhat different from. The reason for this has to do with some obscure implementation details of Maxima. Be that as it may, it's possible to work around that behavior by using the Lisp substitution function SUBST (referenced in Maxima as ?subst) instead of Maxima subst. SUBST is a little different than Maxima subst; the syntax is ?subst(new_thing, old_thing, some_expression). After substituting via SUBST, it's necessary to resimplify explicitly; one way to do that is to say expand(..., 0, 0) (which doesn't expand anything, the only effect is to resimplify).
(%i2) expr: A=B+12-6/C^2;
6
(%o2) A = (- --) + B + 12
2
C
(%i3) simp: false $
(%i4) ?subst (3, C, ?subst (2, B, expr));
6
(%o4) A = (- --) + 2 + 12
2
3
(%i5) simp: true $
(%i6) expand (%o4, 0, 0);
40
(%o6) A = --
3
Since SUBST is has a different effect on the internal representation, it is possible you could create an invalid expression, for some choices of new_thing, old_thing, and some_expression. I won't try to sort that out here.
How to perform arithmetic with values of different widths ?
In verilog there is no problem xoring 2 bits with 8 bits but cryptol complains:
cryptol> let test(x: [2],y: [8]) = x ^ y
[error] at <interactive>:1:31--1:32:
Type mismatch:
Expected type: 2
Inferred type: 8
My original problem:
I would like to rotate the bytes in a 64 bit value, with the number of bytes to shift depending on a two bit input. I struggle to get this working:
cryptol> let shift (v, s:[2]) = v >>> (s*16+8)
[error] at <interactive>:1:5--1:38:
Unsolved constraint:
2 >= 5
arising from
use of literal or demoted expression
at <interactive>:1:33--1:35
In the interpreter I can remove the type specification of s and then it works however I need to get that working from a file and with s being really a 2 bit value.
The type of ^ is:
Cryptol> :t (^)
(^) : {a} (Logic a) => a -> a -> a
Note that it requires both arguments to be exactly the same. You're getting the type-error because [2] is not the same as [8]; as they differ in size. Unlike Verilog, Cryptol will not "pad" things implicitly, and I think Cryptol is definitely doing the right thing here. Verilog programmers can chime in with countless bugs they had due to implicit casting.
All such casting in Cryptol has to be explicit.
The typical way to deal with this situation in Cryptol is to use the polymorphic constant zero:
Cryptol> :t zero
zero : {a} (Zero a) => a
The value zero inhabits all types (you can ignore the Zero constraint for now), and as you can imagine is the "right" padding value in this case. So, you'd define your function as:
Cryptol> let test(x:[2], y:[8]) = (zero#x)^y
Cryptol> :t test
test : ([2], [8]) -> [8]
And use it like this:
Cryptol> test (1, 5)
0x04
And if you wanted to pad on the right for some reason, you'd do:
Cryptol> let test(x:[2], y:[8]) = (x#zero)^y
Cryptol> test(1,5)
0x45
This way, everything is explicit and you don't have to know all the magical rules about how things get padded to become the right size.
If you want to get real fancy, then you can do:
Cryptol> let test(x, y) = (zero#x)^(zero#y)
Cryptol> :t test
test : {n, m, i, j, a} (Logic a, Zero a, m + i == n + j, fin n,
fin m) =>
([i]a, [j]a) -> [m + i]a
Now, that type looks a bit scary; but essentially it's telling you that you can give it any sized arguments, and it would be valid for any other size, so long as the new size is larger than the maximum of the two you've given. Of course, this inferred size is way more polymorphic then you probably cared for; so you can give it something more readable:
test : {m, n} (fin m, fin n) => [m] -> [n] -> [max m n]
test x y = (zero#x) ^ (zero#y)
I believe this captures your intent perfectly. Note how cryptol will make sure your inputs are finite, and you get the maximum of the two sizes given.
Getting back to your example, Cryptol is telling you that to multiply by 16 you need at least 5 bits, and thus 2>=5 is not satisfiable. This is a bit cryptic, but arises from the use of literals which are polymorphically typed. You can use the zero trick to address the issue in the same way as before:
Cryptol> let shift (v, s:[2]) = v >>> ((zero#s)*16+8)
[warning] at <interactive>:1:32--1:38:
Defaulting type argument 'front' of '(#)' to 3
But note how cryptol is warning you about the type of zero that's used there, since the type of >>> is polymorphic enough to allow different size shifts/rotates:
Cryptol> :t (>>>)
(>>>) : {n, ix, a} (fin n, fin ix) => [n]a -> [ix] -> [n]a
In these cases, Cryptol will pick the smallest possible size to default to by looking at the expressions. Unfortunately, it does the wrong thing here. By picking size 3 for zero, you'll have a 5 bit shift, but your expression can produce the maximum value of 3*16+8=56, which requires at least 6 bits to represent. Note that Cryptol only uses the minimum size required to handle the multiplication there, and does not care about overflows! This is why it's important to pay attention to such warnings.
To be clear: Cryptol did the right thing per the language rules on how type inference works, but it ended up picking a size that is just too small for what you wanted to do.
So, you should write your shift as follows:
Cryptol> let shift (v, s:[2]) = v >>> (((zero:[4])#s)*16+8)
Cryptol> :t shift
shift : {n, a} (fin n) => ([n]a, [2]) -> [n]a
The important thing here is to make sure the expression s*16+8 will fit in the final result, and since s is only 2 bits wide the largest value will be 56 as discussed above, which needs at least 6-bits to represent. This is why I chose [4] as the size of zero.
The moral of the story here is that you should always be explicit about the sizes of your bitvectors, and Cryptol will give you the right framework to express your constraints in a polymorphic way to allow for code reuse without ambiguity, avoiding many of the pitfalls of Verilog and other similar languages.
I need to calculate this equation using Delphi programming language
z = (Rot(y ∧ n1 , K2) ∧ K1 ) ⊕ n2
Where:
K1, K2, n1, n2, y are 96-bits binary values
I just want to know what does this symbol means "∧", and how to us it in Delphi?
It might be bitwise AND.
The ⊕ could be exclusive or XOR in Delphi.
The tricky bit might be the ROT operation which rotates the bits of a variable. There is no ROT operation but there is shl and shr for left and right shift. See Delphi Expressions
To make things even harder you don't have a native 96 bit datatype. LongInt is 4 bytes = 32 bit. You will need to use an array if you need to represent the fill 96 bit.
I'm trying to parse a binary file and when it comes to returning numbers packed in little endian into 16 bits, I am hoping that this would work:
foo(Bin, Bits) when is_binary(Bin) ->
<<A, B, C, D, _Rest>> = Bin,
(bar(<<A, B>>, Bits) =/= 0) and (bar(<<C, D>>, Bits) =/= 0).
bar(<<N:16/little-unsigned-integer>>, Bits) ->
binary:at(Bits, N).
Unfortunately, the matcher doesn't work when Bin is 4 bytes or less. Is there a better way to make it so the rest can be empty? If I could avoid testing binary length in the caller, the better.
You could do something like:
foo(<<A:16/little-unsigned-integer,B:16/little-unsigned-integer,_Rest/binary>>, Bits) ->
(binary:at(Bits, A) =/= 0) and (binary:at(Bits, B) =/= 0).
This will not work with a binary which is less than 4 bytes long. What is supposed to happen in that case?
N.B. binary:at/2 works on binaries not bitstrings and the offset is in bytes.