memo package - persistent memoisation

"Abdallah, Samer" <[email protected]> Fri, 18 Apr 2014 14:21:19 +0000
Newsgroups gmane.comp.ai.prolog.swi
Message-ID <[email protected]>
Hello all,
Inspired by Jan's persistency library, I've release a new package called 'memo'
for doing memoisation. Don't get too excited - it doesn't do tabling of nondeterministic
predicates like XSB or YAP, it's intended for deterministic predicates that 
do a lot of computation. I'm using it for doing machine learning experiments where
there are lots of models, parameters and datasets to try in different combinations.
I had an old system for doing this using an external database, ODBC, meta-interpreters
etc but it feels a bit heavy now (not to mention almost impossible for anyone else
to install). This new version uses term expansion and relies on the persistency 
module to handle the database.

	http://www.swi-prolog.org/pack/list?p=memo

I'm posting this to the list because I would be interested if anyone has any comments
about the interface. For example:
	- should calls to the memoised predicate stick to the declared mode for
   		the underlying predicate (i.e. ground inputs, unbound outputs), or would
		it be better to allow calls with unbound inputs to just look up old results?
		At the moment, the mode is checked strictly, and you have to use the 
		browse/{1,2} meta-call operator to look-up old computations.

	- is the 'meta-level' interface at the right level, with browse/{1,2}, compute/{1,2},
		memo/{1,2}, and clear/{1,2} ?

	- should I factor out some of the component functionalities, which at the moment, are
		1. type checking
		2. recording of time, duration and hostname of computations
		3. reification of failures and exceptions
		4. memoisation

	- would it make any sense to have a 'current modality' for calls to a memoised
		predicate? What I mean is, if you declare foo/2 as memoised then calling
		foo(X,Y) currently calls memo(foo(X,Y)), i.e. looks up old computations and
		computes and stores if not found. If alternative modes 'browse' and 'compute'
		were added, and the mode set to 'browse', then
		foo(X,Y) would map to browse(foo(X,Y)) so that only old results would be
		checked. If the mode was set to 'compute', then a new computation would be
		done and not stored every time, and so on. This would mean that predicates
		which are not themselves memoised, but call a memoised predicate, would
		inherit the current mode.
	
Also, looking at the now very large persistent database on disk makes me wonder 
if there is might be way to keep it in a compressed form without impacting too much on
performance. Jan?

Finally, now there is a cleanly separated interface for persistency, it might be nice
to allow switching to an SQL-light or ODBC connected database behind the scenes.

cheers,
Samer.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.iai.uni-bonn.de/pipermail/swi-prolog/attachments/20140418/0f7ae554/attachment.bin>