reading back old number formats

Discussions related to Visual Prolog
B.Hooijenga
VIP Member
Posts: 96
Joined: 11 Jul 2002 23:01

reading back old number formats

Unread post by B.Hooijenga » 20 Nov 2008 14:17

Hello,

I have a file with 10000 records.
Each record is a named_value_list.
My vip71 program makes the file and reads it back without problems
My vip72 program refuses to read it. I get an internal error.
Also, the vip71 program will not read such a file made by vip72
I presume that the problem lies in the fact that each record contains a gmtTimeValue which has now a 64 bit number format .
Does that mean that I have to write a conversion-program in vip71 with the time in another format.
And then convert it in vip72 into the new format?.
Or is there another less time-consuming solution?

By the way, nothing against the wiki or the acrobat-reader, but I would be very glad with a complete helpfile.

Kind regards,

Ben

User avatar
Jan de Lint
VIP Member
Posts: 239
Joined: 6 Mar 2000 0:01

Unread post by Jan de Lint » 20 Nov 2008 19:41

Ben, why don't you use the time in string format? (yyyymmddhhmm etc.)
Even double byte and times 10000 that is not such a big deal, and conversion is easy.
It makes it readable as well.
]an

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

Unread post by Thomas Linder Puls » 21 Nov 2008 0:24

The structs from Vip7.1 still exist in Vip 7.2, but the domains have got new names (in core):

Code: Select all

domains     unsigned64_struct = unsigned64(unsigned Low, unsigned High).   domains     integer64_struct = integer64(unsigned Low, integer High).
There are also conversions predicates (also in core):

Code: Select all

predicates     toUnsigned64 : (unsigned64_struct) -> unsigned64.     fromUnsigned64 : (unsigned64) -> unsigned64_struct.     toInteger64 : (integer64_struct) -> integer64.     fromInteger64 : (integer64) -> integer64_struct.
Let us assume that you file is a save of the following Vip7.1 fact database:

Code: Select all

class facts     myFact : (string Event, gmtTimeValue Time).
In Vip7.1 the gmtTimeValues was unsigned64 "structs", so the files contains facts of the form:

Code: Select all

myFact("PPP",unsigned64(123123,1231313)).
In Vip7.2 this corresponds to the following fact database:

Code: Select all

class facts - myDB     myFact : (string Event, unsigned64_struct Time).
You will have to insert a call to toUnsigned64 to convert the unsigned64_struct to an unsigned64 before you construct a time object.

If you want so make a transition from the old format to a new file format you can introduce a new fact in addition to the old one:

Code: Select all

class facts - myDB     myFact : (string Event, unsigned64_struct Time).     myFact2 : (string Event, gmtTimeValue Time).
The load predicate will consult the file containing either old or new facts, and then it will convert all old facts to new facts (a later save will save all of them as new facts):

Code: Select all

class predicates     load : (string). clauses     load(File) :-         file::consult(File, myDB),         foreach retract(myFact(Event, TimeStruct)) do             assert(myFact2(Event, toUnsigned64(TimeStruct)))         end foreach.
Regards Thomas Linder Puls
PDC

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

Unread post by B.Hooijenga » 21 Nov 2008 15:50

Hello Jan and Thomas,

Jan,

At consult-time the file is put into an internal database.
But I prefer having the facts in an object-oriented database.
The reason is that I feel that the data is easier to manage and it works faster .

For that purpose I have to convert each record into an object.
During that process every element of a named-value list becomes a property in the object.
Vip does that very fast and for elements of a named-value_list it has even special predicates.

Now, the internal database (VIP71) looks like

Code: Select all

giro([...,...,namedvalue("naa",string("testing")),namedvalue("dat",gmttimevalue(unsigned64(2835339264,28660266)))]). giro([...,...,namedvalue("naa",string("testing2")),namedvalue("dat",gmttimevalue(unsigned64(2835339264,28660266)))]).
The object has facts and constructor something like

Code: Select all

facts    datum : time := erroneous.    naam : string := "".    .......    .......   clauses: new(NamedValueList) :-         datum := time::newFromGMT(namedValue::getNamed_gmtTimeValue(NamedValueList, "dat")),         naam := namedValue::getNamed_string(NamedValueList, "naa"),         ......,         .......      
As you can see Time is stored as an object_pointer into datum.

It is possible to choose another constructor

Code: Select all

new : (Year, Month, Day, Hour, Minute, Second).
But then I have to deal with 6 extra elements in the named_value_list or one time-formatted string which I have to split into 6 elements.

Anyway, in my opinion, using a gmtTimeValue - element in the internal database is by far the most elegant and fastest approach.


Thomas,

thanks for your instructive answer.
I am afraid however, that the assumption you make is not the right one for me.
I was speaking about a gmtTimeValue in a namedValueList.

The database I have to consult is declared as

Code: Select all

class facts - giroposten     giro : (core::namedValue_list).
At consulttime Vip72 reads a list-element like

Code: Select all

namedvalue("dat",gmttimevalue(unsigned64(2835339264,28660266)
with the new structure and I would not know how to change that.

Kind regards

Ben

User avatar
Jan de Lint
VIP Member
Posts: 239
Joined: 6 Mar 2000 0:01

Re:

Unread post by Jan de Lint » 21 Nov 2008 20:59

B.Hooijenga wrote:Hello Jan and Thomas,

Anyway, in my opinion, using a gmtTimeValue - element in the internal database is by far the most elegant and fastest approach.
Ben,
I have a lot of files with planning dates in the old VIP 5.x dt_date format which must now be read/consulted by both VIP 5.x and VIP 7.2 programs. I have it working for 7.1 and now again I have to make it work for 7.2. Don't get me wrong, I still think it is worth the effort.
I would never again store such data in a proprietary database using proprietary domains. If you want to handle the data the academic way, but still maintain the operational status, you should be prepared for conversions and perhaps even manual handling.
In this particular case I assume you have got to write some sort of non straight-forward conversion routine (in 7.1?) to create a new file which can be consulted by VIP72. That is, unless Thomas helps you out!
Succes,
]an

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

Unread post by Thomas Linder Puls » 21 Nov 2008 23:36

I believe my approach can be used.

You code is something like:

Code: Select all

facts - giroDB     giro : (namedValue* Attributes).
Somewhere you define a namedValue domain that is compatible with the old domain:

Code: Select all

domains     namedValue71 = namedValue(string Name, vlaue71 Value).   domains     value71 =         ...         gmtTimeValue(unsigned64_struct Value);         ...
You also define and implement a predicate that can convert from the old namedValue lists to the new ones:

Code: Select all

predicates     toNamedValueList : (namedValue71 Old) -> namedValue New.
I leave the implementation to yourself; it will take less than 100 lines of straight forward code.

You change your fact database like this:

Code: Select all

facts - giroDB     giro : (namedValue71* Attributes).     giro2 : (namedValue* Attributes).
And use code similar to the one I showed above:

Code: Select all

clauses     load(...) :-         file::consult(...),         foreach retract(giro(OldList)) do             assert(giro2(toNamedValueList(OldList)))         end foreach.
This code will load both old and new files (and even files in mixed format).

(If you want to do a conversion of the files you can keep the old functor names. The conversion program will have two fact databases with same fact name (so they have to be in each their class)).
Regards Thomas Linder Puls
PDC

Post Reply