text:
/*
 * Copyright (c) 2020, OPEN AI LAB
 * Author: haitao@openailab.com
 */

#ifndef __TENGINE_C_API_H__
#define __TENGINE_C_API_H__

#include <stdint.h>
#include <stddef.h>

#ifdef _MSC_VER
#define DLLEXPORT __declspec(dllexport)
#else
#define DLLEXPORT __attribute((visibility("default")))
#endif

#ifdef __cplusplus
extern "C" {
#endif

#define MAX_SHAPE_DIM_NUM 4

/* the data type of the tensor */
#define TENGINE_DT_FP32 0
#define TENGINE_DT_FP16 1
#define TENGINE_DT_INT8 2
#define TENGINE_DT_UINT8 3
#define TENGINE_DT_INT32 4
#define TENGINE_DT_INT16 5

/* layout type, not real layout */
#define TENGINE_LAYOUT_NCHW 0
#define TENGINE_LAYOUT_NHWC 1

/* tensor type: the content changed or not during inference */
#define TENSOR_TYPE_UNKNOWN 0
#define TENSOR_TYPE_VAR 1
#define TENSOR_TYPE_CONST 2
#define TENSOR_TYPE_INPUT 3
#define TENSOR_TYPE_DEP 4

/* cluster type: big-LITTLE and DynamIQ defined */
#define TENGINE_CLUSTER_ALL 0
#define TENGINE_CLUSTER_BIG 1
#define TENGINE_CLUSTER_MEDIUM 2
#define TENGINE_CLUSTER_LITTLE 3

#define TENGINE_MODE_FP32 0
#define TENGINE_MODE_FP16 1
#define TENGINE_MODE_HYBRID_INT8 2
#define TENGINE_MODE_UINT8 3
#define TENGINE_MODE_INT8 4 // todo

/* node dump action definition */
#define NODE_DUMP_ACTION_DISABLE 0
#define NODE_DUMP_ACTION_ENABLE 1
#define NODE_DUMP_ACTION_START 2
#define NODE_DUMP_ACTION_STOP 3
#define NODE_DUMP_ACTION_GET 4

/* graph perf action definition */
#define GRAPH_PERF_STAT_DISABLE 0
#define GRAPH_PERF_STAT_ENABLE 1
#define GRAPH_PERF_STAT_STOP 2
#define GRAPH_PERF_STAT_START 3
#define GRAPH_PERF_STAT_RESET 4
#define GRAPH_PERF_STAT_GET 5

/* follow the std. UNIX log level definitioin */
enum log_level
{
    LOG_EMERG,
    LOG_ALERT,
    LOG_CRIT,
    LOG_ERR,
    LOG_WARNING,
    LOG_NOTICE,
    LOG_INFO,
    LOG_DEBUG
};

/* note: Android NN only define one event */
enum graph_exec_event
{
    GRAPH_EXEC_START,
    GRAPH_EXEC_SUSPEND,
    GRAPH_EXEC_RESUME,
    GRAPH_EXEC_ABORT,
    GRAPH_EXEC_DONE
};

/* todo: should add suspend? */
enum graph_exec_stat
{
    GRAPH_STAT_CREATED,
    GRAPH_STAT_READY,
    GRAPH_STAT_RUNNING,
    GRAPH_STAT_DONE,
    GRAPH_STAT_ERROR
};

enum device_policy
{
    DEFAULT_POLICY,
    LATENCY_POLICY,
    LOW_POWER_POLICY
};

typedef void* context_t;
typedef void* graph_t;
typedef void* tensor_t;
typedef void* node_t;

typedef int (*event_handler_t)(graph_t, int, void* arg);

typedef void (*log_print_t)(const char*);

/* graph exec options */
struct options
{
    int num_thread;
    int cluster;
    int precision;
    uint64_t affinity;
};

/* performance profiling records */

struct perf_info
{
    const char* name; /* node name */
    const char* dev_name; /* device name */
    uint32_t count;
    uint32_t min;
    uint32_t max;
    uint64_t total_time; /* us or cycle, depends on devices */
    uint32_t base; /* 1ms second time number */
};

struct custom_kernel_tensor
{
    int dim[MAX_SHAPE_DIM_NUM]; /* the shape dim array */
    int dim_num; /* valid entry number */
    int element_num;
    int element_size; /* determined  by data_type */
    int data_type;
    int dev_type; /* indicate the tensor belongs to CPU/GPU ... */
    int layout_type; /*  NCHW type or NHWC type*/

    /* quant info */
    int quant_type; /* int8, int16 or int32 */
    float* scale;
    int* zero_point;
    int* quant_number;

    void* data; /* pointer to host memory (virtual address) */
    void* dev_mem; /* refers to device memory block */
    void* mapped_mem; /* the mapped address for device memory block */
};

/* For user to add user defined kernel*/
struct custom_kernel_ops
{
    const char* kernel_name; /* name of the kernel */
    const char* op; /* name of the op to be implemented */
    int force; /* if not set, when bind() failed,
      try to use other kernel implementations*/
    void* kernel_param; /* used for kernel impl functions */
    int kernel_param_size;

    /*!
     * @brief generate output shape according to input shapes
     *        if not implemented, set it to NULL.
     *
     * @param [in]  ops: The point of custom defined kernel.
     * @param [in]  inputs[]:  pointer array to the shape of input tensors.
     *                         the shape has MAX_SHAPE_DIM_NUM elements,
     *                         and element with value 0  means the end of the shape.
     * @param [in]  input_num: The number of input tensors.
     * @param [out] outputs[]: pointer array to the shape of output tensors.
     *                         the memory has been allocated already
     * @param [in]  output_num: The number of output tensors
     * @param [in]  layout: the graph layout is NHWC or NCHW
     *
     * @return 0: success, -1: fail.
     */
    int (*infer_shape)(struct custom_kernel_ops* ops, const int* inputs[], int input_num, int* outputs[],
                       int output_num, int layout);

    /*!
     * @brief Get the inplace input tensor index for an output tensor.
     *
     * @param [in] ops: The point of custom defined kernel.
     * @param [in] output_idx: The index of custom defined kernel output.
     *
     * @return the inplace input tensor index for an output tensor.
     *         if the output tensor is not an inplace one, return -1.
     */
    int (*inplace_info)(struct custom_kernel_ops* ops, int output_idx);    // optional

    /*!
     * @brief Check if the kernel can work on the input and output shapes.
     *
     * @param [in] ops: The point of custom defined kernel.
     * @param [in] inputs[]: The custom kernel tensors for input.
     * @param [in] input_num: The number of the input tensors.
     * @param [in] outputs[]: The custom kernel output tensor for output
     * @param [in] output_num: The number of the output tensors.
     *
     * @return 0 if the input and output are supported
     *         otherwise, return -1.
     *
     * notes: If not implemented, set it NULL, which means always return 0.
     */
    int (*bind)(struct custom_kernel_ops* ops, const struct custom_kernel_tensor* inputs[], int input_num,
                const struct custom_kernel_tensor* outputs[], int output_num);

    /*!
     * @brief Prepare for run graph.
     *        dynamic_shape means it is not an abnormal case when input_num is zero.
     *
     * @param [in] ops: The point of custom defined kernel.
     * @param [in] inputs[]: The custom defined kernel input tensor.
     * @param [in] input_num: The number of the custom defined kernel input tensor.
     * @param [in] outputs[]: The custom defined kernel output tensor.
     * @param [in] output_num: The number of the custom defined kernel output tensor.
     * @param [in] dynamic_shape: It is not an abnormal case when input_num is zero.

     * @return 0: success, -1: fail.
     */
    int (*prerun)(struct custom_kernel_ops* ops, struct custom_kernel_tensor* inputs[], int input_num,
                  struct custom_kernel_tensor* outputs[], int output_num, int dynamic_shape);

    /*!
     * @brief Reshape the graph.
     *
     * @param [in] ops: The point of custom defined kernel.
     * @param [in] inputs[]: The custom defined kernel input tensor.
     * @param [in] input_num: The number of the custom defined kernel input tensor.
     * @param [in] outputs[]: The custom defined kernel output tensor.
     * @param [in] output_num: The number of the custom defined kernel output tensor.

     * @return 0: success, -1: fail.
     *
     * notes: It will be called, when input shape changed.
     *        After prerun() has been called, need to reclaim and re-allocate run-time
     *        resource depends on input shape.
     */
    int (*reshape)(struct custom_kernel_ops* ops, struct custom_kernel_tensor* inputs[], int input_num,
                   struct custom_kernel_tensor* outputs[], int output_num);

    /*!
     * @brief Run the graph.
     *
     * @param [in] ops: The point of custom defined kernel.
     * @param [in] inputs[]: The custom defined kernel input tensor.
     * @param [in] input_num: The number of the custom defined kernel input tensor.
     * @param [in] outputs[]: The custom defined kernel output tensor.
     * @param [in] output_num: The number of the custom defined kernel output tensor.

     * @return 0: success, -1: fail.
     */
    int (*run)(struct custom_kernel_ops* ops, struct custom_kernel_tensor* inputs[], int input_num,
               struct custom_kernel_tensor* outputs[], int output_num);

    /*!
     * @brief Pause the graph and release the resources used when the graph is running.
     *
     * @param [in] ops: The point of custom defined kernel.
     * @param [in] inputs[]: The custom defined kernel input tensor.
     * @param [in] input_num: The number of the custom defined kernel input tensor.
     * @param [in] outputs[]: The custom defined kernel output tensor.
     * @param [in] output_num: The number of the custom defined kernel output tensor.

     * @return 0: success, -1: fail.
     */
    int (*postrun)(struct custom_kernel_ops* ops, struct custom_kernel_tensor* inputs[], int input_num,
                   struct custom_kernel_tensor* outputs[], int output_num);

    /*!
     * @brief Free the resource allocated this ops implementation.
     *
     * @param [in] ops: The point of custom defined kernel.
     *
     * @return None.
     */
    void (*release)(struct custom_kernel_ops* ops);
};

/************** Library intialization and version checking *******************/

/*!
 * @brief Initialize the tengine, only can be called once.
 *
 * @return 0: Success, -1: Fail.
 */
DLLEXPORT int init_tengine(void);

/*!
 * @brief Release the tengine, only can be called once.
 *
 * @return none.
 */
DLLEXPORT void release_tengine(void);

/*!
 * @brief Get the version of the tengine.
 *
 * @return const char * of version string.
 */
DLLEXPORT const char* get_tengine_version(void);

/*!
 * @brief Check the run-time library supports the verson.
 *        app developer should call get_tengine_version() to save the version used
 *        during developping.
 *
 *
 *        The app knows exactly that it can work on a tengine version, and it can
 *        check run-time tengine library supports that version.
 *
 * @param [in] version: A c string returned by get_tengine_version()
 * @return 1: support, 0: not support.
 */
DLLEXPORT int request_tengine_version(const char* version);

/*************************** graph operate set ********************************/

/*!
 * @brief Create the run-time graph for execution from a saved model.
 *        If model format is NULL, an empty graph handle will be returned.
 *
 * @param [in] context: The context the graph will run inside;
 *                   could be NULL and the graph is created in a private context.
 *
 * @param [in] model_format: The model format type,such as "caffe","tengine"
 * @param [in] file_name:  The name of model file.
 *
 * @return  The graph handler or NULL if failed.
 */

DLLEXPORT graph_t create_graph(context_t context, const char* model_format, const char* file_name, ...);

/*!
 * @brief Set the layout type of the graph
 *        the default layout of graph is NCHW
 * @param [in] graph, the graph handle
 * @param [in] layout_type, the layout type NCHW or NHWC
 *
 * @return 0 success, or -1 fail
 */

DLLEXPORT int set_graph_layout(graph_t graph, int layout_type);

/*!
 * @brief designate the input nodes of the graph
 *
 * @param [in] graph: the graph handle
 * @param [in] input_nodes: the node name list of input nodes
 * @param [in] input_number: the number of input_nodes
 *
 * @note  if using the default input nodes of a graph, this call can be skipped
 */
DLLEXPORT int set_graph_input_node(graph_t graph, const char* input_nodes[], int input_number);

/*!
 * @brief designate the output nodes of the graph
 *
 * @param [in] graph: the graph handle
 * @param [in] output_nodes: the node name list of output nodes
 * @param [in] output_number: the number of output_nodes
 *
 * @note  if using the default output nodes of a graph, this call can be skipped
 */

DLLEXPORT int set_graph_output_node(graph_t graph, const char* output_nodes[], int output_number);

/*!
 * @brief Destory the runtime graph and release allocated resource.
 *
 * @param [in] graph: The graph handle.
 * @return 0: Success, -1: Fail.
 */
DLLEXPORT int destroy_graph(graph_t graph);

/*!
 * @brief Get the number of input node of the graph.
 *
 *  @param [in] graph The graph handle.
 *  @return <0 Fail, >0 the input node number.
 */
DLLEXPORT int get_graph_input_node_number(graph_t graph);

/*!
 * @brief Get the node handle of #idx of input node of the graph.
 *
 * @param [in] graph The graph handle.
 * @param [in] idx The input node index,starting from zero.
 *
 * @return The node name or NULL on error.
 */
DLLEXPORT node_t get_graph_input_node(graph_t graph, int idx);

/*!
 * @brief Get the number of output node of the graph.
 *
 *  @param [in] graph The graph handle.
 *
 *  @return <0 error, >0 the input node number.
 */
DLLEXPORT int get_graph_output_node_number(graph_t graph);

/*!
 * @brief Get the node handle #idx of a graph output node.
 *
 * @param [in] graph The graph handle.
 * @param [in] idx The input node index, starting from zero.
 *
 * @return The node name or NULL on error.
 */
DLLEXPORT node_t get_graph_output_node(graph_t graph, int idx);

/*!
 * @brief Get a tensor handle of a graph output node.
 *
 * @param [in] graph: The graph handle.
 * @param [in] output_node_idx: The output node index.
 * @param [in] tensor_idx: The output tensor index of the output node.
 *
 * @return The tensor handle or NULL on error.
 *
 */
DLLEXPORT tensor_t get_graph_output_tensor(graph_t graph, int output_node_idx, int tensor_idx);

/*!
 * @brief Get tensor handle of one graph input tensor.
 *
 * @param [in] graph: The graph handle.
 * @param [in] input_node_idx: The input node index, starting from zero.
 * @param [in] tensor_idx: The output tensor index of the input node, starting from zero.
 *
 * @return The tensor handle or NULL on error.
 */
DLLEXPORT tensor_t get_graph_input_tensor(graph_t graph, int input_node_idx, int tensor_idx);

/******************* node operate set ****************************/
/*!
 * @brief Create a node for the graph.
 *
 * @param [in] graph: The graph handle.
 * @param [in] node_name: The name of the node.
 * @param [in] op_name: The name of the operate.
 *
 * @return The node handle or NULL on error.
 */
DLLEXPORT node_t create_graph_node(graph_t graph, const char* node_name, const char* op_name);

/*!
 * @brief  Get the node handle of the graph.
 *
 * @param [in] graph: The graph handle.
 * @param [in] node_name: The name of the node.
 *
 * @return The node handle or NULL on error.
 */
DLLEXPORT node_t get_graph_node(graph_t graph, const char* node_name);

/*!
 * @brief  Get the node handle of the graph.
 *
 * @param [in] graph: The graph handle.
 * @param [in] idx: The index of the node.
 *
 * @return The node handle or NULL on error.
 */
DLLEXPORT node_t get_graph_node_by_idx(graph_t graph, int idx);

/*!
 * @brief  Get the node handle of the graph.
 *
 * @param [in] graph: The graph handle.
 *
 * @return The quantities of all nodes.
 */
DLLEXPORT int get_graph_node_num(graph_t graph);

/*!
 * @brief Get the node name.
 *
 * @param [in] node: The node handle.
 *
 * @return The node name, NULL on error.
 */
DLLEXPORT const char* get_node_name(node_t node);

/*!
 * @brief Get the node op.
 *
 * @param [in] node: The node handle.
 *
 * @return The op name, NULL on error.
 */
DLLEXPORT const char* get_node_op(node_t node);

/*!
 * @brief  Release the node handle.
 *
 * @param  [in] node: The node handle.
 *
 * @return None.
 */
DLLEXPORT void release_graph_node(node_t node);

/*!
 * @brief Get the input tensor handle of a node.
 *
 * @param [in] graph: The graph handle.
 * @param [in] node_name: The node name.
 * @param [in] input_idx: The index of the input tensor.
 * @return The tensor name or NULL on error.
 *
 */
DLLEXPORT tensor_t get_node_input_tensor(node_t node, int input_idx);

/*!
 * @brief Get the output tensor handle of a node.
 *
 * @param [in] node: The node handle.
 * @param [in] output_idx: The index of the output tensor.
 *
 * @return The tensor handle or NULL on error.
 *
 */
DLLEXPORT tensor_t get_node_output_tensor(node_t node, int output_idx);

/*!
 * @brief Set a node's the #idx input tensor.
 *
 * @param [in] graph: The graph handle.
 * @param [in] input_idx: The index of the input tensor.
 * @param [in] tesnor: The tensor handle.
 *
 * @return 0 on success or -1 on error.
 *
 */
DLLEXPORT int set_node_input_tensor(node_t node, int input_idx, tensor_t tensor);

/*!
 * @brief Set a node's the #idx output tensor.
 *
 * @param [in] graph: The graph handle.
 * @param [in] output_idx: The index of the output tensor.
 * @param [in] tensor: The tensor handle.
 * @param [in] tensor_type: The tensor type: VAR/CONST/INPUT/DEP
 *
 *  @return 0 on success or -1 on error.
 *
 */
DLLEXPORT int set_node_output_tensor(node_t node, int output_idx, tensor_t tensor, int tensor_type);

/*!
 * @brief Get the output tensor number of a node.
 *
 * @param [in] graph: The graph handle.
 * @param [in] node: The node hanle.
 *
 * @return >=1 the number of output tensor,
 *         -1 on error.
 *
 */
DLLEXPORT int get_node_output_number(node_t node);

/*!
 * @brief Get the input tensor number of a node.
 *
 * @param [in] graph: The graph handle.
 * @param [in] node: The node hanle.
 *
 * @return >=1 the number of output tensor,
 *         -1 on error.
 *
 */
DLLEXPORT int get_node_input_number(node_t node);

/*!
 * @brief Add an attribute to a node.
 *
 * @param [in] node: The target node handle.
 * @param [in] attr_name: The name of the attribute to be added.
 * @param [in] type_name: The name of the std::type_info of the type,
 *                       can be set to NULL to skip type match checking.
 * @param [in] size: The size of the attribute
 *
 * @return 0: Successfully,
 *         -1: Failed.
 */
DLLEXPORT int add_node_attr(node_t node, const char* attr_name, const char* type_name, int size);

/*!
 * @brief Get the attribute value (int) of a node
 *        backended by get_node_attr_generic().
 *
 * @param [in] node: The target node.
 * @param [in] attr_name: The name of the attribute to be retrieval.
 * @param [out] attr_val: Pointer to the int val to be saved.
 *
 * @return 0: Retrieval value Successfully,
 *         -1: Failed, the name does not exist or the type mismatch.
 *
 */
DLLEXPORT int get_node_attr_int(node_t node, const char* attr_name, int* attr_val);

/*!
 * @brief Get the attribute value (float) of a node
 *        backended by get_node_attr_generic().
 *
 * @param [in] node: The target node.
 * @param [in] attr_name: The name of the attribute to be retrieval.
 * @param [out] attr_val: Pointer to the float val to be saved.
 *
 * @return 0: Retrieval value Successfully,
 *         -1: Failed, the name does not exist or the type mismatch.
 */
DLLEXPORT int get_node_attr_float(node_t node, const char* attr_name, float* attr_val);

/*!
 * @brief Get the attribute value (pointer) of a node
 *        backended by get_node_attr_generic().
 *
 * @param [in] node: The target node.
 * @param [in] attr_name: The name of the attribute to be retrieval.
 * @param [out] attr_val: Pointer to the pointer val to be saved.
 *
 * @return  0: Retrieval value Successfully,
 *         -1: Failed, the name does not exist or the type mismatch.
 */
DLLEXPORT int get_node_attr_pointer(node_t node, const char* attr_name, void* attr_val);

/*!
 * @brief Get the attribute value of a node, the data type is indicated by type_info.
 *
 * @param [in] node: The target node.
 * @param [in] attr_name: The name of the attribute to be retrieval.
 * @param [in] type_info: The pointer to the std::type_info of expected type
 *                   can be set to NULL to skip type match checking.
 * @param [out] buf: The pointer to the buffer to save val.
 * @param [in] size: The buffer size.
 *
 * @return  0: Retrieval value Successfully,
 *         -1: Failed; The name does not exist or the type mismatch.
 *
 */
DLLEXPORT int get_node_attr_generic(node_t node, const char* attr_name, const char* type_name, void* buf, int size);

/*!
 * @brief Set the attribute value (int) of a node
 *        backended by set_node_attr_generic().
 *
 * @param [in] node: The target node.
 * @param [in] attr_name: The name of the attribute to be retrieval.
 * @param [in] attr_val: The pointer to the int val to be set.
 *
 * @return  0: Retrieval value Successfully;
 *         -1: Failed, The name does not exist or the type mismatch.
 *
 */
DLLEXPORT int set_node_attr_int(node_t node, const char* attr_name, const int* attr_val);

/*!
 * @brief Set the attribute value (float) of a node
 *        backended by set_node_attr_generic().
 *
 * @param [in] node: The target node.
 * @param [in] attr_name: The name of the attribute to be retrieval.
 * @param [in] attr_val: The pointer to the float val to be set.
 *
 * @return  0: Retrieval value Successfully.
 *         -1: Failed, The name does not exist or the type mismatch.
 *
 */
DLLEXPORT int set_node_attr_float(node_t node, const char* attr_name, const float* attr_val);

/*!
 * @brief Set the attribute value (pointer) of a node
 *        backended by set_node_attr_generic().
 *
 * @param [in] node: The target node.
 * @param [in] attr_name: The name of the attribute to be retrieval.
 * @param [in] attr_val: The pointer to the pointer val to be set.
 *
 * @return  0: Retrieval value Successfully
 *         -1: Failed, The name does not exist or the type mismatch.
 *
 */
DLLEXPORT int set_node_attr_pointer(node_t node, const char* attr_name, const void* attr_val);

/*!
 * @brief Set the attribute value of a node, the data type is indicated by type_info.
 *
 * @param [in] node: The target node.
 * @param [in] attr_name: The name of the attribute to be retrieval.
 * @param [in] type_info: The pointer to the std::type_info of wanted type,
 *                   can be set to NULL to skip type match checking.
 * @param [in] buf: The pointer to the buffer to hold val.
 * @param [in] size: The buffer size.
 *
 * @return  0: Retrieval value Successfully.
 *         -1: Failed, The name does not exist or the type mismatch.
 *
 */
DLLEXPORT int set_node_attr_generic(node_t node, const char* attr_name, const char* type_name, const void* buf, int size);

/*!
 * @brief Set customer kernel of a node, on a specific device,
 *        the operate in kernel_ops must be the same as node's operate.
 *
 * @param [in] node: The node handle.
 * @param [in] device: The kernel works for which device. NULL means for default device.
 * @param [in] kernel_ops: The custom implemented kernel operates.
 *
 * @return 0: Success, -1: Fail.
 */
DLLEXPORT int set_custom_kernel(node_t node, const char* dev_name, struct custom_kernel_ops* kernel_ops);

/*!
 * @brief Remove customer kernel of a node, on a specific device.
 *
 * @param [in] node: The node handle.
 * @param [in] device: The kernel works for which device. NULL means for default device.
 *
 * @return 0: Success, -1: Fail.
 */
DLLEXPORT int remove_custom_kernel(node_t node, const char* dev_name);

/********************* Tensor operate set ***********************************/

/*!
 * @brief create a tensor handle by tensor name.
 *
 * @param [in] graph: The graph handle
 * @param [in] tensor_name: Tensor name.
 * @param [in] data_type:  the data type.
 *
 * @return The tensor handle or NULL on error.
 *
 */
DLLEXPORT tensor_t create_graph_tensor(graph_t graph, const char* tensor_name, int data_type);

/*!
 * @brief Get a tensor handle by tensor name.
 *
 * @param [in] graph: The graph handle.
 * @param [in] tensor_name: Tensor name.
 *
 * @return The tensor handle or NULL on error.
 *
 */
DLLEXPORT tensor_t get_graph_tensor(graph_t graph, const char* tensor_name);

/*!
 * @brief  Get the name of the tensor handle.
 *
 * @param [in] tensor: the tensor handle.
 *
 * @return A c string.

 */
DLLEXPORT const char* get_tensor_name(tensor_t tensor);

/*!
 * @brief Release the tensor handle.
 *
 * @param [in] tensor: The tensor handle.
 *
 * @return None.
 */
DLLEXPORT void release_graph_tensor(tensor_t tensor);

/*!
 * @brief Get the shape of tensor.
 *
 * @param [in] tensor: The tensor handle.
 * @param [out] dims: An int array to get the returned shape.
 * @param [in] dim_number: The array size.
 * @return >=1 the valid dim number, or -1 Fail.
 *
 */
DLLEXPORT int get_tensor_shape(tensor_t tensor, int dims[], int dim_number);

/*!
 * @brief Set the shape of tensor.
 *
 * @param [in] tensor: The tensor handle.
 * @param [in] dims: An int array to represent shape.
 * @param [in] dim_number: The array size.
 * @return 0: Success; -1: Fail.
 *
 */
DLLEXPORT int set_tensor_shape(tensor_t tensor, const int dims[], int dim_number);

/*!
 * @brief Get the byte size of a tensor should occupy.
 *
 * @param [in] tensor: The tensor handle.
 *
 * @return <0: Error; >=0: Tensor size.
 * @note   If return 0, it means the shape of the tensor is not set yet.
 */
DLLEXPORT int get_tensor_buffer_size(tensor_t tensor);

/*!
 * @brief Get the buffer of the tensor.
 *    A tensor may deny to expose its internal buffer, so that get_tensor_buffer()
 *    will fail but get_tensor_buffer_size()/set_tensor_data() succeed.
 *
 * @param [in] tensor: The tensor handle.
 * @return The buffer address. if no buffer allocated return NULL.
 */
DLLEXPORT void* get_tensor_buffer(tensor_t tensor);

/*!
 * @brief Set the buffer of the tensor.
 *    A tensor may deny to change its internal buffer setting.
 *
 * @param [in] tensor: The tensor handle.
 * @param [in] buffer: The buffer address.
 * @param [in] buffer_size: The buffer_size.
 *
 * @return 0: Success; -1: Fail.
 * @note  The buffer is still managed by caller.
 */
DLLEXPORT int set_tensor_buffer(tensor_t tensor, void* buffer, int buffer_size);

/*!
 * @brief Copy tensor data to the output data buffer.
 * @param [in] tensor: The tensor handle.
 * @param [out] output_data: The output data buffer.
 *
 * @param [in] data_size: the output buffer size.
 * @return 0: Success; or -1: Fail.
 *
 */
DLLEXPORT int get_tensor_data(tensor_t tensor, void* output_data, int data_size);

/*!
 * @brief Copy the data to tensor buffer.
 *
 * @param [in] tensor: The tensor handle.
 * @param [in] input_data: The input data.
 * @param [in] data_size: The input data size.
 *
 * @return 0: Success; -1: Fail.
 *
 */
DLLEXPORT int set_tensor_data(tensor_t tensor, const void* input_data, int data_size);

/*!
 * @brief Get the data type of the tensor.
 *
 * @param [in] tensor: The tensor handle.
 *
 * @return The tensor type, see TENGINE_DT_FP32 etc, -1 on error.
 */
DLLEXPORT int get_tensor_data_type(tensor_t tensor);

/*!
 * @brief Set the data type of the tensor.
 *
 * @param [in] tensor: The tensor handle.
 * @param [in] data_type: The data type. see TENGINE_DT_FP32 etc.
 *
 * @return 0 on sucess, -1 on error.
 */
DLLEXPORT int set_tensor_data_type(tensor_t tensor, int data_type);

/*!
 * @brief Set the data layout of the tensor.
 *
 * @param [in] tensor: The tensor handle.
 *
 * @return The tensor type, 0 : nchw, 1 : nhwc.
 */
DLLEXPORT int get_tensor_layout(tensor_t tensor);

/*!
 * @brief Set the data layout of the tensor.
 *
 * @param [in] tensor: The tensor handle.
 * @param [in] layout: The data layout, 0 : nchw, 1 : nhwc.
 *
 * @return 0 on sucess, -1 on error.
 */
DLLEXPORT int set_tensor_layout(tensor_t tensor, int layout);

/*!
 * @brief Set tensor quant parameters
 *
 * @param [in] tensor: The tensor handle.
 * @param [in] scale:  The scale array address.
 * @param [in] zero point: The zero point address.
 * @param [in] number:  The element number of array.
 *
 * @return 0 on sucess, -1 on error.
 */
DLLEXPORT int set_tensor_quant_param(tensor_t tensor, const float* scale, const int* zero_point, int number);

/*!
 * @brief Get tensor quant parameters.
 *
 * @param [in] tensor: The tensor handle.
 * @param [in] scale:  The scale array address.
 * @param [in] zero point: The zero point address.
 * @param [in] number:  The element number of array.
 *
 * @return 0 on sucess, -1 on error.
 */
DLLEXPORT int get_tensor_quant_param(tensor_t tensor, float* scale, int* zero_point, int number);

/************************** Graph run related interface *********************/

/*!
 * @brief The interface to get possible cpu mask bits, when specified cluster of cpu,
 *        function will return the mask bits of the cluster.
 *
 * @param [in] cluster: The be queried cluster.
 *
 * @return affinity mask.
 */
DLLEXPORT size_t get_cluster_affinity_mask(int cluster);

/*!
 * @brief The interface to set cluster and threads count will used.
 *
 * @param [in] graph: The graph handle.
 * @param [in] cluster: The wanted cluster of all cpu clusters.
 * @param [in] threads: The threads count of graph will used to run.
 *
 * @return 0: Success, -1: Fail.
 */
DLLEXPORT int set_graph_thread(graph_t graph, int cluster, int threads);

/*!
 * @brief The interface to directly set used cpu mask.
 *
 * @param [in] graph: The graph handle.
 * @param [in] cpu_mask: The mask bits of graph will used to run.
 *
 * @return 0: Success, -1: Fail.
 */
DLLEXPORT int set_graph_thread_mask(graph_t graph, size_t cpu_mask);

/*!
 * @brief The interface to set some proprietary attribute items for graph.
 *        The backend device to run the graph may use the attribute item.
 *
 * @param [in] graph: The graph handle.
 * @param [in] attr_name: The attribute name.
 * @param [in] buf: The buffer to hold data.
 * @param [in] size: The buffer size.
 *
 * @return 0: Success, -1: Fail.
 */
DLLEXPORT int set_graph_attr(graph_t graph, const char* attr_name, const void* buf, int size);

/*!
 * @brief The interface to get some proprietary config items for graph.
 *        It is probabaly the config will be passed to the DLA driver.
 * @param [in] graph: the graph handle.
 * @param [in] name: The attribute name.
 * @param [in] buf: The buffer to hold data.
 * @param [in] size: The buffer size.
 *
 * @return 0: Success, -1: Fail.
 *
 */
DLLEXPORT int get_graph_attr(graph_t graph, const char* attr_name, void* buf, int size);

/*!
 * @brief Initialize resource for graph execution, and set cluster and threads count will used.
 *
 * @param [in] graph: The graph handle.
 * @param [in] cluster: The wanted cluster of all cpu clusters.
 * @param [in] threads: The threads count of graph will used to run.
 *
 * @return 0: Success, -1: Fail.
 *
 */
DLLEXPORT int prerun_graph_multithread(graph_t graph, struct options opt);

/*!
 * @brief Initialize resource for graph execution.
 *
 * @param [in] graph: The graph handle.
 *
 * @return 0: Success, -1: Fail.
 *
 */
DLLEXPORT int prerun_graph(graph_t graph);

/*!
 * @brief Execute graph.
 *
 * @param [in] graph: The graph handle.
 * @param [in] block: Blocking or nonlocking.
 * @return 0: Success, -1: Fail.
 * @note  If block is 0, need to call wait_graph to get result or set GRAPH_DONE event hook.
 *
 */
DLLEXPORT int run_graph(graph_t graph, int block);

/*!
 * @brief Wait graph execution done.
 *
 * @param [in] graph: The graph handle.
 * @param [in] try_wait: If set, just check status and return.
 * @return  1: Graph is done.
 *          0: Try again.
 *
 */
DLLEXPORT int wait_graph(graph_t graph, int try_wait);

/*!
 * @brief Release the resource for graph execution.
 * @param [in] graph: graph handle.
 *
 * @return 0: Success, -1: Fail.
 */
DLLEXPORT int postrun_graph(graph_t graph);

/*!
 * @brief Get the status of graph execution.
 *
 * @param [in] graph: The graph handle.
 *
 * @return status
 */
DLLEXPORT int get_graph_exec_status(graph_t graph);

/*!
 * @brief Set the event hook for graph execution.
 *
 * @param [in] graph: The graph handle.
 * @param [in] event: The event to be hooked.
 * @param [in] cb_func: The callback funtion.
 * @param [in] cb_arg: The argument will be passed to callback function.
 * @return 0: Success, -1: Fail.
 *
 */
DLLEXPORT int set_graph_event_hook(graph_t graph, int event, event_handler_t cb_func, void* cb_arg);

/***************** Device related *****************************/

/*!
 * @set The default device.
 *
 * @param [in] device: The device name.
 * @return 0: valid, -1: invalid.
 *
 */
DLLEXPORT int set_default_device(const char* device);

/*!
 * @brief Set the device to execution a graph.
 *
 * @param [in] graph: The graph handle.
 * @param [in] dev_name: The device name to run the node.
 *
 * @return  =0: Bind success.
 *          <0: error.
 *
 */
DLLEXPORT int set_graph_device(graph_t graph, const char* dev_name);

/*!
 * @brief get the device the node runs on
 *
 * @param [in] node: the node handle
 *
 * @return the device name or NULL if no device assigned yet
 */
DLLEXPORT const char* get_node_device(node_t node);

/*!
 * @brief Get the default name of device.
 *
 * @return The name of the default device.
 */
DLLEXPORT const char* get_default_device(void);

/******************** execution context *****************************/

/*!
 * @brief Create one execution context with name.
 *
 * @param [in] context_name: The name of the created context.
 * @param [in] empty_context: No device is assigned with this context
 *                            otherwise, all proved devices will be added into the context.
 *
 * @return Execution context handle.
 *         If create Failed, return NULL.
 */
DLLEXPORT context_t create_context(const char* context_name, int empty_context);

/*!
 * @brief Destory and reclaim the resource related with the context.
 *
 * @param [in] context: The context handle.
 */
DLLEXPORT void destroy_context(context_t context);

/*!
 * @brief Get the device number assigned to a context.
 *
 * @param [in] context: The context handle.
 *
 * @return The number of devices inside the context.
 */
DLLEXPORT int get_context_device_number(context_t context);

/*!
 *  @brief Add a device into one context.
 *
 *  @param [in] context: The context handle.
 *  @param [in] dev_name: The device name.
 *
 *  @return 0: Success, -1: Fail.
 */
DLLEXPORT int add_context_device(context_t context, const char* dev_name);

/*!
 *  @brief Remove a device from one context.
 *
 *  @param [in] context: The context handle.
 *  @param [in] dev_name: The device name.
 *
 *  @return 0: Success, -1: Fail.
 */
DLLEXPORT int remove_context_device(context_t context, const char* dev_name);

/*!
 * @brief Set attribute item of a context.
 *
 * @param [in] context: The context handle.
 * @param [in] attr_name: The attribute item name.
 * @param [in] val: The buffer to hold the data to set.
 * @param [in] size: The buffer size.
 * @return 0: Success, -1: Fail.
 */
DLLEXPORT int set_context_attr(context_t context, const char* attr_name, const void* val, int val_size);

/*!
 * @brief Get the attribute item of a context.
 *
 * @param [in] context: The context handle.
 * @param [in] attr_name: The attribute item name.
 * @param [out] val: The buffer to hold the data.
 * @param [in] size: The buffer size.
 * @return 0: Succuess, -1: Fail.
 */
DLLEXPORT int get_context_attr(context_t context, const char* attr_name, void* val, int val_size);

/*
 * Misc API
 */

/*!
 * @brief return the error number
 *        list of the symbolic error name follows glibc definitions
 *
 * @return the last error set in library
 *
 * @note It is MT-safe
 */

DLLEXPORT int get_tengine_errno(void);

/*!
 * @brief return and clear the error number
 *        list of the symbolic error name follows glibc definitions
 *
 * @return the last error set in library
 *
 * @note It is MT-safe
 */

DLLEXPORT int clr_tengine_errno(void);

/*!
 * @brief Set the logger level.
 *
 * @param [in] level: The log level.
 */
DLLEXPORT void set_log_level(enum log_level level);

/*!
 * @brief set the print function of log.
 *
 * @param [in] func: The print function.
 *
 * @return None.
 *
 * @note  default log output is stdout
 */
DLLEXPORT void set_log_output(log_print_t func);

/*!
 * @brief Dump the run-time graph.
 *        If the graph is dumpped after prerun(), it will dump the optimized graph instead of the origin one.
 *
 * @param [in] graph: The graph handle.
 */
DLLEXPORT void dump_graph(graph_t graph);

/**************************** Plug-in operate set *******************/
/*!
 * @brief Load one plugin from disk, and execute the init function.
 *
 * @param [in] plugin_name: Plugin name.
 * @param [in] fname: Plugin file name.
 * @param [in] init_func_name: The name of the init function.
 *
 * @return 0: Plugin loaded and inited Success,
 *      -1: Fail
 */
DLLEXPORT int load_tengine_plugin(const char* plugin_name, const char* fname, const char* init_func_name);

/*!
 * @brief Unload one plugin and call the release function.
 *
 * @param [in] plugin_name: The name of plugin.
 * @param [in] rel_func_name: The release function name.
 *
 * @return  0: Success;
 *      -1: Fail.
 */
DLLEXPORT int unload_tengine_plugin(const char* plugin_name, const char* rel_func_name);

/*!
 * @brief Get the number of loaded plugin.
 *
 * @return The plugin number.
 */
DLLEXPORT int get_tengine_plugin_number(void);

/*!
 * @brief Get the name of #idx plugin.
 *
 * @param [in] idx: The index of loaded plugin.
 *
 * @return The name of plugin.
 */
DLLEXPORT const char* get_tengine_plugin_name(int idx);

DLLEXPORT const char* get_tengine_hcl_version(void);

#ifdef __cplusplus
}
#endif

#ifdef CONFIG_LEGACY_API
#include "tengine_c_compat.h"
#endif

#endif

redpajama_set_name: RedPajamaGithub


Cookie banner _cookiesBanner This cookie is used to control the appearance of the cookies information banner. This cookie is set on arrival to the site by default. It expires after a set time and is not set again unless a user changes their cookie settings.
Cookie preference _cookies This cookie is used to remember a user's choice about cookies on the RETRuly website. This cookie is, by default, set on arrival to the site with a value of 'True'. If users choose to delete non-essential cookies, the cookie value is updated to a value of 'False'.
Security breach notification form cookie ASP.NET_SessionId This cookie is essential for the breach notification form – the form that public electronic communications service providers use to notify RETRuly of a security breach – to operate. It is set only for those people using the form. This cookie is deleted when you close your browser.
_sortorder These cookies contain essential information about your account and your display settings. The cookise are set after you register or login and remains for a set time or until you log out of the site.


Here at The Carpet Guys we value each an every single customer that we come in contact with.
As a locally owned Michigan Company we strive to be known as the very best in our market. Because of this, we want to hear about your experience with our company.
Overall, how you you rate your experience with The Carpet Guys?


Both approach, a Valentine's Day may also be made a lot better with the addition of 1 factor: cocktails. Now not handiest can you get a pleasant buzz on sooner than or after dinner, however it displays the affection of your existence you care about them and you wish to have to turn it. Cocktails are gorgeous blends of taste that, when achieved proper, sing their own praises the artistry of the individual making it.
Smartly, a Valentine's Day cocktail displays off the artistry of the unique cocktail crafter, which is then translated in your personal hand, thereby (with a bit of luck) incomes you some brownie issues. You would possibly not be capable to get a hold of a Valentine's Day cocktail by yourself, however you don't must. Underneath, take a look at one of the crucial best possible beverages you'll be able to combine up in this pretty vacation.
Means: Upload all components to a blending tin and shake. Pour right into a rocks glass with beaten or cubed ice. Garnish with a cinnamon sugar rim with a 10:1 ratio, a strawberry or a spiral lemon twist.
Means: In a big container mix all components, stir and serve over ice. Serves 6.
Means: Mix all components in shaker with ice. Shake vigorously, then double pressure into coupe. Garnish with lime wheel.
*Cardamom cider syrup: take two 16 ozbottles of dry taste cider, upload 1/four cup inexperienced cardamom pods, and cut back over med warmth to two-thirds of the liquid. Upload 21 ozwhite sugar and produce to a boil. Take away from warmth, pressure cardamom pods, and refrigerate for 7-10 days.
Means: Combine components in a shaker with ice and shake neatly. Pressure right into a kick back martini glass and garnish with a cherry.
Means: Upload all components into cocktail shaker, seal your shaker and shake vigorously for five seconds. Then upload ice and shake once more for some other five seconds. Fantastic pressure right into a cocktail glass and garnish with a brandied cherry.
Means: Clutter Strawberries and Kiwis in shaker. Upload cocktail components to shaker. Shake. Pour components into Collins glass. End with ice and your favourite glowing water.
Means: Mix all components with the exception of for the espresso beans in a shaker and shake to include the egg white. Upload ice and shake once more. Pour right into a coupe. Garnish with espresso beans.
Means: Pour components right into a tall glass with ice. Stir and garnish with lemon twist and apple slice.
Means: Mix the rum, cantaloupe juice, syrup, cherry juice and lime juice in a shaker full of ice. Shake for 30 seconds then pour right into a frosted glass. Garnish with a wedge of lime and a melon ball.
*Cantaloupe juice: Mix 2 cups cubed cantaloupe melon in a blender till pureed and easy. Pressure the mix via a mesh strainer.
Means: Shake neatly with ice and pressure into a calming coupe glass. Garnish with a skinny slice of apple.


text:
Q: Python recognize_google from speech recognition module fails when run without console When run with console, module works fine without errors but using Pyinstaller to convert it to consoleless executables makes my program crash. It works till recognize_google() function. This is the full code:
import speech_recognition as sr
import autopy3
import ctypes
import winsound
from winsound import *

upali = sr.Recognizer()

def slusaj():
print("Cekam naredbu...")
with sr.Microphone() as glas:
    zvuk = upali.listen(glas)
    winsound.Beep(670,400)
try:
    #naredba = upali.recognize_google(zvuk)
    winsound.Beep(270,400)
except:
    slusaj()

#try:
winsound.Beep(870,400)
    #naredba = upali.recognize_google(zvuk)
print("Rekao si: "+ upali.recognize_google(zvuk))
winsound.Beep(1000,800)
    #if naredba == "Lock" or "lock":
    #   ctypes.windll.user32.LockWorkStation()
if upali.recognize_google(zvuk) == "lock":
        #winsound.Beep(670,400)
    ctypes.windll.user32.LockWorkStation()
else:
        slusaj()
#except:
    #slusaj()

slusaj()

redpajama_set_name: RedPajamaStackExchange


text:
\section{Abstract}

Two decades of U.S. government legislative outcomes, as well as the policy preferences of rich people, the general population, and diverse interest groups, were captured in a detailed dataset curated and analyzed by Gilens, Page \textit{et al.} (2014).
They found that the preferences of the rich correlated strongly with policy outcomes, while the preferences of the general population did not, except via a linkage with rich people's preferences.
Their analysis applied the tools of classical statistical inference, in particular logistic regression.
In this paper we analyze the Gilens dataset using the complementary tools of Random Forest classifiers (RFs), from Machine Learning.

We present two primary findings, concerning respectively prediction and inference:
\textit{(i)} Holdout test sets can be predicted with approximately 70\% balanced accuracy by models that consult only  the preferences of rich people  and a small number of powerful interest groups, as well as policy area labels.
These results include retrodiction, where models trained on pre-1997 cases predicted ``future" (post-1997) cases.
The 20\% gain in accuracy over baseline (chance), in this detailed but noisy dataset,  indicates the high importance of a  few wealthy  players in U.S. policy outcomes, and  aligns with a body of research indicating that the U.S. government has significant plutocratic tendencies. \\
\noindent \textit{(ii)}  The feature selection methods of RF models identify especially salient subsets of interest groups (economic players).
These can be used to further
investigate the dynamics of governmental policy making, and also offer an example of the potential value of  RF feature selection methods for inference on datasets such as this.

\section{Introduction}

In 2014, Gilens and Page presented their ground-breaking paper "Testing Theories of American Politics: Elites, Interest Groups, and Average Citizens" \cite{originalGilens}, based on their research into the influence of various actors (power groups) on the outcome of important policy outcomes in the United States.
The dataset spanned two decades, from 1981 to 2002, and consisted of policy cases determined to be of high importance.
They identified and described an extensive array of independent variables  in their paper and in their book "Affluence and Influence: Economic Inequality and Power in America" \cite{gilensBook}.

The two most important independent variables (hereafter ``features'') outlined in their work were:

\textit{(i)} The 90\textsuperscript{th} income percentile's opinion (P90);

\textit{(ii)} The net Interest Group Alignment (``netIGA''), a single derived variable combining the effects of 43 powerful interest groups (IGs).

They showed that public opinion at the 50\textsuperscript{th} percentile had little to no effect on the odds of policy adoption, challenging received notions of democracy in the United States.

Additional research over the years has further questioned notions of American democracy.
Thomas Ferguson's research into the effect of major investors and money on election outcomes has shown that money flows are an excellent predictor of U.S. congressional races outcomes \cite{ferguson} \cite{goldenRule}.
In 2016, the United States was downgraded by the UK-based Economic Intelligence Unit from``Full Democracy" to ``Flawed Democracy" \cite{revengeOfDeplorables}.
Bartel's work has shown that the policy preferences of ``affluent" Americans correlate closely  with senators' roll-call votes and government policy \cite{unequalDemocracy}.

Gilens and Page applied classical methods of statistics and regression to analyse their dataset.
Increasingly, Machine Learning (ML) methods are making their way into social science research \cite{mlForSociology}, and offer a distinct, complementary approach and set of tools for dataset analysis, one focused on prediction rather than inference \cite{breimanTwoCultures}.

In the political sphere, ML methods have been applied to Supreme Court rulings \cite{katz}, and to passage of bills in the U.S. Congress based on text in the bills \cite{nay,yano, gerrish}.
Prediction does not require interpretability, and some ML methods are largely ``black-boxes'' (\textit{e.g.} neural nets).
But some ML methods (\textit{e.g.} Random Forests) have interpretable aspects, and are thus potentially useful for inference \cite{domingosAlgorithm}.

Logistic regression (used by Gilens and Page) includes an intrinsic, strong assumption of linearity \cite{logisticRegression} (for details see Appendix).
Random Forests (RFs) in contrast are flexible, non-linear classifiers \cite{breimanRandomForests} that can handle large numbers of sparsely-represented features such as the preferences of the 43 individual IGs  in the Gilens dataset \cite{rfSparse}.
In addition,  RFs have natural metrics to assess the relative importance of each feature.
Thus RFs allow us to probe the dataset in complementary ways to Gilens and Page's use of a calculated netIGA  and logistic regression.

In this work we apply RF methods to the Gilens dataset with two goals, prediction and inference:
We use RFs to build predictive models of U.S. policy; and we extend Gilens and Page's inferential findings as to the influence of various actors on U.S. policy outcomes.
We offer two main findings: \\
(i) Policy outcomes on holdout sets can be predicted with approximately 70\% balanced accuracy (\textit{vs} 50\% chance baseline) using only a few feature categories from the Gilens dataset: Rich voters' preferences, a subset (as few as 14 out of 43) of individual IGs' preferences, and policy area labels. \\
(ii) The RF feature importance metrics enable further understanding and analysis of the salience of  individual actors, and also provide an example of RFs' potential usefulness for inference on datasets of this kind.

\section{Methods}

\subsection{Dataset}

The dataset consists of 1,836 major U.S. federal government policy cases dating from 1981 to 2002.
In terms of prediction, the dependent variable $y$ is  case outcome (``adopted'' or ``not adopted''). We reduced the large array of features in Gilens' dataset to three primary categories, described below:  \textit{(i)} voter preferences (in particular, of the wealthy) \textit{(ii)} IG alignments, and \textit{(iii)} policy descriptors (such as ``Foreign'', ``Social Welfare'', \textit{etc}).  Corresponding abbreviations are listed in Table \ref{featureAbbreviations}.

\begin{table}[!ht]
\begin{adjustwidth}{0.2in}{0.2in}
\centering
\caption{ \textbf{Feature abbreviations}
}
\begin{tabular}{|l|l| }
\hline
P90 & Voter preference of 90\textsuperscript{th} income \%ile \\
netIGA & Net Interest Group Alignment \\
IGs &  Individual Interest Groups (preferences) \\
PAs &  Policy Areas \\
PDs &  Policy Domains (a coarser version of PAs) \\ \hline
\end{tabular}
\begin{flushleft}
\end{flushleft}
\label{featureAbbreviations}
\end{adjustwidth}
\end{table}

\paragraph{Voter preferences (P90):}
Preferences of different wealth tranches were obtained  from national surveys of the general public, where participants were asked whether they favored or opposed a  proposed policy change.
Preferences of the different wealth tranches were then imputed at various income percentiles, viz 90\textsuperscript{th}, 50\textsuperscript{th}, and 10\textsuperscript{th} (hereafter P90, P50, P10).
Gilens and Page noted that P90 was a (rough) indicator of the preferences of even higher income percentiles (e.g. P99).
One of their key findings was that, among voter preferences, only P90 impacted case outcomes.
Our models used P90 as the sole voter preference feature (use of P50 or P10 as features degraded model accuracy).

\paragraph{Interest groups (IGs and netIGA):}
The dataset includes alignments, on each case, for a total of 43 distinct IGs.
These IGs  were mostly business groups such as the American Bankers Association, and also some social IGs such as the AARP (American Association of Retired Persons).
The alignment of each IG toward each case was assigned an ordinal value between 2 and -2 (Strongly Support, Somewhat Support, Neutral, Somewhat Oppose, or Strongly Oppose).
Routinely, a given IG had no opinion in a particular case, so non-neutral (non-zero) values were sparse.

To aid their analysis, Gilens and Page combined the alignments of all the individual IGs to create a single feature, the ``netIGA'' as follows:
\begin{equation}
\label{netIGAEqn}
 \text{netIGA} = log(  F_2+   0.5 F_1  + 1) ~
    - ~ log( O_2 +  0.5 O_1  +1), \text{ where}
\end{equation}
$F_2$ = number of IGs strongly in favor, $F_1$ = number somewhat in favor, $O_2$ = number strongly opposed, and $O_1$ = number somewhat opposed.
The $log(~)$ accounts for diminishing effects of multiple IGs weighing in on the same side of a given case.

Because RFs readily handle large numbers of features, we set aside the netIGA and instead used each IG's alignment value as a separate feature.

\paragraph{Policy areas (PAs):}
The Gilens dataset  includes an in-depth policy descriptor category which we refer to as policy area (PA) labels, \textit{e.g.} Campaign Finance, Welfare Reform, \textit{etc}.

A full list of the 19 PAs is given  in the Appendix.
 PAs were expressed as features via one-hot encoding (\textit{i.e.} one feature per PA, taking values 0 or 1, according as the case was in that PA).
Each case is assigned to exactly one PA.

\paragraph{Policy Domains (PDs):}
The Gilens dataset also includes six broader policy domain (PD) labels (Economic, Foreign, Social welfare, Religious, Guns, and Miscellaneous). In general, several PAs are contained in one PD, though some PAs are also PDs (\textit{e.g.} Foreign Policy).
PDs were one-hot encoded.
Table \ref{tablePosAndNegCountsByDomainAndDate} shows a breakdown of positive (\textit{i.e.} adopted) and negative (\textit{i.e.} not adopted) cases by PD over the full dataset, as well as over just the post-1997 test set (used for retrodiction).

PDs were used for feature selection:
We grouped cases by PD, trained a different  RF model for each PD using P90 and individual IGs as features, then selected  the most salient IGs for each PD based on these models.

\begin{table}[!ht]
\begin{adjustwidth}{0.2in}{0.2in}
\centering
\caption{ \textbf{Positive and negative case counts.}
Number of positive (``adopted'') and negative (``not adopted'') cases, as well as percentage of cases that were positive, for each PD, over the full dataset (numbers over post-1997 cases are in parentheses).
Economic policy and Foreign policy are fairly evenly-balanced, while other PDs skew negative.
In some PDs (\textit{e.g.} Social Welfare, Guns) the distribution of positive/negative cases differed pre- \textit{vs} post-1997. \\~
}
\begin{tabular}{|l|c|c|c| }
\hline
{\bf Domain}  & {\bf Pos} & {\bf Neg} & {\bf \%Pos}  \\ \hline
Economic & 160  (36) & 248 (38)  &  39\% (49\%)\\ \hline
Foreign & 244 (77)  &  196 (59) &  55\% (57\%)\\ \hline
Social Welfare&  101~(20)  & ~310 (152) & 25\% (12\%) \\ \hline
Religious & ~43 (18) & 123 (68)  &  26\% (21\%)\\ \hline
Guns & 18 (1)~ & ~81 (49)   & 18\% (2\%)~~\\ \hline
Misc &  ~77 (36) &  235 (95)   & 25\% (27\%)\\ \hline
Total & 643 (188) & 1193 (461)  & 35\% (29\%)\\ \hline
\end{tabular}
\begin{flushleft}
\end{flushleft}
\label{tablePosAndNegCountsByDomainAndDate}
\end{adjustwidth}
\end{table}

\subsection{Train/test splits}

We trained models in two regimes:
\textit{(i)} Random train/test splits drawn from the full dataset ( \textit{N} = 25 draws, ratio 67\%, 33\%).
This provided robust error bars on our prediction accuracy results since each train/test split was different.
\textit{(ii)} Future prediction (more precisely, retrodiction):
All pre-1997 cases in training and all post-1997 cases  (including 1997) in  testing (ratio 65\%, 35\%).

Retrodiction tested stability over time, with the possibility that individual IGs might gain or lose relevance over the two decade duration of the dataset.

\subsection{Reported metrics}

We report two figures of merit: maximum Balanced Accuracy, and Area Under the Curve (AUC) of the ROC curve.
Evaluated on the test set, these are standard measures of a model's classifying abilities.
Maximum balanced accuracy is defined as
\begin{equation}
\label{balAccEqn}
balanced ~ accuracy = \frac{sensitivity + specificity}{2},
\end{equation}

\noindent where sensitivity is the percentage of positive  cases correctly classified, and specificity  is the percentage of negative cases correctly classified.
The operating point (decision threshold) used to predict test cases is that which gives maximum balanced accuracy on the training set (this threshold typically gives lower test set accuracy than would be possible given oracle  knowledge of test set behavior).

We report balanced rather than raw accuracy for two reasons.
First, it has a clear, consistent baseline accuracy (50\% = chance).
Second, in this dataset, negative cases outnumber positive ones, by substantial margins in some policy domains (cf. Table \ref{tablePosAndNegCountsByDomainAndDate}).
Given a class imbalance, raw accuracy blurs the differences between models because all models can leverage the imbalance by effectively betting on system inertia (\textit{i.e.} the fact that most legislation is not adopted).

\subsection{Random Forest models}

RFs are flexible, robust, non-linear classifiers \cite{breimanRandomForests} based on ensembles of decision trees.
In a RF, many decision trees are generated, each of which trains on a random subset of the training data.
At each node of a given tree, a randomly-chosen feature splits the data.
The final prediction of a test case is an average of the trees' predictions of that case.
RFs are adept at handling sparse datasets with large number of features \cite{rfSparse}, though removing uninformative features can improve model accuracy.

Our code was written in Python \cite{pythonWebsite} and used the sklearn library \cite{sklearnWebsite}.
Full codebase can be found at \cite{githubCodebase}.

The accuracies of two other flexible classifiers, XGBoost \cite{xgBoost} (a flavor of RF) and Neural Nets,  were similar to  standard RFs (results not reported).

\subsection{Feature selection}
To rank the importance of the various IGs as features, cases were divided into 6 groups according to Policy Domain.
For each domain, RFs were trained on random train/test splits (\textit{N} = 21), using  P90 and the 43 IGs as features.
The averaged feature importance scores were then ranked.
For more details see the Appendix.

\section{Results}

Results are divided into two sections: Inference (feature selection by RFs); and Prediction (including retrodiction).

\subsection{Inference}
\label{subsubsectionSelectionOfImportantIGs}
The goal of Inference was to identify the most salient IGs by ranking their power as predictors.
The  43 IGs were ranked as predictors for each Policy Domain as described above.
A typical feature ranking (for the Foreign Policy  domain) is shown in Table \ref{tableInterestGroupOutcomeCorrelationsForeign}.
Similar tables of IG rankings for other PDs are in the Appendix.

The  ranking  extracted those IGs with the most impact on policy outcomes, which has direct relevance to the study of policy decision-making in the U.S.
We note three points about the rankings:

(1) Saliency (defined as maximizing model accuracy) is not the same as effectiveness of influence, because an IG's success is also a function of the difficulty of the particular cases it lobbied for or against (by analogy, a baseball player's batting average is partly a function of the pitchers they face).

(2) Bias can be introduced into the rankings based on various predictor attributes \cite{biasRF}.
For example, less-sparse features (IGs with more at-bats) tend to have higher rankings.
In this dataset, restricting by Policy Domain mitigates this difference in sparsity since IGs tend  to be especially active in a particular PD.

(3) An IG can have predictive saliency due to negative correlations.

Correlations between IG preferences and case outcomes are given in Column 3 of Table \ref{tableInterestGroupOutcomeCorrelationsForeign}.
To calculate this correlation,  only cases where the IG was not neutral (\textit{i.e.} was ``at bat'') were considered:

\begin{equation}
\label{igOutcomeCorrEqn}
corr(IG) =  \frac{0.5}{\#at~bats}\left( \sum\limits_{i | y_i = 1} x_i  ~ - \sum\limits_{i | y_i = 0} x_i \right), \text{  where }
\end{equation}
$x_i$ =  IG preference $\in$\{ -2, -1, +1, +2\} and $y_i$ =  outcome $\in$\{ 0 or 1\},  for the \textit{i\textsuperscript{th}} case.
The 0.5 term normalizes the IG preference values.
For these calculations, P90 values were rescaled from [0,1] to [-2, 2] and then values in [-0.4, 0.4] (i.e. noncommittal) were set to 0, to allow comparison with IGs.

\begin{table}[!t]
\begin{adjustwidth}{0.2in}{0.2in}
\centering
\caption{ \textbf{Feature importance scores in Foreign policy.}
Feature importance scores, IG stance \textit{vs} case outcome correlations, and IG at-bats, given as mean $\pm$ std dev  over 25 random train/test splits of the full dataset, restricted to Foreign policy cases only.
``at-bats'' gives the number of test cases for which the IG had a non-neutral stance (out of 147 $\pm$ 7 foreign policy test cases).
}
\begin{tabular}{|l+c|c|c|c|c|c|}
\hline
   & {\bf RF} &     {\bf IG-outcome }   &  {\bf  at-bats }  \\
  {\bf ~~~~~~~~IG} & {\bf  score} &   {\bf correlation }&  {\bf  (out of 147) }\\
  \hline
P90                            &   41 $\pm$  3   &  20 $\pm$   3      &  93 $\pm$ 6    \\ \hline
Defense industry  &   12 $\pm$   3     &   41 $\pm$  13    &  39 $\pm$ 5 \\ \hline
AIPAC                       & 7 $\pm$  2       &   -18 $\pm$  11   &  17 $\pm$ 4  \\ \hline
Auto companies  &    5  $\pm$  1     &   48 $\pm$  15    &  13 $\pm$   2\\ \hline
UAW union           &    5  $\pm$   1     &   -59 $\pm$  14   &  41 $\pm$   3\\ \hline
Oil companies    &   4 $\pm$   1         &   37  $\pm$  33  &   5 $\pm$  2 \\ \hline
Airlines                  &  4 $\pm$   1      &   54 $\pm$  23   &   8 $\pm$  2 \\   \hline

\end{tabular}
\begin{flushleft} Columns 2 and 3  are scaled by 100$\times$.  \\

\end{flushleft}
\label{tableInterestGroupOutcomeCorrelationsForeign}
\end{adjustwidth}
\end{table}

For example, in the Foreign policy domain (\textit{cf} Table \ref{tableInterestGroupOutcomeCorrelationsForeign}, Defense Contractors' stance was positively correlated with outcomes (mean $\pm$ std dev: 41 $\pm$ 13), AIPAC's stance had mixed correlation (18 $\pm$ 11), and Labor Unions' stances were negatively correlated (-59 $\pm$ 14).
Note that negative correlation does not mean that the IG ``lost'': Its actions may have averted worse outcomes, or modified the case's legislative details in desired ways.\\~

The most salient IGs for each Policy Domain, as determined by RF feature selection, were as follows:\\
1. Foreign policy: Defense contractors; then AIPAC, auto companies and auto workers union.\\
2. Economic policy: Construction and realtors; then tobacco companies and a union.\\
3. Social welfare policy: the AARP and investment companies; then governors, pharmaceutical companies, universities, teachers, and health insurance companies.\\
4. Religious policy: Christian and anti-abortion groups; then doctors, teachers, beer companies, tobacco companies, health insurance companies, and broadcasters.\\
5. Gun policy: the NRA (no other IG was active).\\
6. Miscellaneous: Chamber of Commerce; then two unions (AFL-CIO and government workers), automobile companies; then oil companies, Christian Coalition, and trial lawyers.\\
The preferences of the wealthy (P90) outranked every IG in every policy domain except Social Welfare, where the AARP dominated.

Tables of IG data  for each Policy Domain (feature importance, correlations with outcomes, and number of ``at-bats'') are given in the Appendix.

\subsubsection{Advantages of RF's nonlinear flexibility in feature selection}
\label{nraVsP90}

RFs do not have the built-in linear structure of logistic regression.
In the inference context, this flexibility means that RFs can give insights into feature salience which are unavailable to logistic regression.

An example from the foreign policy domain data is described here.
The highest ranked features for the RF model were P90 and Defense Contractors.
The logistic regression model for the foreign policy domain ranked P90 and Defense Contractors as the 2nd and 6th most salient features, respectively.
We examined policy cases involving P90 and Defense Contractors to gain some comparative understanding.

When Defense Contractors strongly favor a policy change, they almost always get their way, even when the wealthy are opposed.
However, when the Defense Contractors oppose a policy change, P90 has a strong positive correlation with outcomes.
Logistic regression fails to parse this effect, giving many False Negatives (see Fig \ref{figureRfSplitOfForeignCases}).
RFs handle this readily, yielding 95\% balanced accuracy for the RF \textit{vs} 79\% for logistic regression.
That is, the high importance of P90 in Foreign policy cases depends on a relationship more readily encoded by the RF model.

We note that RFs selected significantly more salient features than did logistic regression.
For details see the Appendix, section \ref{sectionFeatureSelectionDetails}.

\begin{figure}[!th]
\begin{adjustwidth}{0.2in}{0.2in}
\centering
{\includegraphics[width= 1\linewidth]{FpynDefenseP90Example_v5.png}}
\caption{{\bf Benefit of nonlinear splits.}
Foreign policy outcomes on cases where Defense Contractors had a non-neutral stance.
\textit{y}-axis = P90, \textit{x}-axis = Defense Contractors' preference.
Solid dots are positive outcomes, open diamonds are negatives.  TP = true positive, TN = true negative, FN = false negative, FP = false positive.
{\bf{left:}}  True outcomes.
There are three regions, marked by magenta lines:  When Defense Contractors favored a case it almost always passed, regardless of P90 (right half of plot).
When Defense Contractors opposed a case then either:  it failed if P90 opposed it (lower left) or  it had reasonable odds of passing if P90 favored it (upper left).
{\bf{middle:}} Logistic predictions (blue = correct, red = wrong), with many errors in the upper left region.
{\bf{right:}} RF predictions (blue = correct, red = wrong).
RFs readily parse all three regions. }
 \label{figureRfSplitOfForeignCases}
\end{adjustwidth}
\end{figure}

\subsection{Prediction}

The goal of Prediction was to examine to what degree U.S. legislative outcomes might be predicted from the preferences of rich voters and Interest Groups, and which actors were most informative.

Our key finding is that legislative outcomes can be accurately predicted using P90, policy descriptors (PDs or PAs), and individual IGs.
Balanced accuracy on test sets of the trained RF reached $\approx$70\%, a gain of 20\% over baseline chance.

P90 was a vital feature, in the sense that excluding it always degraded accuracy.
Inclusion of P50 (median wealth voter preferences)  as a feature slightly degraded accuracy, consistent with the finding of P50's irrelevance in \cite{originalGilens}.
Use of either PD or PA labels as a feature increased accuracy.
Training and then combining separate models for each Policy Domain did not increase overall accuracy (results not reported).

We report results for RF models using four feature sets  (listed below), in two train/test scenarios:
\textit{(i)} Multiple random train/test splits of the full dataset (``Random Draw'' in Table \ref{tableAccuracyOneModel});
and
\textit{(ii)} Retrodiction (i.e., train on pre-1997 cases and test on post-1997 cases,  a single train/test split).

Feature sets used were:

 {\bf Set A:} P90 and netIGA (Baseline, from \cite{originalGilens}).

 {\bf Set B:}  P90, PDs, and all 43 individual IGs.

{\bf Set C:}  P90, PDs, and 14 IGs chosen by RF feature selection (Gini impurity).

{\bf Set D:}  P90, PAs, and all 43 IGs.

Balanced accuracies and AUCs for RF models using the four Feature Sets and in the two regimes are given in Table \ref{tableAccuracyOneModel}.
We offer the following observations:

(1) All feature sets used P90, which was always the most important.
The feature sets differed in how they used IGs, and how they used Policy descriptors.

(2) Sets B - D substantially outperformed Set A (\textit{e.g.} 11\% mean increase in AUC).\\
Use of individual IGs \textit{vs} the simplified netIGA was the main factor behind this improvement in prediction accuracy.
Figure  \ref{figureRelAcc} shows the mean improvement  in accuracy of Set B over Set A,
broken out by individual IGs (``Random Draw'' regime).

(3) Set C had equivalent performance to Set B, indicating that a small subset of 14 IGs (chosen by RF feature selection) carried as much salience as the full set of 43 IGs.
We note this does not imply that these 14 IGs were the only ones that mattered:
Certainly they were important actors, but they likely also encoded correlated salience of other IGs.

(4) Set D posted better performance than Model B, indicating that Policy Area labels had more salience than the coarser Policy Domain labels.

(5) Set D
gave the best results (70\% balanced accuracy, 78\% AUC).
The full list of features for Model D, with their importance rankings, is given in Table \ref{modelDFeatureImportance} in the Appendix.

 \begin{table}[!ht]
\begin{adjustwidth}{0.2in}{0.2in}
\centering
\caption{ \textbf{RF accuracy with various feature sets.}
Balanced Accuracy and AUC for RFs given various feature sets.
``PD'' means Policy Domains.
``PA" means Policy Areas.
Results are given as percentages, mean $\pm$ 1 std dev (\textit{N} = 25).}
\begin{tabular}{|l+c|c+c|c|}
\hline
 \multicolumn{1}{|c+}{\bf Model} & \multicolumn{2}{c+}{\bf Random Draw} & \multicolumn{2}{c|}{\bf Retrodiction}    \\
  & Bal Acc \% & AUC  \%& Bal Acc \% & AUC \%\\ \hline

{\bf A:} P90, netIGA & 61.5 $\pm$ 1.7 & 66.2 $\pm$ 2.1 & 64.6 $\pm$ 0.6 & 70.2 $\pm$ 0.3\\ \hline
{\bf B:}  P90, 43 IGs, PDs & 67.3 $\pm$ 1.6 & 74.9 $\pm$ 1.7 &  69.0 $\pm$ 0.7 & 75.7 $\pm$ 0.2\\ \hline
{\bf C:}  P90, 14 IGs, PDs & 67.3 $\pm$ 1.6 & 75.1 $\pm$ 1.6 &  68.8 $\pm$ 0.5 & 75.7 $\pm$ 0.2\\ \hline
{\bf D:} P90, 43 IGs, PAs & {\bf 70.1  $\pm$ 1.5} & {\bf 77.7 $\pm$ 1.5} & {\bf 71.3 $\pm$ 0.7} &{\bf  76.5 $\pm$ 0.4}\\ \hline

\end{tabular}
\begin{flushleft}
\end{flushleft}
\label{tableAccuracyOneModel}
\end{adjustwidth}
\end{table}

\begin{figure}[!ht]
\begin{adjustwidth}{0.2in}{0.2in}
\centering
{\includegraphics[width= 1 \linewidth]{delta_acc_blueAndRed.png}}
\caption{{\bf Gain in accuracy per IG, Set B \textit{vs} Set A. }
Set B used P90, all 43 IGs and Policy Domains.
Set A used  P90 and netIGA only.
For each IG, we measured test set accuracy on those cases where the IG was ``strongly in favor'' or ``strongly opposed'' and plotted \textit{accuracy(Set B) - accuracy(Set A).}
Set B consistently improved accuracy on these IG-based groups of cases.
Random draw regime, \textit{N} = 25.
Each IG shown had at least 20 cases in the test set.}
 \label{figureRelAcc}
\end{adjustwidth}
\end{figure}

\section{Discussion}

In this work we applied the tools of Machine Learning to the Gilens dataset, as an aid to inference as well as for prediction.
RF algorithms readily handle sparse datasets  that can be difficult for traditional regression techniques.
RF methods enabled prediction of policy outcomes with surprising accuracy, especially considering the intrinsic noisiness of the dataset.
They also enabled us to examine the role of individual IGs and the effects of various features of the dataset.
Additionally, we have shown  how RFs can provide insights into  feature saliency distinct from and arguably superior to traditional regresssion techniques such as logistic regression.

We found that case outcomes on test sets were predictable with $\approx$70\% balanced accuracy
using only the preferences of the wealthy (P90), individual Interest Groups, and Policy Area labels as features.
Inclusion of the wishes of median income voters (P50) always reduced predictive accuracy.
These results also held for a retrodiction split,  training  on pre-1997 cases and testing on post-1997 cases.
We believe that the high predictability of policy outcomes using models based on only a few wealthy actors (P90 and certain IGs) reinforces Gilens and Page's findings about the plutocratic tendencies of U.S. government.

We suspect that the 90\textsuperscript{th} percentile serves as a proxy for the opinions of the very wealthy, and we expect that  predictive accuracy would further  improve given better measures of the opinions of the ``very wealthy" (\textit{e.g.} the 99\textsuperscript{th} income percentile).

There has been effort in recent years to capture the policy opinions of the very wealthy as distinct from the general population.
A unique  study led by Benjamin Page   effectively captured, via surveys and interviews, the policy preferences of those in, or near, the top 1\% of income in the United States \cite{policyPreferencesOfWealthy}.
The results indicated, among other things, that the very wealthy held policy preferences that were much more conservative in such important domains as social welfare programs, taxation, and regulation of the economic system.
Their research also showed that the very wealthy were much more politically active, with significantly higher rates of financial contributions to, and contact with, public officials.
This highlights the importance of  quantitatively capturing the opinions of the very wealthy in the future, in order to better understand their impact on policy adoption by the U.S. government.

\section{Appendix}

\subsection{Logistic regression}
Given a feature-label pair \{$\bm{x}, y$\}, logistic regression gives an  estimate $\hat{y}$ of the class $y$, using features $\bm{x}$, by passing a linear combination of feature values $\bm{\beta x}$ through a (non-linear) sigmoid function $ \sigma(s) = \frac{1}{1 - e^{-s}}$. The coefficients $\bm{\beta}$ are the fitted parameters.
\begin{equation}
\hat{y} = \frac{1}{1 - e^{-\bm{\beta x}}}
\end{equation}

\subsection{Feature selection details}
\label{sectionFeatureSelectionDetails}

In order to identify the most important IGs, we used RF's standard Gini impurity method \cite{breimanClassification}, indicated for this dataset  because the features were sparse, non-categorical, and similarly scaled (in range [-2, 2]) \cite{rfSparse} (because IGs were ranked for each Policy Domain separately, the PDs were not features.)

For feature ranking purposes, P90 scores were rescaled from [0,1] to [-2, 2]  to match the IG preference range.
Unlike Gini impurity, RF's Permutation method had unstable results (IG rankings changed if P90 was excluded).
In general, the RFs selected different subsets of important IGs than those selected via the $\beta$ coefficients of logistic regression.

Features selected by RF (Gini impurity) significantly out-performed features selected by logistic regression, in the sense that  using RF-Gini features gave a model (either RF or logistic regression) much higher accuracy than  using features selected by logistic regression.
Features chosen by FR's Permutation method landed between the two.
Table \ref{tableRfVsLogisticChosenFeatures} shows the gain in accuracy due to RF (Gini)-chosen features vs logistic-chosen features.

We note that for a fixed set of features, RF and logistic regression models gave similar accuracies (in general, RF accuracy was slightly but not significantly better, consistent with \cite{rfVsLogistic1}).
The key advantage of RFs lay not in prediction \textit{per se}, but rather in selecting much more salient features (\textit{i.e.} inference).

\begin{table}[!ht]
\begin{adjustwidth}{0.2in}{0.2in}
\centering
\caption{ \textbf{Difference in salience of IGs chosen by RF \textit{vs} logistic regression.}
Balanced accuracy (balAcc) and AUC of RF and logistic models on test sets, using either RF-chosen IGs or logistic-chosen IGs, given as mean $\pm$ std dev.
The gains in accuracy (RF-chosen minus Logistic-chosen) are shown in bold.
(\textit{N}= 21 train/test splits).
}
\begin{tabular}{|c|c| c|c|c|c| }
\hline \multicolumn{2}{|c|}{\bf Setup} & \multicolumn{2}{c|}{\bf Full data} & \multicolumn{2}{c|}{\bf Retrodiction}    \\
  { Model} & {  IG type} &    { balAcc} & { AUC} &   { balAcc} & { AUC }\\  \thickhline
 &  RF-chosen (Gini)              &  63.5  $\pm$ 1.6         &   68.2  $\pm$ 2.2         &     66.4   $\pm$ 2.4      & 69.7   $\pm$ 1.0      \\ RF   &  Logistic-chosen     &  56.7    $\pm$ 1.7        &  61.1  $\pm$ 1.9         &      53.4    $\pm$  2.7   &     53.9 $\pm$  2.7          \\
 & Gain  &    \bf 6.8  $\pm$ 1.9   &    \bf 7.0  $\pm$ 1.6  &  \bf 13.0    $\pm$ 4.4 &   \bf  15.8    $\pm$   3.3      \\ \hline
& RF-chosen (Gini)      &  59.5   $\pm$ 1.8         &  61.4   $\pm$ 2.1        &    59.3                             &  62.6         \\
Logistic   & Logistic-chosen   &  55.0     $\pm$ 1.6 &  56.6    $\pm$ 1.6      &   52.6                             &   51.6       \\
& Gain &  \bf 4.5  $\pm$ 1.9 & \bf 4.7  $\pm$ 1.7 &  \bf  6.7                         &   \bf  10.9      \\ \hline
\end{tabular}
\begin{flushleft}
``Gain'' is the mean of differences (not difference of means).\\
Logistic regression is deterministic on non-separable data, so its prediction of the post-1997 data  has 0 std dev.\\
\end{flushleft}
\label{tableRfVsLogisticChosenFeatures}
\end{adjustwidth}
\end{table}

\subsection{IG rankings by Policy Domain}

Importance rankings,  correlations with case outcomes, and number of ``at-bats'' for IGs, for various Policy Domains, are given  in Tables  \ref{tableInterestGroupOutcomeCorrelationsEconomic} - \ref{tableInterestGroupOutcomeCorrelationsGuns}.
For more details, and for a table of Foreign policy results, see section \ref{subsubsectionSelectionOfImportantIGs}.

\begin{table}[!h]
\begin{adjustwidth}{0.2in}{0.2in}
\centering
\caption{ \textbf{Economic policy.}
Correlations  for the most salient IGs, given as mean $\pm$ std dev.
Each test set had 130 $\pm$ 6  Economics  cases.
}
\begin{tabular}{|l+c|c|c|c|c|c|}
\hline
   & {\bf RF} &   {\bf IG-outcome }   &  {\bf  at-bats }  \\
  {\bf ~~~~~~~~IG} & {\bf  score} &  {\bf correlation }&  {\bf  (out of 130) }\\
  \hline
P90                                 &   21 $\pm$  2       &   12 $\pm$   4      &  94 $\pm$ 5    \\ \hline
Nat'l Assoc Homebuilders            &      6  $\pm$  2       &   23 $\pm$  7       &  41 $\pm$ 5 \\ \hline
Nat'l Assoc Realtors                        &   6 $\pm$  2       &   46 $\pm$   11    &  22 $\pm$ 4  \\ \hline
Tobacco Companies  &    5  $\pm$  1    &   18 $\pm$  11     &  31 $\pm$   6\\ \hline
Teamsters union         &    5  $\pm$   1       &   40 $\pm$  11   &  19 $\pm$   3\\ \hline

\end{tabular}
\begin{flushleft} Columns 2 and 3 are scaled by 100$\times$.
\end{flushleft}
\label{tableInterestGroupOutcomeCorrelationsEconomic}
\end{adjustwidth}
\end{table}

\begin{table}[!h]
\begin{adjustwidth}{0.2in}{0.2in}
\centering
\caption{ \textbf{Social Welfare policy.}
Correlations  for the most salient IGs, given as mean $\pm$ std dev.
The AARP had strong positive correlation with outcomes, while 90\textsuperscript{th} \%ile was mixed and investment interests had negative correlations.
Each test set had 137 $\pm$ 7  Social Welfare cases.}
\begin{tabular}{|l+c|c|c|c|c|c|}
\hline
   & {\bf RF} &     {\bf IG-outcome }   &  {\bf  at-bats }  \\
  {\bf ~~~~~~~~IG} & {\bf  score} &   {\bf correlation }&  {\bf  (out of 137) }\\
  \hline
AARP                            &   23 $\pm$  2    &  60 $\pm$   8     &  71 $\pm$ 7    \\ \hline
P90                               &   18  $\pm$  2   &     -3 $\pm$  5     &  88 $\pm$ 9 \\ \hline
Invest \& Securities Assoc    & 13 $\pm$  2  &   -94 $\pm$   8    &  15 $\pm$ 3  \\ \hline
Nat'l Governors Assoc &    6  $\pm$  1 &     4 $\pm$  20    &  22 $\pm$   4\\ \hline
Pharmaceuticals      &    5  $\pm$   1     &   48 $\pm$  22    &  13 $\pm$   4\\ \hline
Universities               &  5 $\pm$   2    &  55  $\pm$ 50   &  3  $\pm$  1  \\ \hline
Nat'l Education Assoc          &  4 $\pm$    1      & 27   $\pm$ 25   &  16  $\pm$ 3   \\ \hline
Health insurance Assoc    &  4 $\pm$   1        & 36   $\pm$ 22   &  21  $\pm$  3  \\ \hline

\end{tabular}
\begin{flushleft} Columns 2 and 3 are scaled by 100$\times$.
\end{flushleft}
\label{tableInterestGroupOutcomeCorrelationsSocialWelfare}
\end{adjustwidth}
\end{table}

\begin{table}[!h]
\begin{adjustwidth}{0.2in}{0.2in}
\centering
\caption{ \textbf{Religious policy.}
Correlations  for the most salient IGs, given as mean $\pm$ std dev.
Only 12 IGs had non-zero alignments on Religious cases, and only 2 IGs were often non-zero.
Most features, including P90, had mixed correlations with outcomes.
Anti-abortion groups had negative correlations.
Each test set had 56 $\pm$ 5 Religious cases.
}
\begin{tabular}{|l+c|c|c|c|c|c|}
\hline
   & {\bf RF} &   {\bf IG-outcome }   &  {\bf  at-bats }  \\
  {\bf ~~~~~~~~IG} & {\bf  score} &  {\bf correlation }&  {\bf  (out of 56) }\\
  \hline
P90                                      &   36 $\pm$  3       &  6  $\pm$   5        &  30 $\pm$ 4      \\ \hline
Nat'l Right to Life           &   23  $\pm$  2    &   -55 $\pm$  19   &  16 $\pm$ 4   \\ \hline
Christian Coalition          & 10 $\pm$  2     &   -14 $\pm$   14  &  43 $\pm$ 4    \\ \hline
Am. Medical Assoc          &    7  $\pm$  2     &   -21 $\pm$  38   &  4 $\pm$   1    \\ \hline
Nat'l Education Assoc    &   6  $\pm$   2    &   65 $\pm$  26   &  5 $\pm$   1    \\ \hline
Beer Companies             &  4 $\pm$   1        &  -34  $\pm$ 72   &  2  $\pm$  1    \\ \hline
Tobacco Companies      &  4 $\pm$    1     & -11   $\pm$ 55   &  4  $\pm$ 1    \\ \hline
\end{tabular}
\begin{flushleft} Columns 2 and 3 are scaled by 100$\times$.
\end{flushleft}
\label{tableInterestGroupOutcomeCorrelationsReligion}
\end{adjustwidth}
\end{table}

\begin{table}[!h]
\begin{adjustwidth}{0.2in}{0.2in}
\centering
\caption{  \textbf{Gun policy.}
Correlations   for the most salient IGs, given as mean $\pm$ std dev.
The NRA was the only active IG, and it had strong positive correlation with outcomes.
P90 (and P50) had low overall  correlation with outcomes, but paradoxically had much higher importance scores (both RF and Logistic) than did the NRA.
P90's high RF importance score was likely due to its non-linear splitting ability even while it did not ``get what it wanted'' (similar to the situation described in section \ref{nraVsP90}).
Each test set had 33 $\pm$ 6 Gun cases.
}
\begin{tabular}{|l+c|c|c|c|c|c|}
\hline
   & {\bf RF} &   {\bf IG-outcome }   &  {\bf  at-bats }  \\
  {\bf ~~~~~~~~IG} & {\bf  score} &   {\bf correlation }&  {\bf  (out of 33) }\\
  \hline
P90                            &   96 $\pm$  1    &  -11 $\pm$   11      &  28 $\pm$ 5    \\ \hline
Nat'l Rifle Assoc  &   4  $\pm$  1      &   51 $\pm$  16    &  32 $\pm$ 5 \\ \hline

\end{tabular}
\begin{flushleft} Columns 2 and 3 are scaled by 100$\times$.
\end{flushleft}
\label{tableInterestGroupOutcomeCorrelationsGuns}
\end{adjustwidth}
\end{table}

\clearpage

\subsection{Set D feature importances.}
Feature Set D gave the most accurate predictions.
Features consisted of:
P90 (continuous values $\in$ [0,1]); 43 individual interest groups (values $\in$ \{-2, -1, 0, 1, 2\}); and 19 Policy Areas (Budget, Campaign Finance, Civil Rights, Defense, Economics and Labor, Education, Environment, Foreign Policy, Government Reform, Guns, Health, Immigration, Miscellaneous, Race, Religion, Social Welfare, Taxation, Terrorism, Welfare Reform, all one-hot encoded).
Table \ref{modelDFeatureImportance} shows feature rankings found by RFs (Gini impurity) for Set D.
Note that because this feature set combines one-hot and ordinal value encodings, the caveats in \cite{rfSparse} and \cite{biasRF} may apply.

\begin{table}[!ht]
\begin{adjustwidth}{0.2in}{0.2in}
\centering
\caption{ \textbf{Set D feature importances.}
Mean scores (\textit{N} = 50 runs) of the top 25 most salient features.
Policy Area features indicated by  ``(PA)'' before the feature.
RF importance scores are scaled by 100$\times$.
}
\begin{tabular}{|l|c| }
\hline
	\bf Feature & \bf Mean RF score \\ \hline
	P90 & 27.3 \\ \hline
	AARP & 8.9 \\ \hline
	(PA) Foreign Policy & 7.9 \\ \hline
	Defense Contractors & 4.9 \\ \hline
	Chamber of Commerce & 2.8 \\ \hline
	(PA) Social Welfare & 2.1 \\ \hline
	National Association of Realtors & 2 \\ \hline
	National Right to Life Committee & 2 \\ \hline
	Health Insurance Association & 1.8 \\ \hline
	Christian Coalition & 1.8 \\ \hline
	National Rifle Association & 1.7 \\ \hline
	(PA) Health & 1.7 \\ \hline
	AFLCIO & 1.5 \\ \hline
	(PA) Campaign Finance & 1.5 \\ \hline
	(PA) Defense & 1.4 \\ \hline
	American Farm Bureau Federation & 1.3 \\ \hline
	American Israel Public Affairs Committee & 1.3 \\ \hline
	(PA) Guns & 1.2 \\ \hline
	Securities and Investment Companies & 1.2 \\ \hline
	National Federation of Independent Business & 1.2 \\ \hline
	National Association of Manufacturers & 1.1 \\ \hline
	Automobile Companies & 1.1 \\ \hline
	United Auto Workers Union & 1 \\ \hline
	Tobbaco Companies & 1 \\ \hline
\end{tabular}
\begin{flushleft}
\end{flushleft}
\label{modelDFeatureImportance}
\end{adjustwidth}
\end{table}

\nolinenumbers

redpajama_set_name: RedPajamaArXiv


The First Tee of Fort Worth's complete Life Skills programming is offered year-round at golf courses across our region, including our flagship location at The Ben Hogan Learning Center, Squaw Creek and other local facilities. From age 7 through 18, youth progress through different levels by demonstrating The First Tee Nine Core Values, life and golf skills as well as passing an assessment. All participants regardless of age start at the PLAYer level. The pinnacle of The First Tee is completing Ace.


The paintings shown here are part of a 14 picture series all made on location during February 1992 while the artist and his family lived at 94 Radford Park Road, Plymouth.
As usual in Plymouth in February the weather was grim n grey.
In their way these paintings are a triumph of the human spirit over grim cold environment reminding us that things are rarely as bad as they look if one looks carefully.
Following a 'colour revelation' (see "Red Bales") the previous summer while studying at at the Painting School of Montmiral in SW France the artist was becoming increasingly frustrated being house bound.
His responsibilities included the safe delivery and collection of his two delightful babe's to and from school, their evening supper.
His wife used their car to get to and from work so time was almost as limited as February day light.
Fortunately and not to be kept down, the lake was easy easel distance form the artist's home so well wrapped and snuggled into his sea jacket & 'oil skin' trousers (older spelling trowsers) he took on the challenge of weather, time, and light.
The objectives included to see how much colour could be found on the grizzly grey days accompanying photographs reveal.
A further incentive was Plymouth City Council had in their wisdom decided the wrecks were a health hazard, rat infested (not particularly true) so should be broken up.
Only one hull was to be spared, her name largely forgotten, the most difficult to access, her remains are still there today (2015) 100 feet off shore, the old Tamar River sailing barge "Alfred".
Hooe Lake (sometimes locally called and with good reason, Dolphin Lake) has in it's time seen more than a few adventures.
The lake was known as Dolphin Lake because inteligent dolphins, formerly a more common sight in Plymouth waters used to 'herd ' mackerell through the narrow deep entrance into Hooe lake.
As the tide fell the luckless mackerell would panic and try to escape, an easy meal for the dolphins waiting at the mouth of the lake.


text:
<?xml version="1.0" ?>
<srcfile name="SampleXYDatasetThread.java" file_path="/Users/valerio/Research/Code/Source Code Comments Classification/comments_classification/media/jfreechart/0.6.0/jfreechart-060zip/extracted/jfreechart-0.6.0/source/com/jrefinery/chart/demo/SampleXYDatasetThread.java" >
 <node name="COMPILATION_UNIT" line="0" instruction_class="COMPILATION_UNIT" instruction="COMPILATION_UNIT">
   <node name="PACKAGE_DECLARATION" line="0" instruction_class="KEYWORD" instruction="PACKAGE_KEYWORD">
     <node name="SELECT" line="0" instruction_class="SELECT" instruction="SELECT">
       <node name="SELECT" line="0" instruction_class="SELECT" instruction="SELECT">
         <node name="SELECT" line="0" instruction_class="SELECT" instruction="SELECT">
           <node name="com" line="35" instruction_class="IDENTIFIER" instruction="IDENTIFIER">
           </node>
           <node name="jrefinery" line="35" instruction_class="IDENTIFIER" instruction="IDENTIFIER">
           </node>
         </node>
         <node name="chart" line="35" instruction_class="IDENTIFIER" instruction="IDENTIFIER">
         </node>
       </node>
       <node name="demo" line="35" instruction_class="IDENTIFIER" instruction="IDENTIFIER">
       </node>
     </node>
   </node>
   <class_statement_node name="CLASS_DECLARATION" line="0" instruction_class="CLASS_DECLARATION" instruction="CLASS_KEYWORD">
     <node name="MODIFIERS" line="0" instruction_class="MODIFIERS" instruction="MODIFIERS">
       <node name="public" line="51" instruction_class="MODIFIER" instruction="ACCESS_LEVEL_MODIFIER">
       </node>
     </node>
     <node name="SampleXYDatasetThread" line="51" instruction_class="IDENTIFIER" instruction="IDENTIFIER">
     </node>
     <node name="implements" line="51" instruction_class="KEYWORD" instruction="INTERFACE_IMPLEMENTATION_KEYWORD">
       <node name="Runnable" line="51" instruction_class="TYPE" instruction="CLASS_OR_INTERFACE_TYPE">
       </node>
     </node>
     <node name="CLASS_BODY" line="0" instruction_class="CLASS_BODY" instruction="CLASS_BODY">
       <statement_node name="FIELD_DECLARATION" line="0" instruction_class="FIELD_DECLARATION" instruction="FIELD_DECLARATION">
         <node name="MODIFIERS" line="0" instruction_class="MODIFIERS" instruction="MODIFIERS">
           <node name="private" line="53" instruction_class="MODIFIER" instruction="ACCESS_LEVEL_MODIFIER">
           </node>
         </node>
         <node name="SampleXYDataset" line="53" instruction_class="TYPE" instruction="CLASS_OR_INTERFACE_TYPE">
         </node>
         <node name="VARIABLE_DECLARATOR" line="0" instruction_class="VARIABLE_DECLARATOR" instruction="VARIABLE_DECLARATOR">
           <node name="data" line="53" instruction_class="IDENTIFIER" instruction="IDENTIFIER">
           </node>
         </node>
       </statement_node>
       <method_statement_node name="CONSTRUCTOR_DECLARATION" line="0" instruction_class="METHOD_DECLARATION" instruction="CONSTRUCTOR_METHOD_DECLARATION">
         <node name="MODIFIERS" line="0" instruction_class="MODIFIERS" instruction="MODIFIERS">
           <node name="public" line="55" instruction_class="MODIFIER" instruction="ACCESS_LEVEL_MODIFIER">
           </node>
         </node>
         <node name="SampleXYDatasetThread" line="55" instruction_class="IDENTIFIER" instruction="IDENTIFIER">
         </node>
         <node name="FORMAL_PARAMETERS" line="0" instruction_class="FORMAL_PARAMETERS" instruction="FORMAL_PARAMETERS">
           <node name="FORMAL_PARAMETER" line="0" instruction_class="FORMAL_PARAMETER" instruction="FORMAL_PARAMETER">
             <node name="MODIFIERS" line="0" instruction_class="MODIFIERS" instruction="MODIFIERS">
             </node>
             <node name="SampleXYDataset" line="55" instruction_class="TYPE" instruction="CLASS_OR_INTERFACE_TYPE">
             </node>
             <node name="data" line="55" instruction_class="IDENTIFIER" instruction="IDENTIFIER">
             </node>
           </node>
         </node>
         <statement_node name="CONSTRUCTOR_BODY" line="0" instruction_class="CONSTRUCTOR_BODY" instruction="CONSTRUCTOR_BODY">
           <statement_node name="EXPRESSION_STATEMENT" line="0" instruction_class="EXPRESSION_STATEMENT" instruction="EXPRESSION_STATEMENT">
             <node name="=" line="56" instruction_class="OPERATOR" instruction="ASSIGNEMENT_OPERATOR">
               <node name="SELECT" line="0" instruction_class="SELECT" instruction="SELECT">
                 <node name="THIS" line="0" instruction_class="THIS" instruction="THIS">
                 </node>
                 <node name="data" line="56" instruction_class="IDENTIFIER" instruction="IDENTIFIER">
                 </node>
               </node>
               <node name="data" line="56" instruction_class="IDENTIFIER" instruction="IDENTIFIER">
               </node>
             </node>
           </statement_node>
         </statement_node>
       </method_statement_node>
       <method_statement_node name="METHOD_DECLARATION" line="0" instruction_class="METHOD_DECLARATION" instruction="METHOD_DECLARATION">
         <node name="MODIFIERS" line="0" instruction_class="MODIFIERS" instruction="MODIFIERS">
           <node name="public" line="59" instruction_class="MODIFIER" instruction="ACCESS_LEVEL_MODIFIER">
           </node>
         </node>
         <node name="VOID" line="0" instruction_class="VOID" instruction="VOID">
         </node>
         <node name="run" line="59" instruction_class="IDENTIFIER" instruction="IDENTIFIER">
         </node>
         <node name="FORMAL_PARAMETERS" line="0" instruction_class="FORMAL_PARAMETERS" instruction="FORMAL_PARAMETERS">
         </node>
         <statement_node name="METHOD_BODY" line="0" instruction_class="METHOD_BODY" instruction="METHOD_BODY">
           <statement_node name="while" line="60" instruction_class="LOOP_STATEMENT" instruction="WHILE_STATEMENT">
             <node name="true" line="60" instruction_class="LITERAL" instruction="BOOLEAN_LITERAL">
             </node>
             <statement_node name="BLOCK" line="0" instruction_class="BLOCK" instruction="BLOCK">
               <statement_node name="try" line="61" instruction_class="CONTROLFLOW_STATEMENT" instruction="EXCEPTION_TRY">
                 <statement_node name="BLOCK" line="0" instruction_class="BLOCK" instruction="BLOCK">
                   <statement_node name="EXPRESSION_STATEMENT" line="0" instruction_class="EXPRESSION_STATEMENT" instruction="EXPRESSION_STATEMENT">
                     <node name="CALL" line="0" instruction_class="CALL" instruction="CALL">
                       <node name="SELECT" line="0" instruction_class="SELECT" instruction="SELECT">
                         <node name="Thread" line="62" instruction_class="IDENTIFIER" instruction="IDENTIFIER">
                         </node>
                         <node name="sleep" line="62" instruction_class="IDENTIFIER" instruction="IDENTIFIER">
                         </node>
                       </node>
                       <node name="ARGUMENTS" line="0" instruction_class="ARGUMENTS" instruction="ARGUMENTS">
                         <node name="EXPRESSION_LIST" line="0" instruction_class="EXPRESSION_LIST" instruction="EXPRESSION_LIST">
                           <node name="500" line="62" instruction_class="LITERAL" instruction="INTEGER_LITERAL">
                           </node>
                         </node>
                       </node>
                     </node>
                   </statement_node>
                   <statement_node name="EXPRESSION_STATEMENT" line="0" instruction_class="EXPRESSION_STATEMENT" instruction="EXPRESSION_STATEMENT">
                     <node name="CALL" line="0" instruction_class="CALL" instruction="CALL">
                       <node name="SELECT" line="0" instruction_class="SELECT" instruction="SELECT">
                         <node name="data" line="63" instruction_class="IDENTIFIER" instruction="IDENTIFIER">
                         </node>
                         <node name="setTranslate" line="63" instruction_class="IDENTIFIER" instruction="IDENTIFIER">
                         </node>
                       </node>
                       <node name="ARGUMENTS" line="0" instruction_class="ARGUMENTS" instruction="ARGUMENTS">
                         <node name="EXPRESSION_LIST" line="0" instruction_class="EXPRESSION_LIST" instruction="EXPRESSION_LIST">
                           <node name="+" line="63" instruction_class="OPERATOR" instruction="ADDITIVE_OPERATOR">
                             <node name="CALL" line="0" instruction_class="CALL" instruction="CALL">
                               <node name="SELECT" line="0" instruction_class="SELECT" instruction="SELECT">
                                 <node name="data" line="63" instruction_class="IDENTIFIER" instruction="IDENTIFIER">
                                 </node>
                                 <node name="getTranslate" line="63" instruction_class="IDENTIFIER" instruction="IDENTIFIER">
                                 </node>
                               </node>
                               <node name="ARGUMENTS" line="0" instruction_class="ARGUMENTS" instruction="ARGUMENTS">
                               </node>
                             </node>
                             <node name="0.25" line="63" instruction_class="LITERAL" instruction="FLOATING_POINT_LITERAL">
                             </node>
                           </node>
                         </node>
                       </node>
                     </node>
                   </statement_node>
                 </statement_node>
                 <node name="catch" line="65" instruction_class="CONTROLFLOW_STATEMENT" instruction="EXCEPTION_CATCH">
                   <node name="FORMAL_PARAMETER" line="0" instruction_class="FORMAL_PARAMETER" instruction="FORMAL_PARAMETER">
                     <node name="MODIFIERS" line="0" instruction_class="MODIFIERS" instruction="MODIFIERS">
                     </node>
                     <node name="Exception" line="65" instruction_class="TYPE" instruction="CLASS_OR_INTERFACE_TYPE">
                     </node>
                     <node name="e" line="65" instruction_class="IDENTIFIER" instruction="IDENTIFIER">
                     </node>
                   </node>
                   <statement_node name="BLOCK" line="0" instruction_class="BLOCK" instruction="BLOCK">
                   </statement_node>
                 </node>
               </statement_node>
             </statement_node>
           </statement_node>
         </statement_node>
       </method_statement_node>
     </node>
   </class_statement_node>
 </node>
</srcfile>