Operations On List
list.append(x) Add an item to the end of the list. Equivalent to a[len(a):] = [x]. list.extend(iterable) Extend the list by appending all the items from the iterable. Equivalent to a[len(a):] = iterable. list.insert(i, x) Insert an item at a given position. The first argument is the index of the element before which to insert, so a.insert(0, x) inserts at the front of the list, and a.insert(len(a), x) is equivalent to a.append(x). list.remove(x) Remove the first item from the list whose value is equal to x. It raises a ValueError if there is no such item. list.pop([i]) Remove the item at the given position in the list, and return it. If no index is specified, a.pop() removes and returns the last item in the list. (The square brackets around the i in the method signature denote that the parameter is optional, not that you should type square brackets at that position. You will see this notation frequently in the Python Library Reference.) list.clear() Remove all items from the list. Equivalent to del a[:]. list.index(x[, start[, end]]) Return zero-based index in the list of the first item whose value is equal to x. Raises a ValueError if there is no such item. The optional arguments start and end are interpreted as in the slice notation and are used to limit the search to a particular subsequence of the list. The returned index is computed relative to the beginning of the full sequence rather than the start argument. list.count(x) Return the number of times x appears in the list. list.sort(key=None, reverse=False) Sort the items of the list in place (the arguments can be used for sort customization, see sorted() for their explanation). list.reverse() Reverse the elements of the list in place. list.copy() Return a shallow copy of the list. Equivalent to a[:].
Keshav Malik
How to find the length of an Array in C#
using System; namespace viden { class GFG { // Main Method public static void Main() { // declares a 1D Array of string. string[] weekDays; // allocating memory for days. weekDays = new string[] {"Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat"}; // Displaying Elements of the array foreach(string day in weekDays) Console.Write(day + " "); Console.Write("\nTotal Number of Elements: "); // using Length property Console.Write(weekDays.Length); } } }
Logic Theory —Basic Notation
The origin of logic theory starts at the concept of an argument. The majority of logic textbooks contain an opening, central definition for an argument — one that likely sounds much like the following: An argument contains one or more special statements, called premises , offered as a reason to believe that a further statement, called the conclusion, is true Premises are the atoms of logic theory: everything is built up from them. A premise is a declarative statement that must strictly evaluate to only either true or false. A single premise is referred to as a primitive premise — there are 50 states in the U.S.A (which is true). Connecting multiple premises together form a compound premise — there are 50 states in the U.S.A and it snowed in Miami today (which is false). How does one connect multiple statements? Like you see in the previous example, with operators that you’re already familiar with but that require their own language & syntax. Connectives Similar to other branches of math, premises have their own set of fundamental operators (adding, subtracting, etc…). In logic theory, five basic logical connectors, collectively known as connectives, fill this role. They’re summarized in the table below, assume the letters P & Q represent two primitive premises: If you’ve been exposed to programming at any level, then it’s highly likely that the table above seems at least vaguely familiar. This is because connectives are at the very core of common language syntax & almost always have some special character designated for each connective (&& = and, | = or, etc…). Which of the five connectives is used as a logical connector between two premises determines the overall truth value of the compound statement based on the truth values of the premises being modified. An important principle here that might seem counter-intuitive at first is worth extracting: when analyzing compound statements it’s not necessary to know what parts P & Q actually say, only whether those parts are true or false. Implication Of the five connectives, one is immediately worthy of further inspection — the implication, aka, if-then statements. The implication is a connective with the standard form of P → Q where P is known as the hypothesis (or antecedent), & Q is known as the conclusion (or consequent). While the implication has a standard form defined above, there exists three other common types of conditionals that are worth reviewing. The following four conditionals are simple yet quite common & powerful compound statements made by combining conditionals with the core connectives introduced: A conditional is itself a compound premise, that is, it strictly evaluates to either true or false. For any implication, just like for any other connective, the truth value of the compound premise is determined by the truth values of its two independent premises. Corresponding with the definitions introduced above, for example, an implication is true either when the hypothesis is false, or when the conclusion is true; which leaves only one way for an implication to be false: when the hypothesis is true & the conclusion is false. If that seemed like a lot to track mentally, as it did for me, then breath easy & rest assure that powerful tools lay in the near future that makes analyzing complex conditionals as simple as following a blueprint. The main tool we’ll use is a nifty logic-101 tool by the name of truth tables. Before we get into truth tables, however, let’s make a quick detour to fill one last gap in our knowledge of basic logic theory notation. Inspect a peculiar scenario — is the following statement a premise? x is larger than one hundred Quantifiers Under our strict definition introduced in the opening paragraph, a premise must evaluate to either true or false — the statement cannot be ambiguous or left open-ended. Which means that variables, as we’re used to seeing them since algebra, is a no-no in logic theory; not at least without some modification. The bolded statement above is not considered a premise as x could be 5 or 25, making the statement true or false, but currently neither. This, however, doesn’t mean that we have to delete variables from our tool set altogether. There is a way to make use of variables; the process is called quantifying, a clever way of notating bounds on unknown variables in logic. Take a look at the following, updates statement — is this now a premise? for all x, x is larger than one hundred Now that we’ve defined the universe, or domain, of the variable, the statement is no longer ambigious — it’s now a premise as it evaluates to categorically false. The use of this “for all x” is known in logic theory as applying a quantifier. There are two main types of quantifiers. The first, which we’ve just seen, is aptly named the universal quantifier. Dictated by an upside down “A”, ∀, it’s easy to remember that it stands for All or every possible instance within the universe of the statement made. Inspect this second alteration: there exists an x larger than one hundred Once again without removing the variables we’ve found a way to convert a statement into a premise by applying a quantifier as the statement now evaluates strictly to true. This second type of quantifier is known as the existential quantifier. Notated by a backwards “E”, ∃, it usually reads as “there exists” or “there is.” Both quantifiers are summarized below:
IoT Security
What is the most important IoT security trend we are seeing this year? As consumers and businesses adopt more IoT devices and threats continue to multiply, securing those devices easily and at scale has become a daunting task. We are seeing more specialized security tools and processes specifically for IoT devices this year, specifically the use of digital certificates and public key infrastructure (PKI’s) to enable a more secure onboarding process. “‘Onboarding’ is the process by which a new device is connected and added to the network and the local IoT ecosystem. Onboarding includes the process for authentication, authorization, and accountability of that new device.” -- A Vision for Secure IoT Digital certificates are issued and signed by a reputable source, often referred to as a Certificate Authority or Root of Trust. Like a digital identity card, devices exchange digital certificates to cryptographically authenticate each other’s identity and origin. In other words, authentication credentials allow you to prove you are what you say you are. As the IoT Security Informed Insight explains, “not only do digital certificates increase security, they enable a better customer experience (e.g. no PIN to enter.)” The cryptographic signatures within the certificates cannot feasibly be forged or re-created unless you have the proper private key at the source. You can read more about the authentication process, digital certificates and PKI’s here. What are the main challenges facing the IoT industry today? The challenges are multifaceted, but the three most common I see are: While many companies are beginning to explore solutions, most device makers do not have security experts and are unprepared to manage security complexities Device manufacturers and security companies have traditionally operated in two quite separate worlds. Device manufacturers operate in a world of physical devices, often on the scale of hundreds of thousands, even millions of devices the manufactured each year. Tightly managing inventory, bill of material costs, and just in time delivery are essential to remaining competitive. Device manufacturers work with firmware and small footprint applications, often with limited compute power and storage. Security can be limited to that which is only essential, in order to keep costs down and delivery times short. This market is generally characterized by tens of thousands of small to medium sized companies that individually might not drive very high volumes, but in aggregate ship billions of devices. Security companies have traditionally operated in the world of enterprise computing, networking, and web servers and web applications. These accounts are typically characterized by large corporations with IT groups and staff or consultants that specializes in security. Generally, these are large companies, banks, data centers, health care providers, etc. where there may not be a physical product, but valuable data that is stored in vast database servers. The data enables services and usually involves personal and/or financial information that must be protected. As you can see, this can result in a large mismatch between what a device maker needs, and what a security company is equipped to provide, resulting in the two parties talking past each other. As a result, device security often doesn’t get implemented properly. This is not because the device maker doesn’t want to do it, but because they are not effectively guided on HOW to do it. In the pressure to meet product schedules and quarterly earnings, device security is often omitted or left as an afterthought because it currently takes too much effort and cost to understand and implement it People often hear that cost is the reason for not implementing security, but misinterpret where that cost lies. There is indeed strong pressure to lower BOM costs, but the larger cost is often in the staff a company needs just to understand security itself. Whether it is allocating brain cycles from existing staff or new hires, headcount is generally one of the largest costs a company incurs. Understanding takes brain cycles. Brain cycles = time. Time = money, big money. If we are to address the IoT security issue effectively, we need to address the time aspect of implementing security. Although IoT has existed for some time now, the market pressure to go wireless leaves devices more vulnerable to attacks Autonomous networked devices have existed for quite some time already, but have primarily been implemented on wired networks on a relatively limited scale, using general purpose computers. However, with the relentless march of Moore’s Law, microcontrollers have advanced to the point where even a very small, inexpensive chip can operate a full TCP/UDP network stack in addition to managing a wireless radio. This high integration and lower cost have driven the market towards the adoption of small, wirelessly connected autonomous devices. In addition, the convenience of wireless connectivity has increased the scale of adoption to levels that are orders of magnitude greater than we have ever seen before. Every device that is connected to your network is effectively a user on that network. Would you let a human user onto your network without verifying their identity? If you wouldn’t do that, why would you let a “device” do it? I put “device” in quotes because, in a network environment, you can’t always be sure if something claiming to be a device actually is what it says it is. The justification for omitting security I often hear is “there is nothing important on that device”. That is the data center way of thinking about it where you are protecting what is directly on the system where security is implemented. My response is usually this, “You are absolutely correct. No one cares about what’s on the device. They care about the network it’s connected to.” That usually gets them to rethink their position. Insecure devices provide a foothold on the network to attack higher value devices or capture sensitive data.