Apache MXNet wrapper written in C# for Windows, MacOS and Linux
MXNetDotNet is thin wrapper and similar with original MXNet. So you need not to suffer from complex C/C++ syntax!!
A bloom filter implementation that is serialisable to JSON and compatible between both Ruby and Javascript. Very useful when needing to train a bloom filter in one language and using it in the other.
Why?
Bloom filters allow for space efficient lookups in a list, without having to store all the items in the list. This is useful for looking up tags, domain names, links, or anything else that you might want to do client side.
What this Gem allows you to do is build a bloom filter server side, add all your entries to it, and then serialise the filter to JSON. On the client side you can then load up the serialised data into the Javascript version and use the bloom filter as is.
All of this while not sending the entire list to the client, which is something you might not want to do for either security or efficiency reasons.
Installation
Ruby
gem install json-bloomfilter
Javascript
With the gem installed run
json-bloomfilter install
and the json-bloomfilter.min.js will be copied to your local directory. If you are in a Rails project it will be copied to your app/assets/javascripts folder.
Usage
Ruby
require"json-bloomfilter"# use the factory to configure the filterfilter=JsonBloomFilter.build10000,0.01# number of expected items, desired error rate# or create a define the BloomFilter manuallyfilter=JsonBloomFilter.newsize: 100# and add entriesfilter.add"foo"filter.add"bar"# alternativelyfilter.add["foo","bar"]# test the entriesfilter.test"foo"#=> truefilter.test"bar"#=> truefilter.test"doh"#=> probably false# export the filter to a hash or jsonfilter.to_json#=> hash as JSONconfig=filter.to_hash#=> { "size" => 100, "hashes" => 4, "seed" => 1234567890, "bits" => [...] }# use the hash to generate a new filter with the same configfilter2=JsonBloomFilter.newconfigfilter2.test"foo"#=> truefilter2.test"bar"#=> truefilter2.test"doh"#=> probably false
Javascript
// use the factory to configure the filterfilter=JsonBloomFilter.build(10000,0.01);// number of expected items, desired error rate// or create a define the filter manuallyfilter=newJsonBloomFilter({size: 100});// and add entriesfilter.add("foo");filter.add("bar");// alternativelyfilter.add(["foo","bar"]);// test the entriesfilter.test("foo");//=> truefilter.test("bar");//=> truefilter.test("doh");//=> probably false// export the filter to a hash or jsonfilter.toJson();//=> hash as JSONconfig=filter.toHash();//=> { "size" => 100, "hashes" => 4, "seed" => 1234567890, "bits" => [...] }// use the hash to generate a new BloomFilter with the same configfilter2=newJsonBloomFilter(config);filter2.test("foo");//=> truefilter2.test("bar");//=> truefilter2.test("doh")//=> probably false
Options
Valid options for constructor are:
size (default: 100), the bit size of the bit array used
hashes (default: 4), the number of hashes used to calculate the bit positions in the bit field
seed (default: current UNIX time), the seed for the hashing method
Additionally you can pass along:
bits (default: null), an array with the bitfield in non-bit format. Use #to_hash to create these for your active BloomFilter.
An action that builds docker image and pushes to Google Cloud Registry and Google Artifact Registry.
This action can be used to perform on every git push or every tag creation.
Inputs
gcloud_service_key
The service account key of google cloud. The JSON file can be encoded in base64 or in plain text.
Prior to version 4.1 – This field is required.
From version 5 – This field is optional when you are using workload identity with google-github-actions/auth
registry
The registry where the image should be pushed. Default gcr.io.
project_id
The project id. This field is required.
image_name
The image name. This field is required.
image_tag
The tag for the image. To create multiple tags of the same image, provide a comma (,) separated tag name (e.g. v2.1,v2,latest).
Default: latest.
To use the pushed Tag Name as image tag, see the example.
dockerfile
The image building Dockerfile.
If the context is not the root of the repository, Dockerfile from the context folder will be used.
Default: ./Dockerfile.
context
The docker build context. Default: .
target
If you use a multi-stage build and want to stop building at a certain image, you can use this field. The default value is empty.
build_args
Pass a list of env vars as build-args for docker-build, separated by commas. ie: HOST=db.default.svc.cluster.local:5432,USERNAME=db_user
push_only
If you want to skip the build step and just push the image built by any previous step, use this option. The default for this is false.
Permissions
The service key you provided must have the Storage Admin permission to push the image to GCR.
It is possible to use a lower access level Storage Object Admin, but it will work only if the registry is already created. You must also add the Storage Legacy Bucket Reader permission to the artifacts.<project id>.appspot.com bucket for the given service account.
NB: The included workflow which tests the action’s basic functionalities needs a GitHub secret named JSON_GCLOUD_SERVICE_ACCOUNT_JSON.
Currently, the workflow is not testable for forked repositories but I have an action item to enable this.
Switzerland has been a federal republic since 1848, hence its own cantons may differ significantly in regulations, permissions, prohibitions and… taxes!
This app can offer you a preview of what could be the most convenient places where to settle down in the Helvetic territory, based on a tax comparison between cantons and municipalities.
Getting started
Download the official GitHub repository through HTTPS with the command line
If having any troubles or not having Git installed, just download and decompress the zip folder.
Before launching the program, Python 3 and packages streamlit, polars, altair, geopandas and xlsx2csv must be installed (working versions for Python and for each dependency are pinned in the pyproject.toml).
To launch the program, execute the following command from the project folder:
streamlit run app.py
If using uv software as environment manager run preferably
uv run streamlit run app.py
that will instantiate and activate a virtual environment containing all correct dependencies, including Python 3.13.[1]
About Swiss cantons
Switzerland is a Federal Republic divided into 26 cantons. For convenience the names of the cantons are mostly abbreviated with their official codes throughout the app and hereafter in the README.[2]
Code
Name
Capital
ZH
Zurich
Zurich
BE
Bern
Bern
LU
Lucerne
Lucerne
UR
Uri
Altdorf
SZ
Schwyz
Schwyz
OW
Obwalden
Sarnen
NW
Nidwalden
Stans
GL
Glarus
Glarus
ZG
Zug
Zug
FR
Freiburg
Freiburg
SO
Solothurn
Solothurn
BS
Basel-Stadt
Basel
BL
Basel-Landschaft
Liestal
SH
Schaffhausen
Schaffhausen
AR
Appenzell Ausserrhoden
Herisau
AI
Appenzell Innerrhoden
Appenzell
SG
St. Gallen
St. Gallen
GR
Graubünden
Chur
AG
Aargau
Aarau
TG
Thurgau
Frauenfeld
TI
Ticino
Bellinzona
VD
Vaud
Lausanne
VS
Valais
Sion
NE
Neuchâtel
Neuchâtel
GE
Geneva
Geneva
JU
Jura
Delémont
Insights of data collection and tax calculation
Data were collected from this online tool for tax calculation supplied by the Federal Tax Administration through its internal APIs, in the form of Excel tables.
The data show 4 different main patterns, briefly described below.
$\Delta_s\times c_s% + \text{Tax Base}$ where $\Delta_s=\text{Value}-\text{Floor Rank(Value)}$ and $c_s%$ is a rank-relative coefficient. Income tax for BS, FR, GE, GL, GR, LU, NE, SH, SO, TG, TI, VD, VS, ZG, assets tax for AR, BE, BL, BS, FR, GE, JU, NE, SO, TI, VD, VS, ZG and the Federal Tax follow this formula. Eg. in canton Geneva (GE) a CHF 100,000 income implies a $(100,000-76,812)\times 15.5% +7,828=\text{CHF } 11,422.14$ base for further numeric processing. Tax base may be fixed by the canton or calculated iteratively starting form zero.
$\sum_{i=1}^{s}\Delta_i\cdot c_i%$ that means that a CHF 100,000 income in Zurich will be divided as follows: $(6,900\times 0%) + (4,900\times 2%) + \dots + (17,400\times 8%) + (\text{remaining }24,600\times 9%)=\text{CHF }6,207$ (then further processed). Income tax for AG, AI, AR, BE, BL, JU, NW, SG, SZ, ZH and assets tax for AG, GR, SH and ZH follow this procedure.
Flat tax, a unique rate factor for boundless wealth, such as income tax in OW and UR and assets tax in AI, GL, LU, NW, OW, SG, SZ, TG and UR.
BL (Basel-Landschaft) pursues its own way, namely a rank-based formula. Assuming to be in the $s$-th wealth rank, the formula looks like $a_s\cdot \mathrm{Value}+b_s\cdot\mathrm{Value}\cdot\left(\log(\mathrm{Value}) – 1\right)+c_s$.
Then these values are multiplied for a specific factor depending on the canton and the commune and finally summed together.
DISCLAIMER: This app offers only approximate calculations that ignore important features and articulations of official tax computations, that take into consideration also religion, age, familiar status and so on. Furthermore, even the online tool for tax calculation supplied by the Federal Tax Administration (source of all data) claims not to be binding.[3] [4]
Geographical data
Geographical datasets to draw the base map in the homepage section are released periodically by the Federal Statistical Office under OPEN-BY-ASK License.[5] Coordinates are expressed by default in the CH1903+ (LV95) coordinate reference system, by which positions are measured in meters North/South-ward and East/West-ward from the old observatory of Bern, plus two different constants (one for the North direction, one for the South). Geopandas GeoDataFrame offers a method to trace back to the more familiar EPSG:4326 coordinate reference system and then project the map with the most common projection types (Mercator by Altair default). Alternatively, this dataframe has a structure that allows to be projected as-is, with type of projection equal to “identity”. This approach mantains the Swiss predefined “Swiss-grid” projection, a cylindrical projection centered in Bern.[6] However, the former method was preferred, because it doesn’t affect significantly the comparison between internal surfaces, due to Switzerland’s relatively small extension and it is more understandable.
Enhancement proposals
More accurate tax calculations:
computation of personal tax,
computation of church tax,
using spil factor for couples,
computation of various deductions (presence of children, celibacy, young age etc.).
Interactive maps: due to Streamlit limitations an interaction with the mouse cursor has not been possible, but other libraries such as pydeck might be more compatible with Streamlit.
Selection by travel distance (multiple data sources can be found on the Internet under Open License).
Progressively populating SQLite database to collect increasingly more data without overwriting the previous.
Code optimization for faster response and visualization.
Translations to German, Italian, French or other languages.
This project simulates different process scheduling policies by running CPU-bound and I/O-bound tasks under various scheduling strategies. The objective is to analyze how different scheduling algorithms impact the turnaround time of processes.
Files Overview
Source Code Files
cpu_bound.c: Implements a CPU-intensive computation to simulate CPU-bound tasks.
io_bound.c: Simulates an I/O-heavy process by performing repeated I/O operations.
For each combination, the main program is executed, simulating 50 processes.
The turnaround time for each process is recorded and stored in simulation_results.txt.
Customization
You can modify the simulation parameters in simulation.sh:
Adjust the io_ratios array to test different I/O ratios.
Change the scheduling_policies array to include or exclude policies.
Example Output Format
The results file (simulation_results.txt) will contain entries like:
IO_RATIO=0.1, POLICY=SCHED_RR
PID Type Start Time End Time Turnaround Time
12345 IO 0.123456 0.567890 0.444434
...
Average Turnaround Time: 0.345678
-----------------------------------------
Notes
The main.c file creates 50 child processes, assigning them as CPU-bound or I/O-bound based on the specified ratio.
cpu_bound.c executes a loop-intensive task, while io_bound.c performs periodic file writes and sleeps.
The scheduling policy affects process execution order and turnaround time.
Cleaning Up
To remove compiled binaries and reset the project, run:
make clean
Conclusion
This simulation provides insights into how different scheduling strategies impact CPU-bound and I/O-bound processes. The recorded results help analyze the efficiency of scheduling algorithms under varying workloads.
We highly appreciate you sending us a postcard from your hometown, mentioning which of our package(s) you are using. You’ll find our address on our contact page. We publish all received postcards on our virtual postcard wall.
🔬 Research Contribution: Multi-Object Tracking for Precision Poultry Farming
Role: Research Assistant Institution: University of Georgia Project Title: Enhancing Multi-Object Tracking of Broiler Chickens using Deep Learning, Machine Learning, and Computer Vision
🧠 Overview
Contributed to the development of a robust, real-time, identity-preserving AI tracking system for broiler chickens in commercial poultry farms. The goal was to improve behavior analysis, tracking reliability, and animal welfare using modern deep learning and ML pipelines.
🚀 Technical Highlights
1. Object Detection & Optimization
Trained and benchmarked 10 YOLO variants
Best model:YOLOv11x
Precision: 0.968
Recall: 0.960
mAP@50: 0.986
mAP@50–95: 0.805
Applied L1 unstructured pruning for latency reduction
Inference Speed: Improved from 46.5 FPS → 60 FPS
Pruning Ratio: 0.09
2. Deep Feature Extraction & Re-Identification
Designed a hybrid deep feature extractor using:
Vision Transformer (ViT)
ResNet152
DenseNet201
Embedding Evaluation Metrics:
Cosine Similarity: 0.956 ± 0.032
Euclidean Distance: 0.020 ± 0.007
3. Kinematics-Aware Identity Classification
Developed classifiers using features like velocity, acceleration, and displacement. Benchmarked 15 ML models, including:
Logistic Regression, Random Forest, Extra Trees Classifier (Best)
Tracked over 5,700 broiler chickens under diverse real-world conditions including:
Lighting variability
Occlusions
Region-specific zones (feeder, drinker, open floor)
Enabled:
Long-term identity preservation
Automated behavior monitoring
Precision livestock farming integrations
This project bridged Computer Vision, ML, and Precision Agriculture, delivering a high-accuracy, scalable pipeline to advance smart farming and animal welfare monitoring systems.
The folder also contains the technical drawing for the cut copper rings forming the reaction wheel and the pdf “wheelbot v2.5 assembly view.pdf” that lets you interact with the complete Wheelbot’s assembly (requires Adobe Acrobate reader).
Contains the matlab files used to symbolically derive the EOM of the Wheelbot.
FlywUni_symbolic_derive.m: Derives the Euler-Lagrange equations of a unicycle reaction wheel robot using the parameters set in “config_FlyUni” and the “Langrange.m” defined in external libraries.
FlywUni_symbolic_linearize.m: Reshapes the symbolic ODE obtained from “FlywUni_symbolic_derive”, brings it into the form for the standard matlab ODE solvers and saves it as
Also linearizes the set of equations and saves the linearization as
save('EQS_matrices.mat', 'M', 'RHS')
FlywUni_symbolic_analyze.m: Loads the pre-computed dynamic equations, computes a trajectory using a standard ODE solver (RK45), and plots trajectory and total energy of the system.
Contains the simulink model used to tune the estimator and LQR controller. Recommended matlab version is R2020a.
The file “s00_config” contains the simulation settings including the exact estimates for the mass and inertia of the Wheelbot v2.5 which we obtained from CAD.
Before running “s01_unicycle.slx”, you need to run “s00_designLQR”.
Contains the firmware required to run Wheelbot v2.5
/firmware/M2-on-wheelbot
Contains the firmware that runs on a Maevarm M2 that is attached to the motherboard of the Wheelbot.
/firmware/M2-wifi-dongle
Contains the firmware that runs on a Maevarm M2 being connected to a PC and that handles the wifi communication with the Wheelbot.
/firmware/computer-python-interface
Python program running on Ubuntu 18.04 LTS collecting incoming data/outgoing commands from/to the wifi dongle.
BibTex
@ARTICLE{geist2022wheelbot,
author={Geist, A. Ren\'{e} and Fiene, Jonathan and Tashiro, Naomi and Jia, Zheng and Trimpe, Sebastian},
journal={IEEE Robotics and Automation Letters},
title={The Wheelbot: A Jumping Reaction Wheel Unicycle},
year={2022},
volume={7},
number={4},
pages={9683-9690}
}
Erratum
In the initial publication, in Equation (3), the transform from averaged body rates ${}^{\text{B}}\omega_i$ to Euler rates was incorrectly denoted as
While we implemented the faulty transform in the Wheelbot’s state estimation routine (see main.c, Line 340), the error had not been noticed during experimentation as the robot remained close to its upright equilibrium. In turn, $q_1$ and $q_2$ remained near zero such that both transforms became almost identical, as
Importantly, our results on tilt estimation using accelerometers as depicted in Figure 10 are not affected by this error. In the first experiment (Figure 10, left) the robot’s tilt angles were kept at zero. In the second experiment (Figure 10, right), $q_1 \approx 0$ such that $\tan(q_1) \approx q_1$. In turn, both transforms deviated only marginally from each other in both experiments.
We added a Jupyter notebook to the projects Github repository detailing the calculation of the transform from body rates to Euler rates.
https://github.com/takuya-takeuchi/MXNetDotNet
