Fishtailis in the Finance-Accounting Tech Industry

Fishtail

fishtail

Scientific American Supplement, No. 717, September 28, 1889, by Various, is part of the HackerNoon Books Series. You can jump to any chapter in this book . EARLY ELECTRIC LIGHTING. here EARLY ELECTRIC LIGHTING. The opening of the new station of the Electric Lighting Co., of Salem, Mass., was recently celebrated with appropriate festivities. Among the letters of regret from those unable to attend the opening was the following from Prof. Moses G. Farmer: "Eliot, Me., Aug. 5, 1889. " : To the Salem Electric Lighting Company, Charles H. Price, President "Gentlemen: It would give me great pleasure to accept your kind invitation to be present at the opening of your new station in Salem on the 8th of this present August. "It is now thirty years since the first dwelling house in Salem was lighted by electricity. That little obscure dwelling, 11 Pearl Street, formerly owned by 'Pa' Webb, had the honor to be illuminated by the effulgent electric beam during every evening of July, 1859, as some of your honored residents, perhaps, well remember. Mr. George D. Phippen can doubtless testify to one or more evenings; Mr. Wm. H. Mendell, of Boston, can also add his testimony; dozens of others could also do the same, had not some of them already passed to the 'great beyond,' among whom I well recollect the interest taken by the late and honored Henry L. Williams, Mr. J. G. Felt, and I do not know how many others. I well remember reading some of the very finest print standing with my back to the front wall and reading by the light of a 32 candle power lamp on the northernmost end of the mantel piece in the parlor; very possibly the hole in which the lamp was fastened remains to this day. In a little closet in the rear sleeping room was a switch which could be turned in one direction and give a beautiful glow light, while if turned in the other direction, it instantly gave as beautiful a dark. My then 12 year old daughter used to surprise and please her visitors by suddenly turning on and off the 'glim.' It is not well to despise the day of small things, for although the dynamo had not at that date put in an appearance, and though I used thirty-six Smee cells of six gallons capacity each, yet I demonstrated then and there that the incandescent electric light was a possibility, and although I innocently remarked to the late Samuel W. Bates, of Boston, who with his partner, Mr. Chauncey Smith, furnished so generously in the interest of science, not wholly without hope of return, the funds for the experiment, that it 'did not take much zinc,' and though Mr. Bates as naively replied, 'I notice that it takes some silver, though,' still it was then and there heralded as the coming grand illuminant for the dwelling. I am thankful to have lived to see my predictions partly fulfilled. "During the early fifties I published a statement something like this: 'One pound of coal will furnish gas enough to maintain a candle light for fifteen hours. One pound of gas (the product of five pounds of coal) will, in a good fishtail gas burner, furnish one candle light for seventy-five hours. One pound of coal burned in a good furnace, under a good boiler, driving a good steam engine, turning a good magneto-electric machine, will give a candle light for one thousand hours. But if all the energy locked up in one pound of pure carbon could be wholly converted into light, it would maintain one candle light for more than one and a half years.' "So, gentlemen, ; there is still room for improvement. Let your motto be 'Excelsior.' Possibly you may have already extracted from one-fifteenth to one-twelfth of the energy stored in the pound of carbon, but hardly more. Go on, go on, and bring it so cheap as to reach the humblest dwelling when you shall celebrate the centennial of the opening of your new station. nil desperandum "I do most sincerely regret that I cannot be with you in the flesh. I am, like Ixion of old, confined to a wheel (chair in my case), cannot walk, cannot even stand; hence, owing to the impairment of my understanding (???), I must wish you all the enjoyments of the evening, and gladly content myself that you have made so much possible. "Very truly yours,   Moses G. Farmer." About HackerNoon Book Series: We bring you the most important technical, scientific, and insightful public domain books. This book is part of the public domain. Various (2006). Scientific American Supplement, No. 717, September 28, 1889. Urbana, Illinois: Project Gutenberg. Retrieved https://www.gutenberg.org/cache/epub/17755/pg17755-images.html This eBook is for the use of anyone anywhere at no cost and with almost no restrictions whatsoever. You may copy it, give it away or re-use it under the terms of the Project Gutenberg License included with this eBook or online at , located at . www.gutenberg.org https://www.gutenberg.org/policy/license.html

EARLY ELECTRIC LIGHTING

State and local governments are starting to permit the testing of driverless cars. This will likely result in accidents and traffic jams. There were over 37,000 fatal accidents in the US in 2017. Someday, driverless cars may make our roads safer. At the same time, millions of seniors and people with disabilities suffer from limited mobility. Driverless cars and taxis might someday provide mobility for this population. The US federal government is trying to balance consumer safety with the goal of achieving technological leadership in automated vehicles. But safety advocates are concerned that the balance is shifting towards technology and away from safety. The title of the 2017 autonomous vehicle report by the National Highway Safety Transportation Authority (NHTSA) emphasized safety and was titled . Automated Driving Systems: A Vision for Safety By 2020, the tides had shifted. The title of the 2020 NHTSA report emphasized technology leadership and was titled . Ensuring American Leadership in Automated Vehicle Technologies criticized the US National Highway and Transportation Safety Administration (NHTSA) as having a “dangerously lax hands-off approach” to the safety of driverless vehicles. Consumer Reports https://www.nhtsa.gov/automated-vehicles-safety/av-test-initiative-tracking-tool The map above shows the locations of self-driving vehicle tests across the US. Driverless Vehicle Testing Many manufacturers are testing driverless cars and other types of autonomous vehicles on our roads. Most of these tests are occurring with a safety operator behind the wheel who is responsible for taking over the steering, braking, and acceleration whenever they detect an unsafe situation. However, we are also starting to see the testing of driverless cars. California has issued permits to four companies for tests of driverless taxis: AutoX (Alibaba), Waymo (Google), Zoox (Amazon), and Cruise (GM). These initial permits are only for a handful of driverless cars operating at relatively low speeds primarily in the Bay Area. You can find a US map of all self-driving vehicle tests (with and without a safety operator behind the wheel) . here In California, the driverless cars are primarily being tested as taxis. The self-driving cars that are being operated without a safety driver are required to have a remote operator monitoring the vehicle. The requires the remote operator to continuously monitor the vehicle and to be able to communicate with passengers and police if there is an issue. California law The law specifies that “A remote operator may also have the ability to perform the dynamic driving task” for the driverless car. I hope that all the manufacturers are testing driverless cars with remote operators who are viewing the camera outputs continuously and can take over with remote control if there is a safety issue or an unexpected occurrence. The manufacturers who are running these driverless car tests have all done extensive testing with safety operators behind the wheel and use simulators to train and test the self-driving capabilities. The question is whether all this testing has made driverless cars safe. Will they reduce or eliminate accidents or will they cause accidents? A secondary but important question is whether they can make our roads safer without driving so slowly that they increase congestion on our roads. The average American spends , the equivalent of two and a half work weeks stuck in traffic. 97 hours a year In early 2020, Moscow hosted a driverless car competition. Shortly after it began, a vehicle stalled out at a traffic light. Human drivers would reason about this edge case and decide to just go around the stalled car. However, none of the driverless cars did that, and . We do not want autonomous vehicles to crash, but we also do not want them to stop and block traffic every time they encounter an obstacle. a three-hour traffic jam ensued Edge Cases Are A Barrier to Driverless Car Safety Most of us have encountered unexpected phenomena while driving: A deer darts onto the highway. A flood makes the road difficult or impossible to navigate. A tree falls and blocks the road. The car approaches the scene of a car accident or a construction zone. A boulder falls onto a mountain road. A section of new asphalt has no lines. You notice or suspect black ice. Drivers are fishtailing, trying to get up an icy hill. An elderly driver falls asleep and his car heads right for you (this happened to me). We all have our stories. People do not learn about all these possible edge cases in driving school. Instead, we use our commonsense reasoning skills to predict actions and outcomes. If we hear an ice cream truck in a neighborhood, we know to look out for children running towards the truck. We know that when the temperature is below 32 degrees and there is precipitation on the road, and we are going down a hill that we need to drive very slowly. We change our driving behavior when we see the car in front of us swerving, knowing that the driver might be intoxicated or texting. If a deer crosses the road, we are on the lookout for another deer because our commonsense knowledge tells us they travel as families. We know to keep a safe distance and handle passing a vehicle with extra care when we see a truck with an “Extra Wide Load” sign on the back. When we see a ball bounce into the street, we slow down because a child might run into the street to chase it. If we see a large piece of paper on the road, we know we can drive over it, but if we see a large shredded tire, we know to stop or go around it. Unfortunately, into driverless cars or into AI systems in general. Without commonsense reasoning capabilities to handle these unanticipated situations, self-driving vehicle manufacturers have to anticipate every possible situation. no one knows how to build commonsense reasoning capabilities Driverless cars can only handle the situations that have been anticipated in their software code. Machine learning can only help to the extent that manufacturers anticipate every situation and provide training examples of every possible situation. Crashes and traffic jams will likely result when autonomous vehicles encounter unanticipated situations for which there is no training or programming. It will be difficult, if not impossible, for manufacturers can anticipate every edge case. It will certainly be easier to do this for slow-moving shuttles on corporate campuses. It is hard to imagine that this is possible for self-driving consumer vehicles that can drive anywhere. Self-driving taxis in small, heavily-mapped areas are somewhere in between. Cars Do Not “See” Like People Another difficulty for driverless cars is that they don’t “see” like people. Object detection systems represent tremendous victories for deep learning and AI; however, they also make surprising mistakes. If I train a system to distinguish cats from dogs, and in the training table, all the pictures of dogs are outside, and all the images of cats are inside homes, the deep learning system will likely key in on yard and home features. Then if I show a picture of a dog inside a home, the system will probably label it a cat. Similarly, in the image above, before , both object recognition systems and human subjects correctly labeled the monkey in the photo. Adding the guitar did not confuse people, but it made the object recognition system think it was observing a picture of a person instead of a monkey. The object classification system did not learn the visual characteristics that people use to recognize monkeys and people. Instead, it learned that guitars are only present in pictures of people. researchers pasted the guitar onto the picture Other types of mistakes are even more concerning. A group of Japanese researchers found that by modifying just a single pixel in an image, they could alter an object recognition system’s category choice. In one instance, by changing a single pixel on a picture of a deer, the object recognition system into identifying the image as a car. was fooled Researchers have also figured out how to into recognizing objects such as cheetahs and peacocks in images with high confidence even though there are no objects at all in the image. fool deep learning systems Other researchers showed that minor changes to a speed limit sign could cause driverless cars to think the sign says 85 mph instead of 35 mph and . Similarly, some into changing lanes. In both cases, these minor changes fooled cars but did not fool people. unsafely accelerate as a result Chinese hackers tricked Tesla’s autopilot In real-world driving, many Tesla owners have reported that into thinking that the shadows are real objects. shadows of tree branches often fool their car When an in 2018, the car’s object recognition software first classified the pedestrian as an unknown object, then as a vehicle, and finally as a bicycle. Uber self-driving car killed a pedestrian I do not know about you, but I would rather not be on the road as a pedestrian or a driver if driverless cars cannot recognize pedestrians with 100% accuracy. What if a self-driving car mistakenly perceives a baby stroller as a low-flying piece of paper? It might drive right through it! Deep learning system errors also can provide targets for bad actors who might decide to attack deep learning systems. For example, a bad actor might devise ways of confusing cars or trucks into driving off the road. Should You Be Worried? Take a look at these videos of a . While Tesla says it has “full self-driving” capabilities, its website makes it clear that : “Autopilot is a hands-on driver assistance system that is intended to be used only with a fully attentive driver. It does not turn a Tesla into a self-driving car nor does it make a car autonomous.” Tesla making mistake after mistake its cars are not fully autonomous vehicles You should absolutely be worried. What happens when a driverless car runs over a baby stroller? The manufacturers will likely respond that their cars are safer than human drivers. Maybe so. But before we allow driverless cars on the road, we should require manufacturers to prove this is true. The manufacturers have the necessary data. They know when safety drivers are concerned enough to take over the wheel due to safety concerns. I don’t think we should allow these vehicles on the road without at least a remote safety operator until the number of such disengagements is lower than the average number of accidents per vehicle in the target driving area. But this is not happening. States are allowing driverless cars on the road without proof of safety. The only saving grace is that manufacturers can still be sued under product liability laws. This should give them pause before putting unsafe cars on the road. Some driverless car advocates have proposed the elimination of liability laws for AV manufacturers. In my view, this would be a complete disaster. I don’t want driverless cars and trucks in my neighborhood. They haven’t been proven to be safe. If you feel the same way, write your federal and state legislators and demand proof of safety and manufacturer liability. Please enter any comments below and feel free to visit AI Perspectives where you can find a free online AI Handbook with 15 chapters, 400 pages, 3000 references, and no advanced mathematics. This post was originally published on Steve’s Blog .

Driverless Vehicles: There's No Such Thing As Too Much Safety

McLEAN, United States of America, June 26th, 2024/CyberNewsWire/--FireTail announces a free version of its enterprise-level API security tools, making them accessible to developers and organizations of all sizes. FireTail's unique combination of open-source code libraries, inline API call evaluation, security posture management, and centralized audit trails helps eliminate vulnerabilities and protect APIs in real-time. The free plan covers up to 5 APIs, includes 1M API call logs per month, offers 7 days of data retention, and provides clear developer support. FireTail, a disruptor in API security, unveils free access for all to its cutting-edge API security platform. This initiative opens the door for developers and organizations of any size to access enterprise-level API security tools. Today, over 80% of all internet traffic is computer-to-computer communication via APIs. Every mobile app, IoT device, and most modern software applications use APIs, creating a broad attack surface for potential threats. FireTail’s hybrid approach to API security blends open-source code libraries with a feature-packed cloud platform and equips businesses with a unique suite of tools to eliminate API vulnerabilities and provide robust runtime API protection. "API security is essential for modern applications, and every developer and tech team should have access to effective security tools," said Jeremy Snyder, CEO and Co-Founder of FireTail. "Security through obscurity is no longer a viable approach. We’re on a mission to secure all of the world’s APIs and our new free plan ensures ongoing access to an API security platform that delivers genuine insight into the most pressing attack vectors - design flaws in APIs. It’s perfect for smaller organizations striving for stronger API protection, and a great way for individuals or teams within larger organizations to get started. "Riley Priddle, Co-Founder and CTO at FireTail, added, "We’re excited to help organizations of all sizes to better protect their APIs. We want FireTail to become the de facto standard when it comes to API security. Just because you have a small number of APIs, it doesn’t mean they aren’t critical. We want everyone to have access to the best, enterprise-level API security tools. That’s why we offer both this free tier, as well as our open source libraries." For developers and small to medium-sized organizations needing to secure up to 5 APIs, FireTail's free tier includes comprehensive API security features such as discovery, inventory, assessment, detection and response, and inline runtime protection. Key features include: Protection for up to 5 APIs 1M API calls per month 7 days of logging retention Thomas Martin, Founder at NephoSec, shared "We’ve been working with FireTail from the outset as both a customer and a distribution partner. Having proven that the platform works for even the largest enterprises with the most complex API security requirements, it’s great to see the team opening that technology up to everyone.This will enable us to solve API security challenges for organizations of all shapes and sizes." To access the FireTail API security platform, users can visit https://www.firetail.app or join the team on Tuesday, July 2nd for an in-depth look at what FireTail’s free tier can do. About FireTail FireTail allows customers to solve all the most critical problems facing APIs today with a hybrid approach, bringing together cloud, application and code with full blocking capabilities to solve the root causes of API data breaches - flaws at the application and business logic layer in authentication, authorization and data handling. Headquartered in McLean, VA, with offices in Dublin, Ireland, and Helsinki, Finland, FireTail is backed by leading investors, including Paladin Capital, Zscaler, General Advance, and SecureOctane. Users can learn more at https://www.firetail.io. Contact Marketing Director Alan Fagan FireTail media@firetail.io This story was distributed as a release by Cyberwire under HackerNoon’s Business Blogging Program. Learn more about the program here. McLEAN, United States of America, June 26th, 2024/CyberNewsWire/--FireTail announces a free version of its enterprise-level API security tools, making them accessible to developers and organizations of all sizes. FireTail's unique combination of open-source code libraries, inline API call evaluation, security posture management, and centralized audit trails helps eliminate vulnerabilities and protect APIs in real-time. The free plan covers up to 5 APIs, includes 1M API call logs per month, offers 7 days of data retention, and provides clear developer support. FireTail, a disruptor in API security, unveils free access for all to its cutting-edge API security platform. This initiative opens the door for developers and organizations of any size to access enterprise-level API security tools. Today, over 80% of all internet traffic is computer-to-computer communication via APIs. Every mobile app, IoT device, and most modern software applications use APIs, creating a broad attack surface for potential threats. FireTail’s hybrid approach to API security blends open-source code libraries with a feature-packed cloud platform and equips businesses with a unique suite of tools to eliminate API vulnerabilities and provide robust runtime API protection. "API security is essential for modern applications, and every developer and tech team should have access to effective security tools," said Jeremy Snyder, CEO and Co-Founder of FireTail. "API security is essential for modern applications, and every developer and tech team should have access to effective security tools," said Jeremy Snyder, CEO and Co-Founder of FireTail. "Security through obscurity is no longer a viable approach. We’re on a mission to secure all of the world’s APIs and our new free plan ensures ongoing access to an API security platform that delivers genuine insight into the most pressing attack vectors - design flaws in APIs. It’s perfect for smaller organizations striving for stronger API protection, and a great way for individuals or teams within larger organizations to get started. "Security through obscurity is no longer a viable approach. We’re on a mission to secure all of the world’s APIs and our new free plan ensures ongoing access to an API security platform that delivers genuine insight into the most pressing attack vectors - design flaws in APIs. It’s perfect for smaller organizations striving for stronger API protection, and a great way for individuals or teams within larger organizations to get started. "Riley Priddle, Co-Founder and CTO at FireTail, added, "We’re excited to help organizations of all sizes to better protect their APIs. We want FireTail to become the de facto standard when it comes to API security. Just because you have a small number of APIs, it doesn’t mean they aren’t critical. We want everyone to have access to the best, enterprise-level API security tools. That’s why we offer both this free tier, as well as our open source libraries." "Riley Priddle, Co-Founder and CTO at FireTail, added, "We’re excited to help organizations of all sizes to better protect their APIs. We want FireTail to become the de facto standard when it comes to API security. Just because you have a small number of APIs, it doesn’t mean they aren’t critical. We want everyone to have access to the best, enterprise-level API security tools. That’s why we offer both this free tier, as well as our open source libraries." For developers and small to medium-sized organizations needing to secure up to 5 APIs, FireTail's free tier includes comprehensive API security features such as discovery, inventory, assessment, detection and response, and inline runtime protection. Key features include: Protection for up to 5 APIs 1M API calls per month 7 days of logging retention Thomas Martin, Founder at NephoSec, shared "We’ve been working with FireTail from the outset as both a customer and a distribution partner. Having proven that the platform works for even the largest enterprises with the most complex API security requirements, it’s great to see the team opening that technology up to everyone.This will enable us to solve API security challenges for organizations of all shapes and sizes." To access the FireTail API security platform, users can visit https://www.firetail.app or join the team on Tuesday, July 2nd for an in-depth look at what FireTail’s free tier can do. https://www.firetail.app About FireTail FireTail allows customers to solve all the most critical problems facing APIs today with a hybrid approach, bringing together cloud, application and code with full blocking capabilities to solve the root causes of API data breaches - flaws at the application and business logic layer in authentication, authorization and data handling. Headquartered in McLean, VA, with offices in Dublin, Ireland, and Helsinki, Finland, FireTail is backed by leading investors, including Paladin Capital, Zscaler, General Advance, and SecureOctane. Users can learn more at https://www.firetail.io . https://www.firetail.io Contact Marketing Director Alan Fagan FireTail media@firetail.io media@firetail.io This story was distributed as a release by Cyberwire under HackerNoon’s Business Blogging Program. Learn more about the program here. This story was distributed as a release by Cyberwire under HackerNoon’s Business Blogging Program. Learn more about the program here . here here

FireTail Unveils Free Access For All To Cutting-Edge API Security Platform

In this article I’ll introduce an implementation for Singly and Doubly Linked Lists, which you can reuse or modify for your own purposes. All the or as an npm package. code is available in github Coding data structures in Solidity is weird and beautiful. A few months ago I implemented a in Solidity for a client. More recently I decided that I might take on implementing a in Solidity as a pet project (aren’t nerds fun!) and Linked Lists appeared again. Linked List Fast Limit Order Book As I recently wrote in an article about : when to use different data structures Linked Lists are your data structure of choice when you need to preserve the insertion order, and also when you want to insert in arbitrary positions. I love coding and no one seemed to have done this one*, so I took to it happily. basic building blocks *Disclaimer: While writing this article, and after having coded the contracts, I found this from . Like him, I also considered using an array. Compared to using a mapping, it simplifies the creation of new items but also makes deletion more difficult. earlier implementation chriseth Implementation For this article I’m going to ignore that and code the lists in a single contract. Doing that will allow me to focus on the basics such as data usage. An , but the trade offs deserve an article of its own. Solidity is an Object Oriented Programming Language OOP implementation is possible Implementing a Linked List in a single contract Solidity was not an obvious thing to do. This code would be very convenient, but not doable in Solidity since you can’t have recursive . structs contract ImpossibleLinkedList {
   struct Item {
      Item next;
      address data;
   }
Item public head; The only dynamic contract variable that exists in Solidity are mappings. Even arrays are mappings under the hood. Given that constraint the best implementation for a Linked List in Solidity that I could come up is based on this: contract LinkedList {
  struct Item {
    uint256 id;
    uint256 next;
    address data;
}
mapping ( Item) public items;
uint256 public head;
uint256 public idCounter; => uint256 The Linked List is made of Item. The Item has a unique id, a member for the id of another Item, and an address which is the data payload. Then all items created are stored in a mapping indexed by Item id. You can retrieve any Item at cost O(1) if you know its id, just by looking it up in the mapping. If you are looking at an Item in the List and want to proceed to the next one you have to retrieve item.next which is an Item id, and then look up that next Item in the mapping. If this gets you confused, don’t feel bad. I also got very confused. My first question was “is there any point to a Linked List if you can just arbitrarily retrieve any Item from a list?”. The question is that yes, there is a point, but with a very limited scope. Linked Lists are your data structure of choice when you need to preserve the insertion order, and also when you want to insert in arbitrary positions. The fact that you can iterate over the list is useful to a point, if you have to do that in a transaction the list cannot grow indefinitely. You can use this data structure when a contract needs to frequently use several items in an ordered list that you can assume will be of limited size. For example if you need a contract to always know the 100 largest holders of a token to give them some perks. Unlike in previous articles, this time I’m not going to paste the whole code here. Instead I will direct you to the . There is an implementation for a Singly Linked List and another one for a Doubly Linked List, with each one being about 200 lines of code, which I’ve crafted carefully for maximum clarity. full implementation In this case I think it is more important to discuss the trade offs between a Singly Linked List and Doubly Linked List, in particular given that the Ethereum blockchain is quite limited in the algorithms that you can . execute safely Usage When I started the implementation of linked lists, I thought that doing a Doubly Linked List would be more complex than a Singly Linked List. Interestingly enough, it is slightly easier to implement the former. Adding in each item a link for the previous one allows you to remove this inefficient method: { (_id == head) ;
  Item memory prevItem = items[head]; (prevItem.next != _id) {
    prevItem = items[prevItem.next];
  } prevItem.id;
} /**
 * @dev Given an Item, denoted by `_id`, returns the id of the Item
 * that points to it, or 0 if `_id` refers to the Head.
 */ ( ) ( ) function findPrevId uint256 _id public view returns uint256 if return 0 while return That statement is evil. while You would use this method anytime that you know of an item and you want to insert another before it. Quite a common use case. A gas comparison between LinkedList.sol and DoubleLinkedList.sol sheds some more light on the issue. For these tests I used a list with 100 items. and operations with LinkedList are O(1) and cost about 100K gas. Data retrieval is not depicted but given that we use a mapping the cost will be O(1). addHead insertAfter The issue is when we need to loop over the list. Every item we loop through seems to cost about 1K gas as seen in findTailIdWithGas (which is a mock function that encloses findTailId in a transaction, wasting some gas). Maybe we can make without adding items at the tail or inserting before a known item, but the remove function is more of an issue. In a LinkedList you have to loop through the list from the head to remove items. In smart contracts a method with a cost of O(N) needs to be approached very carefully, or better even, avoided. A Doubly Linked List is easier to implement and more practical, even if a bit more expensive to use. In this specific case, and with a gas block limit of about ten million, it means that you can’t remove items that are more than 10,000 positions away from the head. That can be quite dangerous. For , on the other hand, all the methods are O(1). addHead and insertAfter are more costly than in because we need to update an extra pointer. If you need to insert at the end of the list, find neighbouring items in both directions, or remove items, you’ll benefit from O(1) cost. I haven’t included gas costs for looping the list but they should be identical to LinkedList. DoubleLinkedList LinkedList And as I said before, it’s interesting that for the same functionality, costs less to deploy than LinkedList. Not that important but interesting. DoubleLinkedList As with anything, your mileage will vary. Maybe you can do with a Singly Linked List, maybe you need a Doubly Linked List. Maybe you should use an array. At least now you know them all. Other Implementations The implementations discussed above are not the only ones, I just thought they would be easy to understand. There are other interesting implementations that might fit your use case better: You want to save some gas, then remove the id field from the Item struct. You don’t actually need it, funny enough. You don’t like the structs, them replace each struct variable with a mapping as a state variable, it will work exactly the same. You are happy with just appending items at the tail, and maybe those items expire after a set period of time: You can use . It would work great for a traditional fast limit order book. RenounceableQueue.sol If all the items in your list are unique, then you can use . I like the compactness and elegance of it. OrderedSet.sol If all the items in your list are unique, but you don’t care about the order, then you are after a canonical , get it from . Set OpenZeppelin Conclusion are the first complex data structure that is considered in smart contracts. Given the constraints in smart contracts that force us to code as simply as possible it is necessary to know the trade offs between different linked list implementations. Linked Lists In this article I’ve shown both Singly Linked Lists and Doubly Linked Lists, pointing to . An analysis of gas costs has also been provided, along with guidance for safe use. code ready to be reused I feel quite privileged to have the opportunity to code basic data structures. Sometimes coding smart contracts feels like a trip many years back when programming meant being very close to the hardware and was very close to mathematics. I like that. If you are considering using this code in a project, want to contribute, or have ideas to explore, please ! Talking to those that read me is always a pleasure :) drop me a line

A Linked List Implementation for Ethereum [Deep Dive]

Lately, I have been in the press discussing the need for more inclusive and more representative data sets. The associated and frame the conversation in a number of ways that at times overshadow the main message: artificial intelligence headlines comments . The rise of artificial intelligence necessitates careful attention to inadvertent bias that can perpetuate discriminatory practices and exclusionary experiences for people of all shades Still, the valid points commenters have brought up that: 1.) default camera settings do not properly expose dark skin and 2.) algorithms are not intentionally developed to be racist warrant further discussion. To address these questions and others related to bias in artificial intelligence, I am starting the Illuminate Series. The goal of the Illuminate Series is to broaden the public discourse on artificial intelligence and it’s impact on everyday people. Please let me know if you would like to participate by submitting a question, guest posting, leading a discussion group, creating educational demos, or in some other capacity. ILLUMINATE PART 1 — Cameras, Contrast, and The Coded Gaze. Since sharing my demonstrating facial detection failure, I am asked variations of this hushed question: TED Talk Isn’t the reason your face was not detected due to a lack of contrast given your dark complexion? This is an important question. In the field of computer vision, poor illumination is a major challenge. Ideally you want to create systems that are illumination invariant and can work well in many lighting conditions. This is where training data can come in. to deal with the challenges of illumination is by training a facial detection system on a set of diverse images with a variety of lighting conditions. One way There are of course certain instances where we reach the limits of the visible light spectrum. (Infrared detection systems also exist). My focus here is not on the extreme case as much as the everyday case. The demo in the TED talk shows a real-world office environment. My face is visible to a human eye as is the face of my demonstration partner, but the human eye and the visual cortex that processes its input are far more advanced than a humble web camera. Still, even using the web camera, you can see in the demo that my partner’s face is not so overexposed as to be inscrutable nor is my face so underexposed that there is significant information loss. Though not as pertinent to my demo example, there are extreme failure cases where there is overexposure or underexposure and of course the case of no light at all in the image. Cameras, however, are not as neutral as they may seem. Are Cameras Objective? The default settings for digital cameras are influenced by the history of color film which itself exposes an optimization for lighter skin. This VOX video provides an informative overview of how camera technology evolved with a privileging of lighter skin. https://www.vox.com/2015/9/18/9348821/photography-race-bias Defaults are not neutral I was amused to learn that complaints from chocolate and furniture companies who wanted their products better represented led to improved representation of darker tones in the earlier days of photography. In the digital era, the LDK series was developed by Phillips. The cameras explicitly handled skin tone variation with two chips — one for processing darker tones and another for processing lighter tones. The Oprah Winfrey show used the LDK series for filming because there was an awareness of the need to better expose darker skin. With inclusion in mind, we can make better sensor technology as well as better training data and algorithms. We have to keep in mind that default settings are not neutral. They reflect the Coded Gaze, the preferences of those who have the opportunity to develop technology. Sometimes these preferences can be exclusionary. Exclusion Overhead More than a few observers have recommended that instead of pointing out failures, I should simply make sure I use additional lighting. Silence is not the answer. The suggestion to get more lights to increase illumination in an already lit room is a stop gap solution. Suggesting people with dark skin keep extra lights around to better illuminate themselves misses the point. Should we change ourselves to fit technology or make technology that fits us? Who has to take extra steps to make technology work? Who are the default settings optimized for? One of the goals of the Algorithmic Justice League is to highlight problems with artificial intelligence so we can start working on solutions. We provide actionable critique while working on research to make more inclusive artificial intelligence. In speaking up about my experiences, others have been encouraged to share their stories. The silence is broken. More people are aware that we can embed bias in machines. This is only the beginning as we start to collect more reports. One bias-in-the-wild report we received at AJL shares the following story. “A friend of mine works for a large tech company and was having issues being recognized by the teleconference system that uses facial recognition. While the company has some units that work on her dark skin, she has to make sure to reserve those rooms specifically if she will be presenting. This limits her ability to present and share information to times when these rooms are available.” This employee is dealing with the exclusion overhead that can result when we do not think through or test technology to account for our differences. Full Spectrum Inclusion Mindset Questioning how different skin tones are rendered by cameras can help us think through ways to improve computer vision. Let’s also keep in mind that there is more at stake than facial analysis technology. The work of AJL isn’t just about facial detection or demographic bias in computer vision. I use the mask example as a visible demonstration of how automated systems can unintentionally lead to exclusionary experiences. I know we can do better as technologists once we see where problems arise commit to addressing the issues. We can also be better about gaining feedback by asking for and listening to people’s real-world experiences with the technology we create. We can build better systems that account for the variety of humanity. Let’s not be afraid to illuminate our failures. We can acknowledge physical and structural challenges, interrogate our assumptions about defaults, and move forward to create more inclusive technology. and Action Step: Share Your Story Your voice matters. Speaking up for inclusion is the first step towards change. It took me five years to muster up the courage to share my truth. Even though I was afraid, I am glad I did. The response has been overwhelming. I have witnessed so many people who want to be part of creating a better future. My inbox is overflowing with messages from others who thought they were alone until they heard my story. If you have a story to share please consider submitting it to AJL. Illuminate bias and fight the Coded Gaze here at http://fight.ajlunited.org What question should the Illuminate Series address next? Share your suggestions in the comments below. Joy Buolamwini is a on a mission to show compassion through computation. She writes about and to develop social impact technology. Find her on twitter and connect on or . poet of code incoding creates learning experiences @jovialjoy @ajlunited LinkedIn Facebook

Algorithms aren’t racist. Your skin is just too dark.

Using Tech to Clean Baltimore Harbor With , we are often thinking about innovations that enable us to improve our natural environment. Regardless of whether it is a school, waterway, hiking path or city block, there is a massive amount of work to be done. Aspirations of cleaning the planet one piece of litter at a time can be a daunting task. Litterati So when we uncover stories like the massive trash wheel collecting discarded trash in the Baltimore Inner Harbor, it makes us stop and reflect: if the Baltimore area can produce a project that has picked up over 354 tons of trash through public/private funding — what if we empower people to contribute through technology via ? a mobile app credit: http://baltimorewaterfront.com/ If 5 people picked up 5 pieces a day, 5 days a week we could make a significant impact on a local level. 5 people x 5 pieces x 5 days per week = 6250 pieces. Imagine the difference a 5th grade class, community business, or Girl Scout troop could make. It doesn’t take much to create an impact. Take these local examples and magnify them by county, state and region and our collective impact becomes greater. In the same way that Mr. Trash Wheel in Baltimore makes a really difficult problem approachable — making the bay in Baltimore’s Inner Harbor , we can do the same through Litterati. This model could be applied to regions like the San Francisco Bay Area, the Hudson Valley in upstate New York. Swimmable and Fishable by 2020 For more on Mr. Trash Wheel, check out the or follow along on . live feed Twitter If you have stories about environmental impact in your area we’d love to hear more.

Stories, News & Mentions about FISHTAIL

Fishtail’s Stories on HackerNoon