I am trying to compare 2 sets of element related by a binary relation which as an effect that
#set1 = #set0 + 2
Apparently in this expression the 2 is interpreted as {}, that is what the evaluator tells me, so the expression returns true.
The book says that + arithmetic operator is detected automatically. But apparently the problem is more about how to express the 2 in arithmetic. In the book I saw an example which is exactly what I want to do.
Moreover, when I calculate #Set, which contains set1+set0 the evaluator returns me a negative value.
Does someone have an idea about this?
Thanks in advance.
Try this:
sig A {}
sig B {}
pred show{ #A = add[#B, 2]}
run show for 5
As far as I understand there is special function for adding integers.
Let me know if I understood you right.
Related
I tried to calculate an exponential calculation, I tried both ways, writing it with the normal ** operator and the pow() function.
If I directly use numbers, everything works completely fine. But as soon as I use variables which get their value from input() functions the result is rounded, although I use the float argument.
I am quite new to coding, so please don't go to hard on me.
Code below:
pow(1.05,5), everything fine, result is 1.2762815625 and so on
float(pow(int(a),int(b)) the result is just 1.0, although it should be the same as above.
it is because you are doing the power operation on int i.e first you are converting the 1.05 to 1 by doing int(1.05) and then calculating the power(). you need to apply pow() on float()
print(float(pow(float(1.05),float(5))))
or either
print(pow(float(1.05),float(5)))
The reason the float function returns 1.0 is because of how it deals with integers.
For example:
integer = 5.5236734
print(float(integer))
The above code's output will be:
5.5236734
Now lets say you make some changes:
integer = 5.5236734
print(int(integer))
First, we made integer a decimal number, and then we said to print the int() form of the decimal.
This will be the result:
5
So, to fix your code, you just need to do this:
a = 1.05
b = 5
print(float(pow(a, b)))
Which will output:
1.2762815625000004
Hope this helps!
The question probably has a yes/no answer. Consider the snippet:
sig A { my : lone B }
sig B { }
pred single1 [x:A]{ // defined using []
#x.my = 0
}
pred single2 (x:A){ // defined using ()
#x.my = 0
}
// these two runs produce the exact same results
run single1 for 3 but exactly 1 A
run single2 for 3 but exactly 1 A
check oneOfTheMostTrivialQuestionsOnStackOverflow { all x: A |
single1[x] iff single2[x] // pred calls use [], so as expected, single2(x) would cause a syntax error
} for 3000 but exactly 1 A // assertion holds :)
Are single1 and single2 exactly the same?
They seem to be, but am I missing something?
When we extended the syntax in Alloy 4, we changed the predicate invocations to []. My recollection is that we did it to make parsing easier, so that if you had a predicate P with no args, you could call it as just "P", and there would be no problems if it were followed by a formula in parens "P (...)". As Peter notes, it also seemed reasonable since it's similar to the relational lookup operator, and this makes sense especially for functions. We added the ability to declare predicates and functions with [] for consistency, but saw no reason to prevent () in decls (since there's no possible ambiguity there).
I think the parentheses were originally used for predicates and functions. However, they were changed in favour of the square brackets because it made it look more relational. I vaguely recall that Daniel Jackson explains this in his book.
That said, why ask because you seem to have proven it yourself? :-)
I was experimenting with alloy and wrote this code.
one sig s1{
vals: some Int
}{
#vals = 4
}
one sig s2{
vals: some Int
}{
#vals = 4
}
fact {
all a : s1.vals | a > 2
all i : s2.vals | i < 15
s1.vals = s2.vals
}
pred p{}
run p
It seems to me that {3,4,5,6} at least is a solution however Alloy says no instance found. When I comment s1.vals = s2.vals or change i < 15 to i > 2, it finds instances.
Can anyone please explain me why? Thanks.
Alloy's relationship with integers is sometimes mildly strained; it's not designed for heavily numeric applications, and many uses of integers in conventional programming are better handled in Alloy by other signatures.
The default bit width for integers is 4 bits, and Alloy uses twos-complement integers, so your run p is asking for a world in which integers range in value from -8 to 7. In that world, the constraint i < 15 is subject to integer overflow, and turns out to mean, in effect, i < -1. (To see this, comment out both of your constraints so that you get some instances. Then (a) leaf through the instances produced by the Analylzer and look at the integers that appear in them; you'll see their range is as I describe. Also, (b) open the Evaluator and type the numeral "15"; you'll see that its value in this universe is -1.)
If you change your run command to provide an appropriate bit width for integers (e.g. run p for 5 int), you'll get instances which are probably more like what you were expecting.
An alternative change, however, which leads to a more idiomatic Alloy model, is to abstract away from the specific kind of value by defining a sig for values:
sig value {}
Then change the declaration for vals in s1 and s2 from some Int to some value, and comment out the numeric constraints on them (or substitute some other interesting constraints for them). And then run p in a suitable scope (e.g. run p for 8 value).
Example :
if(A & B)
{
if(C)
{
}
if(D)
{
}
}
We have four different states for all the conditions in this code.
0 represents False and 1 represents true state.
* shows that the condition is not valid in this state flow.
So in this case, all the possible states are listed below.
A B C D
0 * * *
1 0 * *
1 1 1 0
1 1 0 1
Explanation :
In first state (0 * * *), the condition A is true. So there is no role for B in the code. Becuase after evaluating the A itself the if case is failed. Therefore the conditions C and D also are not evaluated.
Like wise the three other possible states also.
But is there any already implemented algorithms by which i can find all these states for a particular input. Because this thing turns to be huge complex problem when we try to solve more complex nested code.
I think it's very difficult to code an application to give such a result.
If any one knows some kind of already implemented things which may help me, please let me know about the same.
I'm sorry to be the bearer or bad news but this algorithm is impossible for two, very famous reasons.
The Halting Problem
To solve this problem in a Turing-Complete language you would need to solve the The Halting problem. If your example program looked like this:
if(A & B & maybeAnInfiniteLoop())
{
if(C)
{
}
if(D)
{
}
}
Then we would have no theoretic way of know if the function maybeAnInfiniteLoop terminates or not and thus if C and D matter at all or if the only valid states of the booleans are 00*,10*, or 01*, since 11* would never finish and C and D are never reached.
NP-Complete
Now let's suppose your capable of reducing your problem just to boolean expressions. In a subset of your language where you only have IF, AND, OR, NOT and booleans the language is not Turing Complete. It is what is called strongly normalizing. The language of boolean expressions is an example of one such useful language.
However even if we can guarantee that the program halts, an algorithm to decide all meaningful states of booleans in that language is an NP-complete problem. It is, in fact, among the most famous. It's called the Boolean Satisfiability Problem. Notice that in your example you say that C and D are meaningless when either A or B are false. This is because you know that only set of values for A and B that satisfy the expression "A&B" is (1,1). You can do this because it's a very simple expression but an algorithm to solve this in the general case might not finish in your lifetime for some very reasonable inputs.
Is there hope?
The question of P=NP does not have a known answer. In fact, it is possibly the most important open math question today. If P=NP then you're in luck but I wouldn't get your hopes up. The smart money is on P does not equal NP.
Consider the following example in e:
var a : int = -3
var b : int = 3
var c : uint = min(a,b); print c
c = 3
var d : int = min(a,b); print d
d = -3
The arguments inside min() are autocasted to the type of the result expression.
My questions are:
Are there other programming languages that use type autocasting, how do they treat functions like min() and max()?
Is this behavior logical? I mean this definition is not consistent with the following possible definition of min:
a < b ? a : b
thanks
There are many languages that do type autocasting and many that will not. I should say upfront that I don't think it's a very good idea, and I prefer a more principled behavior in my language but some people prefer the convenience and lack of verbosity of autocasting.
Perl
Perl is an example of a language that does type autocasting and here's a really fun example that shows when this can be quite confusing.
print "bob" eq "bob";
print "nancy" eq "nancy";
print "bob" == "bob";
print "nancy" == "nancy";
The above program prints 1 (for true) three times, not four. Why not the forth? Well, "nancy" is not == "nancy". Why not? Because == is the numerical equality operator. eq is for string equality. The strings are being compared as you might thing in eq but in == they are being converted to number automatically. What number is "bob" equally to? Zero of course. Any string that doesn't have a number as its prefix is interpreted as zero. For this reason "bob" == "chris" is true. Why isn't "nancy" == "nancy"? Why isn't "nancy" zero? Because that is read as "nan" for "not a number". NaN is not equal to another NaN. I, personally, find this confusing.
Javascript
Javascript is another example of a language that will do type autocasting.
'5' - 3
What's the result of that expression? 2! Very good.
'5' + 3
What's the result of that one? 8? Wrong! It's '53'.
Confused? Good. Wow Javascript, Such Good Conventions, Much Sense. It's a series of really funny Javascript evaluations based on automatic casting of types.
Why would anyone do this!?
After seeing some carefully selected horror stories you might be asking yourself why people who are intelligent enough to invent two of the most popular programming languages in the entire world would do something so silly. I don't like type autocasting but to be fair, there is an argument for it. It's not purely a bug. Consider the following Haskell expression:
length [1,2,3,4] / 2
What does this equal? 2? 2.0? Nope! It doesn't compile due to a type error. length returns an Int and you can't divide that. You must explicitly cast the length to a fraction by calling fromIntegral in order for this to work.
fromIntegral (length [1,2,3,4]) / 2
That can definitely get quite annoying if you're doing a lot of math with integers and floats moving about in your program. But I would greatly prefer that to having to understand why nancy isn't equal to nancy but chris is, in fact, equal to bob.
Happy medium?
Scheme only have one number type. It automatically converts floats and fractions and ints happy and treats them just as you'd expect. It will allow you to divide the length of a list without explicit casting because it knows what you mean. But no, it will never secretly convert a string to a number. Strings aren't numbers. That's just silly. ;)
Your example
As for your example, it's hard to say it is or is not logical. Confusing, yes. I mean you're here on stack overflow aren't you? The reason you're getting 3 I think is either -3 is being interpreted, like Ross said, as a unit in 2's compliment and is a much higher number or because the result of the min is -3 and then it's getting turned into an unsigned int by dropping the negative. The problem is that you asked it for asked it to put the result into an unsigned int but the result is negative. So I would say that what it did is logical in the context of type autocasting, but that type autocasting is confusing. Presumably, you're being saved from having to do explicit type casting all over the place and paying for it with weird behavior like this on occasion.