Thank you for your interest honest comment. We are working on creating a fully consistent and reproducible environment and publishing it on Huggingface.
I've been in this endeavor with Surface Book 2. While the results where good, the CPU usage for software DSP killed the entire effort. Microsoft is using intel's DSP accelerator to do this. While linux technically can use intel's audio DSP I never had enough time to dig into it
Thank you for brilliant comment highligthing the OSS issues.
But I believe you're missing the main point that OP is making: OSS will _statistically_ dominate every single niche.
There are just more reasons why non-OSS software would cease to exist - so eventually Inkscape will become a de-facto standard for Illustrator things; Blender will become de-facto standard of all 3D-Max things; OBS will become a de-facto standard of all Macromedia Flash Broadcast ... oh wait ... did that happen already?
There are several options how to make harvested energy work for interstellar travel
1. Just beam it with a huge laser to the spacecraft (google for several proposed projects already in development and plans for launch)
2. Store it onboard the spacecraft and then use, with multiple options and different levels of today's technology feasibility like creating a small spinning black hole or creation of exotic matter for warp drive
First, you can just google for "logistics is a shady business"
If you want to be more specific, you can google for "carrier haulage tax evasion" - this will be just the tip of the iceberg.
Supply chain is mixed with shady practices for tax evasion, bribery, laundering and all sorts of shady things at all levels that "compete" with actual process optimization. Combined with overall opposition to automation this incapacitates any effort to make the process efficient cuz it's hard, it "steals jobs" and not easy money.
Yes, behind the scenes it lowers the high-level logic of Python to predicate logic, uses RETE on that predicate logic to do the fastest possible JOIN operations on the tables, and uses machine learning to extract heuristics from the task and data to enable feasible monte-carlo search for valid plans.
All that means you input the rules for the "game", and it finds the way to reach the goal, no matter how complex the interactions or data are inside.
Yes, PROLOG with modern Python syntax and mostly imperative flow, commercial database experience instead of "build everything yourself", and ML-based heuristics that are learned on the fly instead of whatever hardcoded logic the particular interpreter had.
This is sometimes referred to as "Automated planning and scheduling" or simply "AI Planning" in academia.
Supply chain is a black box with people who are aggressively not interested in transparency. So the approach is to model the black box as good as we can, and start cutting away the pieces with automation.
My thoughts :) Get the mess solved here first. As a comment on your ideas - there are extremely powerful forces that would oppose any openness in logistics as it's filled with shady gangs. We need to act together to beat them off the market.
Alternatively we could merge with the machines and all go virtual. But I am to believe that part of the humanity will remain explorers and will want to go beyond our star. That's where the physics kicks in. There simply isn't enough energy that can be mined and extracted from minerals.
We're a tiny team that so far only got the confirmation that it works. The focus right now is to make the first batch of customers happy, and continue to spend effort on the metaplanner.
Btw, I advise you to take a look at the metaplanner's code. It's the definition of the planning task for the planner. So that the planner can learn to solve the planner's (it's own) task. It is leveraging the HyperC core that sits in a separate repository in the same github org.
I heard the approach was circulating in the AI planning academic circles but no one had put it together as many academically-uninteresting details needed to be cared for first. That's exactly what we did.
We are not a crypto company. Moreover, being as clean and open as possible is the only way to win the battle of the good guys vs. the bad guys in supply chain.
We're starting with small Amazon sellers. And it's just what I believe is right, the technology must take over the logistics and stop the supply chain gangs from thrashing the planet with waste. We aren't getting anywhere with the status quo.
Andrew here, the founder of HyperC. Thank you very much for your feedback, and especially for your attention and time to look at the note.
Our current and today's focus is, of course, not to send the sattelites to the sun to build the Dyson sphere but rather to automate sending average commodities from China to Amazon FBA. Everything else comes after.
And you're right, the supply chain mess isn't caused by the absense of tech (although this does contribute) but rather by the "dark" forces in the logistics world that would prefer to keep things messy and hard to trace. The entire logistics thing has historically always been a shady business. But big data is coming for the dark guys.
So the immediate plan is to build the model of the "black box" of logistics by analyzing the data we can actually collect, then use the combination of technology and HyperC's reputation-leveraged optimal financing offers to beat the shady schemes out of the market. That itself could be overly ambitious, but this is what I believe is right.
Hello HN, I'm the designer of HyperC Planning Database. Its purpose is to demonstrate that state-of-the-art autonomous planning techniques from self-driving and robotics are usable in real-world IT production environments.
We package all applicable knowledge in AI planning, automatic proof and machine learning to convert multiple data science problems into an IT database administration process.
The ultimate goal is to get as close as possible to the 'universal algorithm' which will solve things like optimal logistics, food production, dyson sphere construction plan, etc.., fully autonomously.
I'm introducing the 2 years of hard work of our team to package classical AI planning into native Python concept.
We will soon follow-up with our ML and GP accelerators of universal heuristics that we build on top of fast-downward and our naive symbolic execution engine.
Things are not quite that simple. You can't say "because my Go app serves a single request under no load in 50us, it will serve 20'000 per core under 100% load" you'd be surprised it will not.
Modern machines are like a networked cluster themselves. You need to do a ton of work to tune both kernel and "hardware" parameters to identify bottlenecks with near-non-existing debugging tools.
There is one truth here: we used to get more performance by scaling "horizontally". Maybe it's time to "scale within"?