DeepObfusCode: Source Code Obfuscation Through Sequence-to-Sequence Networks

Siddhartha Datta

REVIEW 4 major objections 5 minor 23 references

DeepObfusCode: Source Code Obfuscation Through Sequence-to-Sequence Networks

T0 review · 4 major / 5 minor · reviewed 2026-08-14 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read DeepObfusCode claims that a randomly initialized sequence-to-sequence network turns source code into a short ciphertext that a trained key network can decode and execute.

desk verdict New application of seq2seq to code obfuscation, but the core exact-reconstruction claim is assumed, not demonstrated, and the stealth benchmark is largely an artifact of fixed-length ciphertext. read the letter →

arxiv 1909.01837 v3 pith:YVYDGCXU submitted 2019-09-03 cs.CR cs.LGcs.SE

Siddhartha Datta This is my paper · ORCID

classification cs.CRcs.LGcs.SE

keywords sourcecodeobfuscationsequence-to-sequencenetworkrecurrentneuralencoder-decoderciphertextgenerationkeystealthmetricLevenshteindistancedeeplearningcryptography

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper claims that source code obfuscation can be carried out by a text-based recurrent neural network encoder-decoder: a first network with randomly generated weights turns plaintext source into a short, random-looking ciphertext, and a second network trained on the known ciphertext-plaintext pair produces model weights that serve as a key. During live execution, the ciphertext is passed through the key network and the decoded output is executed directly, so the original logic never appears in plaintext. The paper argues this is complete obfuscation rather than the incremental modifications of traditional methods, and that it is at least on par with existing obfuscation in stealth while improving in dissimilarity for larger code bases. It also reports that ciphertext length stays around 72 characters regardless of source length, keeping storage low, while key generation grows linearly with plaintext length.

What carries the argument

The load-bearing object is the character-level sequence-to-sequence RNN encoder-decoder, a neural network that reads an input character sequence, compresses it into an internal context, and generates an output character sequence one character at a time. In DeepObfusCode the same architecture plays two roles: with random weights it produces the ciphertext from the source code, and with weights trained on the ciphertext-plaintext pair it becomes the key that reconstructs and executes the original code. The formulas $C(p)$ and $K(p,c)$ make explicit that both operations are weighted sums over character-level features plus a normalization constant, so the trained weights are literally the cryptographic material.

What would settle it

The decisive check is exact reconstruction: take a random sample of 4,000-character source programs, run the full DeepObfusCode pipeline on each, and require the decoded output to be byte-for-byte identical to the input; any mismatch falsifies the claim because a single wrong character can change execution. A simpler counting argument backs this up: with a fixed character alphabet, the number of distinct ciphertexts of length around 72 is vastly smaller than the number of possible 4,000-character programs, so by the pigeonhole principle two distinct programs must map to the same ciphertext and cannot both be recovered exactly.

Watch

Extended reading notes

Core claim

The paper's central discovery is that a text-based RNN encoder-decoder can serve as both the obfuscator and the deobfuscation key for executable source code. In ciphertext generation, a model with randomly assigned weights maps plaintext $p$ to ciphertext $c$ through $C(p)=\sum_{n=1}^{N}w_{\mathrm{rand}} f_n(c|p)+\log Z(p)$; in key generation, a second model is trained by maximizing $\frac{1}{N}\sum_{n=1}^{N}\log p(p|c)$, and the resulting weights are exported as the key. The claim is that this achieves complete obfuscation: the ciphertext is random-looking, the key is required to decode it, and live execution simply decodes and runs the result. Compared with benchmark obfuscated code, the paper reports an average ratio of proposed-to-benchmark Levenshtein distance of 1.2614, with ciphertext length staying near 72 characters and key-generation time growing linearly with source length.

Load-bearing premise

The scheme collapses unless the trained key network reproduces the original source code exactly from the short random ciphertext, since any altered character can change what the program does.

Editorial extensions

If this is right

Obfuscated code stays small: ciphertext length remains around 72 characters for plaintext lengths up to 4,000, so hidden programs can be stored and transmitted cheaply.
The bottleneck moves to key generation: encryption time shows no clear dependence on source length, while key generation scales linearly with plaintext length.
Stealth grows with code size: the reported Levenshtein distance between original and obfuscated text correlates almost perfectly with plaintext length (0.9994), so larger programs become more dissimilar from their plaintext.
Live execution requires holding the key on the machine that runs the code, so the scheme naturally fits a trusted-server or cloud-confidentiality deployment rather than distributing the key with the ciphertext.
Brute-force deobfuscation would require reconstructing roughly 975,872 32-bit floating-point weight values, making exhaustive key search impractical.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

The paper leaves implicit that a fixed 72-character ciphertext cannot by itself carry all the information in a 4,000-character program; if exact reconstruction works, the trained key must effectively store most of the program's content, so the key file deserves the same protection as the source code.
A testable extension would measure byte-exact reconstruction on programs not used in key training, since the paper reports only an execution pass/fail test and no reconstruction-error rate.
The paper's stealth metric is dissimilarity, not human indistinguishability; an obvious follow-up is a human-reader study asking whether the ciphertext looks like code, data, or random noise.
The same encoder-decoder construction could be applied to non-source data such as binaries or configuration files, but the fixed-length ciphertext limitation would be even more severe for arbitrary byte strings.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Here's the take: the paper's novelty is real—applying sequence-to-sequence RNNs to source-code obfuscation and treating a trained key network as the deobfuscation key is a new combination, and the author ships code, which helps reproducibility. But the core claim of "complete obfuscation" is never tested. The system is supposed to encode arbitrary source into a ~72-character ciphertext and then decode it back, exactly, using a separately trained network. That requires lossless reconstruction of up to 4,000 characters from a short fixed-length code. The paper reports no reconstruction accuracy, no character error rate, and no details of the pass/fail execution test in Section 3.2. A single wrong character can change program semantics or break syntax. This is a load-bearing assumption, not a validation.

Stealth results are also weak: five IOCCC samples, one removed post hoc because it worked against the claim, no error bars or significance tests. And the "dissimilarity" result in Section 4.2 is circular: because ciphertext length is consistently about 72 characters, Levenshtein distance from the original grows almost linearly with plaintext length (correlation 0.9994). That is a fixed-length artifact, not evidence of strong obfuscation. The execution-cost section never compares against existing obfuscators, so the "improvement" claim isn't grounded.

What does work: the idea itself is worth discussing, the paper is clearly written, and the characterization of ciphertext length and character variation is a useful starting point. The citation pattern is thin but fair. As a proof-of-concept for a workshop, it has value; as a validated obfuscation method, it doesn't.

Who should read it: people interested in neural cryptography applied to source code, or anyone teaching a security research seminar on how not to evaluate a system. I'd tell the author to run actual reconstruction tests (e.g., byte-identical, or at least a bounded error rate), compare against standard obfuscators, fix the stealth benchmark, and be open about the fact that this is a prototype. Until then, a serious venue should reject, though a workshop might take it as an ideas paper.

Referee Report

4 major / 5 minor

Summary. The paper proposes DeepObfusCode, a source-code obfuscation method built from sequence-to-sequence RNNs. A randomly initialized encoder-decoder network maps source code to a short ciphertext; a second encoder-decoder is then trained on the (ciphertext, plaintext) pair and its exported weights serve as a key. The authors claim that the ciphertext is highly dissimilar from the original code, that the method is at least on par with traditional obfuscation in stealth, and that it improves execution cost. They evaluate stealth with five IOCCC obfuscated/deobfuscated pairs using Levenshtein distance and study execution time and ciphertext properties on random strings up to 4,000 characters.

Significance. If the central claim were demonstrated, the paper would present a conceptually novel way of applying neural sequence models to code protection, with a public repository that supports reproducibility. However, the load-bearing assertion—that a ~72-character ciphertext can be losslessly decoded into arbitrary source code via a trained key network—is never validated. The stealth evaluation is based on five samples, one of which contradicts the claim and is removed post hoc, and the distance metric is essentially forced by the fixed ciphertext length. The execution-cost comparison promised in the abstract is absent. The contribution is therefore currently a speculative architecture idea rather than a supported obfuscation method.

major comments (4)

[Section 3.2] The central requirement of the method—exact reconstruction of the source code from the ciphertext—is never tested. The text says the model is trained 'until the output text is executable and identical to the source code text,' and a pass/fail execution test is mentioned, but no reconstruction accuracy, character error rate, number of retraining attempts, or convergence analysis is reported. Since a single wrong character can alter program semantics or break syntax, and the decoder receives a roughly 72-character representation of inputs up to 4,000 characters, exact reconstruction cannot be assumed. The manuscript must report per-sample reconstruction accuracy and pass/fail counts, not merely state that retraining continues until the test passes.
[Sections 4.2 and Figure 7] The reported 'greater dissimilarity' result is an artifact of fixed ciphertext length. Ciphertext length is essentially constant (mean about 72 characters) regardless of plaintext length, so the Levenshtein distance between plaintext and ciphertext is bounded below by approximately plaintext_length - 72 and must grow linearly with plaintext length. The correlation of 0.9994 between lev_distance and plaintext_length is therefore a mathematical consequence of the output-length cap, not evidence of increasing obscurity. Distance should be normalized by plaintext length or compared against a random-string baseline before any stealth claim is drawn from Figure 6.
[Section 4.1, Table 1] The stealth benchmark is not statistically valid. It uses only five IOCCC sample pairs, reports no variance or significance test, and one of the five samples (set 2) directly contradicts the claim with a proposed-to-benchmark ratio of 0.192. The paper then excludes that sample post hoc, reporting an improved average of 1.5287, and uses this to claim the method is 'at least on par.' Such selective reporting cannot support the conclusion; a larger benchmark or a clearly defined protocol applied to all samples is required.
[Section 4.2, 'Execution Cost'] The abstract and conclusion claim that the method offers significant improvement in execution cost compared to existing obfuscation methods, but Section 4.2 only reports absolute encryption and decryption times for random strings. There is no comparison to any existing obfuscation tool, so the execution-cost claim is unsupported. A comparison against at least one established obfuscator, such as Obfuscator-LLVM or a name/control-flow obfuscator, under the same hardware is necessary.

minor comments (5)

[Section 2.2] The text refers to 'stenography' where it should refer to 'steganography,' and the same paragraph contains the typo 'en crpyted' (likely 'encrypted').
[Table 1 and Sections 4.1-4.2] The metric is consistently misspelled as 'Levenstein' (and 'Levenstein distance') instead of 'Levenshtein distance'; the table title should also be corrected.
[Section 4.2, Figure 6] Figure 6 is said to 'add onto prior Stealth results,' but it is generated from random strings of length 1 to 4000, not from the IOCCC code samples; the text should clearly distinguish the two experiments and avoid implying that the random-string result measures stealth of actual code.
[Sections 3.1-3.3] Key architecture and training hyperparameters are not stated in the paper: RNN cell type, number of hidden layers beyond the array shapes, optimizer, loss function, batch size, and learning rate are omitted. The repository link helps, but the paper itself should list the central hyperparameters for reproducibility.
[References] The reference list has formatting inconsistencies, including a broken line inside Reference [8]'s URL and missing publication venue information in Reference [10]; a full, consistently formatted bibliography is needed.

Circularity Check

1 steps flagged · score 6.0 of 10

Stealth/dissimilarity finding is tautological with the fixed 72-character output, while the central key-execution claim is unvalidated but not circular.

self definitional [Section 4.2, Figures 6 and 7; cf. Section 3.1 ciphertext generation and the model array [39, 256, 1024, 72, ...] in Section 4.2]
"Figure 6 adds onto prior Stealth results in section 4.1 to reveal that the larger the code base, the greater the dissimilarity between the obfuscated code and the original code base."

The paper also reports that 'the ciphertext length is kept low (on average 72 character length) regardless of the plaintext length,' and the model contains a 72-element output dimension. For plaintext length L and ciphertext length C≈72, the Levenshtein distance is at least |L−C|, so for L≫C the distance grows as L−C. The near-perfect correlation of 0.9994 between plaintext_length and lev_distance in the correlation matrix is therefore a mathematical identity implied by the fixed decoder output length, not an empirical finding about RNN-based obfuscation.

full rationale

The only clear reduction-by-construction found is the stealth/dissimilarity metric: fixing the ciphertext at ~72 characters makes Levenshtein distance approximately track plaintext length, so Figures 6 and 7's central 'larger code, more dissimilar' result is tautological with the output-length design. The paper's other main claim—complete obfuscation plus key-based execution—is not circular: the key is explicitly trained on the ciphertext/plaintext pair, so recovering the plaintext is by construction the training objective. The problem there is lack of evidence (no reported reconstruction error, no pass/fail counts, no demonstration for arbitrary code), which is a validation gap rather than a circular derivation. There are no load-bearing self-citations or imported uniqueness theorems. Accordingly the score reflects one predicted property that is forced by construction, while the core architecture claim retains independent (if unproven) content.

Assumptions & free parameters 4 free parameters · 5 assumptions · 0 invented entities

The paper relies on a set of unstated modeling and evaluation assumptions. The most notable free parameters are the randomness index, training iterations, and an implicit fixed output length. The key training and live execution require exact reconstruction from a short random ciphertext, which is assumed without proof. The stealth metric is assumed to be a valid proxy. These choices are not derived and materially affect the reported results.

free parameters (4)

randomness index n = 10
Section 3.1 sets n=10 as the number of times random weights are generated; this controls the ciphertext output and is chosen by hand, not derived.
key training iterations = 2000
Section 3.2 states 'we tended to use 2000 iterations' for the key-generation model; this is an arbitrary hyperparameter that affects whether the decode is exact.
decoder maximum output length (implicit) = about 72 characters
Section 4.2 reports ciphertext length averaging 72 regardless of plaintext length, implying a fixed output length; the paper does not justify why 72 is sufficient to encode arbitrary source code.
model layer dimensions = [39, 256, 1024, 72, 256, 1024, 256, 72]
Given in Section 4.2 as the structure of the model file; these architecture choices are not derived and affect the key size and reconstruction ability.

assumptions (5)

domain assumption RNN encoder-decoder models are capable of learning a mapping from a short random ciphertext to an arbitrary source code string of length up to 4000.
Invoked in Section 3.2 key generation and Section 4.2 tests on random strings; no theoretical capacity bound or empirical accuracy is provided.
domain assumption Levenshtein distance between obfuscated and original source is a meaningful measure of obfuscation stealth.
Section 4.1 uses this distance as the sole stealth metric; the paper does not validate it against human deobfuscation difficulty.
domain assumption The source code can be treated as plain text and the output of the decoder can be safely executed as source code.
Section 3.3 executes the output directly; the paper does not discuss syntax validity, runtime errors, or security of executing generated strings.
ad hoc to paper Training a model for 2000 iterations (or until a loss threshold) yields exact reconstruction of the source code.
Section 3.2 relies on retraining until an execution test passes; no loss threshold or convergence guarantee is specified.
ad hoc to paper A constant output length of about 72 characters provides sufficient representational capacity for any source code.
Section 4.2 reports ciphertext length averaging 72 regardless of plaintext length; no information-theoretic justification is given.

how reviews work

0 comments

Cite this review

Pith. "Pith review of DeepObfusCode: Source Code Obfuscation Through Sequence-to-Sequence Networks." pith.science (2026). https://pith.science/paper/YVYDGCXU

@misc{pith2026190901837,
  author       = {Pith},
  title        = {Pith review of: DeepObfusCode: Source Code Obfuscation Through Sequence-to-Sequence Networks},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/YVYDGCXU}},
  note         = {Machine review of arXiv:1909.01837}
}

read the original abstract

The paper explores a novel methodology in source code obfuscation through the application of text-based recurrent neural network (RNN) encoder-decoder models in ciphertext generation and key generation. Sequence-to-sequence models are incorporated into the model architecture to generate obfuscated code, generate the deobfuscation key, and live execution. Quantitative benchmark comparison to existing obfuscation methods indicate significant improvement in stealth and execution cost for the proposed solution, and experiments regarding the model's properties yield positive results regarding its character variation, dissimilarity to the original codebase, and consistent length of obfuscated code.

Figures

Figures reproduced from arXiv: 1909.01837 by the authors.

**Figure 1.** Overview of ciphertext generation. We pass the source code and a character set as inputs to initialize both character sets for the encoder-decoder model, then randomly assign weights to generate the ciphertext, an obfuscated version of the source code. To generate the obfuscated code, we first take the original legible text (source code) and a full character set (a string containing all characters, including letters… view at source ↗

**Figure 2.** Overview of key generation. With the known ciphertext and original source code, the developer of the source code would pass them as inputs into another encoderdecoder model and train over a number of iterations such that the model weights obtained can translate the obfuscated code into executable code, with validation of executability at the end. K(p, c) = log p(p|c) = X N n=1 wnfn(p|c) + log Z(c) After the ciphert… view at source ↗

**Figure 3.** Overview of live execution. To run the obfuscated code on any server or system, one would pass in the obfuscated code into an execution engine that takes the ciphertext and the lodged model files as inputs to execute the withheld code. Other parameters such as code potency or resilience would not be applicable to this method, as those comparison metrics require some form of the original code to be preserved; but sin… view at source ↗

Figures from the paper (4 more)

**Figure 4.** Figure 4: Plots of time properties against plaintext length 0 500 1000 1500 2000 2500 3000 3500 4000 plaintext_length 2 4 6 8 10 12 14 ciphertext_character_variation Plot of ciphertext_character_variation against plaintext_length 0 500 1000 1500 2000 2500 3000 3500 4000 plaintex…

**Figure 5.** Figure 5: Plots of ciphertext properties against plaintext length (vi) Average character length of ciphertext. As execution time depends on the device running the simulation, for reference, the simulation was run on a Python Jupyter notebook, running on Windows 10 with a Nvidia …

**Figure 6.** Figure 6: Plot of similarity metric against plaintext length the length of the plaintext input, which further supports the notion of randomness of ciphertext generation, as the ciphertext is based purely on the randomness in the model weight generation; (ii) the ciphertext leng…

**Figure 7.** Figure 7: Correlation matrix of properties References 1. Popa, M. (2011) Techniques of Program Code Obfuscation for Secure Software. Journal of Mobile, Embedded and Distributed Systems 2. Viticchie, A. Regano, L. Torchiano, M. Basile, C. Ceccato, M. Tonella, P. & Tiella, R. (201…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

23 extracted references · 8 canonical work pages

[1]

, " * write output.state after.block = add.period write newline

ENTRY address archive author booktitle chapter doi edition editor eid eprint howpublished institution journal key month note number organization pages publisher school series title type url volume year label extra.label sort.label short.list INTEGERS output.state before.all mid.sentence after.sentence after.block FUNCTION init.state.consts #0 'before.all ...
[2]

write newline

" write newline "" before.all 'output.state := FUNCTION add.period duplicate empty 'skip "." * add.blank if FUNCTION if.digit duplicate "0" = swap duplicate "1" = swap duplicate "2" = swap duplicate "3" = swap duplicate "4" = swap duplicate "5" = swap duplicate "6" = swap duplicate "7" = swap duplicate "8" = swap "9" = or or or or or or or or or FUNCTION ...
[3]

write newline

" write newline "" before.all 'output.state := FUNCTION add.period duplicate empty 'skip "." * add.blank if FUNCTION if.digit duplicate "0" = swap duplicate "1" = swap duplicate "2" = swap duplicate "3" = swap duplicate "4" = swap duplicate "5" = swap duplicate "6" = swap duplicate "7" = swap duplicate "8" = swap "9" = or or or or or or or or or FUNCTION ...
[4]

, " * write output.state after.block = add.period write

ENTRY address author booktitle chapter edition editor eid howpublished institution journal key month note number organization pages publisher school series title type url volume year label INTEGERS output.state before.all mid.sentence after.sentence after.block FUNCTION init.state.consts #0 'before.all := #1 'mid.sentence := #2 'after.sentence := #3 'afte...
[5]

write newline

" write newline "" before.all 'output.state := FUNCTION n.dashify 't := "" t empty not t #1 #1 substring "-" = t #1 #2 substring "--" = not "--" * t #2 global.max substring 't := t #1 #1 substring "-" = "-" * t #2 global.max substring 't := while if t #1 #1 substring * t #2 global.max substring 't := if while FUNCTION word.in bbl.in capitalize ":" * " " *...
[6]

write newline

" write newline "" before.all 'output.state := FUNCTION n.dashify 't := "" t empty not t #1 #1 substring "-" = t #1 #2 substring "--" = not "--" * t #2 global.max substring 't := t #1 #1 substring "-" = "-" * t #2 global.max substring 't := while if t #1 #1 substring * t #2 global.max substring 't := if while FUNCTION word.in bbl.in capitalize ":" * " " *...
[7]

write newline

" write newline "" before.all 'output.state := FUNCTION fin.entry write newline FUNCTION new.block output.state before.all = 'skip after.block 'output.state := if FUNCTION stupid.colon after.authors 'output.state := FUNCTION insert.comma output.state before.all = 'skip between.elements 'output.state := if FUNCTION new.sentence output.state after.block = '...
[8]

, " * write output.state after.block = add.period write newline

ENTRY address author booktitle chapter doi edition editor eid howpublished institution journal key month note number organization pages publisher school series title type url volume year label INTEGERS output.state before.all mid.sentence after.sentence after.block FUNCTION init.state.consts #0 'before.all := #1 'mid.sentence := #2 'after.sentence := #3 '...

Show all 23 references

[9]

write newline

" write newline "" before.all 'output.state := FUNCTION if.digit duplicate "0" = swap duplicate "1" = swap duplicate "2" = swap duplicate "3" = swap duplicate "4" = swap duplicate "5" = swap duplicate "6" = swap duplicate "7" = swap duplicate "8" = swap "9" = or or or or or or...
[10]

write newline

" write newline "" before.all 'output.state := FUNCTION if.digit duplicate "0" = swap duplicate "1" = swap duplicate "2" = swap duplicate "3" = swap duplicate "4" = swap duplicate "5" = swap duplicate "6" = swap duplicate "7" = swap duplicate "8" = swap "9" = or or or or or or...
[11]

, " * write output.state after.block = add.period write newline

ENTRY address author booktitle chapter doi edition editor eid howpublished institution journal key month note number organization pages publisher school series title type url volume year label INTEGERS output.state before.all mid.sentence after.sentence after.block FUNCTION in...
[12]

write newline

" write newline "" before.all 'output.state := FUNCTION if.digit duplicate "0" = swap duplicate "1" = swap duplicate "2" = swap duplicate "3" = swap duplicate "4" = swap duplicate "5" = swap duplicate "6" = swap duplicate "7" = swap duplicate "8" = swap "9" = or or or or or or...
[13]

write newline

" write newline "" before.all 'output.state := FUNCTION n.dashify 't := "" t empty not t #1 #1 substring "-" = t #1 #2 substring "--" = not "--" * t #2 global.max substring 't := t #1 #1 substring "-" = "-" * t #2 global.max substring 't := while if t #1 #1 substring * t #2 gl...
[14]

\ (2011) Techniques of Program Code Obfuscation for Secure Software

Popa, M. \ (2011) Techniques of Program Code Obfuscation for Secure Software. Journal of Mobile, Embedded and Distributed Systems

2011
[15]

\, Regano, L

Viticchie, A. \, Regano, L. \, Torchiano, M. \, Basile, C. \, Ceccato, M. \, Tonella, P. & Tiella, R. \ (2017) Assessment of Source Code Obfuscation Techniques. Retrieved from https://arxiv.org/pdf/1704.02307.pdf

2017 arXiv
[16]

Retrieved from https://arxiv.org/pdf/1612.03345.pdf

Schneider, J.\ & Locher, T.\ (2016) Obfuscation using Encryption. Retrieved from https://arxiv.org/pdf/1612.03345.pdf

2016 arXiv
[17]

Advances in Neural Information Processing Systems

Baluja, S.\ (2017) Hiding Images in Plain Sight: Deep Steganography. Advances in Neural Information Processing Systems

2017
[18]

\ (2018) ConvCrypt

Benoit, S. \ (2018) ConvCrypt. Retrieved from https://github.com/santient/convcrypt

2018
[19]

\, Galal-Edeen, H

Ismail, A. \, Galal-Edeen, H. \, Khattab, S. \, Mohamed, A.E. & Bahtity, M.E. \ (2012) Satellite image encryption using neural networks backpropagation. International Conference on Computer Theory and Applications

2012
[20]

\, Takabi, H

Hesamifard, E. \, Takabi, H. & Ghasemi, M. \ (2017) CryptoDL: Deep Neural Networks over Encrypted Data. Retrieved from https://arxiv.org/pdf/1711.05189.pdf

2017 arXiv
[21]

\, Merrienboer, B.V

Cho, K. \, Merrienboer, B.V. \, Gulcehre, C. \, Bahdanau, D. \, Bougares, F. \, Schwenk, H. & Bengio, Y. \ (2014) Learning Phrase Representations using RNN Encoder-Decoder for Statistical Machine Translation. Retrieved from https://arxiv.org/pdf/1406.1078.pdf

2014 arXiv
[22]

\ (2018) Attention-based Encoder-Decoder Networks for Spelling and Grammatical Error Correction

Ahmadi, S. \ (2018) Attention-based Encoder-Decoder Networks for Spelling and Grammatical Error Correction. Retrieved from https://arxiv.org/pdf/1810.00660.pdf

2018 arXiv
[23]

\, Singh, G

Khatri, C. \, Singh, G. \, Parikh, N. \ (2018) Abstractive and Extractive Text Summarization using Document Context Vector and Recurrent Neural Networks. KDD Deep Learning Day

2018

Pith tools

Reviewed August 14, 2026 · model on record in the stance chip above.

[1] [1]

, " * write output.state after.block = add.period write newline

ENTRY address archive author booktitle chapter doi edition editor eid eprint howpublished institution journal key month note number organization pages publisher school series title type url volume year label extra.label sort.label short.list INTEGERS output.state before.all mid.sentence after.sentence after.block FUNCTION init.state.consts #0 'before.all ...

[2] [2]

write newline

" write newline "" before.all 'output.state := FUNCTION add.period duplicate empty 'skip "." * add.blank if FUNCTION if.digit duplicate "0" = swap duplicate "1" = swap duplicate "2" = swap duplicate "3" = swap duplicate "4" = swap duplicate "5" = swap duplicate "6" = swap duplicate "7" = swap duplicate "8" = swap "9" = or or or or or or or or or FUNCTION ...

[3] [3]

write newline

" write newline "" before.all 'output.state := FUNCTION add.period duplicate empty 'skip "." * add.blank if FUNCTION if.digit duplicate "0" = swap duplicate "1" = swap duplicate "2" = swap duplicate "3" = swap duplicate "4" = swap duplicate "5" = swap duplicate "6" = swap duplicate "7" = swap duplicate "8" = swap "9" = or or or or or or or or or FUNCTION ...

[4] [4]

, " * write output.state after.block = add.period write

ENTRY address author booktitle chapter edition editor eid howpublished institution journal key month note number organization pages publisher school series title type url volume year label INTEGERS output.state before.all mid.sentence after.sentence after.block FUNCTION init.state.consts #0 'before.all := #1 'mid.sentence := #2 'after.sentence := #3 'afte...

[5] [5]

write newline

" write newline "" before.all 'output.state := FUNCTION n.dashify 't := "" t empty not t #1 #1 substring "-" = t #1 #2 substring "--" = not "--" * t #2 global.max substring 't := t #1 #1 substring "-" = "-" * t #2 global.max substring 't := while if t #1 #1 substring * t #2 global.max substring 't := if while FUNCTION word.in bbl.in capitalize ":" * " " *...

[6] [6]

write newline

" write newline "" before.all 'output.state := FUNCTION n.dashify 't := "" t empty not t #1 #1 substring "-" = t #1 #2 substring "--" = not "--" * t #2 global.max substring 't := t #1 #1 substring "-" = "-" * t #2 global.max substring 't := while if t #1 #1 substring * t #2 global.max substring 't := if while FUNCTION word.in bbl.in capitalize ":" * " " *...

[7] [7]

write newline

" write newline "" before.all 'output.state := FUNCTION fin.entry write newline FUNCTION new.block output.state before.all = 'skip after.block 'output.state := if FUNCTION stupid.colon after.authors 'output.state := FUNCTION insert.comma output.state before.all = 'skip between.elements 'output.state := if FUNCTION new.sentence output.state after.block = '...

[8] [8]

, " * write output.state after.block = add.period write newline

ENTRY address author booktitle chapter doi edition editor eid howpublished institution journal key month note number organization pages publisher school series title type url volume year label INTEGERS output.state before.all mid.sentence after.sentence after.block FUNCTION init.state.consts #0 'before.all := #1 'mid.sentence := #2 'after.sentence := #3 '...