I'm a Data Scientist. For some time, I've been working on a library for feature engineering.
• GitHub: https://github.com/feature-express/feature-express
• Website: https://feature.express
It isn't yet complete, and I wouldn't consider it ready for production use or handling larger datasets. Here are some of its characteristics:
• Event-based workflows: Initially, everything is converted to an event format, ingested into an event store, and processed from there.
• In-memory: Both the event store and evaluation have been built from scratch.
• Written in Rust, but there's a Python package available.
• A DSL (Domain Specific Language) for defining aggregations, similar to SQL.
Why am I developing this? I've always found it challenging to build models based on time. These models can be surprisingly tricky, and there's a high risk of accidentally using future data, which can lead to data leakage. FeatureExpress is designed to nearly eliminate such mistakes. Moreover, I believe that representing data as events is an intuitive approach.
Right now I start my prompts to chatgpt-4 with "dont be lazy". For every question I have it answers that it is a complex problem... GPT-3.5 in the API is more consistent that chatgpt-4. Even with some additional prompts it is making so many mistakes that it takes me multiple tries to get the right output with conversation resets from time to time to start from the previous solution.
I'm pretty surprised more people dont use logit biases to call openai with. Checking if something is either a or b means that the tokens for those letters must be 100 weight which means they will be chosen no matter what and no other character is allowed.
Except Paul McCartney is considered as one of the best song writers of all time. There may be many musicians who can do the same on a technical level but even then he is a significant outlier.
You realize that Scikit-learn is written mostly in Cython (where high performance is needed)? It is a part of the most influential ML library in existence.
If you believe Rust zero cost abstraction - being safe doesn't mean it has to be compared to safe languages because Rust and C can translate into same assembler code. But in Rust the compiler gives you more guarantees.
I would say that a proper way to rephrase it would be to use idiomatic code vs unidiomatic. If you start using any high-level language in a non intended fashion (writing non idiomatic code) probably most of them would be faster.
To some extent it depends on the settings of the tournament because engines can work in the background and analyse position while it is not their turn. It is called ponder.
Time management is based on some heuristics built into the engine. Some positions that are being evaluated are more dynamic and engines have rules to evaluate positions which are settled down.
As for the hardware if 2 CPU engines are playing they have exactly the same resources. The problem arises when one engine is GPU based and the other is CPU. In this situations balancing the compute power is hard but even then they normally have the same time allocated.
Yes you are right it is not a very good UX. For me the most interesting part is observing the evaluations of the position from the perspective of 2 engines. See the charts that track it move by move. It is often the case that one engine sees something that other doesn't. For example, say, that it is completely busted. I imagine internal dialogue: I'm fine, I'm fine, am I in trouble... oh $^#^ I'm losing now. It was especially true in the early days of neural chess engines which saw ideas which were well beyond the event horizon of traditional engines. Most people who are watching these tournaments on twitch are chess engine developers themselves that's why interfaces like these are fine for them.