# [ICortex](https://github.com/textcortex/icortex): Giving Programming Superpowers to Non-Programmers Introducing [ICortex](https://github.com/textcortex/icortex), our new [Jupyter](https://jupyter.org/) kernel that allows you to generate Python code from natural language prompts: {%youtube AtVCBNq48oc %} ICortex is a drop-in replacement for the IPython kernel that powers Jupyter Notebooks. It is open source, fully extensible, and can connect to multiple code generation services, including TextCortex API, OpenAI Codex API, locally-running HuggingFace models, and so on. Whether you are ... - a beginner who has just started their Python journey, - an advanced developer with years of experience, - or a non-programmer who would like to let AI do the programming for you, ICortex has something to offer to you. ## Installation Install it with ```bash pip install icortex ``` Configure it once for your current project directory: ```bash icortex init ``` Keep pressing enter to use TextCortex as the default code generation service with the default settings. Provide your API key when asked for it. You can fetch your API key at https://app.textcortex.com/user/dashboard/settings/api-key Then simply launch JupyterLab, ``` jupyter lab ``` and create a new notebook with ICortex. We are giving free credits to our first users—[join our Discord](https://discord.textcortex.com/) so that we can shape ICortex together 💪. ## Usage The main feature of ICortex is the ability to generate Python code from natural language. Try pasting the following into a new cell and then execute it: ``` /Integrate sin(x) from 0 to 10 and print the result ``` Ideally, TextCortex should return code that looks similar to the following: ```python from math import sin from scipy.integrate import quad def f(x): return sin(x) result, error = quad(f, 0, 10) print(result) ``` If the `scipy` package is not installed in your Python environment, it will ask for permission to install it. Then, it will ask for permission to execute it, and if you accept: ``` 1.839071529076452 ``` Visit our [GitHub repo](https://github.com/textcortex/icortex) fore more details on how to use ICortex. ## Learn more In 1984, computer scientist Donald Knuth introduced the [literate programming (LP) paradigm](https://en.wikipedia.org/wiki/Literate_programming). It is a fancy way of saying that code is embedded in a plain language document with explanations, which makes it easier to understand what the code does. 38 years after the conception of LP, the [Jupyter Notebook](https://en.wikipedia.org/wiki/Project_Jupyter) remains the most popular application of the paradigm. Since its introduction, Jupyter Notebook (initially called the IPython Notebook) revolutionized how people do research, collaborate and share their work. A data scientist can record their entire day's work in a Jupyter Notebook without ever having to use a word processor or a spreadsheet. [ICortex](https://github.com/textcortex/icortex) supercharges literate programming to the max: it allows you to program without ever writing any code! There is arguably nothing better for programmer productivity than not having to write any low-level code at all. Think of it as moving one step higher in the abstraction layer: ICortex is to Python as Python is to C—except that it's not yet another programming language, but plain English. With ICortex, having a high level understanding of what a program should do is enough to get the work done. This is called [Natural Language Programming](https://en.wikipedia.org/wiki/Natural-language_programming). It has been possible to write programs by describing them in natural language since a couple of decades. However, with the recent breakthroughs with large language models, users are able to get away with less specific descriptions, paving the way for productivity tools like ICortex. [Join our Discord](https://discord.textcortex.com/) to get help starting out with ICortex. **--- [TextCortex](https://textcortex.com) Team**
Last changed by  
 
Onur
286

Read more

AutoPrice

Background Control Mechanisms for Trustless Self-Governing Protocols It is a feature of public blockchains, where a protocol parameter needs to adapt to certain conditions, but should not be controlled by a specific participant. The solution is to implement a mechanism where it auto-adjusts, according to quantifiable and objective conditions. The primary example is Bitcoin’s difficulty adjustment. There, variations in average block time are used to dynamically adjust Bitcoin’s block difficulty, every 2016 blocks. Owing to difficulty adjustment, Bitcoin blocks are mined every 10 minutes on average without any external control. Shifts in block time feed back into the difficulty parameter, which then dampens said shifts, creating a negative feedback loop. Here, Bitcoin's designer made use of elementary control theory, setting mean block time as a process variable and difficulty adjustment as the control action: Gas Price Volatility Blockchains have a limited supply, and a vertical supply curve. For that reason, blockchain resources are subjected to very high price volatilities, once user demand surpasses platform capacity. Let's consider Ethereum. Demand for gas isn’t distributed equally around the globe. Ethereum users exist in every inhabited continent, with the highest demand seen in East Asia, primarily China. Europe+Africa and the Americas seem to be on par in terms of demand. This results in predictable patterns that follow the peaks and troughs of human activity in each continent. The correlation between gas usage and price is immediately noticeable, demonstrated by a 5 day period from March 2019. The grid marks the beginnings of the days in UTC, and the points in the graph correspond to hourly averages, calculated as:

6/29/2020
Lazy Strategies

In Proof of Work We investigate the strategy where miners mine empty blocks to reduce the uncertainty of mining a block which is invalid because it contains a transaction that is already included by another block. In this case, the miner is aware of the new block, already has its hash and/or header, but has not downloaded the rest of the block which contains the transactions. Constant reward per mined block: $R$ Time required to mine an empty block: $T_e$ Time required to mine a full block: $T_f$ Gas price: $P$ Gas in a block: $G$ Block gas limit: $G_\max$ Average tx fee collected from a block: $F(G) = PG$

5/18/2020
Compensation Fees in Transaction Fee Distribution

Users need to specify a fee when submitting their transactions. When it is a validator’s turn to propose a block, the validator collects transactions from the transaction pool, executes them in a certain order, and publishes them in a new block. Fees in a block are distributed to all validators pro rata. This is to weaken the incentive to steal transactions from other blocks, in case the block proposer receives the whole fee. The protocol has the following parameters: $P$: Average gas price of the previous era. This value is updated at the end of each era, calculated by dividing total collected fees by total consumed gas. $G$: Gas in a block. $G_{\text{max}}$: Block gas limit. $G \leq G_{\text{max}}$ for every block. $F$: Total fee collected from transactions in a block. $N$ is the current number of validators, $w_i$ is the normalized weight of validator $i$.

5/15/2020
Maximizing PoS blockchain throughput

Disclaimer: This is work in progress. Smart contract platforms like Ethereum have network parameters that dictate how often a block is to be produced, and how much computation can be performed in a block or how big a block's size can be. The selection of these parameters determine the maximum amount of computation per second that the overall network can perform. We want to maximize that number by choosing the right parameters. Protocol execution consists of cycles called rounds. Each round has a leader (validator), responsible for proposing a block at the beginning of that round. We mean by block time, denoted by $\Delta$, the length of a round. Block time is spent by first executing transactions and including them in a new block, and then by propagating that block throughout the network. Ideally, a leader should have enough time to receive and verify his predecessor's block before the previous round ends, so that he can declare it as a parent of his block when his round begins. If that is not the case, then the blockchain would fork. To prevent validators from creating arbitrarily large blocks or blocks with arbitrarily many operations, certain limits are imposed on blocks at the protocol level. These protocol parameters are: Block time: Defined above. Block size limit: Maximum size of a block in bytes.

5/5/2020
Read more from Onur
Published on HackMD