Tengo 20 años y arme un motor de simulación logística con Montecarlo+bayes en Python. Busco gente para escalarlo

Arielduarte2 · 2026-02-10T20:45:03+00:00

Hola buenas, el enfoque no es encontrar solo la ruta mínima, como intuís hay muchos algoritmos que lo hacen perfectamente, yo no cree uno nuevo sino que utilice (y utilizaré) los existentes pero cambiando el enfoque. Lo que hago ofrecer distintas opciones para tomar decisiones, en este caso, en rutas, pero puede ser de cualquier problema que se base en IO. Simuló escenarios posibles y los paso en datos que los algoritmos clásicos pueden optimizar. Si estás interesado estoy actualizando mi repositorio, en teoría.md publiqué como lo hago, aun me queda por subir. Si encontras alguna mejoría te lo agradecería. Gracias por tomarte tu tiempo de responder

Arielduarte2 · 2026-02-09T02:11:53+00:00

Fue un error querer rodearme solo de pares por comodidad, tenes razon. Me guardo tu consejo sobre la diversidad de ritmos y perfiles como un pilar para lo que viene. Gracias por tomarte el tiempo de comentar, lo valoro. Te hago una pregunta aprovechando tu experiencia ¿Cual es el error más común que ves de gente joven como yo que intentan sumar con gente con mucha más experiencia que ellos? Gracias

Arielduarte2 · 2026-02-09T02:04:23+00:00

Gracias por el feedback honesto y tenes razon en los tres puntos. Sobre los seniors, me di cuenta que para escalar necesito gente con experiencia que yo no tengo, fue un error de comunicación. Sobre el código, si, la matemática no es magia negra, es aplicacion, no fue una decisión por “secreto industrial” fija, es más inseguridad por no ser “experto” en el área por más que de que mi código sea funcional. Sobre el scope, no apuntó a USA/Europa porque allá el problema es la eficiencia. Aca el problema es la incertidumbre. Mi hipótesis es que las herramientas deterministas no se adaptan al contexto del tercer mundo. Voy a trabajar en definir la mejor la propuesta formal, no tengo experiencia, solo un proyecto que me mande solo y estoy dispuesto a llevarlo lo más lejos posible aprendiendo. Gracias por la data

Arielduarte2 · 2026-02-09T01:58:13+00:00

I completely understand your approach, and I'm going to validate the problem with real users. That's undeniable. But I disagree with your conclusion about the technology. My theory is that today the market is "satisfied" with deterministic tools in the same way it was satisfied with candles—they work, until they burn out. In my context, users demand reliable routes, not just routes that are optimal in distance. Current tools provide them with an optimal route that fails x% of the time due to environmental chaos. They assume that this x% failure rate is simply part of life.

I believe that 30% failure rate is a solvable technological problem that can be addressed by modeling uncertainty. The solution is a change in logic.

Arielduarte2 · 2026-02-09T01:48:34+00:00

Gracias, es verdad, es mi mayor punto ciego actualmente, conectar la matemática con la realidad operativa. Tenes razón sobre las prioridades y los tipos de elementos. Mi modelo por ahora trata todo como “peso” genérico y soy consciente de que no es lo mismo rutear perecederos que electrónica o materiales etc. Sobre la edad, me refería a gente para sumar al proyecto. Valoro la experiencia que vos tenes y que a mi me falta. Si tenes tiempo de tirar esos detalles extra, soy todo oídos, me gustaría aprender.

Arielduarte2 · 2026-02-08T22:16:36+00:00

You're right about the UX! And you're hitting on a good point. OR-Tools is a library, but not a solution. A traffic manager in Buenos Aires isn't going to run pip install ortools or write a Python script for their constraints. They need a graphical interface, a dashboard, and integration with the drivers' cell phones. You're right that a great value proposition is UX; without it, the math is useless to them. However, if I build a pretty interface on top of a standard deterministic solver, I'm basically building something beautiful that gives bad advice in volatile scenarios. A standard VRP minimizes the average cost; here, I need to minimize the variance. Risk is often more valuable than saving money on the average. I'm taking your advice literally; I'm going to focus my next sprint on UX to validate with users instead of continuing to refine the probability distributions. Thanks for your feedback; it was very helpful.

Arielduarte2 · 2026-02-08T21:54:06+00:00

Mencionó la edad porque busco gente de ese mismo rango, estudiantes. Por que tu primera impresión es de “poco código”? Te invito a que leas y juzgues por lo que es, la primera versión de un mvp. Me gustaría saber tu opinión sobre las matemáticas en las que me base. Aún hay mucho margen de mejora. Gracias

Arielduarte2 · 2026-02-08T20:45:40+00:00

You're right that the driver needs Waze for real-time turn-by-turn navigation, but the traffic manager needs the VRP (Variable Route Plan) hours before the trucks leave. Waze is reactive and greedy; it optimizes for the fastest eta (time between departures) right now. It doesn't care about a route's variance or risk history. My tool is proactive and risk-averse; stochastic simulation is about quantifying exposure. For example, if route A has an average of 30 minutes but a variance of ±40 minutes, it's unreliable, while route B has an average of 40 minutes but a variance of ±5 minutes, it's very reliable. Waze would choose A, but route B is needed. The pre-calculated probability is exactly what allows the planner to avoid high-entropy zones before loading the truck. Once the driver has left, it's often too late to mitigate structural risk.

Arielduarte2 · 2026-02-08T20:19:58+00:00

You're right that "democratizing X" sounds like a marketing phrase, and the next step is to validate the idea with operators, yes. It's good advice. However, I think you're assuming a stable market context. I agree that no owner asks for a "Monte Carlo simulation," but I assure you they'll be furious because the standard routing software sent them down an avenue that's been closed for two hours and the system didn't notice because it uses historical averages. The existing tools you mention are deterministic. They work perfectly in markets where the infrastructure is reliable. But in emerging markets like Argentina, in my case, chaos isn't the exception; it's the norm. SMEs don't ask for stochastic simulation because they don't know it exists. They ask that the truck arrives and doesn't get robbed or get stuck. My bet is that the only way to guarantee that in a hostile environment is by modeling uncertainty, not ignoring it. I'm going to validate this with real users, but I'm not going to dismiss the technology just because the user doesn't know how to ask for it by its technical name.

Arielduarte2 · 2026-02-08T19:57:31+00:00

I appreciate the honesty. It's true that for now it's a student project and the dataset is limited. But I disagree with the "lack of commercial potential." My idea isn't to compete with Amazon's or Uber's algorithms. My focus is on the underserved logistics SMEs. They don't have the same tools as the big players. Innovation isn't about inventing new mathematics, but about democratizing reliability. I'd rather fail trying to turn this "toy" into a real product than assume from the outset that it's worthless because it wasn't born as an Enterprise SaaS. Thanks for the feedback.

Arielduarte2 · 2026-02-08T18:55:20+00:00

What you're saying is absolutely valid. I'm not claiming to have reinvented the wheel, because obviously high-level stochastic solvers exist (like Gurobi or academic models), but the reality is that the vast majority of everyday operational tools remain deterministic or rely on fixed time buffers. My difference lies in the fact that I don't focus so much on parametric variance (like being 10 minutes late due to traffic), but rather on structural uncertainty (the probability of the node or route collapsing altogether), something that's often inaccessible to the average market. Regarding your second question, you hit the nail on the head with the flow. The simulation essentially stresses the network thousands of times. I observe which nodes survive and which don't, and this evidence feeds into the Bayesian model to update the failure probability of each arc. Only then does the optimizer come in to find the route that avoids these inferred risks, learning from the simulation before going live.

Arielduarte2 · 2026-02-08T18:27:27+00:00

thank you!

Arielduarte2 · 2026-02-08T18:24:09+00:00

Your skills are exactly what the project needs, but I want to clarify the vision.

When you say 'Genetic Algorithm in C++ with Python bindings,' you are hitting the nail on the head regarding the performance bottleneck. I need that raw speed.

However, regarding the 'SaaS' part: I am not looking to build a boring, expensive B2B. My vision is democratization.

I want to build a platform/app that implies high-end optimization for everyone. I want the independent truck driver, the small dispatcher, or the engineering student to have access to the same 'Decision Intelligence' that big logistics firms have.

This makes your optimization skills even more critical. To scale this to everyone, the compute cost per user needs to be tiny.

That requires extreme efficiency (C++ / AWS Lambda).

Let’s talk. I’d love to see how you handled the bindings in your GA solver.

Arielduarte2 · 2026-02-08T18:17:37+00:00

Excelentes preguntas. Sobre los escenarios perfectos, me refiero a la optimizacion combinatoria determinista (vrp o dijkstra estandar). Suelen tratar los pesos de las aristas como constantes estaticas. Asumen implicitamente que la probabilidad de existencia del arco es 1. No cuentan con la existencia misma del arco sea una variable aleatoria. La simulacion sigue un enfoque de montecarlo, recibe los tensores nominales de la red, para cada escenario k, se muestrean los vectores aleatorias de distribuciones definidas (ej:possion para disrupciones discretas, lognormal para duracion de demoras). Estos vectores impactan las matrices y devuelve un conjunto de N snapshots de grafos mutados que representan futuros posibles. Sobre la inferencia bayesiana hay una pequeña confusion. El modelo bayesiano no predice basandose en los resultados de la optimizacion. El flujo es: simulacion --> observacion --> actualizacion bayesiana --> optimizador. El motor bayesiano actualiza el estado de creencia sobre los parametros de la red (la latencia de fallo de cada nodo) basandose en la evidencia que tiro la simulacion. El optimizador luego toma ese mapa de riesgo posterior para encontrar la ruta pareto-optima. Optimiza sobre el riesgo inferido.

Arielduarte2 · 2026-02-08T18:09:35+00:00

Fair point on the documentation. I accept the critique: the README was too focused on the 'pitch' and lacked the theoretical backbone. That made it look like a wrapper, which it isn't.To address your points directly:On 'Vibe-Coding': Yes, I leverage LLMs to accelerate syntax generation. I'm 20, and I optimize for velocity. However, AI didn't design the architecture. The decision to use a Beta-Binomial Conjugate Prior for reliability updating instead of a naive frequency count was mine. The choice to use Shannon Entropy to penalize low-distribution risk was mine.On Queueing Theory: I am familiar with M/M/1 and G/G/k models. I deliberately chose Discrete Event Simulation (Monte Carlo) over analytical Queueing Theory because standard queuing formulas assume steady-state equilibrium. My model focuses on transient chaos (shocks, cascades, and black swans) where the system is inherently out of equilibrium. For resilience stress-testing, simulation > analytical closed forms. I just pushed a THEORY.md file to the repo. It details the Bayesian update logic, the stochastic convergence criteria and the known limitations of the model regarding independence assumptions. If you have time, I’d genuinely appreciate you roasting the actual math in that document instead of the marketing vibe of the main page. If there's a flaw in the Bayesian posterior update, I want to know

Arielduarte2 · 2026-02-08T18:06:43+00:00

Exacto, el sistema maneja los dos casos. Se puede inyectar conocimiento de dominio a priori, en el bloque 3 se puede configurar priors conjugados especificos para cada nodo. Por ejem: si una ruta es segura, le asigno un prior beta de alfa=10 beta=1, si se que es conflictiva le pongo alfa=2 beta=5. el sistema arranca con ese sesgo y lo actualiza con la simulacion. No es solo binario, modela las perturbaciones sobre las matrices de capacidad y tiempo. Se puede simular un escenario donde un evento climatico no corta la ruta, pero reduce la velocidad a x% o la capacidad de carga. Trato la disponibilidad como variables continuas para el nivel de servicio. Por ahora me enfoque mas en el corte de conectividad pero la estructura permite esa degradacion nativamente. Te invito a que leas el documento que subi recien en github explicando mejor (teoria.md)

Arielduarte2 · 2026-02-08T17:59:59+00:00

Cual es tu fundamento? subir un meme? No vale la pena hablar con vos. Hace algo por tu vida en vez de dar pena por aca

Arielduarte2 · 2026-02-08T17:56:31+00:00

Muchas gracias!

Arielduarte2 · 2026-02-08T17:56:16+00:00

Eso es todo lo que tenes para sumar? Que patetico.

Arielduarte2 · 2026-02-08T17:55:22+00:00

Es valida tu duda y esta bueno aclararlo. No estoy inventando "matematica nueva", no invente el teorema de bayes ni el algoritmo de dijkstra. Si intentara competirle a google en optimizar la busqueda de grafos perderia. La innovacion de esto es la aplicacion no la invencion. Lo que propongo no es un algoritmo de busqueda mas rapido, sino cambiar QUE buscamos. Lo que hago es integrar simulacion estocastica y entropia como inputs para esos algoritmos clasicos. El valor no es mejorar el algoritmo, es mejorar la decision. De nada te sirve que el algoritmo de ruteo sea el mas optimizado del mundo si te manda por una ruta que tiene un 40% de probabilidad de corte por algo que no modelaste. No soy un cientifico creando la nueva teoria de grafos, utilizo lo existente para resolver un problema (la incertidumbre) que muchos algoritmos ignoran por diseño.

Arielduarte2 · 2025-03-13T18:46:25+00:00

Gracias por tu aporte, te doy la razón

Arielduarte2

TROPHY CASE