cru_fabricator - isomorphic graph specification for the cru library
#include <cru/cru.h>
typedef struct
cru_fabricator_s
{
cru_uop
v_fab;
cru_uop
e_fab;
struct
cru_sig_s
fa_sig;
} *cru_fabricator;
This structure parameterizes the cru_fabricated library function with necessary information initialized by the application to create a new graph that is isomorphic to a given graph.
If all three of the fields fa_sig.orders.v_order, fa_sig.destructors.v_free, and v_fab field are NULL or zero-filled, then an identity function is inferred as the vertex fabricator v_fab, but this option is valid only when the given graph has scalar vertices. The analogous convention applies to the e_fab field.
These errors are reportable for the following reasons by the cru_fabricated function given an invalid cru_fabricator structure.
CRU_UNDVFB
No vertex fabricator functon is defined or inferrable.
CRU_UNDEFB
No edge fabricator functon is defined or inferrable.
An edge order is not necessary for fabricating a graph, but is necessary for the operations of composition, merging, deduplication, postponement, and stretching existing graphs. For these operations, an edge ordering must be defined or inferrable at some point in advance, so it should be defined in the fa_sig.orders.e_order field if any of these operations is anticipated.
Creating an isomorphism to a graph requires sufficient memory for both graphs. If the original graph is no longer needed, mutating it in place is more space efficient. Algorithms that require maintaining multiple large graphs concurrently might benefit from reference counted shared vertices and edges, subject to adequate provision on the part of the application for mutually exclusive access by their destructors.
If either of the operators is non-injective, for example by mapping distinct input vertices to identical output vertices, then it is possible for the fabricated graph to contain duplicate vertices or labels. This situation can be remedied by passing the result returned by cru_fabricated through the cru_deduplicated library function, provided the fa_sig field is correctly initialized. As a performance tradeoff, this step is not taken automatically because an application developer in the unusual case of non-injective operators can discern its necessity and plan accordingly. Moreover, if a graph having duplicate vertices were to be fabricated deliberately with the intention of deduplicating it, then the cru_merged library function would provide a faster and more space efficient alternative.
/usr/local/include/cru/data_types.h
/usr/local/include/cru/function_types.h
/usr/local/include/cru/error_codes.h
cru, cru_bop, cru_bpred, cru_builder, cru_built, cru_cbop, cru_classifier, cru_class_of, cru_class_size, cru_composed, cru_composer, cru_connect, cru_connector, cru_cqop, cru_crossed, cru_crosser, cru_ctop, cru_ctop_pair, cru_ctop_quad, cru_data_types, cru_deduplicated, cru_destructor, cru_destructor_pair, cru_edge_count, cru_fabricated, cru_filter, cru_filtered, cru_fold, cru_free_kill_switch, cru_free_later, cru_free_now, cru_free_partition, cru_function_types, cru_get, cru_hash, cru_induced, cru_inducer, cru_kernel, cru_kill, cru_killed, cru_mapreduced, cru_mapreducer, cru_merged, cru_merger, cru_mutated, cru_mutator, cru_new_kill_switch, cru_nop, cru_order, cru_order_pair, cru_partition_of, cru_plan, cru_postponed, cru_postponer, cru_prop, cru_prop_pair, cru_pruner, cru_qop, cru_qpred, cru_set, cru_sig, cru_singleton, cru_split, cru_splitter, cru_spread, cru_strerror, cru_stretch, cru_stretched, cru_stretcher, cru_subconnector, cru_terminus_count, cru_top, cru_tpred, cru_united, cru_uop, cru_vertex_count, cru_zone
Dennis Furey (milonga@delayinsensitive.com)
https://github.com/gueststar/cru