I need to prove that the language L(EVEN) = { M : |L(M)| is even } is undecidable.
In other words, the language L(EVEN) is the set of all Turing Machines which accept some language of even cardinality.
Here, M is the encoding of some Turing Machine which would be passed in as input if there existed a decider for L(EVEN).
I've completed other problems similar to this one using Turing Reductions, one example can be seen here:
My issue is that I am unable to come up with some previously proved undecidable language that would be useful to show L <= L(EVEN).
The undecidable languages weve covered so far in class are as follows:
- L(emptyset) = { M | M is a TM and |L(M)| = emptyset}
- L(ACC) = { (M, x) | M is a TM, and M accepts input x}
- L(HALT) = { (M, x) | M is a TM, and M halts on input x}
- L(EQ) = { (M1, M2) | M1, M2 are TMs, and L(M1) == L(M2) }
- L(∈ - HALT) = { M | M is a TM, M halts on input ∈ }
I could also possibly use the complements of these languages as decidability is closed under complementation. How could I use one of these undecidable languages to prove that L(EVEN) is also undecidable, using a similar setup to the example problem I included?
Suppose we had a decider for L(EVEN). Then, we can decide L(ACC) as follows:
From input M to the TM for L(ACC), construct a TM M' which first verifies the input tape is the input x to M, and then runs M on x. M' so constructed either accepts the language {x}, if M accepts x, or the empty language if M does not.
By using our decider for L(EVEN) on the encoding of M', we can tell if |L(M')| is even (in which case L(M') is empty and M does not accept x) or odd (in which case L(M') = {x} and M accepts x).
Related
I am trying to write a function in Julia that takes in a multi-dimensional array (a data cube) and rescales every entry from 0 to 1. However, whenever I run the code in atom, I get the error
LoadError: MethodError: no method matching -(::Array{Float64,2}, ::Float64)
Closest candidates are:
-(::Float64, ::Float64) at float.jl:397
-(::Complex{Bool}, ::Real) at complex.jl:298
-(::Missing, ::Number) at missing.jl:97
...
Stacktrace:
[1] rescale_zero_one(::Array{Float64,2}) at D:\Julio\Documents\Michigan_v2\CS\EECS_598_Data_Science\codex\Codex_3\svd_video.jl:40
[2] top-level scope at D:\Julio\Documents\Michigan_v2\CS\EECS_598_Data_Science\codex\Codex_3\svd_video.jl:50 [inlined]
[3] top-level scope at .\none:0
in expression starting at D:\Julio\Documents\Michigan_v2\CS\EECS_598_Data_Science\codex\Codex_3\svd_video.jl:48
I have the basics of what my function must do, but I really don't understand some of the notation and what the error is telling or how to fix it.
function rescale_zero_one(A::Array)
B = float(A)
B -= minimum(B)
B /= maximum(B)
return B
end
m,n,j = size(movie_cube)
println(j)
C = Array{Float64}(UndefInitializer(),m,n,j)
for k in 1:j
println(k)
C[:,:,j] = rescale_zero_one(movie_cube[:,:,j])
end
the variable movie_cube is a 3 dimensional data array of Float64 entries and I just want to rescale the entries from zero to one. However, the error that I mentioned keeps appearing. I would really appreciate any help with this code!
Try to use dot syntax for doing some operations in an array!
function rescale_zero_one(A::Array)
B = float.(A)
B .-= minimum(B)
B ./= maximum(B)
return B
end
This code is a bit faster and simpler (it only makes two passes over the input matrix rather than five in the previous answer):
function rescale(A::Matrix)
(a, b) = extrema(A)
return (A .- a) ./ (b - a)
end
This can be generalized to three dimensions, so that you don't need the outer loop over the dimensions in C. Warning: this solution is actually a bit slow, since extrema/maximum/minimum are slow when using the dims keyword, which is quite strange:
function rescale(A::Array{T, 3}) where {T}
mm = extrema(A, dims=(1,2))
a, b = first.(mm), last.(mm)
return (A .- a) ./ (b .- a)
end
Now you could just write C = rescale(movie_cube). You can even generalize this further:
function rescale(A::Array{T, N}; dims=ntuple(identity, N)) where {T,N}
mm = extrema(A, dims=dims)
a, b = first.(mm), last.(mm)
return (A .- a) ./ (b .- a)
end
Now you can normalize your multidimensional array along any dimensions you like. Current behaviour becomes
C = rescale(movie_cube, dims=(1,2))
Rescaling each row is
C = rescale(movie_cube, dims=(1,))
Default behaviour is to rescale the entire array:
C = rescale(movie_cube)
One more thing, this is a bit odd:
C = Array{Float64}(UndefInitializer(),m,n,j)
It's not wrong, but it is more common to use the shorter and more elegant:
C = Array{Float64}(undef, m, n, j)
You might also consider simply writing: C = similar(movie_cube) or C = similar(movie_cube, Float64).
Edit: Another general solution is to not implement the dimension handling in the rescale function, but to rather leverage mapslices. Then:
function rescale(A::Array)
(a, b) = extrema(A)
return (A .- a) ./ (b - a)
end
C = mapslices(rescale, A, dims=(1,2))
This is also not the fastest solution, for reasons I don't understand. I really think this ought to be fast, and might be sped up in a future version of Julia.
I don't understand the pumping lemma very well, and could use a simple break down of how to prove something like this.
Assume that the language L = {a^n b^m: n < m < 2m} is regular. Then, by the pumping lemma, every string in L of length at least p can be written as xyz where |xy| < p, |y| > 0 and for every natural number k, x(y^k)z is also a string in L. Consider the string a^p b^(p+1). This string has length at least p and is in L. Now we consider options for the substring y:
y consists only of a's. Then, we can choose k > 1 to increase the number of a's to be greater than the number of b's, getting a string not in L.
y consists of both a's and b's. Then, for k > 1, pumping will cause some a's to come after some b's, resulting in a string that can't possibly be in L.
y consists only of b's. Then, we can choose k = p so there are at least 2p + 1 b's, giving more than twice the number of b's as there are a's, and therefore a string not in L.
Because these three ways are the only ways to choose the substring y, there is no way to choose y so that the conditions of the pumping lemma are satisfied. This is a contradiction. Therefore, the assumption that the language is regular must be incorrect. It follows that the language is not regular. The proof was by contradiction / reduction ad absurdum.
I know how to code an ALU using behavioral style, but I'm completely lost as to how to do it using structural design. I need an 8-function bit-slice structural ALU so I can change the word size through a parameter which gets passed and it still works. I found a schematic for a 2-function ALU, but would anyone tell me how I could translate it to 8-function or possibly link me to a Verilog example for it? Here's the 2-function ALU schematic:
I can't remember remotely enough about truth tables, k-maps, etc. to even attempt to figure out the logic for this on my own. Not sure where to even start. Any help is greatly appreciated, thanks!
Unless you are trying to simplify the logic down to a minimal form (which is honestly wasted effort as synthesis tools are very good at doing this themselves, at least when it comes to combining terms to get smaller, functional equivalent logic), you can break this problem down further. You should typically be thinking in this way when writing behavioral Verilog, as doing so makes it more likely for your design to synthesize into a workable, solid netlist.
You have a schematic, so start by taking the major pieces of the design and implementing modules to do those functions. For example, you have a number of 2x1 muxes in the design. So, we should implement logic that selects from the correct input. Now, what is a mux? Well, it s a basic combinational function that looks like this:
S A B O
----------
0 0 x 0
0 1 x 1
1 x 0 0
1 x 1 1
Ie, if S is 0, O = A, if S is 1, O = B. So, we can reformat these to logical expressions: O = ~S & A | S & B (Note, if S = 0, we will pass A and the B term will be 0'd out, and vice versa if S is 1).
Now just implement that in Verilog gate primatives:
module mux2x1(input A,
input B,
input S,
output O);
wire AO, BO, NOT_S;
not n1(NOT_S, S); // NOT_S = ~S;
and a1(AO, A, NOT_S), // AO = A & ~S;
a2(BO, B, S); // BO = B & S;
or o1(O, BO, AO); // O = (A & ~S) | (B & S);
endmodule
Now, in order to increase the width of A, B and O, we need only make a bunch of these muxes for each bit of A, B and O. We can do that but generating a much of our mux module, or but doing it to the logic inside the module like so:
module mux2x1 #(parameter W = 1)
(input [W-1:0] A,
input [W-1:0] B,
input S,
output [W-1:0] O);
wire [W-1:0] AO, BO;
wire NOT_S;
genvar i;
not n1(NOT_S, S); // NOT_S = ~S;
generate begin
for (i = 0; i < W; i = i + 1) begin : mux_w
and a1(AO[i], A[i], NOT_S), // AO[i] = A[i] & ~S;
a2(BO[i], B[i], S); // BO[i] = B[i] & S;
or o1(O[i], BO[i], AO[i]); // O[i] = (A[i] & ~S) | (B[i] & S);
end
end
endmodule
Now that you see a worked through example, I hope you can work through doing other modules the same way (like the adder and 4x1 mux). This really wasnt a formal way of doing it, but it helps to just think things through. Also note there are plenty of adder architectures online if you are having trouble figuring out the logic.
I have two functions f and g:
let f (x:float) (y:float) =
x * y
let g (x:float) =
x * 2.0
I want to compose (>>) them to get a new function that performs f and then g on the result.
The solution should behave like:
let h x y =
(f x y) |> g
This does not work:
// Does not compile
let h =
f >> g
How should >> be used?
I think you want to achieve this:
let fog x = f x >> g
You can't compose them directly f >> g in that order, it makes sense since f expects two parameters, so doing f x will result in a partially applied function, but g expects a value, not a function.
Composing the other way around works and in your specific example you get even the same results, because you are using commutative functions. You can do g >> f and you get a composition that results in a partially applied function since g expects a single value, so by applying a value to g you get another value (not a function) and f expects two values, then you will get a partially applied function.
Writing in point-free style, i.e. defining functions without explicit arguments, can become ugly when the implicit arguments are more than one.
It can always be done, with the correct combination of operators. But the outcome is going to be a disappointment and you will lose the primary benefit of point-free style - simplicity and legibility.
For fun and learning, we'll give it a try. Let's start with the explicit (a.k.a. "pointful") style and work from there.
(Note: we're going to rearrange our composition operators into their explicit form (>>) (a) (b) rather than the more usual a >> b. This will create a bunch of parentheses, but it will make things easier to grok, without worrying about sometimes-unintuitive operator precedence rules.)
let h x y = f x y |> g
let h x = f x >> g
// everybody puts on their parentheses!
let h x = (>>) (f x) (g)
// swap order
let h x = (<<) (g) (f x)
// let's put another pair of parentheses around the partially applied function
let h x = ((<<) g) (f x)
There we are! See, now h x is expressed in the shape we want - "pass x to f, then pass the result to another function".
That function happens to be ((<<) g), which is the function that takes a float -> float as argument and returns its composition with g.
(A composition where g comes second, which is important, even if in the particular example used it doesn't make a difference.)
Our float -> float argument is, of course, (f x) i.e. the partial application of f.
So, the following compiles:
let h x = x |> f |> ((<<) g)
and that can now be quite clearly simplified to
let h = f >> ((<<) g)
Which isn't all that awful-looking, when you already know what it means. But anybody with any sense will much rather write and read let h x y = f x y |> g.
So, I was just thinking about how cool chaining is and how it makes things easier to read. With a lot of languages, when applying a bunch of functions to a variable, you'd write something like this:
i(h(g(f(x))))
And you have to read it from right-to-left or inner-most to outer-most. You apply f first, then g, and so forth. But if it were chained, it would look more like
x|f|g|h|i
And you could read it like a normal human being. So, my question is, there has to be some languages that do it that way, what are they? Is that what these fancy-pants functional programming languages do?
Because of this, I usually end up creating a whole bunch of temp variables so that I can split it onto separate lines and make it more readable:
a = f(x)
b = g(a)
c = h(b)
what_i_really_wanted_all_along = i(c)
Where's with my magical language, you could still split it onto different lines, if they're getting too long, without needing intervening variables:
x | f
| g
| h
| i
Yes, with F# you have a pipeline operator |> (also called forward pipe operator, and you have a backward pipe <|).
You write it like: x |> f |> g |> h |> i
Check this blog post that gives a good idea of real life usage.
It's not exclusive to functional programming, though it probably best implemented in functional languages, since the whole concept of function composition is squarely in the functional programming's domain.
For one thing, any language with object-oriented bent has chaining for methods which return an instance of the class:
obj.method1().method2().method3(); // JavaScript
MyClass->new()->f()->g()->i(); # Perl
Alternately, the most famous yet the least "programming-language" example of this chaining pattern would be something completely non-OO and non-functional ... you guessed it, pipes in Unix. As in, ls | cut -c1-4 | sort -n. Since shell programming is considered a language, I say it's a perfectly valid example.
Well, you can do this in JavaScript and its relatives:
function compose()
{
var funcs = Array.prototype.slice.call(arguments);
return function(x)
{
var i = 0, len = funcs.length;
while(i < len)
{
x = funcs[i].call(null, x);
++i;
}
return x;
}
}
function doubleIt(x) { print('Doubling...'); return x * 2; }
function addTwo(x) { print('Adding 2...'); return x + 2; }
function tripleIt(x) { print('Tripling...'); return x * 3; }
var theAnswer = compose(doubleIt, addTwo, tripleIt)( 6 );
print( 'The answer is: ' + theAnswer );
// Prints:
// Doubling...
// Adding 2...
// Tripling...
// The answer is: 42
As you can see, the functions read left-to-right and neither the object nor the functions need any special implementation. The secret is all in compose.
What you're describing is essentially the Fluent Interface pattern.
Wikipedia has a good example from a number of languages:
http://en.wikipedia.org/wiki/Fluent_interface
And Martin Fowler has his write up here:
http://www.martinfowler.com/bliki/FluentInterface.html
As DVK points out - any OO language where a method can return an instance of the class it belongs to can provide this functionality.
C# extension methods accomplish something very close to your magical language, if a little less concisely:
x.f()
.g()
.h()
.i();
Where the methods are declared thus:
static class Extensions
{
static T f<T>(this T x) { return x; }
static T g<T>(this T x) { return x; }
...
}
Linq uses this very extensively.
Haskell. The following three examples are equivalent:
i(h(g(f(x)))) (Nested function calls)
x & f & g & h & i (Left-to-right chaining as requested)
(i . h . g . f)(x) (Function composition, which is more common in Haskell)
http://www.haskell.org/haskellwiki/Function_composition
http://en.wikipedia.org/wiki/Function_composition_(computer_science)
I am not suggesting you could use Mathematica if you don't do some math usually, but it certainly is flexible enough for supporting Postfix notation. In fact, you may define your own notation, but let's keep with Postfix for simplicity.
You may enter:
Postfix[Sin[x]]
To get
x // Sin
Which translates to Postfix notation. Or if you have a deeper expression:
MapAll[Postfix, Cos[Sin[x]]]
To get:
(Postfix[x]//Sin)//Cos
Where you may see Postfix[x] first, as for Mathematica x is an expression to be evaluated later.
Conversely, you may input:
x // Sin // Cos
To get of course
Cos[Sin[x]]
Or you can use an idiom very frequently used, use Postfix in Postfix form:
Cos[x] // Postfix
To get
x // Cos
HTH!
BTW:
As an answer to Where's with my magical language,? , see this:
(x//Sin
// Cos
// Exp
// Myfunct)
gives
Myfunct[E^Cos[Sin[x]]]
PS: As an excercise to the readers :) ... How to do this for functions that take n vars?
As has been previously mentioned, Haskell supports function composition, as follows:
(i . h . g . f) x, which is equivalent to: i(h(g(f(x))))
This is the standard order of operations for function composition in mathematics. Some people still consider this to be backward, however. Without getting too much into a debate over which approach is better, I would like to point out that you can easily define the flipped composition operator:
infixr 1 >>>, <<<
(<<<) = (.) -- regular function composition
(>>>) = flip (.) -- flipped function composition
(f >>> g >>> h >>> i) x
-- or --
(i <<< h <<< g <<< f) x
This is the notation used by the standard library Control.Category. (Although the actual type signature is generalized and works on other things besides functions). If you're still bothered by the parameter being at the end, you can also use a variant of the function application operator:
infixr 0 $
infixl 0 #
f $ x = f x -- regular function application
(%) = flip ($) -- flipped function application
i $ h $ g $ f $ x
-- or --
x % f % g % h % i
Which is close to the syntax you want. To my knowledge, % is NOT a built-in operator in Haskell, but $ is. I've glossed over the infix bits. If you're curious, thats a technicality that makes the above code parse as:
(((x % f) % g) % h) % i -- intended
and not:
x % (f % (g % (h % i))) -- parse error (which then leads to type error)