Code Monkey home page Code Monkey logo

srs-benchmark's Introduction

SRS Benchmark

Introduction

Spaced repetition algorithms are computer programs designed to help people schedule reviews of flashcards. A good spaced repetition algorithm helps you remember things more efficiently. Instead of cramming all at once, it spreads out your study sessions over time. To make this efficient, these algorithms try to understand how your memory works. They aim to predict when you're likely to forget something, so they can schedule a review just in time.

This benchmark is a tool to test how well different algorithms do at predicting your memory. It compares several algorithms to see which ones give the most accurate predictions.

Dataset

The dataset for the SRS benchmark comes from 20 thousand people who use Anki, a flashcard app. In total, this dataset contains information about ~1.5 billion reviews of flashcards. The full dataset is hosted on Hugging Face Datasets: open-spaced-repetition/FSRS-Anki-20k.

Evaluation

Data Split

In the SRS benchmark, we use a tool called TimeSeriesSplit. This is part of the sklearn library used for machine learning. The tool helps us split the data by time: older reviews are used for training and newer reviews for testing. That way, we don't accidentally cheat by giving the algorithm future information it shouldn't have. In practice, we use past study sessions to predict future ones. This makes TimeSeriesSplit a good fit for our benchmark.

Note: TimeSeriesSplit will remove the first split from evaluation. This is because the first split is used for training, and we don't want to evaluate the algorithm on the same data it was trained on.

Metrics

We use two metrics in the SRS benchmark to evaluate how well these algorithms work: log loss and a custom RMSE that we call RMSE (bins).

  • Log Loss (also known as Binary Cross Entropy): Utilized primarily for its applicability in binary classification problems, log loss serves as a measure of the discrepancies between predicted probabilities of recall and review outcomes (1 or 0). It quantifies how well the algorithm approximates the true recall probabilities, making it an important metric for model evaluation in spaced repetition systems.
  • Root Mean Square Error in Bins (RMSE (bins)): This is a metric engineered for the SRS benchmark. In this approach, predictions and review outcomes are grouped into bins based on three features: the interval length, the number of reviews, and the number of lapses. Within each bin, the squared difference between the average predicted probability of recall and the average recall rate is calculated. These values are then weighted according to the sample size in each bin, and then the final weighted root mean square error is calculated. This metric provides a nuanced understanding of model performance across different probability ranges. For more details, you can read The Metric.

Smaller is better. If you are unsure what metric to look at, look at RMSE (bins). That value can be interpreted as "the average difference between the predicted probability of recalling a card and the measured probability". For example, if RMSE (bins)=0.05, it means that that algorithm is, on average, wrong by 5% when predicting the probability of recall.

Models

  • FSRS v3: the first version of the FSRS algorithm that people actually used.
  • FSRS v4: the upgraded version of FSRS, made better with help from the community.
  • FSRS-4.5: the minorly improved version based on FSRS v4. The shape of the forgetting curve has been changed. This benchmark also includes FSRS-4.5 with default parameters (which have been obtained by running FSRS-4.5 on all 20 thousand collections) and FSRS-4.5 where only the first 4 parameters (values of initial stability after the first review) are optimized and the rest are set to default.
  • FSRS-rs: the Rust port of FSRS-4.5. See also: https://github.com/open-spaced-repetition/fsrs-rs
  • GRU: a type of neural network that's often used for making predictions based on a sequence of data. It's a classic in the field of machine learning for time-related tasks.
  • DASH: the model proposed in here. The name stands for Difficulty, Ability, and Study History. In our benchmark, we only use the Ability and Study History because the Difficulty part is not applicable to our dataset. We also added two other variants of this model: DASH[MCM] and DASH[ACT-R]. For more details, you can read the paper here.
  • ACT-R: the model proposed in here. It includes an activation-based system of declarative memory. It explains the spacing effect by the activation of memory traces.
  • HLR: the model proposed by Duolingo. Its full name is Half-Life Regression. For more details, you can read the paper here.
  • Transformer: a type of neural network that has gained popularity in recent years due to its superior performance in natural language processing. ChatGPT is based on this architecture.
  • SM-2: one of the early algorithms used by SuperMemo, the first spaced repetition software. It was developed more than 30 years ago, and it's still popular today. Anki's default algorithm is based on SM-2, Mnemosyne also uses it.
  • NN-17: a neural network approximation of SM-17. It has a comparable number of parameters, and according to our estimates, it performs similarly to SM-17.

For more details about the FSRS algorithm, read this wiki page: The Algorithm.

Result

Total number of users: 19,990.

Total number of reviews for evaluation: 707,964,360. Same-day reviews are excluded; only one review per day (the first chronologically) is used by each algorithm. This is why the number of reviews is significantly lower than the 1.5 billion mentioned earlier. Plus, an outlier filter is also used.

The following tables show the weighted means and the 99% confidence intervals. The best result is highlighted in bold. The rightmost column shows the number of optimizable (trainable) parameters. If a parameter is a constant, it is not included.

Weighted by number of reviews

Algorithm Log Loss RMSE (bins) Parameters
FSRS-4.5 0.33±0.006 0.053±0.0011 17
FSRS-rs 0.33±0.005 0.055±0.0013 17
FSRS v4 0.33±0.006 0.058±0.0014 17
DASH 0.33±0.005 0.063±0.0011 9
DASH[MCM] 0.33±0.005 0.064±0.0012 9
DASH[ACT-R] 0.34±0.006 0.068±0.0014 5
FSRS v3 0.36±0.007 0.072±0.0015 13
FSRS-4.5 (only pretrain) 0.34±0.006 0.075±0.0019 4
GRU 0.38±0.007 0.080±0.0017 36
NN-17 0.35±0.006 0.081±0.0016 39
FSRS-4.5 (default parameters) 0.35±0.006 0.086±0.0021 0
ACT-R 0.36±0.006 0.092±0.0023 5
HLR 0.41±0.009 0.107±0.0021 3
SM-2 0.54±0.012 0.149±0.0031 0
Transformer 0.52±0.011 0.187±0.0036 127

Weighted by ln(number of reviews)

Algorithm Log Loss RMSE (bins) Parameters
FSRS-4.5 0.349±0.0031 0.073±0.0008 17
FSRS-rs 0.349±0.0030 0.074±0.0009 17
FSRS v4 0.358±0.0032 0.080±0.0009 17
DASH 0.355±0.0030 0.082±0.0009 9
DASH[MCM] 0.355±0.0031 0.084±0.0009 9
DASH[ACT-R] 0.358±0.0032 0.087±0.0010 5
FSRS-4.5 (only pretrain) 0.360±0.0031 0.088±0.0009 4
FSRS v3 0.413±0.0043 0.103±0.0013 13
NN-17 0.375±0.0034 0.105±0.0012 39
FSRS-4.5 (default parameters) 0.375±0.0032 0.105±0.0011 0
GRU 0.431±0.0049 0.107±0.0012 36
ACT-R 0.389±0.0036 0.112±0.0012 5
HLR 0.448±0.0049 0.125±0.0013 3
Transformer 0.55±0.006 0.191±0.0018 127
SM-2 0.68±0.011 0.195±0.0021 0

Averages weighted by the number of reviews are more representative of "best case" performance when plenty of data is available. Since all algorithms perform better when there's a lot of data to learn from, weighting by n(reviews) biases the average towards lower values.

Averages weighted by the natural logarithm of the number of reviews are more representative of "average case" performance. In reality, not every user will have hundreds of thousands of reviews, so the algorithm won't always be able to reach its full potential.

The image below shows the p-values obtained by running the Wilcoxon signed-rank test on the RMSE of all pairs of algorithms. Red means that the row algorithm performs worse than the corresponding column algorithm, and green means that the row algorithm performs better than the corresponding column algorithm. Grey means that the p-value is >0.01, and we cannot conclude that one algorithm performs better than the other.

Almost all p-values are extremely small, many orders of magnitude smaller than 0.01. Of course, p-values this low beg the question, "Can we even trust these values?". scipy.stats.wilcoxon itself uses an approximation for n>50, and our modified implementation uses an approximation to return the decimal logarithm of the p-value rather than the p-value itself, to avoid the limitations of 64-bit floating point numbers. So it's an approximation of an approximation. But more importantly, this test is not weighted, meaning that it doesn't take into account the fact that RMSE depends on the number of reviews.

Overall, these p-values can be trusted on a qualitative (but not quantitative) level.

Wilcoxon, 19990 collections

Default Parameters

FSRS-4.5:

0.4872, 1.4003, 3.7145, 13.8206,
5.1618, 1.2298, 0.8975, 0.031,
1.6474, 0.1367, 1.0461,
2.1072, 0.0793, 0.3246, 1.587,
0.2272, 2.8755

Comparisons with SuperMemo 15/16/17

Please go to:

Run the benchmark

Requirements

Dataset (tiny): #28 (comment)

Dependencies:

pip install -r requirements.txt

Commands

FSRS-4.5:

python script.py

FSRS-4.5 with default parameters:

DRY_RUN=1 python script.py

FSRS-rs:

FSRS_RS=1 FSRS_NO_OUTLIER=1 PYTHONPATH=~/Codes/anki/out/pylib:~/Codes/anki/pylib python script.py

Please change the PYTHONPATH variable to the path of your Anki source code.

FSRSv4/FSRSv3/HLR/LSTM/SM2:

MODEL=FSRSv4 python other.py

Please change the MODEL variable to FSRSv3, HLR, GRU, or SM2 to run the corresponding model.

Dev model in fsrs-optimizer:

DEV_MODE=1 python script.py

Please place the fsrs-optimizer repository in the same directory as this repository.

srs-benchmark's People

Contributors

dae avatar expertium avatar l-m-sherlock avatar rlzhi avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar

srs-benchmark's Issues

Revlogs parsing

revlogs2dataset.zip
Here are the stats_pb2.py and revlogs2dataset.py
Also, here are the 10 revlog.
10.zip
For file 1 I expected this result, card_id,review_th,delta_t,rating
0,1,-1,3
0,2,0,3
0,3,4,3
0,163,6,4
0,237,1,2
0,380,11,4
1,4,-1,3
1,14,0,1
1,16,0,1
1,21,0,3
1,30,0,3
1,111,2,3
1,160,4,4
1,340,8,3
2,5,-1,1
2,7,0,1
2,10,0,3
2,17,0,3
2,101,2,4
2,158,4,3
2,243,1,2
2,352,7,4
2,384,4,2 from revlog 1, but got this result:
card_id,review_th,delta_t,rating
0,4863,-1,3
0,4864,0,3
0,4997,4,3
0,5846,5,4
0,6105,2,2
0,6745,10,4
1,4998,-1,3
1,5008,0,1
1,5010,0,1
1,5015,0,3
1,5024,0,3
1,5276,1,3
1,5843,4,4
1,6371,9,3
2,4999,-1,1
2,5001,0,1
2,5004,0,3
2,5011,0,3
2,5266,1,4
2,5841,4,3
2,6111,2,2
2,6383,7,4
2,6800,4,2

Cannot download dataset from huggingface

from datasets import load_dataset

raw_datasets = load_dataset("open-spaced-repetition/FSRS-Anki-20k")

produces the following error:

Generating train split: 720284748 examples [05:41, 2111906.74 examples/s]
Traceback (most recent call last):
  File "/home/nieradzik/.conda/envs/pytorch2.1.1/lib/python3.11/site-packages/datasets/builder.py", line 2011, in _prepare_split_single
    writer.write_table(table)
  File "/home/nieradzik/.conda/envs/pytorch2.1.1/lib/python3.11/site-packages/datasets/arrow_writer.py", line 585, in write_table
    pa_table = table_cast(pa_table, self._schema)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/nieradzik/.conda/envs/pytorch2.1.1/lib/python3.11/site-packages/datasets/table.py", line 2295, in table_cast
    return cast_table_to_schema(table, schema)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/nieradzik/.conda/envs/pytorch2.1.1/lib/python3.11/site-packages/datasets/table.py", line 2249, in cast_table_to_schema
    raise CastError(
datasets.table.CastError: Couldn't cast
card_id: null
review_th: null
delta_t: null
rating: null
__index_level_0__: null
-- schema metadata --
pandas: '{"index_columns": ["__index_level_0__"], "column_indexes": [{"na' + 780
to
{'card_id': Value(dtype='int64', id=None), 'review_th': Value(dtype='int64', id=None), 'delta_t': Value(dtype='int64', id=None), 'rating': Value(dtype='int64', id=None)}
because column names don't match

During handling of the above exception, another exception occurred:


Traceback (most recent call last):
  File "/home/nieradzik/anki/download.py", line 3, in <module>
    raw_datasets = load_dataset("open-spaced-repetition/FSRS-Anki-20k")
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/nieradzik/.conda/envs/pytorch2.1.1/lib/python3.11/site-packages/datasets/load.py", line 2609, in load_dataset
    builder_instance.download_and_prepare(
  File "/home/nieradzik/.conda/envs/pytorch2.1.1/lib/python3.11/site-packages/datasets/builder.py", line 1027, in download_and_prepare
    self._download_and_prepare(
  File "/home/nieradzik/.conda/envs/pytorch2.1.1/lib/python3.11/site-packages/datasets/builder.py", line 1122, in _download_and_prepare
    self._prepare_split(split_generator, **prepare_split_kwargs)
  File "/home/nieradzik/.conda/envs/pytorch2.1.1/lib/python3.11/site-packages/datasets/builder.py", line 1882, in _prepare_split
    for job_id, done, content in self._prepare_split_single(
  File "/home/nieradzik/.conda/envs/pytorch2.1.1/lib/python3.11/site-packages/datasets/builder.py", line 2013, in _prepare_split_single
    raise DatasetGenerationCastError.from_cast_error(
datasets.exceptions.DatasetGenerationCastError: An error occurred while generating the dataset

All the data files must have the same columns, but at some point there are 1 new columns ({'__index_level_0__'})

This happened while the csv dataset builder was generating data using

hf://datasets/open-spaced-repetition/FSRS-Anki-20k/dataset/2/10054.csv (at revision 9440578f519d7113db474c284bba7828fcbeccaf)

Please either edit the data files to have matching columns, or separate them into different configurations (see docs at https://hf.co/docs/hub/datasets-manual-configuration#multiple-configurations)

Updating the benchmark with new data

open-spaced-repetition/fsrs4anki#493 (comment)
Now that Dae has provided us with far more data, I'd like you to update the benchmark repo and include the following algorithms:

  1. FSRS v4.5 (after we figure out whether the extra parameters are worth using or not)
  2. FSRS v4
  3. FSRS v4 (dry run)
  4. FSRS v3
  5. LSTM
  6. HLR
  7. SM-2
  8. Ebisu (once you figure out the details with the dev)

LSTM (short-term) is optional IMO. I'm planning to make a reddit post, and I will need those 8 algorithms. Since benchmarking will take a lot more CPU time now, I can also help you to speed it up by doing some of it myself, if you want me to. Also, please make the dataset downloadable using the python download_data.py command, I want to re-do my test of button usage and RMSE.

[Question] Some more details from a ML perspective

Hey, first of all thank you for the dataset. I was wondering if you could provide some more details for people who want to train their own ML algorithms but might not be familiar with the internals of Anki.

Let me see if I understand the dataset correctly:

  • The dataset consists of n * m time series where n are the number of users and m are the number of cards.
  • Each time series has 3 features: days between last review, rating 1-4, current number of reviews

What is the target variable? And how are you handling the time series for RNNs?

Using the mode to find the best default parameters

This will be the new issue to discuss this, as I was polluting the previous issue.
@L-M-Sherlock here's some interesting data from my preliminary testing; with sqrt(n) in pretrain, 107 489 380 reviews from 2988 users. All three estimates (half-range, half-sample, kernel density) seem to agree with one another in most, but not all cases. Below are the values of modes obtained by these three estimators after sorting the values:

[0.3534, 0.3601, 0.4564]
[0.9, 0.9, 0.903]
[2.3, 2.5091, 2.5861]
[10.9, 10.9, 365.0]
[5.0375, 5.049, 5.0491]
[1.0596, 1.0597, 1.0598]
[0.7406, 0.8595, 0.86]
[0.0, 0.0, 0.0]
[1.49, 1.49, 1.49]
[0.1, 0.1, 0.1]
[0.94, 0.94, 0.9405]
[2.1257, 2.18, 2.1803]
[0.01, 0.01, 0.01]
[0.3399, 0.34, 0.34]
[1.26, 1.26, 2.0]
[0.0, 0.0, 0.0]
[2.61, 2.61, 4.0]

In order to calculate the final value, I use all three estimators (HRM, HSK, KDE), and then take the average of the two closest ones. This isn't used in the data above, just to clarify.
S0 for "Easy" is the problem. It's either the default value of 10.9, or the max. value, so modes don't help in this case.

Inconsistency in the description

image
The description says that there are 72 collections and 6240084 reviews, but the actual dataset has 71 collections and 4632965 reviews.

[Feature request] A quantitative measure of cheating

I have an idea how to measure the degree of "cheatiness" of an algorithm.

  1. Do the same procedure that you do for plotting the calibration graph.

  2. Record the number of values in the densest bin, aka the highest bar. Example:
    image

  3. Divide it by the total number of reviews. For a cheating algorithm, this will be 100% since there is only one bin, so 100% of reviews fall into that bin.

  4. Do this for every user for a given algorithm.

  5. Calculate the (unweighted) average.

From a theoretical point of view, the issue is that the cutoff will be arbitrary. If the average is 90%, meaning that on average 90% of predicted R values fall within the same bin, is it cheating? What about 80%? Or 50%?
From a practical point of view, this will require re-running every single algorithm since this information cannot be obtained from .json result files right now. At the very least, you will have to re-run FSRS-4.5, ACT-R and DASH[ACT-R], since we are sure that FSRS-4.5 isn't cheating, and ACT-R algorithms are the main suspects. But of course, to get a better idea of what values of this metric are good and what values are bad, you need to re-run the entire benchmark.

Also, this is not intended to be included in the readme. It's for our internal testing.

[Feature Request] Add a Transformer

This isn't high priority at all, of course, but I would like to see how well a Transformer neural network can perform.
Slightly unrelated, but please add the number of parameters used by LSTM to the description.
image
Also, ideally, the number of parameters in LSTM and in the Transformer should be roughly the same to make the comparison fair and clearly see how much the difference in architecture matters.

[Question] A “raw” version of the tiny_dataset.zip

In #28 a link to a pre-processed small dataset was shared.

While testing different ways of converting review logs of different spacing algorithms
to FSRS, my evaluation on ~7000 reviews generated using an EmacsLisp implementation of py-fsrs
suggests that updating the difficulty and stability for reviews with an interval greater than 1 day
is slightly better than using the (re)learning/review states of the py-fsrs implementation.

To make sure I didn't make any mistake in my evaluation code and test on larger datasets,
I'd like to retry this experiment using the code and datasets of this benchmark
but I can't do so with the “tiny_dataset.zip” because the delta_t have been rounded to days.

Would it be possible to get access to a similar dataset either in an unprocessed format
or with floating-point delta_t values?

This seems to be related to a difference in how the benchmark and the optimizer
implement the FSRS algorithm (using the first review of each day, as I understand it) and how it's
implemented in e.g. py-fsrs (using states to decide when to update the parameters).
I'm not sure how to compare the two approaches other than using review logs from FSRS
and testing if the recall prediction would have been more accurate if we had included
reviews that occurred in the (re)learning state but after a sufficiently large interval or on a different day.

Ebisu?

Thank you for this very interesting analysis! If you all feel inclined to include it, I'd be curious to see how Ebisu compares.

[TODO] Add DASH and its variants

image

Jones, M. N. (Ed.). (2016). Predicting and Improving Memory Retention: Psychological Theory Matters in the Big Data Era. In Big Data in Cognitive Science (0 ed., pp. 43–73). Psychology Press. https://doi.org/10.4324/9781315413570-8

image

Randazzo, Giacomo. (2020-21). Memory Models for Spaced Repetition Systems (Tesi di Laurea Magistrale in Mathematical Engineering - Ingegneria Matematica, Politecnico di Milano). Advisor: Marco D. Santambrogio. Retrieved from https://hdl.handle.net/10589/186407

[Feature Request] Add a BiLSTM

Here's my code:
biLSTM.zip

It's basically other.py, but you don't need to specify the model, just run set DEV_MODE=1 && python biLSTM.py. I removed other algorithms and changed class LSTM. The problem is - I don't get any errors, but I don't get any output files either. You said that it could be a RAM issue, but I tried setting n_hidden to 1 and still got no output. Since there are no errors, I found it hard to debug. So I want you to do 2 things:

  1. Find out what's the problem with my code
  2. Benchmark the bi-directional LSTM and add it to the table

[Feature request] Add the ACT-R model (see paper)

Relevant paper.
Main formulas:
image
image
The appendix has example calculations.

It only has 4 parameters: decay intercept (a), decay scale (c), activation threshold (𝜏) and noise (s). Seems to be fairly straightforward to implement. In the paper 𝜏 and s are fixed, but I think we should make them optimizable. I don't see why they should be fixed.
Btw, a reminder: please add the Transformer to the table with p-values.

[Feature request] Add confidence intervals for all metrics

Calculating the confidence interval is very easy if we assume that the values of metrics (RMSE, logloss, etc.) are distributed normally. I really hope they are, otherwise this will get complicated.
CI=const * st. dev. / sqrt(N)
For a 99% confidence interval, the constant is 2.576. sqrt(N) is just the square root of the number of collections, and st. dev is the standard deviation of the selected metric.
So all you need is just RMSE and logloss values for every collection, which you, of course, have. There is one tricky part, however. Since we are using a weighted average (with the number of reviews as a weight), the standard deviation also has to be weighted. I found a short and elegant solution after a little bit of googling:
np.sqrt(np.cov(values, aweights=weights))
Here values would be logloss or RMSE of each collection, and weights would be the number of reviews of each collection.
This should make our benchmark more rigorous as well as give us an idea of whether some algorithm actually performs better than another or whether it's just a fluke.

[Feature Request] Group users into single dataset

Currently each user is treated as an isolated dataset and the results are taken by a weighted average by various schemes.

It would be helpful to allow models that learns from one user and can apply it to others. even without card data. A simple one would just take the current FSRS or LSTM benchmark and apply regularization to the parameters relative to the individual mean (or the mean can be its own parameter).

[Feature Request] Train a gradient-boosted decision tree

Although transformers are probably what would give the best performance with enough training and tweaking of hyperparameters, I suspect that a gradient boosted decision tree ensemble model might outperform FSRS with very little tweaking using a methodology similar to this: https://machinelearningmastery.com/xgboost-for-time-series-forecasting/. It would, however be a much heavier model with many more parameters than even the LSTM that was attempted.

This is something i'd be interested in exploring if I could have access to the training data.

Add Memrise to the comparison

It's not very important, but I do want to see how well (or, rather, how poorly) it performs.
https://memrise.zendesk.com/hc/en-us/articles/360015889057-How-does-the-spaced-repetition-system-work-
Next review in: 4 hours > 12 hours > 24 hours > 6 days > 12 days > 48 days > 96 days > 180 days.
My ancient python code:

def memrise(history):
    ivl = 0
    reps = 0
    for delta_t, rating in history:
        delta_t = delta_t.item()
        rating = rating.item() + 1
        intervals = [1, 6, 12, 24, 48, 96, 180]
        if rating > 1:
            reps += 1
            if reps > 7:
                reps = 7
            ivl = intervals[reps-1]
        else:
            ivl = 1
            reps = 1
    return ivl

dataset['memrise_interval'] = dataset['tensor'].map(memrise)
dataset['memrise_p'] = np.exp(np.log(0.9) * dataset['delta_t'] / dataset['memrise_interval'])

The obvious issue is that it's unclear what retention level it aims for. I guess we should use 90%. I tried searching for anything that could give me a hint, but found nothing. Btw, what about HLR? I don't know what % it aims for.
As for description, you can add something like: "Memrise, the algorithm used by a language learning app Memrise.".

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.