{% load email %} {% subject %}You have been invited to administer the {{ program_name }} program.{% endsubject %} {% body %} Hello, {{ first_name }}. You have been invited to administer the {{ program_name }} program. {% if is_existing_user %} As you are an existing SEMA user you can simply use your existing participant/admin ID and password to sign into the website. Participant/Admin ID: {{ username }} If you have forgotten your password you can reset it here: {{ password_change_url }} {% else %} As you are a new user we have automatically generated an participant/admin ID and password for you. Use this id and password to sign into the website. Participant/Admin ID: {{ username }} Password: {{ password }} If you forget your password you can reset it here: {{ password_change_url }} {% endif %} If you want to also join the program as a participant and receive surveys on your mobile device you should send a participant invite to this email address after logging in. Please click the Confirm Access link below to confirm your access as a program administrator: {{ enrollment_url }} Sincerely, The Team {% endbody %} {% bodyhtml %}
Hello, {{ first_name }}.
You have been invited to administer the {{ program_name }} program.
{% if is_existing_user %}As you are an existing SEMA user you can simply use your existing participant/admin ID and password to sign into the website.
Participant/Admin ID: {{ username }}
If you have forgotten your password you can reset it here: Reset Password
{% else %}As you are a new user we have automatically generated an participant/admin ID and password for you. Use this id and password to sign into the website.
Participant/Admin ID: {{ username }}
Password: {{ password }}
If you forget your password you can reset it here: Reset Password
{% endif %}If you want to also join the program as a participant and receive surveys on your mobile device you should send a participant invite to this email address after logging in.
Please click the Confirm Access link below to confirm your access as a program administrator:
Confirm AccessSincerely,
The Team
{% endbodyhtml %}


where journey begins.
Discover your next great adventure, become an explorer to get started!
Find your dream tour today!
When you create pictures, charts, or diagrams, they also coordinate with your current document look.


Hi my name is {{slimshady}}
Hi, I'm {{name}} {{>kicks}}
and I roundhouse-kicked {{today}} people today. By tomorrow it will be {{tomorrow}}
ICanHaz Tests?
test markup, will be hidden


The Meaning Of Decentralization
The Meaning of Decentralization 去中心化的含义
本文翻译自：https://medium.com/@VitalikButerin/the-meaning-of-decentralization-a0c92b76a274
翻译时间：2017-10-12
“Decentralization” is one of the words that is used in the cryptoeconomics space the most frequently, and is often even viewed as a blockchain’s entire raison d’être, but it is also one of the words that is perhaps defined the most poorly. Thousands of hours of research, and billions of dollars of hashpower, have been spent for the sole purpose of attempting to achieve decentralization, and to protect and improve it, and when discussions get rivalrous it is extremely common for proponents of one protocol (or protocol extension) to claim that the opposing proposals are “centralized” as the ultimate knockdown argument.
“去中心化”是最常在密码经济学领域中使用的词之一, 而且经常被认为是区块链的存在的全部理由, 但它也是被定义的最糟糕的词之一。人们已经花了数千小时的研究, 以及数十亿美元的算力, 来尝试实现去中心化, 并加以保护和改进。 在争论中, 一个协议 (或扩展协议) 的支持者经常以反对者的提议是 “中心化”的作为最终论据。
But there is often a lot of confusion as to what this word actually means. Consider, for example, the following completely unhelpful, but unfortunately all too common, diagram:
但这个词实际上意味着什么, 经常会有很多混淆。如下图:
Now, consider the two answers on Quora for “what is the difference between distributed and decentralized”. The first essentially parrots the above diagram, whereas the second makes the entirely different claim that “distributed means not all the processing of the transactions is done in the same place”, whereas “decentralized means that not one single entity has control over all the processing”. Meanwhile, the top answer on the Ethereum stack exchange gives a very similar diagram, but with the words “decentralized” and “distributed” switched places! Clearly, a clarification is in order.
现在, 来看一下 Quora 上关于“分布式和去中心化的区别是什么” 的两个答案。第一个答案重用了以上的图表, 而第二个给出了完全不同的说法, “分布式指不是所有的处理交易在同一个地方完成”, 而 “去中心化是指没有任何单一节点可以控制所有处理 “。同时, Ethereum stack exchange 的最高答案给出来一个非常类似的图, 但是 “去中心化” 和 “分布式” 两个词的解释对换了! 显然, 有必要对他们澄清一下。
Three types of Decentralization
去中心化的三种形式
When people talk about software decentralization, there are actually three separate axes of centralization/decentralization that they may be talking about. While in some cases it is difficult to see how you can have one without the other, in general they are quite independent of each other. The axes are as follows:
当人们谈论软件去中心化时, 实际上他们可能在谈论三种独立的中心化/去中心化的维度。虽然在某些情况下, 你很难看到他们其中一个单独使用, 总的来说, 他们还是相当独立的。
-
Architectural (de)centralization — how many physical computers is a system made up of? How many of those computers can it tolerate breaking down at any single time?
-
架构 (去) 中心化 - 系统有多少台物理计算机组成？能容忍多少台计算机随时发生故障？
-
Political (de)centralization — how many individuals or organizations ultimately control the computers that the system is made up of?
-
政治（去）中心化 - 有多少个人或者组织控制了系统服务器
-
Logical (de)centralization — does the interface and data structures that the system presents and maintains look more like a single monolithic object, or an amorphous swarm? One simple heuristic is: if you cut the system in half, including both providers and users, will both halves continue to fully operate as independent units?
-
逻辑（去）中心化 - 系统接口和数据结构更像是单体模块, 还是非晶群？一个简单的判断方法是: 如果你把系统（服务器和用户）切成两半, 两个部分是否能继续作为独立单元运作？
We can try to put these three dimensions into a chart: 我们把以上三个维度画成图：
Note that a lot of these placements are very rough and highly debatable. But let’s try going through any of them: 示意图很粗糙也很有争议。但我们分别来看一下：
-
Traditional corporations are politically centralized (one CEO), architecturally centralized (one head office) and logically centralized (can’t really split them in half)
-
传统的公司是政治中心化 (一个 CEO), 架构中心化 (一个总部) 和逻辑中心化的 (不能分成一半)
-
Civil law relies on a centralized law-making body, whereas common law is built up of precedent made by many individual judges. Civil law still has some architectural decentralization as there are many courts that nevertheless have large discretion, but common law have more of it. Both are logically centralized (“the law is the law”).
-
民法依赖于一个中心化的立法机构, 而普通法是在许多个人法官的判案先例所建立的。民法任然有一部分是架构去中心化的, 因为许多法院有很大的酌处权, 而普通法有更多的酌处权。两者都是逻辑中心化的 (“法律即法律”)。
-
Languages are logically decentralized; the English spoken between Alice and Bob and the English spoken between Charlie and David do not need to agree at all. There is no centralized infrastructure required for a language to exist, and the rules of English grammar are not created or controlled by any one single person (whereas Esperanto was originally invented by Ludwig Zamenhof, though now it functions more like a living language that evolves incrementally with no authority)
-
语言是逻辑去中心化的; 两个人的英语沟通和另两个人的英语沟通完全可以独立进行。语言不需要中心化结构的存在, 并且英语语法也不是由个人创建或控制的。
- BitTorrent is logically decentralized similarly to how English is. Content delivery networks are similar, but are controlled by one single company.
-
BitTorrent 也是逻辑去中心化的， 和英语类似。 CDN也类似， 但是是由一个公司控制的。
-
Blockchains are politically decentralized (no one controls them) and architecturally decentralized (no infrastructural central point of failure) but they are logically centralized (there is one commonly agreed state and the system behaves like a single computer)
- 区块链是政治去中心化的（没人控制它们）和架构去中心化的（没有单点失败）， 但是是逻辑中心化的（有共识机制并且系统看起来就像只有一台电脑）
Many times when people talk about the virtues of a blockchain, they describe the convenience benefits of having “one central database”; that centralization is logical centralization, and it’s a kind of centralization that is arguably in many cases good (though Juan Benet from IPFS would also push for logical decentralization wherever possible, because logically decentralized systems tend to be good at surviving network partitions, work well in regions of the world that have poor connectivity, etc; see also this article from Scuttlebot explicitly advocating logical decentralization).
许多时候人们谈论区块链的优点时, 他们会说它拥有 “一个中心化的数据库”。 这个中心化是指逻辑中心化, 在许多情况下它是好的 (尽管IPFS 的 Juan Benet 也会尽可能地推动逻辑去中心化, 因为逻辑去中心化的系统往往在子网络生存的更好, 在网络环境较差的地区也能工作良好; 请参考Scuttlebot 的这篇文章。
Architectural centralization often leads to political centralization, though not necessarily — in a formal democracy, politicians meet and hold votes in some physical governance chamber, but the maintainers of this chamber do not end up deriving any substantial amount of power over decision-making as a result. In computerized systems, architectural but not political decentralization might happen if there is an online community which uses a centralized forum for convenience, but where there is a widely agreed social contract that if the owners of the forum act maliciously then everyone will move to a different forum (communities that are formed around rebellion against what they see as censorship in another forum likely have this property in practice).
架构中心化经常导致政治中心化， 虽然这不是必须的 - 传统的民主, 政客在一些有形的政府会议室里开会和投票, 但这个会议室的维护人士最终不会产生任何实质性决定。在计算机化的系统中, 架构去中心化，政治中心化是可能发生的，比如有个在线社团， 他们使用同一个论坛。如果论坛所有者恶意行动，号召大家搬去另一个论坛并得到大家的同意， 那大家就会搬到另一个论坛。
Logical centralization makes architectural decentralization harder, but not impossible — see how decentralized consensus networks have already been proven to work, but are more difficult than maintaining BitTorrent. And logical centralization makes political decentralization harder — in logically centralized systems, it’s harder to resolve contention by simply agreeing to “live and let live”.
逻辑中心化使架构去中心化变得更难， 但并非不可能 - 去中心化的共识网络已经被证实是可以运行的， 但比维护 BitTorrent 要难。并且逻辑中心化使得政治去中心化更难 - 在逻辑中心化的系统中， 通过简单地同意 “自己活着和让别人活着” 来解决争论就更困难了。
Three reasons for Decentralization
去中心化的三个理由
The next question is, why is decentralization useful in the first place? There are generally several arguments raised: 第一个问题是， 去中心化为什么有用？有这么几个论点：
-
Fault tolerance— decentralized systems are less likely to fail accidentally because they rely on many separate components that are not likely.
-
容错性— 去中心化的系统不太可能意外的出错， 因为它们依赖的独立模块不容易出错。
-
Attack resistance— decentralized systems are more expensive to attack and destroy or manipulate because they lack sensitive central points that can be attacked at much lower cost than the economic size of the surrounding system.
-
抗攻击性— 去中心化的系统攻击，毁坏， 或者篡改的代价更高，因为没法低成本的攻击敏感的中心点。
-
Collusion resistance — it is much harder for participants in decentralized systems to collude to act in ways that benefit them at the expense of other participants, whereas the leaderships of corporations and governments collude in ways that benefit themselves but harm less well-coordinated citizens, customers, employees and the general public all the time.
-
抗共谋性 — 去中心化系统的参与者很难串通起来, 以牺牲其他参与者的利益为代价来采取行动, 而公司和政府的领导人则经常以利己但不伤害公民或客户的方式来共谋。
All three arguments are important and valid, but all three arguments lead to some interesting and different conclusions once you start thinking about protocol decisions with the three individual perspectives in mind. Let us try to expand out each of these arguments one by one.
这三个论点都是重要且有效的, 但一旦您开始考虑满足这三个不同方面的协议，它们都导致了一些有趣的和不同的结论。让我们试着把这些论点一个个地展开。
Regarding fault tolerance, the core argument is simple. What’s less likely to happen: one single computer failing, or five out of ten computers all failing at the same time? The principle is uncontroversial, and is used in real life in many situations, including jet engines, backup power generators particularly in places like hospitals, military infrastructure, financial portfolio diversification, and yes, computer networks.
关于容错性， 核心论点很简单。 哪种情况更可能会发生： 一台电脑出错， 还是十台电脑中的五台同时出错？ 这个原则是无可争议的，而且应用在生活中的方方面面，包括飞机发动机, 备用发电机, 特别是在医院, 军事基础设施, 金融投资组合多样化, 当然， 还有计算机网络。
However, this kind of decentralization, while still effective and highly important, often turns out to be far less of a panacea than a naive mathematical model would sometimes predict. The reason is common mode failure. Sure, four jet engines are less likely to fail than one jet engine, but what if all four engines were made in the same factory, and a fault was introduced in all four by the same rogue employee?
然而, 这种去中心化虽然有效和重要, 但往往远不及一个简单的数学模型所能预见。原因是常见失败模式。当然, 四喷气式发动机比一台喷气发动机更不容易失灵, 但是如果所有的四引擎都是在同一工厂制造的, 而且所有四个都是同一个坏员工引入的, 那该怎么办呢？
Do blockchains as they are today manage to protect against common mode failure? Not necessarily. Consider the following scenarios:
今日的区块链能防止常见的失败模式吗？ 不一定。 考虑以下场景：
-
All nodes in a blockchain run the same client software, and this client software turns out to have a bug.
-
区块链中的所有节点都运行同一个客户端软件，而这个客户端软件有一个bug。
-
All nodes in a blockchain run the same client software, and the development team of this software turns out to be socially corrupted.
-
区块链中的所有节点都运行同一个客户端软件， 而这个软件的开发团队意图不正。
-
The research team that is proposing protocol upgrades turns out to be socially corrupted.
-
研究小组提出的协议升级是邪恶的。
-
In a proof of work blockchain, 70% of miners are in the same country, and the government of this country decides to seize all mining farms for national security purposes.
-
在基于POW的区块链中， 70%的旷工来自同一个国家， 而这个国家的政府由于安全原因决定关闭矿池。
-
The majority of mining hardware is built by the same company, and this company gets bribed or coerced into implementing a backdoor that allows this hardware to be shut down at will.
-
挖矿的硬件来自于同一个公司，而这个公司在硬件里面加了后门， 可以随时关闭这个硬件。
-
In a proof of stake blockchain, 70% of the coins at stake are held at one exchange.
-
在基于POS的区块链中， 70%的代币在同一个交易所。
A holistic view of fault tolerance decentralization would look at all of these aspects, and see how they can be minimized. Some natural conclusions that arise are fairly obvious:
从整体角度来看, 去中心化的容错将着眼于所有这些方面, 并看看如何将它们降到最低。结论相当明显:
-
It is crucially important to have multiple competing implementations.
-
有多个相互竞争的实现至关重要。
-
The knowledge of the technical considerations behind protocol upgrades must be democratized, so that more people can feel comfortable participating in research discussions and criticizing protocol changes that are clearly bad.
-
对协议升级背后的技术考虑的知识必须是民主化的, 这样更多的人可以愉快的参与研究讨论，批评不好的协议的变化。
-
Core developers and researchers should be employed by multiple companies or organizations (or, alternatively, many of them can be volunteers).
-
核心开始或者研究员必须来自多个公司或者组织（或者有些可以是志愿者）。
-
Mining algorithms should be designed in a way that minimizes the risk of centralization
-
挖矿算法要避免挖矿中心化
-
Ideally we use proof of stake to move away from hardware centralization risk entirely (though we should also be cautious of new risks that pop up due to proof of stake).
-
利润上我们应该使用POS来避免硬件中心化（虽然我们也应该谨慎POS带来的贡献）。
Note that the fault tolerance requirement in its naive form focuses on architectural decentralization, but once you start thinking about fault tolerance of the community that governs the protocol’s ongoing development, then political decentralization is important too.
注意容错性的需求只是简单的要求架构去中心化， 但你一旦开始控制该协议的社区的容错性， 那政治的去中心化也是很重要的。
Now, let’s look at attack resistance. In some pure economic models, you sometimes get the result that decentralization does not even matter. If you create a protocol where the validators are guaranteed to lose $50 million if a 51% attack (ie. finality reversion) happens, then it doesn’t really matter if the validators are controlled by one company or 100 companies — $50 million economic security margin is $50 million economic security margin. In fact, there are deep game-theoretic reasons why centralization may even maximize this notion of economic security (the transaction selection model of existing blockchains reflects this insight, as transaction inclusion into blocks through miners/block proposers is actually a very rapidly rotating dictatorship).
现在, 让我们来看看抗攻击性。在一些纯粹的经济模式中, 你有时会得到去中心化不重要的结果。如果您创建了一个协议, 当51% 攻击发生时, 就会损失5000万美元, 那么, 这个程序是由一家公司或100家公司控制的就无关紧要了。 事实上, 有深层次的博弈论的原因, 为什么中心化甚至可以最大化这种经济安全的概念 (现有区块链的交易选择模型反映了这种洞察力, 因为通过矿工/区块的交易实际上是一个快速轮流的专政)。
However, once you adopt a richer economic model, and particularly one that admits the possibility of coercion (or much milder things like targeted DoS attacks against nodes), decentralization becomes more important. If you threaten one person with death, suddenly $50 million will not matter to them as much anymore. But if the $50 million is spread between ten people, then you have to threaten ten times as many people, and do it all at the same time. In general, the modern world is in many cases characterized by an attack/defense asymmetry in favor of the attacker — a building that costs $10 million to build may cost less than $100,000 to destroy, but the attacker’s leverage is often sublinear: if a building that costs $10 million to build costs $100,000 to destroy, a building that costs $1 million to build may realistically cost perhaps $30,000 to destroy. Smaller gives better ratios.
然而, 一旦你采取了更丰富的经济模式, 特别是承认可能的胁迫 (或更温和的事情, 如针对节点的 DoS 攻击), 去中心化变得更加重要。如果威胁到一个人的生命, 5000万美元将不再对他们有多大的关系。但是如果5000万美元在十人之间传播, 那么你就必须同时威胁到十倍的人。总的来说, 在许多情况下, 现代世界的特点是攻击/防御的不对称性， 更倾向于攻击者。一栋耗资1000万美元的建筑可能耗资不到10万美元就能摧毁。 但攻击者的杠杆往往是亚线性的: 如果一栋1000万美元的大楼需要耗资10万美元来摧毁, 那么耗资100万美元建造的大楼可能实际需要花费3万美元来摧毁。规模越小， 比率越高。
What does this reasoning lead to? First of all, it pushes strongly in favor of proof of stake over proof of work, as computer hardware is easy to detect, regulate, or attack, whereas coins can be much more easily hidden (proof of stake also has strong attack resistance for other reasons). Second, it is a point in favor of having widely distributed development teams, including geographic distribution. Third, it implies that both the economic model and the fault-tolerance model need to be looked at when designing consensus protocols.
这个推理会导致什么？首先, 它有力的说明了POS比POW更好, 因为计算机硬件是更容易被检测, 调节, 或攻击, 而代币可以更容易隐藏 (POS还有其他原因说明它是抗攻击的)。其次, 是拥有一个来自不同地域的分布式的开发团队。第三, 它意味着在设计协商一致协议时, 需要研究经济模型和容错模型。
Finally, we can get to perhaps the most intricate argument of the three, collusion resistance. Collusion is difficult to define; perhaps the only truly valid way to put it is to simply say that collusion is “coordination that we don’t like”. There are many situations in real life where even though having perfect coordination between everyone would be ideal, one sub-group being able to coordinate while the others cannot is dangerous.
最后, 我们来看一下三个论点中最复杂的, 抗共谋性。共谋很难定义，也许一个简单有效的说法是, 共谋是 “我们不喜欢的协调”。在现实生活中有很多情况, 即使每个人之间有完美的协调是理想的, 一个小组能够协调, 而其他小组不能协调也是危险的。
One simple example is antitrust law — deliberate regulatory barriers that get placed in order to make it more difficult for participants on one side of the marketplace to come together and act like a monopolist and get outsided profits at the expense of both the other side of the marketplace and general social welfare. Another example is rules against active coordination between candidates and super-PACs in the United States, though those have proven difficult to enforce in practice. A much smaller example is a rule in some chess tournaments preventing two players from playing many games against each other to try to raise one player’s score. No matter where you look, attempts to prevent undesired coordination in sophisticated institutions are everywhere.
一个简单的例子就是反垄断法–故意设置的监管壁垒, 为了使市场上的参与者更难勾结起来, 像垄断者一样行事, 并以牺牲其他人的利益为代价获得超额的利润。另一个例子是反对在美国的候选人和超级 PACs 之间的积极协调的规则, 尽管那些已经证明在实践中很难实施。一个更小的例子是一些国际象棋锦标赛中的一个规则, 防止两个玩家互相打很多比赛来提高得分。无论你看哪个领域, 你会发现防止共同作弊的机制无处不在。
In the case of blockchain protocols, the mathematical and economic reasoning behind the safety of the consensus often relies crucially on the uncoordinated choice model, or the assumption that the game consists of many small actors that make decisions independently. If any one actor gets more than 1/3 of the mining power in a proof of work system, they can gain outsized profits by selfish-mining. However, can we really say that the uncoordinated choice model is realistic when 90% of the Bitcoin network’s mining power is well-coordinated enough to show up together at the same conference?
在区块链协议方面, 共识安全背后的数学和经济推理往往依赖于不协调的选择模型, 或者假设这个游戏由许多小参与者组成, 它们各自做出独立的决定.如果任何一个参与者在POW中获得超过1/3 的采矿权, 他们可以通过自私的采矿获得超额利润。然而, 我们真的可以说, 当90% 的比特币网络的旷工同时出现在一个会议上, 他们的选择是一致的吗？
Blockchain advocates also make the point that blockchains are more secure to build on because they can’t just change their rules arbitrarily on a whim whenever they want to, but this case would be difficult to defend if the developers of the software and protocol were all working for one company, were part of one family and sat in one room. The whole point is that these systems should not act like self-interested unitary monopolies. Hence, you can certainly make a case that blockchains would be more secure if they were more discoordinated.
区块链的拥护者还指出, 区块链软件更安全, 因为它们不能被随意改变， 除非软件和协议的开发者来自同一家公司, 一个家庭, 或坐在同一个房间。总体而言， 系统不应该被垄断。因此你可以肯定, 如果区块链不被协同控制， 它们将更安全。
However, this presents a fundamental paradox. Many communities, including Ethereum’s, are often praised for having a strong community spirit and being able to coordinate quickly on implementing, releasing and activating a hard fork to fix denial-of-service issues in the protocol within six days. But how can we foster and improve this good kind of coordination, but at the same time prevent “bad coordination” that consists of miners trying to screw everyone else over by repeatedly coordinating 51% attacks?
然而，这是一个根本的悖论。 许多社区，包括以太坊社区，经常被称赞是为了具有强大的社区精神，并能够在六天内迅速协调实施，发布和激活硬分叉来解决协议中的拒绝服务问题。 但是我们如何能够促进和改善这种好协调，同时防止矿工们通过反复协调51％的攻击力量来扭转其他人的“坏协调”？
There are three ways to answer this:
有三种方法来回答这个问题：
-
Don’t bother mitigating undesired coordination; instead, try to build protocols that can resist it.
-
不要费心缓和不受欢迎的协调;相反, 尝试构建能够抵御它的协议。
-
Try to find a happy medium that allows enough coordination for a protocol to evolve and move forward, but not enough to enable attacks.
-
试着找到一个好的媒介, 让一个协议有足够的协调来进化和向前迈进, 但不足以被攻击。
-
Try to make a distinction between beneficial coordination and harmful coordination, and make the former easier and the latter harder.
-
试着区分有益的协调和有害的协调, 使前者更容易, 后者更难。
The first approach makes up a large part of the Casper design philosophy. However, it by itself is insufficient, as relying on economics alone fails to deal with the other two categories of concerns about decentralization. The second is difficult to engineer explicitly, especially for the long term, but it does often happen accidentally. For example, the fact that bitcoin’s core developers generally speak English but miners generally speak Chinese can be viewed as a happy accident, as it creates a kind of “bicameral” governance that makes coordination more difficult, with the side benefit of reducing the risk of common mode failure, as the English and Chinese communities will reason at least somewhat separately due to distance and communication difficulties and are therefore less likely to both make the same mistake.
第一种方法构成了Casper设计哲学的一大部分。然而, 它本身并不充分, 因为依靠经济本身不能处理其他两类关于去中心化的问题。第二个是很难明确的工程，特别是长期的，但它经常发生意外。例如, 比特币的核心开发者通常会说英语, 但矿工一般会说中文, 这是一个幸福的意外, 因为它创造了一种 “两院制” 的治理, 使得协调更加困难, 其好处在于减少共同模式失败的风险, 因为由于距离和沟通的困难, 英语和华人社区至少会有理由分开, 因此不太可能犯同样的错误。
The third is a social challenge more than anything else; solutions in this regard may include:
第三个是社会挑战, 而不是其他任何东西;这方面的解决办法可能包括:
Social interventions that try to increase participants’ loyalty to the community around the blockchain as a whole and substitute or discourage the possibility of the players on one side of a market becoming directly loyal to each other. 社会干预会试图提高参与者对整个区块链社区的忠诚度, 并替代或劝阻市场一方的参与者终于另一方。
Promoting communication between different “sides of the market” in the same context, so as to reduce the possibility that either validators or developers or miners begin to see themselves as a “class” that must coordinate to defend their interests against other classes.
在同一背景下促进不同“市场角色”之间的沟通，以减少验证者，开发者或矿工开始认为自己是“不同角色”的可能性，这种“角色”必须协调捍卫自己与其他角色的利益。
Designing the protocol in such a way as to reduce the incentive for validators/miners to engage in one-to-one “special relationships”, centralized relay networks and other similar super-protocol mechanisms.
设计协议时要考虑减少由于验证者/矿工从事一对一“特殊关系”，集中式中继网络和其他类似超协议机制的产生激励。
Clear norms about what the fundamental properties that the protocol is supposed to have, and what kinds of things should not be done, or at least should be done only under very extreme circumstances.
协议应该明确规定它具有的基本属性以及不应该做什么样的事情，和在极端情况才能做的事情。
This third kind of decentralization, decentralization as undesired-coordination-avoidance, is thus perhaps the most difficult to achieve, and tradeoffs are unavoidable. Perhaps the best solution may be to rely heavily on the one group that is guaranteed to be fairly decentralized: the protocol’s users.
这第三种去中心化， 避免有害协调，也最难达到，权衡是不可避免的。也许最好的解决方案可能是, 依赖一个保证相当分散的群体: 协议的用户。
区块链中文字幕组
致力于前沿区块链知识和信息的传播，为中国融入全球区块链世界贡献一份力量。
如果您懂一些技术、懂一些英文，欢迎加入我们，加微信号:w1791520555。
本文译者简介
小丹 区块链技术爱好者 热衷于区块链底层技术研究 ， 欢迎加微信号 zhuangjun0606
本文由币乎社区（bihu.com）内容支持计划赞助。
版权所有，转载需完整注明以上内容。


Character Voice in James Joyce's Ulysses
Jonathan Reeve
Literary Modeling and Visualization Lab
Columbia University
The Questions
- How does Joyce distinguish his characters in Ulysses through their speech?
- What do Joyce's characters talk about? What are their preoccupations?
- Which of Joyce's characters are stylistically similar? Semantically?
- What can a statistical analysis tell us that we don't already know?
Defining "Speech"
- Not thought or interior monologue
- Anything with a dialogue dash
- Excludes alternate forms of dialogue in Circe, Ithaca, Penelope (for now)
- (Sorry, Molly!)
Mining Structured Data
- Uses the open-source critical edition of Ulysses, written in TEI XML
- TEI XML: Text Encoding Initiative eXtensible Markup Language
"He held the bowl aloft and intoned:
—Introibo ad altare Dei."
Who is "he"? Who is speaking?
He held the bowl aloft and intoned:
<said who="Buck Mulligan">
―<quote xml:lang="la">Introibo ad altare Dei.</quote>
</said>
(This is from the open-source TEI XML edition.)
Stylistic Analysis
- TF/IDF of 500 most frequent words
- Dimensionality reduction using Principal Component Analysis
- Shows stylistic similarity
Semantic Analysis
- Uses Stanford GloVe word vectors (pre-trained word collocation models)
- Computes semantic document similarity using cosine similarity
Most Distinguishing Words of Characters
- Compute the distance, in standard deviations, from the mean of each word frequency, by character
- Tabulate words more than 2.5 standard deviations from the mean frequencies
Buck Mulligan
absurd, beastly, because, dedalus, etiquette, gentleman, jesuit, kinch, knows, mockery, mother, must, only, sea, thinks
Stephen Dedalus
black, brawn, dark, deasy, fear, from, mine, servant, sir, thank, three, understand
Leopold Bloom
awfully, councillor, coy, excuse, fact, idea, just, keep, keyes, keys, metempsychosis, part, pussens, run, wants
Simon Dedalus
back, ben, blessed, child, christ, dick, died, glass, hold, little, looked, man, many, ned, poor, simple, stand, straight, whatever, wouldn
Joe Hynes
again, alf, ay, citizen, field, terry, truth
Professor MacHugh
fitzgibbon, heard, lord, loyal, shore, speech, taylor, words
Myles Crawford
bite, bushe, forget, gallaher, gumley, in, mouth, murder, north, ohio, place, press, psha, right, time, took, twas, where
John Eglinton
believes, family, feel, genius, hamlet, has, hear, seven, shakespeare, shall, should, therefore, true
The Citizen
fein, fish, flint, half, our, save
Readability
- Automated Readability Index (ARI)
- US grade level needed to understand a character's speech.
- Calculates readability using characters per word and words per sentence.
Topic Modeling
- Uses non-negative matrix factorization (not LDA)
- Term weighting with TF-IDF


Try out AudioChess!


|
900
|
Housekeeping, 098 Lecture Theatre (260-098)
|
|
910
|
Could Do Better … A Report Card For Statistical Computing Ross Ihaka, University of Auckland 098 Lecture Theatre (260-098)
|
|
1000
|
Morning Tea (30 minutes)
|
|
|
|
1030
|
R&D Policy Regimes In France: New Evidence From A Spatio-Temporal Analysis Benjamin Montmartin
|
Analysing Scientific Collaborations Of New Zealand Institutions Using Scopus Bibliometric Data Samin Aref
|
Family Structure And Academic Achievements Of High School Students In Tonga Losana Vao Latu Latu
|
Analysis Of Multivariate Binary Longitudinal Data: Metabolic Syndrome During Menopausal Transition Geoff Jones
|
Clustering Of Curves On A Spatial Domain Using A Bayesian Partitioning Model Chae Young Lim
|
The Uncomfortable Entrepreneurs: Bad Working Conditions And Entrepreneurial Commitment Catherine Laffineur
|
|
1050
|
Spatial Surveillance With Scan Statistics By Controlling The False Discovery Rate Xun Xiao
|
Statistical Models For The Source Attribution Of Zoonotic Diseases: A Study Of Campylobacteriosis Sih-Jing Liao
|
Towards An Informal Test For Goodness-Of-Fit Anna Fergusson
|
Identifying Clusters Of Patients With Diabetes Using A Markov Birth-Death Process Mugdha Manda
|
Bayesian Temporal Density Estimation Using Autoregressive Species Sampling Models Seongil Jo
|
How Does The Textile Set Describe Geometric Structures Of Data? Ushio Tanaka
|
|
1110
|
Intensity Estimation Of Spatial Point Processes Based On Area-Aggregated Data Hsin-Cheng Huang
|
Bayesian Inference For Population Attributable Measures Sarah Pirikahu
|
An Information Criterion For Prediction With Auxiliary Variables Under Covariate Shift Takahiro Ido
|
Analysis Of A Brief Telephone Intervention For Problem Gambling And Examining The Impact On Co-Existing Depression? Nick Garrett
|
Prior-Based Bayesian Information Criterion Woncheol Jang
|
Early Childhood Dental Decay Sarah Sonal
|
|
1130
|
Geographically Weighted Principal Component Analysis For Spatio-Temporal Statistical Dataset Narumasa Tsutsumida
|
Dimensionality Reduction Of Multivariate Data For Bayesian Analysis Anjali Gupta
|
An EWMA Chart For Monitoring Covariance Matrix Based On Dissimilarity Index Longcheen Huwang
|
Adjusting For Linkage Bias In The Analysis Of Record-Linked Data Patrick Graham
|
Bayesian Semiparametric Hierarchical Models For Longitudinal Data Analysis With Application To Dose-Response Studies Taeryon Choi
|
Optimizing Junior Rugby Weight Limits Ankit Patel
|
|
1150
|
Spatial Scan Statistics For Matched Case-Control Data Inkyung Jung
|
Whitebait In All Its Varieties: One Fish, Two Fish, Three, Four, Five Fish. Bridget Armstrong
|
Latent Variable Models And Multivariate Binomial Data John Holmes
|
Asking About Sex In General Health Surveys: Comparing The Methods And Findings Of The 2010 Health Survey For England With Those Of The Third National Survey Of Sexual Attitudes And Lifestyles Philip Prah
|
Bayesian Continuous Space-Time Model Of Burglaries Paul Brown
|
Tolerance Limits For The Reliability Of Semiconductor Devices Using Longitudinal Data Thomas Nowak
|
|
1210
|
Lunch (1 hour 10 minutes)
|
|
1320
|
Session In Memory Of Alastair John Scott 1320hrs-1530hrs Speakers: Professor John Neuhaus (UCSF), Professor Chris Wild, Professor Alan Lee, Professor Thomas Lumley
|
|
1530
|
Afternoon tea (30 minutes)
|
|
|
|
1600
|
Model-Checking For Regressions: A Local Smoothing-Based Global Smoothing Test Lingzhu Li
|
Breeding Value Estimation In Partially-Genotyped Populations Alastair Lamont
|
BIVAS: A Scalable Bayesian Method For Bi-Level Variable Selection Mingxuan Cai
|
Ranking Potential Shoplifters In Real Time Barry McDonald
|
Two Stage Approach To Data-Driven Subgroup Identification In Clinical Trials Toshio Shimokawa
|
|
|
1620
|
Inverse Regression For Multivariate Functional Data Ci-Ren Jiang
|
Including Covariate Estimation Error When Predicting Species Distributions: A Simulation Exercise Using Template Model Builder Andrea Havron
|
Adjusted Adaptive Index Model For Binary Response Ke Wan
|
Factors Influencing On Growth Of Garments Industry In Bangladesh Md. Shahidul Islam
|
Comparison Of Exact And Approximate Testing Procedures In Clinical Trials With Multiple Binary Endpoints Takuma Ishihara
|
|
|
1640
|
Multiple Function-On-Function Linear Regression With Application To Weather Forecast Calibration Lu-Hung Chen
|
Modelling The Distribution Of Lifetime Using Compound Time-Homogenous Poisson Process Kien Tran
|
Detecting Change-Points In The Stress-Strength Reliability P(X<Y) Hang Xu
|
New Zealand Crime And Victims Survey: Filling The Knowledge Gap Tianying Chu
|
Missing Data In Randomised Control Trials: Stepped Multiple Imputation Rose Sisk
|
|
|
1700
|
|
NZSA Annual General Meeting 1700 - 1815
|
IASC General Assembly 1700-1815
|
|
|
|
|
1830
|
Conference Dinner Owen G Glenn Building Foyer Level 1, 20 Grafton Road 1830-2230
|


Install all of the following programs to the Tools folder in your Fallout New Vegas Modding Folder unless instructed otherwise
Special install instructions:
- Required libraries for FNV and the 4GB Patcher
Special install instructions:
- Required libraries for the mod manager for this guide, Mod Organizer 2 and NVGE
Special install instructions:
- By far the best mod manager for all Bethesda games, takes advantage of a Virtual File System to keep your Data folder completely clean
Join the Mod Organizer 2 team's
Discord
for developer builds (please don't go to their Discord and ask for troubleshooting with my guide! That's what my Discord is for)
Links to developer versions of the tools listed in this section will be provided, but the instructions in the guide are specifically written for the public release verisons. I suggest only using the developer versions if you are familiar with the tools and can work out any discrepancies with the instructions in the guide.
Special install instructions:
- Adds two new features to MO2, the ability to hide plugins that have been merged and the ability to sync profile mod orders with one another
For when a new version of Mod Organizer 2 is released:
Install normally
- Advanced file viewer/editor and conflict detector. More commonly referred to as 'xEdit'
Join the xEdit team's
Discord
for developer builds
For a good tutorial (shouldn't be necessary if you are just following this guide, but if you want to learn more for yourself), see here
Install normally
- Frontend tool similar to xEdit, will only be used in the guide to merge plugins
Check the linked Github page for new releases
Install normally
- One-click LOD generator
Developer builds can be found on the same Discord as xEdit
Special install instructions:
- Tool that allows you to create/edit any data from the game
For a good tutorial resource (shouldn't be necessary if you are just following this guide, but if you want to learn more for yourself), see here
Special install instructions:
- Decompresses BSAs and repacks them without zlib compression and fixes certain audio files that would not play in vanilla
NOTE: Verifying your game files through either Steam or GOG will undo the Decompressor's effects, so you must rerun it after
If at any point during gameplay you encounter a lot of missing mesh errors (big red triangles), do the following:
Special install instructions:
- Latest compiled Ogg Vorbis Libraries that allow the game to play certain .ogg files it wouldn't be able to play otherwise


This document describes design decisions that went into implementing Open vSwitch. While we believe these to be reasonable decisions, it is impossible to predict how Open vSwitch will be used in all environments. Understanding assumptions made by Open vSwitch is critical to a successful deployment. The end of this document contains contact information that can be used to let us know how we can make Open vSwitch more generally useful.
Over time, Open vSwitch has added many knobs that control whether a given controller receives OpenFlow asynchronous messages. This section describes how all of these features interact.
First, a service controller never receives any asynchronous messages unless it changes its miss_send_len from the service controller default of zero in one of the following ways:
Second, OFPT_FLOW_REMOVED and NXT_FLOW_REMOVED messages are generated only if the flow that was removed had the OFPFF_SEND_FLOW_REM flag set.
Third, OFPT_PACKET_IN and NXT_PACKET_IN messages are sent only to OpenFlow controller connections that have the correct connection ID (see struct nx_controller_id and struct nx_action_controller):
Finally, Open vSwitch consults a per-connection table indexed by the message type, reason code, and current role. The following table shows how this table is initialized by default when an OpenFlow connection is made. An entry labeled yes means that the message is sent, an entry labeled --- means that the message is suppressed.
| message and reason code | other | slave |
|---|---|---|
| OFPR_NO_MATCH | yes | --- |
| OFPR_ACTION | yes | --- |
| OFPR_INVALID_TTL | --- | --- |
| OFPR_ACTION_SET (OF1.4+) | yes | --- |
| OFPR_GROUP (OF1.4+) | yes | --- |
| message and reason code | other | slave |
|---|---|---|
| OFPRR_IDLE_TIMEOUT | yes | --- |
| OFPRR_HARD_TIMEOUT | yes | --- |
| OFPRR_DELETE | yes | --- |
| OFPRR_GROUP_DELETE (OF1.4+) | yes | --- |
| OFPRR_METER_DELETE (OF1.4+) | yes | --- |
| OFPRR_EVICTION (OF1.4+) | yes | --- |
| message and reason code | other | slave |
|---|---|---|
| OFPPR_ADD | yes | yes |
| OFPPR_DELETE | yes | yes |
| OFPPR_MODIFY | yes | yes |
| message and reason code | other | slave |
|---|---|---|
| OFPCRR_MASTER_REQUEST | --- | --- |
| OFPCRR_CONFIG | --- | --- |
| OFPCRR_EXPERIMENTER | --- | --- |
| message and reason code | other | slave |
|---|---|---|
| OFPTR_VACANCY_DOWN | --- | --- |
| OFPTR_VACANCY_UP | --- | --- |
| message and reason code | other | slave |
|---|---|---|
| OFPRFR_GROUP_MOD | --- | --- |
| OFPRFR_METER_MOD | --- | --- |
The NXT_SET_ASYNC_CONFIG message directly sets all of the values in this table for the current connection. The OFPC_INVALID_TTL_TO_CONTROLLER bit in the OFPT_SET_CONFIG message controls the setting for OFPR_INVALID_TTL for the "master" role.
The OpenFlow 1.0 specification requires the output port of the OFPAT_ENQUEUE action to "refer to a valid physical port (i.e. < OFPP_MAX) or OFPP_IN_PORT". Although OFPP_LOCAL is not less than OFPP_MAX, it is an 'internal' port which can have QoS applied to it in Linux. Since we allow the OFPAT_ENQUEUE to apply to 'internal' ports whose port numbers are less than OFPP_MAX, we interpret OFPP_LOCAL as a physical port and support OFPAT_ENQUEUE on it as well.
The OpenFlow specification for the behavior of OFPT_FLOW_MOD is confusing. The following tables summarize the Open vSwitch implementation of its behavior in the following categories:
An entry labeled yes means that the flow mod type does have the indicated behavior, --- means that it does not, an empty cell means that the property is not applicable, and other values are explained below the table.
| RULE | ADD | MODIFY | STRICT | DELETE | STRICT |
|---|---|---|---|---|---|
| match on priority | yes | --- | yes | --- | yes |
| match on out_port | --- | --- | --- | yes | yes |
| match on flow_cookie | --- | --- | --- | --- | --- |
| match on table_id | --- | --- | --- | --- | --- |
| controller chooses table_id | --- | --- | --- | ||
| updates flow_cookie | yes | yes | yes | ||
| updates OFPFF_SEND_FLOW_REM | yes | ||||
| honors OFPFF_CHECK_OVERLAP | yes | ||||
| updates idle_timeout | yes | ||||
| updates hard_timeout | yes | ||||
| resets idle timer | yes | ||||
| resets hard timer | yes | yes | yes | ||
| zeros counters | yes | ||||
| may add a new flow | yes | yes | yes | ||
| sends flow_removed message | --- | --- | --- | % | % |
where:
OpenFlow 1.1 makes these changes:
| RULE | ADD | MODIFY | STRICT | DELETE | STRICT |
|---|---|---|---|---|---|
| match on priority | yes | --- | yes | --- | yes |
| match on out_port | --- | --- | --- | yes | yes |
| match on flow_cookie | --- | yes | yes | yes | yes |
| match on table_id | yes | yes | yes | yes | yes |
| controller chooses table_id | yes | yes | yes | ||
| updates flow_cookie | yes | --- | --- | ||
| updates OFPFF_SEND_FLOW_REM | yes | ||||
| honors OFPFF_CHECK_OVERLAP | yes | ||||
| updates idle_timeout | yes | ||||
| updates hard_timeout | yes | ||||
| resets idle timer | yes | ||||
| resets hard timer | yes | yes | yes | ||
| zeros counters | yes | ||||
| may add a new flow | yes | # | # | ||
| sends flow_removed message | --- | --- | --- | % | % |
where:
OpenFlow 1.2 makes these changes:
| RULE | ADD | MODIFY | STRICT | DELETE | STRICT |
|---|---|---|---|---|---|
| match on priority | yes | --- | yes | --- | yes |
| match on out_port | --- | --- | --- | yes | yes |
| match on flow_cookie | --- | yes | yes | yes | yes |
| match on table_id | yes | yes | yes | yes | yes |
| controller chooses table_id | yes | yes | yes | ||
| updates flow_cookie | yes | --- | --- | ||
| updates OFPFF_SEND_FLOW_REM | yes | --- | --- | ||
| honors OFPFF_CHECK_OVERLAP | yes | --- | --- | ||
| updates idle_timeout | yes | --- | --- | ||
| updates hard_timeout | yes | --- | --- | ||
| resets idle timer | yes | --- | --- | ||
| resets hard timer | yes | yes | yes | ||
| zeros counters | yes | & | & | ||
| may add a new flow | yes | --- | --- | ||
| sends flow_removed message | --- | --- | --- | % | % |
OpenFlow 1.3 makes these changes:
The table for 1.3 is the same as the one shown above for 1.2.
OpenFlow 1.4 makes these changes:
Open vSwitch makes all flow table modifications atomically, i.e., any datapath packet only sees flow table configurations either before or after any change made by any flow_mod. For example, if a controller removes all flows with a single OpenFlow flow_mod, no packet sees an intermediate version of the OpenFlow pipeline where only some of the flows have been deleted.
It should be noted that Open vSwitch caches datapath flows, and that the cached flows are NOT flushed immediately when a flow table changes. Instead, the datapath flows are revalidated against the new flow table as soon as possible, and usually within one second of the modification. This design amortizes the cost of datapath cache flushing across multiple flow table changes, and has a significant performance effect during simultaneous heavy flow table churn and high traffic load. This means that different cached datapath flows may have been computed based on a different flow table configurations, but each of the datapath flows is guaranteed to have been computed over a coherent view of the flow tables, as described above.
With OpenFlow 1.4 bundles this atomicity can be extended across an arbitrary set of flow_mod. Bundles are supported for flow_mod and port_mod messages only. For flow_mod, both atomic and ordered bundle flags are trivially supported, as all bundled messages are executed in the order they were added and all flow table modifications are now atomic to the datapath. Port mods may not appear in atomic bundles, as port status modifications are not atomic.
To support bundles, ovs-ofctl has a --bundle option that makes the flow mod commands (add-flow, add-flows, mod-flows, del-flows, and replace-flows) use an OpenFlow 1.4 bundle to operate the modifications as a single atomic transaction. If any of the flow mods in a transaction fail, none of them are executed. All flow mods in a bundle appear to datapath lookups simultaneously.
Furthermore, ovs-ofctl add-flow and add-flows commands now accept arbitrary flow mods as an input by allowing the flow specification to start with an explicit add, modify, modify_strict, delete, or delete_strict keyword. A missing keyword is treated as add, so this is fully backwards compatible. With the new --bundle option all the flow mods are executed as a single atomic transaction using an OpenFlow 1.4 bundle. Without the --bundle option the flow mods are executed in order up to the first failing flow_mod, and in case of an error the earlier successful flow_mod calls are not rolled back.
The OpenFlow 1.1 specification for OFPT_PACKET_IN is confusing. The definition in OF1.1 openflow.h is[*]:
/* Packet received on port (datapath -> controller). */ struct ofp_packet_in { struct ofp_header header; uint32_t buffer_id; /* ID assigned by datapath. */ uint32_t in_port; /* Port on which frame was received. */ uint32_t in_phy_port; /* Physical Port on which frame was received. */ uint16_t total_len; /* Full length of frame. */ uint8_t reason; /* Reason packet is being sent (one of OFPR_*) */ uint8_t table_id; /* ID of the table that was looked up */ uint8_t data[0]; /* Ethernet frame, halfway through 32-bit word, so the IP header is 32-bit aligned. The amount of data is inferred from the length field in the header. Because of padding, offsetof(struct ofp_packet_in, data) == sizeof(struct ofp_packet_in) - 2. */ }; OFP_ASSERT(sizeof(struct ofp_packet_in) == 24);
The confusing part is the comment on the data[] member. This comment is a leftover from OF1.0 openflow.h, in which the comment was correct: sizeof(struct ofp_packet_in) is 20 in OF1.0 and ffsetof(struct ofp_packet_in, data) is 18. When OF1.1 was written, the structure members were changed but the comment was carelessly not updated, and the comment became wrong: sizeof(struct ofp_packet_in) and offsetof(struct ofp_packet_in, data) are both 24 in OF1.1.
That leaves the question of how to implement ofp_packet_in in OF1.1. The OpenFlow reference implementation for OF1.1 does not include any padding, that is, the first byte of the encapsulated frame immediately follows the table_id member without a gap. Open vSwitch therefore implements it the same way for compatibility.
For an earlier discussion, please see the thread archived at: https://mailman.stanford.edu/pipermail/openflow-discuss/2011-August/002604.html
[*] The quoted definition is directly from OF1.1. Definitions used inside OVS omit the 8-byte ofp_header members, so the sizes in this discussion are 8 bytes larger than those declared in OVS header files.
The 802.1Q VLAN header causes more trouble than any other 4 bytes in networking. More specifically, three versions of OpenFlow and Open vSwitch have among them four different ways to match the contents and presence of the VLAN header. The following table describes how each version works.
| Match | NXM | OF1.0 | OF1.1 | OF1.2 |
|---|---|---|---|---|
| [1] | 0000/0000 | ????/1,??/? | ????/1,??/? | 0000/0000,-- |
| [2] | 0000/ffff | ffff/0,??/? | ffff/0,??/? | 0000/ffff,-- |
| [3] | 1xxx/1fff | 0xxx/0,??/1 | 0xxx/0,??/1 | 1xxx/ffff,-- |
| [4] | z000/f000 | ????/1,0y/0 | fffe/0,0y/0 | 1000/1000,0y |
| [5] | zxxx/ffff | 0xxx/0,0y/0 | 0xxx/0,0y/0 | 1xxx/ffff,0y |
| [6] | 0000/0fff | <none> | <none> | <none> |
| [7] | 0000/f000 | <none> | <none> | <none> |
| [8] | 0000/efff | <none> | <none> | <none> |
| [9] | 1001/1001 | <none> | <none> | 1001/1001,-- |
| [10] | 3000/3000 | <none> | <none> | <none> |
| [11] | 1000/1000 | <none> | fffe/0,??/1 | 1000/1000,-- |
where:
The matches are:
Matches only packets without an 802.1Q header.
Matches only packets that have an 802.1Q header with PCP y (and any VID).
Matches only packets that have an 802.1Q header with VID xxx and PCP y.
- NXM:
- z is ((y << 1) | 1).
- OF1.2:
- Presumably other masks such that (vlan_vid_mask & 0x1fff) == 0x1fff would also work.
Additional notes:
OpenFlow 1.0 and later versions have the concept of a "flow cookie", which is a 64-bit integer value attached to each flow. The treatment of the flow cookie has varied greatly across OpenFlow versions, however.
In OpenFlow 1.0:
OpenFlow 1.1 made the following changes:
OpenFlow 1.2 made the following changes:
Open vSwitch support for OpenFlow 1.0 implements the OpenFlow 1.0 behavior with the following extensions:
The following table shows the handling of different protocols when receiving OFPFC_MODIFY and OFPFC_MODIFY_STRICT messages. A mask of 0 indicates either an explicit mask of zero or an implicit one by not specifying the NXM_NX_COOKIE(_W) field.
| OpenFlow 1.0 | no | yes | (add on miss) | (add on miss) |
| OpenFlow 1.1 | yes | no | no | yes |
| OpenFlow 1.2 | yes | no | no | no |
| NXM | yes | yes* | no | yes |
* Updates the flow's cookie unless the cookie field is UINT64_MAX.
OpenFlow 1.0 has only rudimentary support for multiple flow tables. Notably, OpenFlow 1.0 does not allow the controller to specify the flow table to which a flow is to be added. Open vSwitch adds an extension for this purpose, which is enabled on a per-OpenFlow connection basis using the NXT_FLOW_MOD_TABLE_ID message. When the extension is enabled, the upper 8 bits of the command member in an OFPT_FLOW_MOD or NXT_FLOW_MOD message designates the table to which a flow is to be added.
The Open vSwitch software switch implementation offers 255 flow tables. On packet ingress, only the first flow table (table 0) is searched, and the contents of the remaining tables are not considered in any way. Tables other than table 0 only come into play when an NXAST_RESUBMIT_TABLE action specifies another table to search.
Tables 128 and above are reserved for use by the switch itself. Controllers should use only tables 0 through 127.
This section covers the history of the OFPTC_* table configuration bits across OpenFlow versions.
OpenFlow 1.0 flow tables had fixed configurations.
OpenFlow 1.1 enabled controllers to configure behavior upon flow table miss and added the OFPTC_MISS_* constants for that purpose. OFPTC_* did not control anything else but it was nevertheless conceptualized as a set of bit-fields instead of an enum. OF1.1 added the OFPT_TABLE_MOD message to set OFPTC_MISS_* for a flow table and added the config field to the OFPST_TABLE reply to report the current setting.
OpenFlow 1.2 did not change anything in this regard.
OpenFlow 1.3 switched to another means to changing flow table miss behavior and deprecated OFPTC_MISS_* without adding any more OFPTC_* constants. This meant that OFPT_TABLE_MOD now had no purpose at all, but OF1.3 kept it around "for backward compatibility with older and newer versions of the specification." At the same time, OF1.3 introduced a new message OFPMP_TABLE_FEATURES that included a field config documented as reporting the OFPTC_* values set with OFPT_TABLE_MOD; of course this served no real purpose because no OFPTC_* values are defined. OF1.3 did remove the OFPTC_* field from OFPMP_TABLE (previously named OFPST_TABLE).
OpenFlow 1.4 defined two new OFPTC_* constants, OFPTC_EVICTION and OFPTC_VACANCY_EVENTS, using bits that did not overlap with OFPTC_MISS_* even though those bits had not been defined since OF1.2. OFPT_TABLE_MOD still controlled these settings. The field for OFPTC_* values in OFPMP_TABLE_FEATURES was renamed from config to capabilities and documented as reporting the flags that are supported in a OFPT_TABLE_MOD message. The OFPMP_TABLE_DESC message newly added in OF1.4 reported the OFPTC_* setting.
OpenFlow 1.5 did not change anything in this regard.
| OpenFlow | OFPTC_* flags | TABLE_MOD | Statistics | TABLE_FEATURES | TABLE_DESC |
|---|---|---|---|---|---|
| OF1.0 | none | no (*)(+) | no (*) | nothing (*)(+) | no (*)(+) |
| OF1.1/1.2 | MISS_* | yes | yes | nothing (+) | no (+) |
| OF1.3 | none | yes (*) | no (*) | config (*) | no (*)(+) |
| OF1.4/1.5 | EVICTION/VACANCY_EVENTS | yes | no | capabilities | yes |
where:
(*): Nothing to report/change anyway.
(+): No such message.
Open vSwitch supports stateless handling of IPv6 packets. Flows can be written to support matching TCP, UDP, and ICMPv6 headers within an IPv6 packet. Deeper matching of some Neighbor Discovery messages is also supported.
IPv6 was not designed to interact well with middle-boxes. This, combined with Open vSwitch's stateless nature, have affected the processing of IPv6 traffic, which is detailed below.
The base IPv6 header is incredibly simple with the intention of only containing information relevant for routing packets between two endpoints. IPv6 relies heavily on the use of extension headers to provide any other functionality. Unfortunately, the extension headers were designed in such a way that it is impossible to move to the next header (including the layer-4 payload) unless the current header is understood.
Open vSwitch will process the following extension headers and continue to the next header:
When a header is encountered that is not in that list, it is considered "terminal". A terminal header's IPv6 protocol value is stored in nw_proto for matching purposes. If a terminal header is TCP, UDP, or ICMPv6, the packet will be further processed in an attempt to extract layer-4 information.
IPv6 requires that every link in the internet have an MTU of 1280 octets or greater (RFC 2460). As such, a terminal header (as described above in "Extension Headers") in the first fragment should generally be reachable. In this case, the terminal header's IPv6 protocol type is stored in the nw_proto field for matching purposes. If a terminal header cannot be found in the first fragment (one with a fragment offset of zero), the nw_proto field is set to 0. Subsequent fragments (those with a non-zero fragment offset) have the nw_proto field set to the IPv6 protocol type for fragments (44).
An IPv6 jumbogram (RFC 2675) is a packet containing a payload longer than 65,535 octets. A jumbogram is only relevant in subnets with a link MTU greater than 65,575 octets, and are not required to be supported on nodes that do not connect to link with such large MTUs. Currently, Open vSwitch doesn't process jumbograms.
An OpenFlow switch must establish and maintain a TCP network connection to its controller. There are two basic ways to categorize the network that this connection traverses: either it is completely separate from the one that the switch is otherwise controlling, or its path may overlap the network that the switch controls. We call the former case "out-of-band control", the latter case "in-band control".
Out-of-band control has the following benefits:
In-band control, on the other hand, has the following advantages:
Open vSwitch supports both out-of-band and in-band control. This section describes the principles behind in-band control. See the description of the Controller table in ovs-vswitchd.conf.db(5) to configure OVS for in-band control.
The fundamental principle of in-band control is that an OpenFlow switch must recognize and switch control traffic without involving the OpenFlow controller. All the details of implementing in-band control are special cases of this principle.
The rationale for this principle is simple. If the switch does not handle in-band control traffic itself, then it will be caught in a contradiction: it must contact the controller, but it cannot, because only the controller can set up the flows that are needed to contact the controller.
The following points describe important special cases of this principle.
In-band control must be implemented regardless of whether the switch is connected.
It is tempting to implement the in-band control rules only when the switch is not connected to the controller, using the reasoning that the controller should have complete control once it has established a connection with the switch.
This does not work in practice. Consider the case where the switch is connected to the controller. Occasionally it can happen that the controller forgets or otherwise needs to obtain the MAC address of the switch. To do so, the controller sends a broadcast ARP request. A switch that implements the in-band control rules only when it is disconnected will then send an OFPT_PACKET_IN message up to the controller. The controller will be unable to respond, because it does not know the MAC address of the switch. This is a deadlock situation that can only be resolved by the switch noticing that its connection to the controller has hung and reconnecting.
In-band control must override flows set up by the controller.
It is reasonable to assume that flows set up by the OpenFlow controller should take precedence over in-band control, on the basis that the controller should be in charge of the switch.
Again, this does not work in practice. Reasonable controller implementations may set up a "last resort" fallback rule that wildcards every field and, e.g., sends it up to the controller or discards it. If a controller does that, then it will isolate itself from the switch.
The switch must recognize all control traffic.
The fundamental principle of in-band control states, in part, that a switch must recognize control traffic without involving the OpenFlow controller. More specifically, the switch must recognize all control traffic. "False negatives", that is, packets that constitute control traffic but that the switch does not recognize as control traffic, lead to control traffic storms.
Consider an OpenFlow switch that only recognizes control packets sent to or from that switch. Now suppose that two switches of this type, named A and B, are connected to ports on an Ethernet hub (not a switch) and that an OpenFlow controller is connected to a third hub port. In this setup, control traffic sent by switch A will be seen by switch B, which will send it to the controller as part of an OFPT_PACKET_IN message. Switch A will then see the OFPT_PACKET_IN message's packet, re-encapsulate it in another OFPT_PACKET_IN, and send it to the controller. Switch B will then see that OFPT_PACKET_IN, and so on in an infinite loop.
Incidentally, the consequences of "false positives", where packets that are not control traffic are nevertheless recognized as control traffic, are much less severe. The controller will not be able to control their behavior, but the network will remain in working order. False positives do constitute a security problem.
The switch should use echo-requests to detect disconnection.
TCP will notice that a connection has hung, but this can take a considerable amount of time. For example, with default settings the Linux kernel TCP implementation will retransmit for between 13 and 30 minutes, depending on the connection's retransmission timeout, according to kernel documentation. This is far too long for a switch to be disconnected, so an OpenFlow switch should implement its own connection timeout. OpenFlow OFPT_ECHO_REQUEST messages are the best way to do this, since they test the OpenFlow connection itself.
This section describes how Open vSwitch implements in-band control. Correctly implementing in-band control has proven difficult due to its many subtleties, and has thus gone through many iterations. Please read through and understand the reasoning behind the chosen rules before making modifications.
Open vSwitch implements in-band control as "hidden" flows, that is, flows that are not visible through OpenFlow, and at a higher priority than wildcarded flows can be set up through OpenFlow. This is done so that the OpenFlow controller cannot interfere with them and possibly break connectivity with its switches. It is possible to see all flows, including in-band ones, with the ovs-appctl "bridge/dump-flows" command.
The Open vSwitch implementation of in-band control can hide traffic to arbitrary "remotes", where each remote is one TCP port on one IP address. Currently the remotes are automatically configured as the in-band OpenFlow controllers plus the OVSDB managers, if any. (The latter is a requirement because OVSDB managers are responsible for configuring OpenFlow controllers, so if the manager cannot be reached then OpenFlow cannot be reconfigured.)
The following rules (with the OFPP_NORMAL action) are set up on any bridge that has any remotes:
In-band also sets up the following rules for each unique next-hop MAC address for the remotes' IPs (the "next hop" is either the remote itself, if it is on a local subnet, or the gateway to reach the remote):
In-band also sets up the following rules for each unique remote IP address:
In-band also sets up the following rules for each unique remote (IP,port) pair:
The goal of these rules is to be as narrow as possible to allow a switch to join a network and be able to communicate with the remotes. As mentioned earlier, these rules have higher priority than the controller's rules, so if they are too broad, they may prevent the controller from implementing its policy. As such, in-band actively monitors some aspects of flow and packet processing so that the rules can be made more precise.
In-band control monitors attempts to add flows into the datapath that could interfere with its duties. The datapath only allows exact match entries, so in-band control is able to be very precise about the flows it prevents. Flows that miss in the datapath are sent to userspace to be processed, so preventing these flows from being cached in the "fast path" does not affect correctness. The only type of flow that is currently prevented is one that would prevent DHCP replies from being seen by the local port. For example, a rule that forwarded all DHCP traffic to the controller would not be allowed, but one that forwarded to all ports (including the local port) would.
As mentioned earlier, packets that miss in the datapath are sent to the userspace for processing. The userspace has its own flow table, the "classifier", so in-band checks whether any special processing is needed before the classifier is consulted. If a packet is a DHCP response to a request from the local port, the packet is forwarded to the local port, regardless of the flow table. Note that this requires L7 processing of DHCP replies to determine whether the 'chaddr' field matches the MAC address of the local port.
It is interesting to note that for an L3-based in-band control mechanism, the majority of rules are devoted to ARP traffic. At first glance, some of these rules appear redundant. However, each serves an important role. First, in order to determine the MAC address of the remote side (controller or gateway) for other ARP rules, we must allow ARP traffic for our local port with rules (b) and (c). If we are between a switch and its connection to the remote, we have to allow the other switch's ARP traffic to through. This is done with rules (d) and (e), since we do not know the addresses of the other switches a priori, but do know the remote's or gateway's. Finally, if the remote is running in a local guest VM that is not reached through the local port, the switch that is connected to the VM must allow ARP traffic based on the remote's IP address, since it will not know the MAC address of the local port that is sending the traffic or the MAC address of the remote in the guest VM.
With a few notable exceptions below, in-band should work in most network setups. The following are considered "supported" in the current implementation:
The following are explicitly not supported by in-band control:
It seems likely that many controllers, at least at startup, use the OpenFlow "flow statistics" request to obtain existing flows, then compare the flows' actions against the actions that they expect to find. Before version 1.8.0, Open vSwitch always returned exact, byte-for-byte copies of the actions that had been added to the flow table. The current version of Open vSwitch does not always do this in some exceptional cases. This section lists the exceptions that controller authors must keep in mind if they compare actual actions against desired actions in a bytewise fashion:
Please report other discrepancies, if you notice any, so that we can fix or document them.
Suggestions to improve Open vSwitch are welcome at discuss@openvswitch.org.


The majority of funds are raised in the first three-to-four weeks after disasters. From that, 80% of the funding goes to first-response. If we focus only on first-response, we can’t build resilience. We need your help to put children and their families back on their feet and rebuild resilient communities.
Volunteers often set out to make a difference in the lives of others but in the process, realise that their lives are forever changed. If you have not volunteered with us before, read real volunteers’ experiences to get a feel for what our community is like.
We work alongside communities to determine where their greatest needs lie. Our record of financial efficiency and transparency delivers the right support, in the right places, at the right time. Every coin spent is worth it.
If you’re local to Florida, Feeding the Gulf is looking for volunteers to help make sure families in affected areas have plenty of food. They are looking for volunteers to help distribute food in areas affected by Hurricane Michael. Volunteers of all ages are welcome; supervision is required for youth under 14.
To register for an event, please view our current calendar below.
The Red Cross highlighted a “critical” need for platelet and blood donations in the wake of Michael. Make an appointment through our website on the button below, through the Red Cross blood donor app, or by calling 1-800-733-2767.
Address:
53 Gordon Plaza SW, Atlanta, GA 30310
You can help. Make a gift donation today.


Exploring:
Current:
Construct File:
Create New File
Construct Directory:
Create New Directory
Open File
Delete
Get Info
Move File
Copy File


App version: {{version}}
First name: {{user.firstName}}
Last name: {{user.lastName}}
Full name: {{user.fullName}}
{{team.league.id}} - {{team.league.division}}


Re:Zero is probably on of the best animated shows ever made. Truly, the Brothers Karamazov of anime (or maybe Tengen Toppa Gurren Lagann? why not both... hmmm...)


Real Madrid 'will not sell Isco in January'
Real Madrid are reportedly not open to selling Isco in January despite the attacker's struggles this season.
by Matt LawThe 27-year-old has only made six La Liga appearances for Los Blancos during the 2019-20 campaign, while he has featured in just one of their four Champions League fixtures.
There have been suggestions that Madrid could look to sell the Spaniard at the start of 2020, but according to Marca, that is not an option in the upcoming transfer window.
A hamstring injury saw the attacker miss six matches earlier this season, but he has struggled to break into Zinedine Zidane's first XI upon his return to fitness.
In all, the playmaker, who has also lost his spot in the Spain squad, has scored 48 times in 284 appearances for Madrid since arriving from Malaga.
Meanwhile, the former Valencia youngster has a contract at the Bernabeu until the summer of 2022.
body check tags ::


Yorlang is an esoteric programming language designed to write small programs using yoruba language constructs. It is the first of its kind and it can carry out basic programming operations in yoruba language (a language spoken in some parts of Nigeria ).
Variables are created with keyword 'jẹ́kí'. Since yorlang is a dynamic language, any variable created with this keyword can hold any value types such as strings, numbers etc.
There are various types of loops and conditionals in yorlang. They include fún (for loop), nígbàtí (while loop), yí (switch block), ṣé (if block), tàbí (else block) and tàbí ṣé (else if block).
Functions are declared with keyword 'iṣẹ́'. There's support for nested functions in yorlang. Arrays and multi-dimensional arrays are also included in yorlang.


| view_or_browse {diffobj} | R Documentation |
Use getOption("viewer")
to view HTML output if it is available as
per RStudio. Fallback to browseURL
if not available.
view_or_browse(url)
url |
character(1L) a location containing a file to display |
the return vaue of getOption("viewer")
if it is a function, or
of browseURL
if the viewer is not available


Follow these steps to create a project on Local Platform:
- Log in to Local Platform.
- In the left navigation menu, click the QuantConnect icon.
- If a project is already open, close it.
- In the Open Project panel, click Create Project.
- Enter the project name and then press Enter.
The new project directory is added to your organization workspace directory and the project opens.


class Transition extends PQItem with Ordered[Transition] with PetriNetRules with Identifiable
The Transition
class represents a timed transition.
- Alphabetic
- By Inheritance
- Transition
- PetriNetRules
- Ordered
- Comparable
- PQItem
- Identifiable
- Error
- AnyRef
- Any
- Hide All
- Show All
- Public
- All
Instance Constructors
-
new
Transition(x: Double, y: Double, firingDist: Variate, colors: Array[Color])
- x
the x-coordinate for 'this' transition
- y
the y-coordinate for 'this' transition
- firingDist
the random variate for the firing distribution
- colors
the colors of the tokens (needed for firing rules)
Value Members
-
final
def
!=(arg0: Any): Boolean
- Definition Classes
- AnyRef → Any
-
final
def
##(): Int
- Definition Classes
- AnyRef → Any
-
def
<(that: Transition): Boolean
- Definition Classes
- Ordered
-
def
<=(that: Transition): Boolean
- Definition Classes
- Ordered
-
final
def
==(arg0: Any): Boolean
- Definition Classes
- AnyRef → Any
-
def
>(that: Transition): Boolean
- Definition Classes
- Ordered
-
def
>=(that: Transition): Boolean
- Definition Classes
- Ordered
-
val
actTime: Double
- Definition Classes
- PQItem
-
def
addFluids(_fluids: VectorD): Unit
Add fluids to 'this' transition.
Add fluids to 'this' transition.
- _fluids
the fluid vector to add
-
def
addTokens(_tokens: VectorI): Unit
Add tokens to 'this' transition.
-
final
def
asInstanceOf[T0]: T0
- Definition Classes
- Any
-
def
calcFiringDelay(v: Variate, w_t: VectorD, t: VectorI, w_f: VectorD, f: VectorD): Double
Function to compute the delay in firing a transition.
Function to compute the delay in firing a transition. The base time is given by a random variate. This is adjusted by weight vectors multiplying the number of aggregate tokens and the aggregate amount of fluids summed over all input places: delay = v + w_t * t + w_f * f.
- v
the random variate used to compute base firing time
- w_t
the weight for the token vector
- t
the aggregate token vector (summed over all input places)
- w_f
the weight for the fluid vector
- f
the aggregate fluid level vector (summed over all input places)
- Definition Classes
- PetriNetRules
-
def
checkGuard: Boolean
Check the incoming arcs from discrete place for enough tokens of the right colors and the incoming arcs from continuous places for enough fluid of the right colors.
-
def
clone(): AnyRef
- Attributes
- protected[java.lang]
- Definition Classes
- AnyRef
- Annotations
- @throws( ... )
-
def
compare(tr2: Transition): Int
Compare 'this' transition to 'tr2' based on firing time.
Compare 'this' transition to 'tr2' based on firing time.
- tr2
the other transition
- Definition Classes
- Transition → Ordered
-
def
compare(other: PQItem): Int
- Definition Classes
- PQItem
-
def
compareTo(that: Transition): Int
- Definition Classes
- Ordered → Comparable
-
def
connect(_pnet: PetriNet, _inI: Array[ArcI], _inD: Array[ArcD], _outI: Array[ArcI], _outD: Array[ArcD]): Unit
Connect 'this' transition to all the incoming and outgoing arcs as well as the containing Petri net.
Connect 'this' transition to all the incoming and outgoing arcs as well as the containing Petri net.
- _pnet
the containing Petri net
- _inI
the incoming arcs from discrete/
Int
places- _inD
the incoming arcs from continuous/
Double
places- _outI
the outgoing arcs to discrete/
Int
places- _outD
the outgoing arcs to continuous/
Double
places
-
def
connect(_pnet: PetriNet, _in: Array[ArcD], _out: Array[ArcD]): Unit
Connect 'this' transition to all the incoming and outgoing continuous arcs as well as the containing Petri net.
Connect 'this' transition to all the incoming and outgoing continuous arcs as well as the containing Petri net.
- _pnet
the containing Petri net
- _in
the incoming arcs from continuous/
Double
places- _out
the outgoing arcs to continuous/
Double
places
-
def
connect(_pnet: PetriNet, _in: Array[ArcI], _out: Array[ArcI]): Unit
Connect 'this' transition to all the incoming and outgoing discrete arcs as well as the containing Petri net.
Connect 'this' transition to all the incoming and outgoing discrete arcs as well as the containing Petri net.
- _pnet
the containing Petri net
- _in
the incoming arcs from discrete/
Int
places- _out
the outgoing arcs to discrete/
Int
places
-
var
cqueue: ConcurrentLinkedQueue[AnimateCommand]
The animation command queue
-
def
enable(): Double
Enable 'this' transition by computing the firing delay.
Enable 'this' transition by computing the firing delay. Should immediately place it on the time ordered firing list. Also, move tokens/fluids from input places to 'this' transition.
-
final
def
eq(arg0: AnyRef): Boolean
- Definition Classes
- AnyRef
-
def
equals(that: Any): Boolean
- Definition Classes
- Identifiable → AnyRef → Any
-
def
finalize(): Unit
- Attributes
- protected[java.lang]
- Definition Classes
- AnyRef
- Annotations
- @throws( classOf[java.lang.Throwable] )
-
def
fire(): Unit
Fire 'this' transition by moving the requisite number and color of tokens from 'this' transition to each outgoing discrete place and the requisite amount and color of fluid to each outgoing continuous place.
-
var
firingDelay: Double
The firing delay for 'this' transition
-
final
def
flaw(method: String, message: String): Unit
- Definition Classes
- Error
-
def
fluidFlow(f: VectorD, derv: Array[Derivative], t0: Double, d: Double): VectorD
Compute the amount of fluid to flow over an arc according to the system of first-order Ordinary Differential Equation 'ODE's: "integral 'derv' from t0 to t".
Compute the amount of fluid to flow over an arc according to the system of first-order Ordinary Differential Equation 'ODE's: "integral 'derv' from t0 to t". Supports ODE base flow models.
- f
the fluid vector (amount of fluid per color)
- derv
the array of derivative functions
- t0
the current time
- d
the time delay
- Definition Classes
- PetriNetRules
-
def
fluidFlow(f: VectorD, b: VectorD, r: VectorD = null, d: Double = 0): VectorD
Compute the amount of fluid to flow over an arc according to the vector expression: b + r * (f-b) * d.
Compute the amount of fluid to flow over an arc according to the vector expression: b + r * (f-b) * d. If r is 0, returns b. Supports linear (w.r.t. time delay) and constant (d == 0) flow models.
- f
the fluid vector (amount of fluid per color)
- b
the constant vector for base fluid flow
- r
the rate vector (amounts of fluids per unit time)
- d
the time delay
- Definition Classes
- PetriNetRules
-
var
fluids: VectorD
Fluid vector for transition
-
final
def
getClass(): Class[_]
- Definition Classes
- AnyRef → Any
-
def
hashCode(): Int
- Definition Classes
- Identifiable → AnyRef → Any
-
val
id: Int
- Definition Classes
- Identifiable
-
var
inD: Array[ArcD]
Arcs incoming from continuous places
-
var
inI: Array[ArcI]
Arcs incoming from discrete places
-
final
def
isInstanceOf[T0]: Boolean
- Definition Classes
- Any
-
var
locked: Boolean
A transition is locked from the time it is enabled until it fires
-
def
me: String
- Definition Classes
- Identifiable
-
def
name: String
- Definition Classes
- Identifiable
-
def
name_=(name: String): Unit
- Definition Classes
- Identifiable
-
final
def
ne(arg0: AnyRef): Boolean
- Definition Classes
- AnyRef
-
final
def
notify(): Unit
- Definition Classes
- AnyRef
-
final
def
notifyAll(): Unit
- Definition Classes
- AnyRef
-
var
outD: Array[ArcD]
Arcs outgoing to continuous places
-
var
outI: Array[ArcI]
Arcs outgoing to discrete places
-
var
pnet: PetriNet
The containing Petri net
-
def
simType: String
- Definition Classes
- Identifiable
-
final
def
synchronized[T0](arg0: ⇒ T0): T0
- Definition Classes
- AnyRef
-
def
takeFluids(_fluids: VectorD): Unit
Take fluids from 'this' transition.
Take fluids from 'this' transition.
- _fluids
the fluid vector to take away
-
def
takeTokens(_tokens: VectorI): Unit
Take tokens from 'this' transition.
-
def
thresholdD(f: VectorD, b: VectorD): Boolean
Return whether the vector inequality is true: f >= b.
Return whether the vector inequality is true: f >= b. The firing threshold should be checked for every incoming arc. If all return true, the transition should fire.
- f
The fluid vector (amount of fluid per color)
- b
The base constant vector
- Definition Classes
- PetriNetRules
-
def
thresholdI(t: VectorI, b: VectorI): Boolean
Return whether the vector inequality is true: t >= b.
Return whether the vector inequality is true: t >= b. The firing threshold should be checked for every incoming arc. If all return true, the transition should fire.
- t
the token vector (number of tokens per color)
- b
the base constant vector
- Definition Classes
- PetriNetRules
-
def
toString(): String
- Definition Classes
- PQItem → AnyRef → Any
-
def
tokenFlow(t: VectorI, b: VectorI, r: VectorI = null, d: Double = 0): VectorI
Compute the number of tokens to flow over an arc according to the vector expression: b + r * (t-b) * d.
Compute the number of tokens to flow over an arc according to the vector expression: b + r * (t-b) * d. If d is 0, returns b. Supports linear (w.r.t. time delay) and constant (d == 0) flow models.
- t
the token vector (number of tokens per color)
- b
the constant vector for base token flow
- r
the rate vector (number of tokens per unit time)
- d
the time delay
- Definition Classes
- PetriNetRules
-
var
tokens: VectorI
Token vector for transition
-
final
def
wait(): Unit
- Definition Classes
- AnyRef
- Annotations
- @throws( ... )
-
final
def
wait(arg0: Long, arg1: Int): Unit
- Definition Classes
- AnyRef
- Annotations
- @throws( ... )
-
final
def
wait(arg0: Long): Unit
- Definition Classes
- AnyRef
- Annotations
- @throws( ... )
- val x: Double
- val y: Double


Transformed Select menu
Choose your favorite cryptocurrency...
Bitcoin
Litecoin
Dogecoin
Mastercoin
Primecoin
Peercoin
Ripple


When I discover a new project I always do the same analysis. So I decided to create a little project with my scripts to gather important information. In this post, I present how to use my scripts with a java project.
Preparation
In this post, we will extract information from the Traccar project. Traccar is a Java application that used the GWT framework to create a Riche Internet Application. You can download Traccar.
Once the application is downloaded, we generate a .mse file thanks to VerveineJ. Please refer to the VerveineJ documentation for more details.
The analysis is done with Moose. First of all, we need to download a Moose 8 image.
Finally, we load the .mse file in Moose.
"Import the model in moose"
model := FAMIXMooseModel importFromMSEStream: './path/to/file.mse' asFileReference readStream.
model rootFolder: '/path/to/rootfolder'.
"Add the model in the Moose Panel and compute some metrics"
model install.
Installation
My scripts are available on github. You can easily install them by executing the following line in a playground:
Metacello new
githubUser: 'badetitou' project: 'OOAnalysis' commitish: 'master' path: '.';
baseline: 'OOAnalysis';
load
The analysis
Once the tool is installed, open the System Browser and check the class OOCriticsVisu
with the protocol software visualization
.
You can execute the methods from the browser by clicking on the methods icon.
Each method will execute a common analysis on the loaded model.
In the following section, I describe the analysis.
Queries
Main methods
#mainMethods
searches the main methods inside the Java project.
In the case of Traccar there is none since the project is run by the GWT framework.
In other projects, you can find several mains.
It may be interesting to understand why.
Probably some are used for testing.
God classes by lines
#godClassesByLines
returns the classes with more than 150 lines of code.
In Traccar, it founds 36 classes.
model allModelClasses select: [ :each | each numberOfLinesOfCode > 150 ]
First, it asks the model all the model classes (the classes that are part of Traccar, excluding the classes from its dependencies). Then, it select classes with a number of line of code superior to 150.
God classes by methods
#godClassesByMethods
returns the classes with more than 50 methods.
In Traccar, there are 4 god classes with more than 50 methods.
model allModelClasses select: [ :each | each numberOfMethods > 50 ]
First, it asks the model all the model classes (the classes that are part of Traccar, excluding the classes from its dependencies). Then, it selects classes with a number of methods superior to 50.
Visualizations
Class diagram
#classDiagram
shows the class diagram of the project.
It uses Roassal to create the visualization.
| b |
b := RTMondrian new.
b nodes: model allClasses.
b edges connectFrom: #superclass.
b layout tree.
b build.
^ b view
First, it creates a mondrian.
Then, it defines the nodes of the visualization, in our case, it is all the classes of the model.
It connects the nodes by asking for the #superclass
.
Finally, it defines the layout as a tree.
Packages hierarchy with complexity
#packagesHierarchyWithComplexity
shows the package hierarchy and their complexity.
The width corresponds to the number of classes.
The height corresponds to the number of methods.
The color corresponds to the number of lines of code.
In Traccar, the most important packages seems to be org::traccar::web::client::view and org::traccar::web::server::model.
b := RTMondrian new.
b shape rectangle
width: [ :p | p numberOfClasses ];
height: [ :p | p numberOfMethods ];
linearFillColor: #numberOfLinesOfCode within: model allModelNamespaces entities;
borderColor: Color lightGray.
^ b
nodes: model allModelNamespaces;
edgesFrom: #parentScope;
treeLayout;
build;
view
First, it defines how an element should be displayed.
Then , it adds the namespaces (packages) as nodes and connect them with the #parentScope
keyword.
Finally, it defines the layout as a tree.


VIT University Vellore
CodeChef was created as a platform to help programmers make it big in the world of algorithms, computer programming and programming contests. At CodeChef we work hard to revive the geek in you by hosting a programming contest at the start of the month and another smaller programming challenge in the middle of the month. We also aim to have training sessions and discussions related to algorithms, binary search, technicalities like array size and the likes. Apart from providing a platform for programming competitions, CodeChef also has various algorithm tutorials and forum discussions to help those who are new to the world of computer programming.
CodeChef was created as a platform to help programmers make it big in the world of algorithms, computer programming and programming contests. At CodeChef we work hard to revive the geek in you by hosting a programming contest at the start of the month and another smaller programming challenge in the middle of the month. We also aim to have training sessions and discussions related to algorithms, binary search, technicalities like array size and the likes. Apart from providing a platform for programming competitions, CodeChef also has various algorithm tutorials and forum discussions to help those who are new to the world of computer programming.
I am a Full stack web developer who strives to marry the love of web and graphic design.
I am a Full stack web developer who strives to marry the love of web and graphic design.
I am a Full stack web developer who strives to marry the love of web and graphic design.
I am a Full stack web developer who strives to marry the love of web and graphic design.
I am a Full stack web developer who strives to marry the love of web and graphic design.
I am a Full stack web developer who strives to marry the love of web and graphic design.
I am a Full stack web developer who strives to marry the love of web and graphic design.
I am a Full stack web developer who strives to marry the love of web and graphic design.
I am a Full stack web developer who strives to marry the love of web and graphic design.
I am a Full stack web developer who strives to marry the love of web and graphic design.
I am a Full stack web developer who strives to marry the love of web and graphic design.
I am a Full stack web developer who strives to marry the love of web and graphic design.
Code Combat is a unique blend of gaming and coding. To gain enough amount of time to solve as many competitive coding problems, something of equal value must be given. Come join us in teams of three and find out the value of time. In this heat, all you need to do is play your favourite game in an A/C room for 10 hours with friends and food and winning cash prizes! We've got refreshments, fun, music and some surprises as well, so register now!
The workshop on Digital Footprint, the first workshop of the new semester was a success! We thank all of you guys for making it one. Hope all of you liked it. The upcoming events and workshops are going to be even more interesting. Stay updatedThe workshop on Digital Footprint, the first workshop of the new semester was a success! We thank all of you guys for making it one. Hope all of you liked it. The upcoming events and workshops are going to be even more interesting. Stay updated
The workshop on Digital Footprint, the first workshop of the new semester was a success! We thank all of you guys for making it one. Hope all of you liked it. The upcoming events and workshops are going to be even more interesting. Stay updatedThe workshop on Digital Footprint, the first workshop of the new semester was a success! We thank all of you guys for making it one. Hope all of you liked it. The upcoming events and workshops are going to be even more interesting. Stay updated
The workshop on Digital Footprint, the first workshop of the new semester was a success! We thank all of you guys for making it one. Hope all of you liked it. The upcoming events and workshops are going to be even more interesting. Stay updatedThe workshop on Digital Footprint, the first workshop of the new semester was a success! We thank all of you guys for making it one. Hope all of you liked it. The upcoming events and workshops are going to be even more interesting. Stay updated
The workshop on Digital Footprint, the first workshop of the new semester was a success! We thank all of you guys for making it one. Hope all of you liked it. The upcoming events and workshops are going to be even more interesting. Stay updatedThe workshop on Digital Footprint, the first workshop of the new semester was a success! We thank all of you guys for making it one. Hope all of you liked it. The upcoming events and workshops are going to be even more interesting. Stay updated
The workshop on Digital Footprint, the first workshop of the new semester was a success! We thank all of you guys for making it one. Hope all of you liked it. The upcoming events and workshops are going to be even more interesting. Stay updatedThe workshop on Digital Footprint, the first workshop of the new semester was a success! We thank all of you guys for making it one. Hope all of you liked it. The upcoming events and workshops are going to be even more interesting. Stay updated
The workshop on Digital Footprint, the first workshop of the new semester was a success! We thank all of you guys for making it one. Hope all of you liked it. The upcoming events and workshops are going to be even more interesting. Stay updatedThe workshop on Digital Footprint, the first workshop of the new semester was a success! We thank all of you guys for making it one. Hope all of you liked it. The upcoming events and workshops are going to be even more interesting. Stay updated
The workshop on Digital Footprint, the first workshop of the new semester was a success! We thank all of you guys for making it one. Hope all of you liked it. The upcoming events and workshops are going to be even more interesting. Stay updatedThe workshop on Digital Footprint, the first workshop of the new semester was a success! We thank all of you guys for making it one. Hope all of you liked it. The upcoming events and workshops are going to be even more interesting. Stay updated
The workshop on Digital Footprint, the first workshop of the new semester was a success! We thank all of you guys for making it one. Hope all of you liked it. The upcoming events and workshops are going to be even more interesting. Stay updatedThe workshop on Digital Footprint, the first workshop of the new semester was a success! We thank all of you guys for making it one. Hope all of you liked it. The upcoming events and workshops are going to be even more interesting. Stay updated
The workshop on Digital Footprint, the first workshop of the new semester was a success! We thank all of you guys for making it one. Hope all of you liked it. The upcoming events and workshops are going to be even more interesting. Stay updatedThe workshop on Digital Footprint, the first workshop of the new semester was a success! We thank all of you guys for making it one. Hope all of you liked it. The upcoming events and workshops are going to be even more interesting. Stay updated
The workshop on Digital Footprint, the first workshop of the new semester was a success! We thank all of you guys for making it one. Hope all of you liked it. The upcoming events and workshops are going to be even more interesting. Stay updatedThe workshop on Digital Footprint, the first workshop of the new semester was a success! We thank all of you guys for making it one. Hope all of you liked it. The upcoming events and workshops are going to be even more interesting. Stay updated


UNWTO Seasonality Dashboard
Destination Tracker
UNWTO Global Tourism
Tourism Recovery Tracker
International Tourism - COVID19


0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
sine
square
sawtooth
triangle
0.0
0.01
0.1
0.3
0.5
0.7
1.0
3.0
5.0
7.0
0.0
0.01
0.1
0.3
0.5
0.7
1.0
3.0
5.0
7.0
infinite
0.0
0.1
0.3
0.5
0.7
1.0
3.0
5.0
7.0
0.0
0.01
0.1
0.3
0.5
0.7
1.0
3.0
5.0
7.0
x 1
x 0.5
x 0.8
x 1.2
x 1.5
x 1.7
x 2.0
x 2.5
x 3.0
change keyboard
keyboard.html
keyboard88.html


{% extends "layout.html" %} {% block title %} Political Parties {% endblock title %} {% block article %}
"We all know how it works," said David Cameron of lobbying. But do we? Lobbyists are the paid persuaders whose job it is to influence the decisions of government. Typically, they operate behind closed doors, through quiet negotiation with politicians.


{% extends "blog/base.html" %} {% block title %}Password reset{% endblock %} {% block content %} Your password has been set! log in now {% endblock %}
Your password has been set!


{{ post.title }}
{{ post.excerpt }}
Read More
--- title: A modern standard for event-oriented data layout: default ---
Osso is a modern standard for representing event-oriented data in high-throughput operational systems. It uses existing open source standards for schema definition and serialization, but adds semantic meaning and definition to make integration between systems easy, while still being size- and processing-efficient.
{% if site.posts.length > 0 %}


CREATE INDEX -- define a new index
CREATE [ UNIQUE ] INDEX name ON table ( { column | ( expression ) } ) [ TABLESPACE tablespace ]
CREATE INDEX constructs an index, name, on the specified table. Indexes are primarily used to enhance database performance (though inappropriate use will result in slower performance).
The key field(s) for the index are specified as column names, or alternatively as expressions written in parentheses. Multiple fields can be specified to create multicolumn indexes.
An index field can be an expression computed from the values of one or more columns of the table row. This feature can be used to obtain fast access to data based on some transformation of the basic data. For example, an index computed on UPPER(col) would allow the clause WHERE UPPER(col) = 'JIM' to use an index.
Postgres Plus Advanced Server provides the B-tree index method. The B-tree index method is an implementation of Lehman-Yao high-concurrency B-trees.
Indexes are not used for IS NULL clauses by default.
All functions and operators used in an index definition must be "immutable", that is, their results must depend only on their arguments and never on any outside influence (such as the contents of another table or the current time). This restriction ensures that the behavior of the index is well-defined. To use a user-defined function in an index expression remember to mark the function immutable when you create it.
UNIQUE
Causes the system to check for duplicate values in the table when the index is created (if data already exist) and each time data is added. Attempts to insert or update data which would result in duplicate entries will generate an error.
name
The name of the index to be created. No schema name can be included here; the index is always created in the same schema as its parent table.
table
The name (possibly schema-qualified) of the table to be indexed.
column
The name of a column in the table.
expression
An expression based on one or more columns of the table. The expression usually must be written with surrounding parentheses, as shown in the syntax. However, the parentheses may be omitted if the expression has the form of a function call.
tablespace
The tablespace in which to create the index. If not specified, default_tablespace is used, or the database’s default tablespace if default_tablespace is an empty string.
Up to 32 fields may be specified in a multicolumn index.
To create a B-tree index on the column, ename, in the table, emp:
CREATE INDEX name_idx ON emp (ename);
To create the same index as above, but have it reside in the index_tblspc tablespace:
CREATE INDEX name_idx ON emp (ename) TABLESPACE index_tblspc;


{% extends "single-column.html" %} {% block title %}Crunch.io - Create Account{% endblock %} {% block pagetitle %}Create Account{% endblock %} {% block content %}
Crunch.io is currently in a limited beta, so accounts created with this form will not be activated immediately. You must provide a valid email address and AWS credentials or your account will be deleted. Your account will not be activated until after you are contacted by Crunch.io.
{% endblock %}