louise VS flecs

and this is a cool repo to track: https://github.com/stassa/louise

From what I understand this is a relatively new approach to ML? Has anyone heard of this? I was hoping to get a general feel for what people in the industry believe for the perspectives of this approach. If you're curious, here's an implementation of MIL.

Thanks, that's a nice example.

>> For an example. The potential hypothesis here are pre generated, but you can imagine an algorithm or adapt an existing one with a tight generalise/specialise loop.

Yes! I'm thinking of how to adapt Louise (https://github.com/stassa/louise) to do that. The fact that s(CASP) is basically a Prolog-y version of ASP (with constraints) could make it a very natural sort of modification. Or, of course, there's always Well-Founded Semantics (https://www.swi-prolog.org/pldoc/man?section=WFS).

Well, since we're going a little mad with speculation in this thread, I have to point out that true one-shot learning (as opposed to "one-billion-plus-one-shot") works just fine, but only in the symbolic machine learning paradigm. For example, see:

https://github.com/stassa/louise#capabilities

In particular the second example listed there. A trivial example, but one that cannot be reproduced by current approaches without big-data pre-training.

I bring up the 80/20% training/test split that is standard in machine learning because I remember an interaction with my supervisor at the start of my PhD. In one of our meetings my supervisor asked me about the details of some experiments I was running, with a system called metagol (linked from the Louise repository above). En passant, I mentioned that I was training with ta 20/80% training/test split and my supervisor stopped me to ask me if I thought that was a standard setup for machine learning. Thinking he meant the splitting of my training data to training and testing partitions I asked, a bit bemused, that yes, of course, that's the standard thing. To which my supervisor laughed and replied "I don't think so". Later of course I realised that he meant that the done thing in machine learning is to use most of the data for training and leave as little as possible for testing.

In Inductive Logic Programming, it's typically the other way around, and the datasets are often a few examples, like a dozen or so. Of course our systems don't do the spectacular, impressive things that deep learning systems do, but then again we don't have a dozen thousand graduates racing to out-do each other with new feats of engineering. Which is a bit of a shame because I think that if we had no more than a thousand people working on ILP, we 'd make huge progress in applications, as well as in understanding of machine learning in general.

Oh well. It's probably all for the best. Who wants to build genuinely useful and intelligent systems anyway?

Note you can do machine learning of logic programs. My PhD research:

https://github.com/stassa/louise

In which case it _is_ machine learning and it still really works :D

If you want to auto-write Haskell, use MagicHaskeller:

http://nautilus.cs.miyazaki-u.ac.jp/~skata/MagicHaskeller.ht...

And if you want to auto-write Prolog, use my own Louise:

https://github.com/stassa/louise

My guess is the end result of all this "AI" assisted code-generation is that it will have the same impact on the software engineering industry as spreadsheets had on accounting. I also believe that this AI-powered stuff is a bit of a "two-steps forward, one step back" situation and the real innovation will begin when ideas from tools like Louise [1] are integrated into the approach taken in Codex.

When VisiCalc was released departments of 30 accountants were reduced to 5 accountants because of the improvement for individual worker efficiency, however accounting itself remains largely unchanged and accountants are still a respected profession who perform important functions. There's plenty of programming problems in the world that simply aren't being solved because we haven't figured out how to reduce the burden of producing the software; code generation will simply increase the output of an individual software developer.

The same forces behind "no-code" are at work here. In fact I see a future where these two solutions intermingle: where "no-code" becomes synonymous with prompt-driven development. As we all know, however, these solutions will only take you so far -- and essentially only allow you to express problems in domains that are already well-solved. We're just expressing a higher level of program abstraction; programs that generate programs. This is a good thing and it is not a threat to the existence of our industry. Even in Star Trek they still have engineers who fix their computers...

[1] - https://github.com/stassa/louise

I've also been enjoying building My First Game™ in Bevy using ECS. The community around Bevy really shines, but Flecs (https://github.com/SanderMertens/flecs) is arguably a more mature, open-source ECS implementation. You don't get to write in Rust, though, which makes it less cool in my book :)

I'm not very proud of the code I've written because I've found writing a game to be much more confusing than building websites + backends, but, as the author notes, it certainly feels more elegant than OOP or globals given the context.

I'm building for WASM and Bevy's parallelism isn't supported in that context (yet? https://github.com/bevyengine/bevy/issues/4078), so the performance wins are just so-so. Sharing a thread with UI rendering suuucks.

If anyone wants to browse some code or ask questions, feel free! https://github.com/MeoMix/symbiants

Flecs does just that: https://ajmmertens.medium.com/why-it-is-time-to-start-thinking-of-games-as-databases-e7971da33ac3

I'm trying to optimize my workflow as much as possible, and came across this thing called an ECS. After doing a little bit more digging I found some decent guides on how you would make one, I also found one premade called FLECS. FLECS is nice and all, but I was looking for something more simple that just has the bare bones of what I need and is also configurable. I haven't been able to really find anything like that, so I was wondering if anyone had an example of maybe their way of implementing an ECS. I know how to go about it, but I'm unsure of exactly what the code would look like.

Since we wanted a common game simulation that would be on both the server and the client we looked into a few libraries that would fit our ECS needs. It was decided we were going to write this common part of our game in C++, but rust was considered. C++ was a familiar language for us so naturally EnTT and flecs came up right away. I had used EnTT before, writing some small demo projects, so our choice was made based on familiarity. In order to integrate with Unity we created a small C interface to communicate between our simulation code and Unity’s C#. Here’s close to what it looked like. I removed some parts for brevity sake.

Repository: https://github.com/SanderMertens/flecs

This is the project: https://github.com/SanderMertens/flecs (query engine implementation lives here: https://github.com/SanderMertens/flecs/tree/master/src/addons/rules)

There's also a performance question. While we can now use Blueprint nativization to convert Blueprints to C++ the result will be a fairly naive version, fast enough for most purposes but not if you're trying to push every bit of performance. This is where you're looking at making sure you're hitting things such as using the CPU cache as well as possible for an ECS system (Look at ENTT or Flecs if you want to see what they're about and why you'd want one), or a system needing to process massive amounts of data quickly such as the Voxel Plugin.

If I knew C++ and I'd heard about it before I started my current project, I would have been tempted to use this https://github.com/SanderMertens/flecs which can be built to WASM. Of course you still need JavaScript in the front end to link to the WASM part. I've recently been using esbuild to bundle my front end code, which does a pretty similar job to webpack, but is a bit faster.

When do think bevy will support entity-entity relationships ? https://github.com/bevyengine/bevy/issues/3742.

Flecs ECS already supports this: https://github.com/SanderMertens/flecs/blob/master/docs/Rela...

For a modern engine you’re probably best looking at Unity’s DOTS. You may also want to check out some of the different open source ECS libraries such as flecs and EnTT are two popular ones for C++, but there’s lots of them. Largely you’ll see lots of different approaches taken, all with their own pros and cons. Not all of them will be performant (some focus more on the design benefits) while others will be optimised for certain use cases. What you should prioritise will depend on your specific needs.