varM versus fact-variables

Discussions related to Visual Prolog
dominique f pannier
VIP Member
Posts: 98
Joined: 23 Sep 2002 23:01

varM versus fact-variables

Unread post by dominique f pannier » 2 Jan 2012 10:30

Hi,
First, Happy new year !

I usually used fact-variables to collect informations which have to be handled in a predicate - an object one in the following example:

Code: Select all

facts      f : (string A, string B) nondeterm. clauses     f("A1", "B1").     f("A2", "B2").     f("A3", "B3"). facts      holder : string_list := []. predicates      p : () -> string_list Result. clauses p() = _ :-      holder := [],      f(A, B),      holder := append(holder, [A]),      fail(). p() = holder.
But after reading differents posts referring the new class varM added in VIP 7.3, it seems preferable to use a varM object :

Code: Select all

facts      f : (string A, string B) nondeterm. clauses     f("A1", "B1").     f("A2", "B2").     f("A3", "B3"). predicates      p : () -> string_list Result. clauses p() = Holder:value :-      Holder = varM::new([]),      foreach f(A, B) do           Holder:value := append(Holder:value, [A]),      end foreach.
Is it right, and if yes why ?
Regards
Dominique Pannier

User avatar
Tonton Luc
VIP Member
Posts: 502
Joined: 16 Oct 2001 23:01

Unread post by Tonton Luc » 2 Jan 2012 12:36

Hi,

:idea:

Code: Select all

facts      f : (string A, string B) nondeterm. clauses     f("A1", "B1").     f("A2", "B2").     f("A3", "B3"). predicates      p : () -> string_list Result. clauses p() = [X||f(X,_)].

Steve Lympany
VIP Member
Posts: 119
Joined: 31 Mar 2001 23:01

Unread post by Steve Lympany » 2 Jan 2012 12:38

Hi,
Facts should be used to describe some state of the object, or important value for the object. For unimportant / transient etc values, like counters, varM should be used.
cheers
s

Harrison Pratt
VIP Member
Posts: 295
Joined: 5 Nov 2000 0:01

Unread post by Harrison Pratt » 2 Jan 2012 15:31

This still confuses me ... are there performance advantages to using varM or is it a matter of sytactic purity?

My practice has been, when necessary, to use an internal database which is not visible or accessible globally. I name these databases something like tempDB and only implement save when I need to sort out some problem with intermediate data during development.

To me, using varM seems appropriate for variables which need to be global to the application, but not for ones internal to the class or its objects.

Trying not to be evil ... but probably still confused. :?

dominique f pannier
VIP Member
Posts: 98
Joined: 23 Sep 2002 23:01

Unread post by dominique f pannier » 3 Jan 2012 10:10

Thanks for your reply.
You are right, Tonton, it's an evident simplification.
But about the general case, I'm still in confusion, like Harrison. Thomas gave his opinion, about this subject :
http://discuss.visual-prolog.com/viewto ... light=varm
but did not tell his reasons.
In that other post, he told the same thing like Steve.
http://discuss.visual-prolog.com/viewto ... light=varm
But it is not really clear for me.
Could you give to me, Steve, an example of a fact-variable describing some state of the object ?
Regards
Dominique Pannier

dominique f pannier
VIP Member
Posts: 98
Joined: 23 Sep 2002 23:01

Unread post by dominique f pannier » 3 Jan 2012 10:22

:idea:
I got an idea of describing some state of the object.
I supposed I made the calculation of p() predicate. But I need to keep the result for an other one future usage. In that case, I store it in a fact-variable. Is it at something like that you mean ?
Regards
Dominique Pannier

Steve Lympany
VIP Member
Posts: 119
Joined: 31 Mar 2001 23:01

Unread post by Steve Lympany » 3 Jan 2012 16:35

Hi,
If you have an object "door", the states could be "open", "opening", "closing", "closed".

For an object "boiler", there could be several variables/facts eg current temperature, pressure, size.

But you could also have a state whereby an object can check itself for safety or consistency - like an SQL database. For the boiler, there could be two overall states "good", and "blown up" (and therefore non-recoverable).

You could use VIP's "property" for those too.

You wouldn't want to store "number of iterations" for a boiler thermal calculatrion: it's not very interesting!

http://en.wikipedia.org/wiki/Shlaer%E2% ... lor_method

This is quite a nice method for some cases. In your class design, you draw a table, with "states" as the columns, and "messages" for the rows. The messages are essentially predicates. In each table cell, there is an action, which, when the object receives a message in one state, it [can] jump to another state. You can make objects (and your software) very robust, because you can do error checking in a very methodical way. And every table cell must be defined.

So if your door object receives a message "open door", and the state is already "open", you can control how the object should behave.

cheers
s

dominique f pannier
VIP Member
Posts: 98
Joined: 23 Sep 2002 23:01

Unread post by dominique f pannier » 4 Jan 2012 9:17

Thanks Steve for you explanation and the link. It gives an interesting conceptual framework of an object, which seems especially designed for VIP...
Then now, I think that using varM is not a matter of syntactic purity, like told Harrison.
But its simultaneaous usage with fact-variables gives more visibility in the code. I'm now using varM for ordinarily collecting values, and my facts-variables for holding various results accessible as properties instead of like a skivvy :-) previously...
Regards
Dominique Pannier

Harrison Pratt
VIP Member
Posts: 295
Joined: 5 Nov 2000 0:01

Unread post by Harrison Pratt » 5 Jan 2012 7:20

Thanks for the discussion everyone!

I think I have the concept ...

(1) Facts are class or object attributes of interest having some expectation of persistence, including class or object states of immediate or possible future interst.. Using facts for volatile "variable" data that is really of use only transiently (e.g., a counter or summation) during the process of determining persistent class or object attributes violates the VIP object model (in concept) although the code will "work" using this flawed model.

(2) Using varM is simpler to program (even if using single facts and a temporary database) since a "temporary" database and its maintenance clauses do not need to be defined for each data type used in those clauses which could otherwise use varM. As a work saving feature, varM appears to accept "anyterm" for storage.

(3) I would guess, but don't really know, that varM initializes an area in memory that is reused when the value of the mutable variable is changed ... right??? If so, this should be more efficient computationally than using a class or obect database.

So .... am I closer to understanding varM? :? It's been a worthwhile discussion.

User avatar
Ferenc Nagy
VIP Member
Posts: 289
Joined: 24 Apr 2007 12:26

Can I store integers, reals and any other types in a "varM" object?

Unread post by Ferenc Nagy » 9 Dec 2012 8:37

I understand that fact variables and the varM objects are two different ways of smuggling back the mutable variables omitted from older versions of Turbo and Visual Prolog.
The above header of varM.i is very short.
What does
{@Term}
mean in the above interface command?
Somewhere I saw an add procedure but there I see only the value property.
TIA, Regards,
Frank Nagy

B.Hooijenga
VIP Member
Posts: 69
Joined: 11 Jul 2002 23:01

Unread post by B.Hooijenga » 9 Dec 2012 10:19

Hello,

I understand it as follows:

varM is an abstract data type.
This means that it can hold different datatypes.

varM is an object class. Every varMobject holds a datavalue.
Therefore it can replace several (fact)variables.

@Term stands for the datatype.
If you give the constructor 123. the compiler sees it as an number.
If you give "hello" it makes a string of it.

Code: Select all

class predicates      test:(). clauses     test():-         A = varM::new(123),         B = varM::new("Hello"),         stdio::writef("A =  %,B = %\n",A:value,B:value).    
Kind regards
Ben.

User avatar
Thomas Linder Puls
VIP Member
Posts: 1641
Joined: 28 Feb 2000 0:01

Unread post by Thomas Linder Puls » 9 Dec 2012 12:19

Code: Select all

interface varM{@Term}


means that the interface varM is parameterized (with one parameter called @Term). The scope of such a parameter is the entire interface, and therefore we have decided to give it the special syntax with the '@'.

The description in the language reference contains examples that should help you to understand the ideas: Language Reference/Generic Interfaces and Classes.

I consider generic classes and interfaces a major feature of Visual Prolog. You may not use it directly, but it is the thing, that has made it possible for us to make the highly useful Collection Library.

I only have one thing to says about the Collection Library: Use it!!! ;-)
Regards Thomas Linder Puls
PDC

User avatar
Ferenc Nagy
VIP Member
Posts: 289
Joined: 24 Apr 2007 12:26

How can I preset the exact length the created integer and real varM objects?

Unread post by Ferenc Nagy » 10 Dec 2012 12:33

I see that the type of the varM object is inherited from the type of the parameter its constructor.
But the

Code: Select all

123
in

Code: Select all

I=varM::new(123)
may be positive, positive optional, short, long, unsigned, 8-bit, 16-bit integer. Similar ambiguity emerges from

Code: Select all

R=varM::new(123.456E-12)
creating a real variable. How can I force the constructor to create a given kind of integer and real variable?
TIA, Regards,
Frank Nagy

User avatar
George
VIP Member
Posts: 313
Joined: 19 Sep 2011 8:54

Unread post by George » 10 Dec 2012 12:45

:idea:

The following is the sample code for it.

Code: Select all

        A = varM{real}::new(1.22), %define the type while creating the object for it..         B = varM{integer}::new(10),         C = varM{real}::new(123.456E-12),         D = varM{real*}::new([1.221]),         E = varM{integer*}::new([322]),         A:value := A:value + 1.3,         B:value := B:value + 10,         C:value := B:value + 23.32523E-10,
Kind Regards,
George Ananth. S | Prolog Developer
georgeananth.prolog@gmail.com
+91 9791499282

User avatar
Thomas Linder Puls
VIP Member
Posts: 1641
Joined: 28 Feb 2000 0:01

Unread post by Thomas Linder Puls » 10 Dec 2012 13:52

While it is correct that you can add explicit parameters to the class name in the constructor it is very seldom necessary.

The reason is that it is not just the type of the arguments supplied to the constructor that decides the type, how you use the constructed object is also taken into account.

It is no different from creating a list: X = [123] here the type of 123 is just as under-determined as in the varM example.

Consider the even more under-determined case of creating an empty map:

Code: Select all

clauses     p() :-         M = mapM_redBlack::new(), % the type of the created map is determined by the subsequent usage of M         foreach X = list::getMember_nd([1,2,3]) do            M:insert(X, toString(X))  % this still leaves M a little under-determined         end foreach         q(M).  % But here M's type will (most likely) be determined by the type of q
Again it the completely similar to the use of lists:

Code: Select all

clauses     p() :-         L = [], % the type of the empty list is determined by the subsequent usage of L         L2 = [tuuple(X, toString(X) || list::getMember_nd([1,2,3], % this changes nothing         L3 = list::append(L2, L), % this stille leaves L a little under-determined         q(L3).  % But here L's type will (most likely) be determined by the type of q
Regards Thomas Linder Puls
PDC

Post Reply