Archived News: 2007-01

2007-01 31:

As the Mercury standard library does not have a matrix
protocol, I am building a module that handles some basic
matrix operations; this module and its test suites will
be added to the
utils
library when in serviceable condition.

30:

Thanks to the efforts of the Mercury research group at
Melbourne, their Mercury compiler (mmc) is now
available for Macintosh computers with the Intel chipset. This
is the alpha ROTD (2007-01-21) as opposed to the currently
sanctioned 0.13.1 release, so some things are experimental
in this version of the compiler. Email logicaltypes.com
if you wish to have a binary distribution.

Our compiler, ltq (that allows syntactic
extensions with the op/3 directive, see the news
archives at
2006-03-02), may need
some work as the Mercury research team has changed the
ops module. This, of course, also means that
systems that depend on these improvements, such as the
test-building framework qcpt (see news archive
post 2006-05-12),
must also be retested. We will post an update when
qld is again tested and working.

Libraries

Libraries, etc.
       
Logical types has the following libraries, systems, and sample code.  All provided with the usual caveats (they are not guaranteed to work, and Logical Types is not liable for you downloading and using this code):
      
      
 
      
Libraries
      
   utils
        
a set of utilities useful for building production systems     
contains modules:       
         
    
Module
    
test status
    
documentation
         
         
utils
    
1/4 submodules tested
no
         
utils.graph
    
0/1 new preds tested
no
         
utils.random
    
0/10 preds tested
no
         
utils.series
    
3/3 preds/funcs tested
no
         
utils.xml
    
2/3 submodules tested
no
         
utils.xml.facade
    
1/1 pred tested
no
         
utils.xml.pprint
    
2/2 preds tested
no
         
utils.xml.transform
    
4/9 funcs/preds tested
    
no
       
   
      
      
qcheck2
        
A testing/verification framework for Mercury programs     
     see qcheck2         justification (work in progress)
      
      
 
      
Systems
      
ltq
        
Extends Mercury with op/3 declarations, allowing     syntax modification     
     see installation         instructions
   see                 ltq doc
see       write_canonical       that interprets op/3 declarations

samples:       hello.m and       play.m
      
      
 
      
Fixes/Patches
      
anys
        
A set of fixes to the utilities provided in the Mercury     extras distribution supporting operations     with the any mode
            see anys-diffus.zip              simply to apply patches
      
 
      
Alpha:   You Have Been Warned!
      
matrix
        
Work in progress to add a viable matrix protocol; will be         rolled into the utils library.
      
tiffany       
        
A very small, thread-un-safe, foreign interface to     libtiff; also requires     matrix (which it already bundles).
      
 
      
      

Contact Information: dauclair at hotmail.com 703-300-0447
Copyright © 2006-2007, Logical Types, LLC. All rights reserved.

Literature
We have the works available under the following topics:
Language Modification
January 3, 2006	Mutable syntax in Mercury
Testing/Verification
work in progress	Testing with qcheck2
Miscellanea
January 16, 2006	PADL symposium post mortem

Rule-Based Logic System

	Rule-based Systems	Rule-based systems process data according to sets of constraints established by the user. The results of these systems is a collection of rule findings that can be used to construct the final product or to assist the user in rendering an informed decision. The above description may seem all-too-general, as that describes the what most programs do. This is indeed correct: rule-based programming is sufficiently powerful enough to describe any computable system. In fact, the rule-based approach is now being viewed by the mainstream as the preferred method for workflow analysis, process, resource scheduling, service-based systems, etc. Nearly every software system has a set of rules, explicit or implied, to which it adheres. The rule-based programming style model these rule constructs directly and facilitate their manipulation as the system grows and changes.
	Deductive Logic	The traditional approach to building logic systems is to construct a set of clauses where the head of the clause matches a condition and the rest of the clause verifies the match through a set of goals for that match. These clauses are known as rules and a set of rules is a predicate, and this predicate can be used, in turn, as a goal in a new rule. Deductive logic matches problem specifications very closely and is a very effective way to convert a set of requirements into a production system. Some examples of types of problems that are easily modelled in deductive logic are expert systems, planning systems and scheduling systems. Deductive systems are used when the rules are clear, when the user requires certain outcomes, and are very good at "explaining" what the rule findings are and how they were arrived at.
	Inductive Logic	The opposite approach to a deductive system is an inductive one. Whereas in an deductive system, the user has very exacting control over the process and outcome, in an inductive system, the rules are obtained by deriving the relations between input data and their outcomes, with very little guidance, if any, from the builder of the system. Traditional inductive systems required very clean data and had little tolerance for deviation -- a slight perturbation in the data set could cause the system to fall into an undefined state. Modern inductive systems have taken a different approach: reaping the benefits of recent advances in probability and statistics, these systems (such as Bayesian systems and neural networks) are highly redundant and adaptive. These new systems consistently perform well: they have excellent success narrowing to a classification from apparently unrelated attributes, and they have a high rate of stability, being very fault-tolerant, even in the presence of very noisy data. It is also trivial to convert a statically trained inductive system to one that learns continuously from new inputs and outcomes. Inductive systems are used when users cannot explain how they arrive at decisions (attributing the outcomes to a "feel" for the situation), and where gradual trends result in eventual changes to outcomes. These systems excel at making the correct decision with a very high degree of confidence, but are poor at explaining what prompted the decision.
	Our Approach	Logical Types, LLC uses both deductive and inductive logic to build systems as the needs of the customer demand: To rediscover the implicit rules of a phoneme-based name matching system, we created a purely inductive system that output a new program that had the phoneme contruction rules explicit. A human resource scheduling system that required a set of clearly stated rules that filled duty times with a pool of personnel under a guiding principle of "fairness" was built using purely deductive logic. A combined learning system and knowledge-engineered rule-based expert system was designed using a deductive rule manager with a supervised learning, Bayesian-like, component.

Contact Information: dauclair at hotmail dot com 703-300-0447
Copyright © 2006-2007, Logical Types, LLC. All rights reserved.

Archived News: 2006-07

2006-07 17:

The various data structures provided in the ROTD
extras/ distribution that handles solver
types (particularly the various any
modes) do not compile because of purity issues;
also, since their release, the coding style has
changed for module qualification. The fixes to
get these types compiled are
here. For the
Mercury team's review are the
diffs to fold
back into the distribution.

Archived News: 2006-05

2006-05 13:

We present a complete rewrite of Mercury's

QuickCheck implementation:
qcheck2 (the sample
unit test module (peano_unit_tests)
requires the peano
module in order to run). The essence of testing
à la qcheck --
type discernment to obtain (random) test values
with a test specification language -- remains
unchanged. The new features of this new version
enhance the system with:

1. complete control over what is reported and
   when it is reported;


2. dynamic control over ranges of random
   number-like values (ints,
   floats and chars) as
   well as the random number generator type itself;


3. and for the code-hacker: qcheck2
   is broken up into separate modules along
   functional lines

The documentation for qcheck (upon
which qcheck2 is built) is a model
for any system to follow; so, documentation, to
include a system description and transition guide,
for qcheck2 is under development.

Update 2006-05-20:

As the test description
(Description) may now be of any
type -- even non-comparable types, such as,
for example, function types -- using a map
with Description keys is will cause
errors when using Description types
that cannot be compared. As such, the
qstate now uses an
assoc_list to accumulate the test
results.

Update 2006-05-21:

Added information to the summary
report: this report now shows which predicates
were not tested. The work-in-progress
documentation
now covers the reporting facility comprehensively.

12:

ltq
(Logical Types Quicksilver compiler) now comes
with qcpt (QuickCheck Predicate
Types), a system that discerns the interface
predicates and functions of a system (to
facilitate comprehensive unit testing). Perhaps
even more important is the inclusion of a README
that doubles as a HOWTO and INSTALL document.

11:

Completed the document describing an implementation
of mutable syntax for Mercury. This article in
available in the literature section (see above).

Archived News: 2006-04

2006-04 30:

The graph module takes a rather
non-directed approach to locating a path from
Node1 to NodeN. This is
fine if the path has no associated cost, but if
one is looking for the best path (where a path has
an associated cost), this laissez-faire
approach becomes problematic.

As I often need a efficient path in a graph, I
have added best_path/5 and other
supporting predicates that cannot be implemented
well operationally given the protocol of module
graph and submitted these changes to
the Mercury team for review. While they consider
these changes, I provide the implementation here
as module doug_graph, with an
associated example. Locating the best path in the
given example using
the naive path implementation took
over 20 seconds; the reimplementation here
completes the computations in less than a
second.

27:

The following Mercury compiler distributions are
available from here on request:

• 
  mercury-2006-04-26-rotd-powerpc.apple.darwin8.5
  


• 
  mercury-2006-04-26-rotd-sparc.sun.solaris2.8
  

These distributions include the extras/, the
samples/ (in extras/) and
the HTML documentation (in doc/).