I have an ECLiPSe script whose goal is to encode my problem into a set of arithmetic constraints. In REPL, I eventually get a list of delayed goals which looks as follows:
-(_2941{4 .. 7}) + _2900{1 .. 4} #=< 0
_2941{4 .. 7} - _2900{1 .. 4} #= 3
-(_3393{7 .. 21}) + _3352{4 .. 18} #=< 0
_3393{7 .. 21} - _3352{4 .. 18} #= 3
_3845{14 .. 17} - _3804{4 .. 7} #= 10
_4297{18 .. 21} - _4256{14 .. 17} #= 4
-(_4749{19 .. 22}) + _4708{18 .. 21} #=< 0
_4749{19 .. 22} - _4708{18 .. 21} #= 1
...
Is there a predicate that would give me a similar readable list of constraints in the constraint store?
delayed_goals gives some library-specific constraints (like prop_ic_con(ic_con(... <some special characters> etc )) rather than the clean output as in the above listing. I need to output it to a file from a shell script, not from the interactive loop which hides delayed goals by default.
The translation from an internal goal to a readable one is performed by a
goal-portray-transformation. The output predicates
printf and write_term can optionally invoke this translation, e.g.
?- 3*X+6*Y #> 9, delayed_goals([G]), printf("%Gmw", [G]), nl.
6 * Y{-1.0Inf .. 1.0Inf} + 3 * X{-1.0Inf .. 1.0Inf} #> 9
?- 3*X+6*Y #> 9, delayed_goals([G]), write_term(G, [as(goal)]), nl.
6 * Y{-1.0Inf .. 1.0Inf} + 3 * X{-1.0Inf .. 1.0Inf} #> 9
You can also invoke the translation explicitly using portray_term/3:
?- 3*X+6*Y #> 9, delayed_goals([G]), portray_term(G, P, goal).
G = prop_ic_con(ic_con(...))
P = (6 * Y{-1.0Inf .. 1.0Inf} + 3 * X{-1.0Inf .. 1.0Inf} #> 9)
Related
I recently had the following question
regarding the function mean! of the Statistics.jl package.
The following bug is reported regarding the behavior of mean!. As indicated, the mean! function does not properly consider that its arguments may alias each other. In some such cases the result from mean! is not correct:
julia> let a = [1 2 3]
mean!(a, a)
end
1×3 Array{Int64,2}:
0 0 0
julia> let a = [1 2 3]
mean!(copy(a), a)
end
1×3 Array{Int64,2}:
1 2 3
julia> versioninfo()
Julia Version 1.5.3
Commit 788b2c77c1 (2020-11-09 13:37 UTC)
Platform Info:
OS: macOS (x86_64-apple-darwin18.7.0)
CPU: Intel(R) Core(TM) i9-9980HK CPU # 2.40GHz
WORD_SIZE: 64
LIBM: libopenlibm
LLVM: libLLVM-9.0.1 (ORCJIT, skylake)
However, I think that this behavior is normal since viewing the definition of mean!, the result of the operation mean!(r, v) is written in r. Therefore it seems logical to me that if you use the same object as variable r and as variable v, the result is unpredictable.
I have seen that this also happens with the sum! function.
Someone can tell me if I am right or indeed, there is something that I am not understanding.
mean! behaves the way you observe because it internally calls sum!.
Now sum! behaves this way for the following reason. It was designed to perform summation without making any allocations. Therefore the first thing sum! does is initializing the target vector to 0 (a neutral element of summation). After this is done your a vector contains only 0s, and thus later you get all 0s also.
However, indeed it would make sense that the sum! (and similar) functions docstring should mention that the target should not alias with the source. Here is another example of the same you have observed:
julia> x = [1 2 3
4 5 6
7 8 9]
3×3 Matrix{Int64}:
1 2 3
4 5 6
7 8 9
julia> y = view(x, :, 1)
3-element view(::Matrix{Int64}, :, 1) with eltype Int64:
1
4
7
julia> sum!(y, x)
3-element view(::Matrix{Int64}, :, 1) with eltype Int64:
5
11
17
julia> x
3×3 Matrix{Int64}:
5 2 3
11 5 6
17 8 9
I found this code on internet but I am not able to understand how the print statement is working.
I have already tried to see many answers but none answers it perfectly.
def main():
n=int(raw_input())
for i in range(0, 1<<n):
gray=i^(i>>1)
print "{0:0{1}b}".format(gray,n),
main()
for i in range(0, 1<<n):
Here, 1 << n shifts 1 by n bits to left. It means:
if n = 1, 1 << 1 would be 10,
n = 2, 1 << 10 would be 100 [2 = binary 10]
and so on.
For decimal number the answer is equivalent 2 to the power n.
For binary 'n' number of zeros are added.
So the range is for i in range(0, 2 ** n).
gray=i^(i>>1)
Here i>>1 shifts i by 1 bit to right. It means:
if i = 1, 1 >> 1 would be 0,
i = 2, 10 >> 1 would be 1 [2 = binary 10]
i = 3, 100 >> 1 would be 10 (in binary) 2 in decimal
and so on.
For decimal numbers it is equivalent to dividing by 2 (and ignoring digits after . decimal point).
For binary last digit is erased.
^ is exclusive OR operator. It is defined as:
0 ^ 0 = 0,
0 ^ 1 = 1 ^ 0 = 1,
1 ^ 1 = 0
print "{0:0{1}b}".format(gray,n)
Here {1} refers to n, b refers to binary. So gray is converted to binary and expressed in n digits.
What you are looking at is known by the concept of Advanced string formatting. Specifically, PEP 3101 Advanced string Formatting
You may refer the official documentation for understanding purposes.
I'm controlling a board that has 16 outputs in two groups #1: 1-8, #2: 9-16.
The first part of the command is the group [1,...] or [2,...]
The second part is the output, so in the limited examples I am shown [1,1,...] would turn on [group 1, channel 1, ....]-- so far so good.
The next example is Output 8: [1, 128, ...]
The next example is Outputs 1 & 8: [1, 129, ...]
What is this conversion called? I'm assuming the outputs map as follows, is this correct:
Output 1 (or 9): 1
Output 2 (or 10): 16
Output 3 (or 11): 32
...
Output 8 (or 16): 128
So if I wanted outputs 2 & 3 the command would be [1, 48]?
You work with bits. 10000000 means turn on output 8. 10000000 in binary means 128 in decimal. If you wanted output 7 you’d do 1000000 which is 64 in decimal. Most programming languages would let you do something like 0x01001100 for example to turn on 7,4 and 3. Easier to work in binary.
The generic formula for you to find the value to set 1 output would be:
second_part = 2^(output_to_set - 1)
For multiple outputs, you just need to add them.
So if you want to set, outputs 2 and 3:
second_part = 2^1 + 2^2 = 6
In a lecture earlier, we were told that using a greedy approach to solve a change making problem would not always work.
An example of this was given as follows:
We want to reach n = 14, and we have three coins of different values: d1 = 1,d2 = 7,d3 = 10.
Using the greedy approach this would lead us to do 10 + 1 + 1 + 1 + 1 (5 coins).
It was said the a dynamic problem approach would solve this accurately. I tried working it out but it came back to 5.
Assume F holds the number of coins needed to make an amount
F[14] = min {F[14 – 1] , F[14 – 7], F[14 – 10]} + 1
= F[14 – 10] + 1 = 4 + 1 = 5
This shows again that we need 5 coins, when this can clearly be done by using 2 coins (7 + 7).
What gives? Thanks.
You assumed that min {F[14 – 1] , F[14 – 7], F[14 – 10]}=F[14-10] when it is not the case. The minimum is actually F[14-7]=1 and hence the optimum is 2
I am trying to learn Haskell and was working on a book problem on recursive functions.
> If X_1 = 1 then X_2 = 1 + X_1 = 2, X_3 = 1 + X_1 + X_2
or when it is 5, X_5 = 1 + X_4 + X_3 + X_2 + X_1 = 16, and so forth.
I tried doing this on haskell:
test :: Int -> Int
test 1 = 1
test n = sum[test n .. test (n-1)]
but the output is always 1. I think I have to do a function guard first and then sum it but I dont know how to do it with recursive behavior.
A good place to start is with list comprehensions:
[ test i | i <- [1..5] ]
means
[ test 1, test 2, test 3, test 4, test 5 ]
See if you can solve it now.
Don't forget to add 1!
This part of your code is a Haskell range
[test n .. test (n-1)]
Ranges work by figuring out the left number and the right number, and then constructing a list that contains all steps from the left number to the right number. So:
[1 .. 6] --> [1,2,3,4,5,6]
[5 .. 9] --> [5,6,7,8,9]
As you can see, the default step is 1, so if you have a left number that is higher than the right, you will get an empty list:
[4 .. 3] --> []
As an aside, You can override the default step by providing another number:
[1, 3 .. 6] --> [1,3,5] -- step is 2
[8, 6 .. 3] --> [8,6,4] -- step is -2
As you can see, when you have another step size than 1, you have to be careful with what gets included in the resulting list. This goes especially for negative steps, and even more if you have non-integer steps like [1, 1.25, .. 2.1]. You should almost never generate a list of non-integer numbers using a range.
In your solution you have the line
test n = sum[test n .. test (n-1)]
According to the rules for ranges, this is bound to go wrong. When the program tries to make the list from the range, it tries to compute test n since that is the left number of the range. But that gets us nowhere, since test n is what this whole line is trying to compute in the first place. So we have an infinite loop, and the program hangs.
You could try to do
test n = sum[1 .. test (n-1)]
That looks closer to the examples you gave. It starts with 1 (which is test 1), and ends with test (n-1). But the problem is those values in between. Because ranges have the step of one, what you end up with is:
[1 .. test (n-1)] --> [1,2,3, ......., test (n-1)]
which is not the same as
[test 1, test 2, test 3, .... , test (n-1)]
And since a range can only have a constant step, there is no way to get this last line with a simple range, even if you override the default step. One hint on how to solve this is to notice the number of elements in the list.
length [1 .. test (n-1)] --> test (n-1),
-- because [1,2,3] has 3 elements, [1,2,3,4] has 4 and so on
length [test 1, test 2, test 3, ....... , test (n-1)] --> n-1
-- this is not quite Haskell syntax
The Haskell way here is to make a list that has the correct number of elements, and then transform it so each element is the correct one. How do you make a list of (n-1) elements? Simple:
[1..(n-1)]
From here you can go several ways. There is the list comprehension from luqui:
[test x | x <- [1..(n-1)]]
You can think of this as taking each number out of the range, assigning it to x and then applying the test function to x, so you get [test 1, test 2, test 3, ....... , test (n-1)]. Another way would be to use the map function:
map test [1..(n-1)]
I think of this as applying test to each element of the list at the same time, but it is exactly the same thing as the list comprehension, just two ways of looking at it. Notice that both ways use the [1..(n-1)] range.
If you use either of these instead of the [test n .. test (n-1)] range in your original code, you are very close to the solution. The only thing missing, as luqui reminds, is to remember to add the 1.