195 research outputs found
A Proof-Producing Compiler for Blockchain Applications
No full textCairo is a programming language for running decentralized applications (dapps) at scale. Programs written in the Cairo language are compiled to machine code for the Cairo CPU architecture, and cryptographic protocols are used to verify the results of the execution traces efficiently on blockchain. We explain how we have extended the Cairo compiler with tooling that enables users to prove, in the Lean 3 proof assistant, that compiled code satisfies high-level functional specifications. We demonstrate the success of our approach by verifying primitives for computations with an elliptic curve over a large finite field, as well as their use in the validation of cryptographic signatures
Efficient Testing without Efficient Regularity
No full textThe regularity lemma of Szemeredi turned out to be the most powerful tool for studying the testability of graph properties in the dense graph model. In fact, as we argue in this paper, this lemma can be used in order to prove (essentially) all the previous results in this area. More precisely, a barrier for obtaining an efficient testing algorithm for a graph property P was having an efficient regularity lemma for graphs satisfying P. The problem is that for many natural graph properties (e.g. triangle freeness) it is known that a graph can satisfy P and still only have regular partitions of tower-type size. This means that there was no viable path for obtaining reasonable bounds on the query complexity of testing such properties.
In this paper we consider the property of being induced C_4-free, which also suffers from the fact that a graph might satisfy this property but still have only regular partitions of tower-type size.
By developing a new approach for this problem we manage to overcome this barrier and thus obtain a merely exponential bound for testing this property. This is the first substantial progress on a problem raised by Alon in 2001, and more recently by Alon, Conlon and Fox.
We thus obtain the first example of an efficient testing algorithm that cannot be derived from an efficient version of the regularity lemma
Twico Control Engine
No full text
Twico Control Engine
Twico Control Engine
Twico Control is a Flask-based orchestration engine for digital materialisation /
digital twin workflows.
It coordinates virtual actors (software representations) and their paired
physical actors (robots, tools, sensors), executes tasks in a controlled order,
forward information to external services, and optionally synchronises state of the local DB with a
cloud database via REST API.
A web UI is included for managing actors, tasks, jobs, and monitoring execution.
Status: research / prototyping-friendly codebase. Contributions and issues are welcome.
What problem it solves
In a typical digital materialisation process you have:
Tasks to execute (move, read data, fabricate, etc.)
Physical actors that do the work (robots, PLCs, devices)
Virtual actors that encapsulate communication + pre/post-processing
Services that generate tasks or react to task completion
Twico Control acts as the execution core: it keeps a local “authoritative” state,
dispatches tasks to actors, listens for events, and updates external systems.
Key concepts
Actor (Virtual Actor): a Python class that implements a standard interface
(actors/ActorBase.py) and handles: connection, task preparation (preSend), task dispatch,
completion monitoring, and response handling (postSend).
Task: an executable unit that is assigned to a main_actor with extra per-actor
parameters under actors_data.
Engine: a Flask server that runs the UI + API endpoints and coordinates task execution.
RabbitMQ: optional event bus for “task received” / “task complete” style workflows.
Execution model (high level)
The engine runs continuously and coordinates execution across actors:
Ensure all required virtual actors are registered and connected.
For each available actor:
fetch the next task from the local DB (or tasks queue)
call preSend(task) then send the task to the paired physical actor
wait for completion / acknowledgements (depending on your communication pattern)
call postSend(response) and log results
trigger any linked services
In parallel, background listeners can:
ingest new tasks (e.g. via RabbitMQ)
propagate task completion updates to a cloud DB (if REST API is configurated)
Project structure
TWICO_Release/
├── actors/
│ ├── __init__.py
│ ├── ActorBase.py
│ ├── RMQ_setup.py
│ ├── DemoActor/
│ │ ├──__init__.py
│ │ └── DemoActor.py
│ ├── ServiceConnectedActor/
│ │ ├──__init__.py
│ │ └── ServiceConnectedActor.py
│ └── TaskInjectingActor/
│ │ ├──__init__.py
│ └── TaskInjectingActor.py
├── apps/
│ ├── actors/
│ │ ├──__init__.py
│ │ ├── forms.py
│ │ ├── model.py
│ │ ├── routes.py
│ │ └── services.py
│ ├── authentication/
│ │ ├──__init__.py
│ │ ├── forms.py
│ │ ├── model.py
│ │ ├── routes.py
│ │ └── services.py
│ ├── home/
│ │ ├──__init__.py
│ │ ├── forms.py
│ │ ├── routes.py
│ │ └── services.py
│ ├── Logger/
│ │ ├──__init__.py
│ │ ├── logs/
│ │ ├── Logger.py
│ ├── RabbitMQ/
│ │ ├──__init__.py
│ │ └── listener.py
│ ├── run/
│ │ ├──__init__.py
│ │ ├── routes.py
│ │ └── services.py
│ ├── static/
│ │ └── assets/
│ ├── tasks/
│ │ ├──__init__.py
│ │ ├── forms.py
│ │ ├── model.py
│ │ ├── routes.py
│ │ └── services.py
│ ├── templates/
│ │ ├── actors/
│ │ ├── auth/
│ │ ├── dashboard/
│ │ ├── includes/
│ │ ├── layouts/
│ │ ├── run/
│ │ └── tasks/
│ ├── .env.example
│ ├── __init__.py
│ └── config.py
├── Examples/
│ ├── Basic/
│ │ ├── basic_tasks.py
│ ├── Parallel_actors/
│ │ ├── parallel_actors_tasks.py
│ ├── Self_injecting_actor/
│ │ ├── self_injecting_actor_tasks.py
│ ├── Task_injecting_service/
│ │ ├── task_injecting_service.py
│ │ ├── task_injecting_service_tasks.py
│ └── tasks_builder.py
├── .gitignore
├── CHANGELOG.md
├── CONTRIBUTING.md
├── docker-compose.yml
├── LICENSE
├── README.md
├── requirements.txt
└── run.py
Notable folders
actors/ — Virtual actor implementations (your integration layer)
ActorBase.py defines the interface for all actors
DemoActor/ provides an example actor
apps/ — Flask application code (blueprints, models, services)
apps/authentication/ login + license gating
apps/tasks/ task models, services, and UI routes
apps/actors/ actor registration/management in the UI
apps/RabbitMQ/ RabbitMQ listener
apps/Logger/ logging utilities
apps/templates/ HTML templates for the UI
apps/static/backups folder that save current state of tasks in the DB after execution or when
clearing tasks from DB.
Examples/ — example scripts and task JSON
Requirements
Python 3.10+
A virtualenv or conda environment (recommended)
Optional but recommended:
RabbitMQ server (local, Docker, or remote)
A REST API backend for cloud synchronisation (if you use that workflow)
Quick start (local)
1) Create and activate an environment
Using conda:
conda create -n Twico python=3.10
conda activate Twico
Or with venv:
python -m venv .venv
# Windows
.venv\Scripts\activate
2) Install dependencies
pip install -r requirements.txt
3) Configure environment variables
Create a .env in the project root (do not commit it) based on
.env.example.
AUTHOR_NAME=Your Name
APP_VERSION=0.1.0
SERVER_NAME=127.0.0.1:5000
SECRET_KEY=change-me
API_URL=
ASSETS_ROOT=/static/assets
DB_ENGINE=sqlite
DB_NAME=db.sqlite3
RABBIT_MQ_HOST=localhost
RABBIT_MQ_PORT=5672
RABBIT_MQ_USER=guest
RABBIT_MQ_PASS=guest
RABBIT_MQ_VH=/
4) Run
python run.py
Open the UI at:
http://127.0.0.1:5000
Working with tasks
Tasks can be loaded from:
the cloud REST API (if configured)
a local JSON file (see Examples folder)
A task have the following structure:
{
"name": "A_temp_0",
"type": "Move",
"main_actor": "DemoActor_A",
"description": "",
"message": "Moving DemoActor to position",
"job": 1,
"level": 1,
"index": 0,
"element_id": [],
"actors_data": {
"DemoActor_A": {
"X": 1,
"Y": 2,
"Z": 3,
"Speed": 0.2
}
}
}
where the actors_data feild can contain any key-value pair.
Adding a new actor
Create a new folder under actors/ (e.g. actors/MyRobotActor/)
Implement the interface in ActorBase (connect, send, monitor, etc.)
Make sure the file name and the class name are the same as the folder name.
Ensure the actor is importable (package with __init__.py)
Register/configure it via the UI (apps/actors/) or your project-specific bootstrap code
RabbitMQ (optional)
If you use RabbitMQ, you can run a local instance with Docker:
docker compose up -d rabbitmq
See docker-compose.yml in this repo for a ready-to-use configuration.
Documentation
This repository is compatible with Sphinx autodoc (docstrings → HTML docs).
If you add a docs/ folder, you can build API docs automatically.
Docs for the folder can be found in apps/static/docs or under the docs in the UI navigation sidebar.
Author / Maintainers
Lior Skoury (original author)
</html
Replication Data for: Do Personality Traits Predict Voter Attitudes When Politics Is Structured Around Conflict? Lessons From Israel
No full textThe relationship between personality traits and political attitudes has been studied extensively. However, existing accounts largely study personality’s links to liberal-conservative divisions on social and economic issues. We know far less about its attitudinal influences when politics is organized around other issue domains, particularly ethnonational conflicts. Addressing this gap, we examine the relationship between the Big Five personality traits, policy preferences, and political orientation in Israel, where the main ideological cleavage involves the Israeli-Palestinian conflict. Using original survey data, we find that the known relationships with social and economic attitudes operate only partly and more weakly in this context. Unlike these domains, conflict-related preferences in Israel correlate primarily with greater conscientiousness, largely through authoritarian tendencies. General Left-Right orientations mimic this relationship, reflecting conflict-related views rather than social or economic inclinations. These findings expand the scope of current debates about personality and political attitudes and underscore the importance of national ideological contexts for future research
Testing Linear Inequalities of Subgraph Statistics
No full textProperty testers are fast randomized algorithms whose task is to distinguish between inputs satisfying some predetermined property ? and those that are far from satisfying it. Since these algorithms operate by inspecting a small randomly selected portion of the input, the most natural property one would like to be able to test is whether the input does not contain certain forbidden small substructures. In the setting of graphs, such a result was obtained by Alon et al., who proved that for any finite family of graphs ℱ, the property of being induced ℱ-free (i.e. not containing an induced copy of any F ∈ ℱ) is testable.
It is natural to ask if one can go one step further and prove that more elaborate properties involving induced subgraphs are also testable. One such generalization of the result of Alon et al. was formulated by Goldreich and Shinkar who conjectured that for any finite family of graphs ℱ, and any linear inequality involving the densities of the graphs F ∈ ℱ in the input graph, the property of satisfying this inequality can be tested in a certain restricted model of graph property testing. Our main result in this paper disproves this conjecture in the following strong form: some properties of this type are not testable even in the classical (i.e. unrestricted) model of graph property testing.
The proof deviates significantly from prior non-testability results in this area. The main idea is to use a linear inequality relating induced subgraph densities in order to encode the property of being a pseudo-random graph
Apocalypse - 2004
No full textContributers include: Valerie Joy Rix, Joe Eldridge, Rena Marzen, Montana Piper, B.Z. Niditch, Vic Cavalli, Benigno Boyas, Michelle Thurman, Alyssa Joy Coiley, Joan Payne Kincaid, Mike Fullerton, Daniuel Green, Eric Cruz, Cecilia Carboni, Tashi Khorlatsang, Joshua Halperns-Givens, Berta Landa WIlson, Tony Crooks, Nathania Quatch, Effie Mihopoulous, Diana Smith, Lior Alon
Issue also contains an audio CD companion.https://neiudc.neiu.edu/apocalypse/1007/thumbnail.jp
Digital-Twin Data for Large-Scale 3D Printing
No full text
MTRL_DATASET - Material Analysis Tools
body {
font-family: Arial, sans-serif;
line-height: 1.6;
padding: 20px;
}
pre {
background-color: #f4f4f4;
padding: 10px;
overflow-x: auto;
}
code {
font-family: Consolas, monospace;
}
table {
border-collapse: collapse;
width: 100%;
margin-bottom: 20px;
}
table, th, td {
border: 1px solid #ccc;
}
th, td {
padding: 8px;
text-align: left;
}
h1, h2, h3, h4 {
margin-top: 1.2em;
}
Overview
This project contains a dataset from research on a data-informed digital twin for large-scale 3D printing. The data was collected through a series of experiments using two machines: (i) a Kuka KR50R2500 industrial robot and (ii) a MAI® MULTIMIX-3D mortar mixing pump. Additionally, measurements of the printed object's width were recorded during the experiments.
The dataset has been used to explore correlations between machine performance, material behavior, and the final printed structure. The accompanying codebase enables replication of the study’s results, offering tools for data processing, clustering, visualization, and the analysis of various material properties and printing parameters.
The experiments in this study were conducted in two phases:
Correlation Analysis: The first phase focused on exploring the relationships between machine performance, material behavior, and the resulting printed object. Data from these experiments was then used to develop a clustering-based prediction model and a set of feedback control services to automate the operation of the Kuka robot and the mortar mixing pump.
Evaluation of Feedback Control: In the second phase, the feedback control services were implemented in a new set of experiments to assess their effectiveness in optimizing the 3D printing process.
Project Structure
MTRL_DATASET/
│
├── Data/
│ ├── Block_Tests/
│ │ ├── BlockTasks.json - Tasks data for block (evaluation ) tests
│ │ └── BlockMeasurements.json - Width measurements for different block types
│ │
│ └── Mixture_Experiments/
│ ├── PumpResponse_Clean.json - Clean pump response data for mixture experiments (used for clustering)
│ ├── PumpTasks.json - Task data for pump operations
│ └── WidthCorrelationTests.json - Data for width correlation tests
│
├── Clusters/ - Directory for saved ML models
│ ├── kmeans.pkl - Trained KMeans model
│ └── scaler.pkl - Fitted StandardScaler
|
├── Figs/ -Directory of all plots from the code
|
├── Blocks.py - Block data analysis and visualization
├── BlockMeasurements.py - Analysis of block measurement data
├── Clusters.py - Machine learning clustering of pump data
├── PumpData.py - Pump data analysis utilities
├── WidthCorrelations.py - Analysis of correlations between printed object width, Kuka robot velocity and pump reqeuncy
└── README.md - This file
Data Description
01_Mixture Experiments Data
The experiments in this section were done with 4 types of mixtures as follows:
Mix
Clay (kg)
Sand (kg)
Water (kg)
Flow Table (mm)
Density (g/L)
M1
5.00
7.50
3.00
169
2080
M2
5.00
7.50
2.75
163
2100
M3
5.00
7.50
2.50
147
2140
M4
5.00
7.50
2.25
127
2196
PumpResponse_Clean.json
Contains cleaned pump response data including:
Pump output power and current measurements
Mortar temperature readings
Pump pressure readings
Temporal data for pump operations
PumpTasks.json
Contains task information related to pump operations:
Task details for mixture experiments
Timing information for pump actions
Operational parameters and settings
WidthCorrelationTests.json
Contains test data for analyzing correlations between:
Width measurements
Pump frequency
Robot velocity
02_Block Tests Data
The experiments in this section were conducted on 3 block types with the following features:
Block
Velocity (m/s)
Frequency (Hz)
B1
0.11
17
B2
Adaptive
17
B3
0.11
Adaptive
BlockMeasurements.json
Contains width measurements (in mm) for three different blocks. This data is used for comparing width consistency across different block printing strategies.
BlockTasks.json
Contains detailed task data from the pump and the robot for block printing processes, including:
Task IDs and names
Task types (ReadData, Read, SetValue)
Actors (KukaPassiveRead, MaiPrinter)
Timestamps for start and end times
Job identification (e.g., "BLOCK1")
Processing levels and indices
The file contains over 2300 task entries.
03_Features
Within both the BlockTasks.json and PumpTask.json files, every data point adheres to a standardized Task Data Schema that includes the following fields:
_id: A unique identifier for this record.
task_id: A unique identifier for the specific task or operation.
name: The name assigned to the task or process.
type: The category or type of operation (e.g., a data reading action).
main_actor: The primary machine or module responsible for carrying out the task.
description: A brief textual description of the task.
message: A log message or status note associated with the operation.
element_id: A list of identifiers for related design elements (if any).
actors_data: Contains information for the actors involved in the task (nested details are omitted).
job: The job or process identifier associated with this record.
level: The hierarchical level or depth in a process, indicating its relative position.
index: A numerical order or position indicator for the task.
start_time: The timestamp marking the start of the task or operation.
end_time: The timestamp marking when the task was completed.
response: Contains the outcome or data returned by the task (nested details are omitted).
versions: Version control or metadata information regarding this record.
project: The identifier for the project to which this record belongs.
author: The user or entity that created or is responsible for this record.
04_Scripts
PumpData.py
Analyzing and visualising pump tasks data for the 4 mixtures.
WidthCorrelations.py
Analyzes and visualises correlations between width measurements, robot velocity, and pump frequency.
Clusters.py
Implements machine learning clustering on pump data and visualises the results.
Blocks.py
Analyzes task data for different block types, calculates timing metrics, and visualises the results.
BlockMeasurements.py
Analyzes and visualises block width measurement data.
05_Usage
Dependencies
This project requires the following Python packages:
pandas
numpy
matplotlib
scikit-learn
joblib
Install dependencies with:
pip install pandas numpy matplotlib scikit-learn joblib
Run the code
To generate the full analysis and plots from the dataset, simply execute the main.py file. Open your terminal, navigate to the code directory, and run:
cd path/to/your/code/directory
python main.py
For a more detailed overview of available parameters, run each of the individual Python files separately.
</html
A Generalized Turán Problem and its Applications
No full textAbstractThe investigation of conditions guaranteeing the appearance of cycles of certain lengths is one of the most well-studied topics in graph theory. In this paper we consider a problem of this type that asks, for fixed integers ℓ and k, how many copies of the k-cycle guarantee the appearance of an ℓ-cycle? Extending previous results of Bollobás–Gy̋ri–Li and Alon–Shikhelman, we fully resolve this problem by giving tight (or nearly tight) bounds for all values of ℓ and k. We also present a somewhat surprising application of the above mentioned estimates to the study of the graph removal lemma. Prior to this work, all bounds for removal lemmas were either polynomial or there was a tower-type gap between the best-known upper and lower bounds. We fill this gap by showing that for every super-polynomial function , there is a family of graphs , such that the bounds for the removal lemma are precisely given by . We thus obtain the 1st examples of removal lemmas with tight super-polynomial bounds. A special case of this result resolves a problem of Alon and the 2nd author, while another special case partially resolves a problem of Goldreich.</jats:p
Neumann domains on manifolds and graphs
No full textThe nodal set of a Laplacian eigenfunction forms a partition of the underlying manifold or graph.
Another natural partition is based on the gradient vector field of the eigenfunction (on a manifold) or on the extremal points of the eigenfunction (on a graph).
The submanifolds (or subgraphs) of this partition are called Neumann domains.
We present the main results concerning Neumann domains on manifolds and on graphs.
We compare manifolds to graphs and relate the Neumann domain results on each of them to the nodal domain study.
The talk is based on joint works with Lior Alon, Michael Bersudsky, Sebastian Egger, David Fajman and Alexander Taylor.Non UBCUnreviewedAuthor affiliation: TechnionResearche
- …
