Discussions related to Visual Prolog
Eftychios
Posts: 14
Joined: 19 Feb 2014 10:37

Increase integer variable

Unread post by Eftychios »

Hello,

if i have an integer variable Counter = 100

and i want this variable to make it + 1 so the new one will be 101. How can i do this?

In java we can write Counter = Counter + 1;


To be more specific i have made something like this

Code: Select all

for each Counter = std::downTo(20, 1) do      if Button:getLabel <> "Number" then          %do some things here    else             Counter = Counter + 1    <----- What i want to do is if the label is equals to something then to try
again without decrease the counter.
end foreach.

Thanks in advance.
User avatar
Tonton Luc
VIP Member
Posts: 204
Joined: 16 Oct 2001 23:01

Unread post by Tonton Luc »

Hi,

You can use this :

Code: Select all

facts counter:interger:=erroneous.   goal counter := 100, foreach _Cpt = std::fromTo(0,10) do     stdio::write(counter),stdio::nl,     counter := counter + 1 end foreach,
Eftychios
Posts: 14
Joined: 19 Feb 2014 10:37

Unread post by Eftychios »

Thank you very much .... it works fine :)
User avatar
Thomas Linder Puls
VIP Member
Posts: 1398
Joined: 28 Feb 2000 0:01

Unread post by Thomas Linder Puls »

In general you should write your algorithms in a way which does not need such mutable variables, for example by using recursion instead of foreach.

Butt there are situations where you may want to have such side effects anyway. In such cases, you should not use a fact variable as suggested by Tonton Luc (sorry, TonTon ;-)). Facts should be used to hold the state of your program, not to be temporaries for algorithms.

A much better solution is to use a varM:

Code: Select all

goal     Counter = varM::new(100),     foreach _Cpt = std::fromTo(0,10) do         stdio::write(Counter:value), stdio::nl,         Counter:value := Counter:value + 1     end foreach.
But as mentioned you should perhaps rather use a recursive predicate (even if the code looks more difficult):

Code: Select all

clauses     something(N, Cnt1) = Cnt0 :-         if N = 0 then             Cnt0 = Cnt1         else             if test(...) then                 % some code                 Cnt2 = Cnt1             else                 Cnt2 = Cnt1+1             end if,             Cnt0 = something(N-1, Cnt2)         end if.
Regards Thomas Linder Puls
PDC
User avatar
Tonton Luc
VIP Member
Posts: 204
Joined: 16 Oct 2001 23:01

Unread post by Tonton Luc »

Ok, thanks Thomas.
I did not know that varM was better in this case.
Harrison Pratt
VIP Member
Posts: 439
Joined: 5 Nov 2000 0:01

Unread post by Harrison Pratt »

Question for Thomas:

Is this somewhat equivalent code compiled to better/worse/same code as the if/then/else syntax?

Code: Select all

    something(0, Cnt) = Cnt :- !.     something(N, Cnt1) = Cnt0 :-         0 = N mod 2 , % if test(...) then         !,         Cnt0 = something( N-1, Cnt1 ).     something(N, Cnt) = Cnt0 :-         Cnt0 = something( N-1, Cnt + 1 ).
I find the if/then/else syntax to be visually bulky and harder to debug for more complex code, but of course that's just personal preference.

Disclaimer: code compiled but was not tested. :wink:
User avatar
Thomas Linder Puls
VIP Member
Posts: 1398
Joined: 28 Feb 2000 0:01

Unread post by Thomas Linder Puls »

Choosing between if-then-else and backtracking+cut is more free. I/we do however use if-then-else more and more. The flow in if-then-else is clear and clean. Backtracking can be more complex, running a little several clauses:

Code: Select all

clauses     p(X) :-         X > 10,         pp1(X),         X < 20,         !,         pp2(X).       p(X) :-         pp3(X),         X < 30,         !,         pp4(X).       p(X) :-         pp5(X).
The code above is "silly", trying to rephrase it using if-then-else is quite difficult (which kind of prove that the code is "silly"). A potential problem with backtracking+cut is that code as above can evolve over time (during maintenance).
Regards Thomas Linder Puls
PDC
Harrison Pratt
VIP Member
Posts: 439
Joined: 5 Nov 2000 0:01

Unread post by Harrison Pratt »

Thanks, Thomas. I understand your meaning.
Code maintainability (by ordinary mortals) and clarity should be the first consideration.
Post Reply