From OpenCog
(Redirected from Valuation)
Jump to: navigation, search

A Value is used to assign valuations to Atoms. Multiple, different valuations can be associated to a single atom, which can be accessed with a key. The key can be any other atom. In essence, every atom has an associated key-value store. The triple (atom, key, value) is called a Valuation.

In the atom type hierarchy, Values inherit from ProtoAtom.

Values can be lists of floats, lists of strings, or lists of values. There are two values that are treated specially in the code: the various different TruthValues, and the AttentionValues.

Other examples include:

(FloatValue 0.1 0.2 0.3)
(StringValue "a" "bb" "ccc")
(LinkValue  (StringValue "foo") (FloatValue "41 43 43 44"))

There is no IntValue or BooleanValue ... These don't seem to be useful or important for any current uses. These could be added, but if you feel you need them, you should re-examine your design and your thinking. Keep in mind that Atomese is meant to be a system for knowledge representation, and for data-structure introspection and re-writing. It is NOT meant to be a traditional "programming language": it is designed to be easy-to-understand by AI algorithms, not by humans. That is why we don't have IntValue or BooleanValue's so far.

Values and atoms both can be saved to a persistent store (currently, a postgress SQL backend).

Atoms vs. Values

In many ways, atoms and values are similar; however, they are intended to solve different knowledge-representation problems. Atoms are globally unique, and can be thought of as being static and unchanging. Atoms are immutable: they can only be created and destroyed; they cannot be changed. Values, and valuations in general, should be thought of as rapidly-changing data. For example, the (probability of the) truth of some proposition might change over time, as new evidence is gathered up, or as new deductions and inferences are made.

Note that, due to the type hierarchy, all atoms are values, and so, if desired, one can use an atom wherever a value might go. The converse is not true: one cannot use values as if they were atoms.

Suggestd usage guidelines

Valuations are triples, consisting of (atom, key, value) and intentionally resemble an EvaluationLink. Thus, it is strongly suggested that keys should always be PredicateNodes. This allows one to conceptually envision something like this, if desired:

  PredicateNode "some-key"

which would cause "SomeValue" to be associated with "SomeAtom" under the key of "PredicateNode some-key".

Implementation and API

The C++ code that implements values and valuations is in /opencog/atoms/base. The scheme bindings for creating and working with values are defined in (use-modules (opencog)), that is, in the core module. The currently defined routines include:

cog-value       ; Get the value for an (atom, key) pair.
cog-set-value!  ; Create a valuation triple (atom, key, value)
cog-value?      ; Return #t if the argument is an opencog value.
cog-value-type? ; Return the type of a value.
cog-new-value   ; Create a new value
cog-value->list ; Convert an opencog value to a scheme list. This discards the type of the value.
cog-value-ref   ; Get the n'th item in the value.

Note that guile also defines a concept of "value" but this is something completely different and unrelated!.

A list of all scheme functions pertaining to values can be obtained by typing a, value at the guile prompt. Documentation for each individual functions can be found by typing d, func-name. Recall that a, is short for "apropos", and d, is short for "describe".