In the Coq standard library, the "less than" relation is decidable for the natural numbers (lt_dec) and for the integers (Z_lt_dec). When I search however (Search ({ _ _ _ } + {~ _ _ _ })) I can't find a Q_le_dec or Qle_dec for the rationals, only Qeq_dec for decidable equality.
Is this because the "less than" relation is not decideable for the rationals in Coq? Or is it decideable but the decision procedure is just not implemented in the standard library?
A quick look at Coq's standard library gives two lemmas, albeit not in the exact form you have searched for:
Q_dec about the decidability of comparison ({x < y } + { x > y } + { x = y });
Q_lt_le_dec ({ x<y } + { y<=x }).
I admit I haven't made the exercise, but it seems like you can easily derive whatever decidability result over Qle or Qlt you want from there.
Related
I would like:
unknown_function(123.456) -> 456
unknown_function(1234.56) -> 56
Or
unknown_function(123.456) -> "456"
Is there a builtin for this? The builtin trunc/1 does the opposite:
2> trunc(123.456).
123
There is this answer for C: Extract decimal part from a floating point number in C and this for Java: How to get the decimal part of a float?
No there is no BIF for this, but you can do this:
decimal_point(X, DecimalDigits) when X < 0 ->
decimal_point(-X, DecimalDigits);
decimal_point(X, DecimalDigits)->
(X - trunc(X)) * math:pow(10,DecimalDigits).
> decimal_point(2.33, 2).
33
> decimal_point(-2.33, 2).
33
This is inspired by #Dogbert's comment
The algorithm doesnt work using native floats due to floating point representation limits and rounding errors.
However, using https://github.com/tim/erlang-decimal:
frac_to_denom_int(Num, Denom, Precison) ->
{X, _} = string:to_integer(lists:nth(2, string:tokens(decimal:format(decimal:divide(Num, Denom, [{precision, Precison}])), "."))),
X.
E.g.,
frac_to_denom_int("1.0", "3.0", 1000).
> 3333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333
If you don't have a frac,
d_to_denom_int(D_Tup)->
string:to_integer(lists:nth(2, string:tokens(decimal:format(D_Tup), "."))).
d_to_denom_int({0, 123456, -3}).
> 456
Based on #dogbert's comment, passing in one more flag compact on the float_to_list/2 call will help:
lists:nth(2, string:tokens(float_to_list(123.456, [{decimals, 10}, compact]), ".")).
% "456"
If you go over decimals 14, you'll start to see those rounding errors.
If I have two unknown values, lets say x and y, what is the best way loop through all of the values between between those values?
For example, given the values x = 0 and y = 5 I would like to do something with the values 0, 1, 2, 3, 4, and 5. The result could exclude 0 and 5 if this is simpler.
Using Swift's Range operator, I could do something like this:
for i in x...y {
// Do something with i
}
Except I do not know if x or y is the greater value.
The Swift documentation for Range Operators states:
The closed range operator (a...b) defines a range that runs from a to b, and includes the values a and b. The value of a must not be greater than b.
There are a number of solutions here. A pretty straight forward one is:
let diff = y - x
for i in 0...abs(diff) {
let value = min(x, y) + i
// Do something with value
}
Is there a better, or more elegant way to achieve this?
I guess the most explicit way of writing it would be:
for i in min(a, b)...max(a, b) {
// Do something with i
}
To exclude the first and last value, you can increment your lower limit and use the Swift ..< syntax:
let lowerLimit = min(a, b) + 1
let upperLimit = max(a, b)
for i in lowerLimit..<upperLimit {
// Do something with i
}
I can't understand why this one works:
var arr = [4,5,6,7]
arr.map() {
x in
return x + 2
}
while this one not
arr.map() {
x in
var y = x + 2
return y
}
with error
Playground execution failed: MyPlayground.playground:13:5: error:
cannot invoke 'map' with an argument list of type '((_) -> _)'
arr.map() {
The problem here is there error message. In general, when you see something like cannot invoke .. with ... it means that the compiler's type inference has just not worked.
In this case, you've run up against one of the limitations of inference within closures. Swift can infer the type of single-statement closures only, not multiple-statement ones. In your first example:
arr.map() {
x in
return x + 2
}
There's actually only one statement: return x + 2. However, in the second:
arr.map() {
x in
var y = x + 2
return y
}
There's an assignment statement (var y = x + 2), and then the return. So the error is a little misleading: it doesn't mean you "can't invoke map() with this type of argument", what it means to say is "I can't figure out what type x or y is".
By the way, in single-statement closures, there are two other things that can be inferred. The return statement:
arr.map() {
x in
x + 2
}
And the variable name itself:
arr.map() { $0 + 2 }
It all produces the same compiled code, though. So it's really a matter of taste which one you choose. (For instance, while I think the inferred return looks clean and easier to read, I don't like the $0, so I generally always put x in or something, even for very short closures. It's up to you, though, obviously.)
One final thing: since this is all really just syntax stuff, it's worth noting that the () isn't needed either:
arr.map { x in x + 2 }
As #MartinR pointed out, the compiler can infer some types from outer context as well:
let b: [Int] = arr.map { x in
var y = x + 2
return y
}
Which is worth bearing in mind. (it seems that the "one-statement" rule only applies when there's no other type info available)
Swift can't infer type every time. Even though it should see that y = x + 2 means y is an Int too. My guess is that Swift parses the closure in a certain order that makes it not aware of the return type ahead of time in your case.
This works:
arr.map() {
x -> Int in
var y = x + 2
return y
}
I'm trying to find the solutions of a function that contains a logical expression, but with no success so far.
First, I defined several functions:
isPlant(x) := is ((x = "tree") or (x = "grass"));
isAnimal(x) := is ((x = "cat") or (x = "dog"));
isLiving(x) := is (isAnimal(x) or isPlant(x));
Next, I tried to find all solutions of an equation with these functions, but none of the solutions were obtained:
solve([Living(x) = true], [x]); //this returns an empty list instead of [x = "cat", x = "dog", x = "tree", x = "grass"]
Is is possible to obtain solutions of these functions in Maxima?
The solve function assumes that the domain is a set of numbers. If we first specify the domain
(%i) domain : {"tree","grass","cat","dog"};
(%o) {cat, dog, grass, tree}
then we can use the subset function to find the solutions of the equations.
(%i) subset(domain,lambda([x], is(isPlant(x)=true)));
(%o) {grass, tree}
The functions you've defined are predicates, and so return the values true and false, which means that the equations predicate(x)=true are equivalent to predicate(x). For example, IsLiving(x)=true if and only if IsLiving(x). So rather than finding the elements of the domain which are solutions of the equation predicate(x)=true, we can find the elements of the domain which satisfy the predicate, which is more concise.
(%i) subset(domain,isLiving);
(%o) {cat, dog, grass, tree}
(%i) subset(domain,isPlant);
(%o) {grass, tree}
I am struggling to understand the cause of this issue. To the point:
1) Passing an integer ( 10 ) to the following factorization function works immediately:
test() ->
X = 10,
F = factorize(X).
factorize(0) -> 1;
factorize(N) -> N * factorize(N-1).
2) Passing a float ( 10.0 ) will cause the beam process to hang, taking high CPU and not even terminating. Notice this is a small value. I can factorize a high integer number and get an almost immediate response, but a small float number 10.0 will cause it hang.
test() ->
X = 10.0, <-- NOTICE THE DOT ZERO 10.0
F = factorize(X).
factorize(0) -> 1;
factorize(N) -> N * factorize(N-1).
Question: why on Erl Earth would this hanging occur with some mere multiplication recurrency of floats ?
As documentation says, there are two operations to compare equality of terms in Erlang and they differ only in handling integer and floats:
=:= - exactly equal - which counts numbers equal if the types are the same, and their values are the same too false = (0.0 =:= 0)
== - equal - counts numbers equal if their values are the same but their types may not be equal true = (0.0 == 0)
Pattern matching uses the first one - exactly equal - operator, that's why your function hanged in the second clause.
Another problem with floats is thier approximate value. You can never be sure you have some exact value especially after arithmetic operation. There is a common practice to use small value epsilon in floats equality tests.
is_zero(F) -> (F < 1.0e-10) andalso (F > -1.0e-10).