Maps toolkit - Geo-measurements Utils in Flutter

A library for area, distance, heading measurements (spherical_util.dart if port from android-maps-utils).

Getting Started

In your dart/flutter project add the dependency:

 dependencies:
   ...
   maps_toolkit: ^2.0.1

A simple usage example:

import 'package:maps_toolkit/maps_toolkit.dart';

main() {
  val distanceBetweenPoints = SphericalUtil.computeDistanceBetween(
    LatLng(51.5073509, -0.1277583),
    LatLng(48.856614, 2.3522219)
  );

  final p1 = LatLng(45.153474463955796, 39.33852195739747);
  final p2 = LatLng(45.153474463955796, 39.33972358703614);
  final p3 = LatLng(45.15252112936569, 39.33972358703614);
  final p4 = LatLng(45.1525022138355, 39.3385460972786);

  val areaInSquareMeters = SphericalUtil.computeArea([p1, p2, p3, p4, p1]);
}

Usage with Google Maps package (specify a prefix for an import):

import 'package:maps_toolkit/maps_toolkit.dart' as mp;
import 'package:google_maps/google_maps.dart';
import 'package:test/test.dart';

void main() {
  final pointFromToolkit = mp.LatLng(90, 0);
  final pointFromGoogleMap = LatLng(90, 0);

  mp.SphericalUtil.computeAngleBetween(pointFromToolkit, pointFromToolkit);
}

List of functions

SphericalUtil.computeArea - calculate the area of a closed path on Earth.

SphericalUtil.computeDistanceBetween - calculate the distance between two points, in meters.

SphericalUtil.computeHeading - calculate the heading from one point to another point.

SphericalUtil.computeLength - calculate the length of the given path, in meters, on Earth.

SphericalUtil.computeOffset - calculate the point resulting from moving a distance from an origin in the specified heading (expressed in degrees clockwise from north).

SphericalUtil.computeOffsetOrigin - calculate the location of origin when provided with a point destination, meters travelled and original heading.

SphericalUtil.computeSignedArea - calculate the signed area of a closed path on Earth.

SphericalUtil.interpolate - calculate the point which lies the given fraction of the way between the origin and the destination.

PolygonUtil.containsLocation - computes whether the given point lies inside the specified polygon.

PolygonUtil.isLocationOnEdge - computes whether the given point lies on or near the edge of a polygon, within a specified tolerance in meters.

PolygonUtil.isLocationOnPath - computes whether the given point lies on or near a polyline, within a specified tolerance in meters.

PolygonUtil.locationIndexOnPath - computes whether (and where) a given point lies on or near a polyline, within a specified tolerance.

PolygonUtil.locationIndexOnEdgeOrPath - computes whether (and where) a given point lies on or near a polyline, within a specified tolerance.

PolygonUtil.simplify - simplifies the given poly (polyline or polygon) using the Douglas-Peucker decimation algorithm.

PolygonUtil.isClosedPolygon - returns true if the provided list of points is a closed polygon.

PolygonUtil.distanceToLine - computes the distance on the sphere between the point p and the line segment start to end.

PolygonUtil.decode - decodes an encoded path string into a sequence of LatLngs.

PolygonUtil.encode - encodes a sequence of LatLngs into an encoded path string.

Features and bugs

Please file feature requests and bugs at the issue tracker.

Use this package as a library

Depend on it

Run this command:

With Dart:

 $ dart pub add maps_toolkit

With Flutter:

 $ flutter pub add maps_toolkit

This will add a line like this to your package's pubspec.yaml (and run an implicit dart pub get):

dependencies:
  maps_toolkit: ^2.0.1

Alternatively, your editor might support dart pub get or flutter pub get. Check the docs for your editor to learn more.

Import it

Now in your Dart code, you can use:

import 'package:maps_toolkit/maps_toolkit.dart';

example/maps_toolkit_example.dart

import 'package:maps_toolkit/maps_toolkit.dart';

void main() {
  final cityLondon = LatLng(51.5073509, -0.1277583);
  final cityParis = LatLng(48.856614, 2.3522219);

  final distance =
      SphericalUtil.computeDistanceBetween(cityLondon, cityParis) / 1000.0;

  print('Distance between London and Paris is $distance km.');
}

Download Details:

Author:  kb-apps.com

Source Code: https://github.com/kb0/maps_toolkit/

#flutter #map #toolkit #areas #distance #measurement 

Physics Wallah Units and Measurements Class 11 Revision Notes

The concept of measurement is the comparison of an object's physical characteristics to a reference. The Class 11 Physics Chapter 2 Notes provide a thorough understanding of all measurement types, units, dimensions, and measurement defects.

https://www.pw.live/physics-questions-mcq/units-and-measurements

 

 

#classes  #physics  #class11notes  #ncertsolutions  #science  #measurement 

Rdiversity: An R Package for Measuring Similarity-sensitive Diversity

rdiversity: diversity measurement in R

rdiversity is a package for R based around a framework for measuring biodiversity using similarity-sensitive diversity measures. It provides functionality for measuring alpha, beta and gamma diversity of metacommunities (e.g. ecosystems) and their constituent subcommunities, where similarity may be defined as taxonomic, phenotypic, genetic, phylogenetic, functional, and so on. It uses the diversity framework described in the arXiv paper arXiv:1404.6520 (q-bio.QM), "How to partition diversity".

This package has now reached a stable release and is cross-validated against our Julia package Diversity.jl, which is developed independently. Please raise an issue if you find any problems.

To install rdiversity from CRAN, simply run the following from an R console:

install.packages("rdiversity")

The latest development version can be installed from GitHub:

# install.packages("devtools")
devtools::install_github("boydorr/rdiversity")

Examples of how to use the package are included in our docs, as well as in a vignette currently only available in the development version of this package:

install_github("boydorr/rdiversity", build_vignettes = TRUE)
vignette("examples", "rdiversity")

Download Details:

Author: boydorr
Source Code: https://github.com/boydorr/rdiversity 

#r #measurement 

The Correct Way to Measure Inference Time of Deep Neural Networks

The network latency is one of the more crucial aspects of deploying a deep network into a production environment. Most real-world applications require blazingly fast inference time, varying anywhere from a few milliseconds to one second. But the task of correctly and meaningfully measuring the inference time, or latency, of a neural network, requires profound understanding. Even experienced programmers often make common mistakes that lead to inaccurate latency measurements. The impact of these mistakes has the potential to trigger bad decisions and unnecessary expenditures.

In this post, we review some of the main issues that should be addressed to measure latency time correctly. We review the main processes that make GPU execution unique, including asynchronous execution and GPU warm up. We then share code samples for measuring time correctly on a GPU. Finally, we review some of the common mistakes people make when quantifying inference time on GPUs.

Asynchronous execution

We begin by discussing the GPU execution mechanism. In multithreaded or multi-device programming, two blocks of code that are independent can be executed in parallel; this means that the second block may be executed before the first is finished. This process is referred to as asynchronous execution. In the deep learning context, we often use this execution because the GPU operations are asynchronous by default. More specifically, when calling a function using a GPU, the operations are enqueued to the specific device, but not necessarily to other devices. This allows us to execute computations in parallel on the CPU or another GPU.

Figure 1. Asynchronous execution. Left: Synchronous process where process A waits for a response from process B before it can continue working. Right: Asynchronous process A continues working without waiting for process B to finish.

Asynchronous execution offers huge advantages for deep learning, such as the ability to decrease run-time by a large factor. For example, at inference of multiple batches, the second batch can be preprocessed on the CPU while the first batch is fed forward through the network on the GPU. Clearly, it would be beneficial to use asynchronism whenever possible at inference time.

The effect of asynchronous execution is invisible to the user; but, when it comes to time measurements, it can be the cause of many headaches. When you calculate time with the “time” library in Python, the measurements are performed on the CPU device. Due to the asynchronous nature of the GPU, the line of code that stops the timing will be executed before the GPU process finishes. As a result, the timing will be inaccurate or irrelevant to the actual inference time. Keeping in mind that we want to use asynchronism, later in this post we explain how to correctly measure time despite the asynchronous processes.

#runtime #deep-learning #measurement #deci #machine-learning #neural networks

Levels of Measurements

Photo by William Warby on Unsplash

Measurement is the process of assigning numbers to quantities (variables). The process is so familiar that perhaps we often overlook its fundamental characteristics. A single measure of some attribute (for example, weight) of sample is called statistic. These attributes have inherent properties too that are similar to numbers that we assign to them during measurement. When we assign numbers to attributes (i.e., during measurement), we can do so poorly, in which case the properties of the numbers to not correspond to the properties of the attributes. In such a case, we achieve only a “low level of measurement” (in other words, low accuracy). Remember that in the earlier module we have seen that the term accuracy refers to the absolute difference between measurement and real value. On the other hand, if the properties of our assigned numbers correspond properly to those of the assigned attributes, we achieve a high level of measurement (that is, high accuracy).

American statistician Stanley Smith Stevens is credited with introducing various levels of measurements. Stevens (1946) said: “All measurements in science are conducted using four different types of scales nominal, ordinal, interval and ratio”. These levels are arranged in ascending order of increasing accuracy. That is, nominal level is lowest in accuracy, while ratio level is highest in accuracy. For the ensuing discussion, the following example is used. Six athletes try out for a sprinter’s position in CUPB Biologists’ Race. They all run a 100-meter dash, and are timed by several coaches each using a different stopwatch (U through Z). Only the stopwatch U captures the true time, stopwatches V through Z are erroneous, but at different levels of measurement. Readings obtained after the sprint is given in Table.

Nominal level of measurement

Nominal scale captures only equivalence (same or different) and set membership. These sets are commonly called categories, or labels. Consider the results of sprint competition, Table 1. Watch V is virtually useless, but it has captured a basic property of the running times. Namely, two values given by the watch are the same if and only if two actual times are the same. For example, participants Shatakshi and Tejaswini took same time in the race (13s), and as per the readings of stopwatch V, this basic property remains same (20s each). By looking at the results from stopwatch V, it is cogent to conclude that ‘Shatakshi and Tejaswini took same time in the race’. This attribute is called equivalency. We can conclude that watch V has achieved only a nominal level of measurement. Variables assessed on a nominal scale are called categorical variables. Examples include first names, gender, race, religion, nationality, taxonomic ranks, parts of speech, expired vs non expired goods, patient vs. healthy, rock types etc. Correlating two nominal categories is very difficult, because any relationships that occur are usually deemed to be spurious, and thus unimportant. For example, trying to figure out how many people from Assam have first names starting with the letter ‘A’ would be a fairly arbitrary, random exercise.

Ordinal level of measurement

Ordinal scale captures rank-ordering attribute, in addition to all attributes captured by nominal level. Consider the results of sprint competition, Table 1. Ascending order of time taken by the participants as revealed by the true time are (respective ranks in parentheses): Navjot (1), Surbhi (2), Sayyed (3), Shatakshi and Tejaswini (4 each), and Shweta (5). Besides capturing the same-difference property of nominal level, stopwatches W and X have captured the correct ordering of race outcome. We say that the stopwatches W and X have achieved an ordinal level of measurement. Rank-ordering data simply puts the data on an ordinal scale. Examples at this level of measurement include IQ Scores, Academic Scores (marks), Percentiles and so on. Rank ordering (ordinal measurement) is possible with a number of subjective measurement surveys. For example, a questionnaire survey for the public perception of evolution in India included the participants to choose an appropriate response ‘completely agree’, ‘mostly agree’, ‘mostly disagree’, ‘completely disagree’ when measuring their agreement to the statement “men evolved from earlier animals”.

#measurement #data-analysis #data #statistical-analysis #statistics #data analysis

Keep Delivering Software Effectively in the "New Normal World "

Key Takeaways
It is vital that technology leadership understand the health of their delivery capability in the ‘new normal’ world of remote working, uncertainty and cost pressure
This requires the ability to track a set of critical metrics. For organisations delivering software in an Agile way, a sensible place to start is a hierarchy of metrics that tie back to the core Agile principle of “the early and continuous delivery of valuable software”.
Our five overall delivery health metrics for the ‘new normal’ world which are meaningful when tracked over time at an aggregate level and give your whole organisation a simple set of metrics around which to align are: Time to Value; Deployment Frequency; Throughput; Defect Density; Team Engagement
Our top five cascaded delivery metrics for managers and teams, which drive the five over-riding metrics at the top of the metrics hierarchy are: Deployment Frequency; Flow Efficiency; Cycle Time and Lead Time; Completion Rate; Engineer Morale Score
We hope that many organisations will take the metrics suggested as a good place to start. However, you may prefer to build your own bespoke metrics. Whichever metrics you choose, In our view it is the discipline of tracking and managing to metrics (that reflect core Agile principles) that is critical in the ‘new normal’ world.
The world has changed dramatically and a “new normal” has appeared almost overnight - a time of remote working, great uncertainty, changing priorities and dramatic cost pressures.

Software delivery teams sit at the heart of this challenging new environment as organisations look to them to deliver more, for less in strategically critical areas.

Metrics, visibility and risk management were already an increasing priority in Agile software delivery – particularly in large scale organisations. But recent events have seen these catapulted from important to essential, as the ‘new normal’ world presents a whole new set of challenges.

#adopting agile #agile in the enterprise #measurement #metrics #agile #devops #development #culture & methods #article

Applying Observability to Ship Faster

To get fast feedback, ship work often, as soon as it is ready, and use automated systems in Live to test the changes. Monitoring can be used to verify if things are good, and to raise an alarm if not. Shipping fast in this way can result in having fewer tests and can make you more resilient to problems.

Dan Abel shared lessons learned from applying observability at Aginext.io 2020.

Shipping small changes, daily or hourly, sounds simple, but it can be a hard thing to be great at. It really helps to have independent, low coupled systems, said Abel. He mentioned that thinking about the desired design, constantly while coding, really helps:

The Bounded Context concept (from Domain Driven Design) is a great guide to thinking how things can start to be separated and operate independently. I also have a rule that if several services have to be shipped together, we’ve probably built ourselves something too coupled to test, ship and monitor in the way we do.

Getting our products and features released as soon as we can allows us to learn as we go, Abel said. “We can often better see and solve issues in the small; learning good patterns before we scale up,” he mentioned.

InfoQ interviewed Dan Abel, a software engineer, consultant, and coach, about applying observability to ship faster.

InfoQ: What purpose do metrics, monitors, and dashboards serve?

Dan Abel: For us at Tes, these allow us to check in on the health of our systems. They give us confidence that things are working as intended and crucially that our users are reaching their goals.

We instrument our applications to gather metrics - information from our Live systems. We then get visible displays of our service health via dashboards. Crucially we can assert on this data using monitors.

We verify our systems by tracking success and failure metrics, and setting expectations on these via monitors to get alerted if user success drops too low, or if errors rise.

For example, we can ask, “Did we fail to render those PDFs?” “Did we serve those downloads okay?”

For me, that’s test automation in production.

InfoQ: What happened when you arrived at a new company who was shipping fast with fewer tests?

Abel: When I arrived at Tes, I found working in this new way both exciting and challenging. It felt weird to not be running integration suites and thoroughly testing every nook before shipping. I was there to learn about new things and be an engineer with service ownership, so: challenge accepted.

I found myself on a team that was building a replacement job application system. The existing system was extremely valuable to the business, so we needed to find new ways to keep releasing and learning.

“Move fast and break things” couldn’t quite apply here. If we wanted to keep shipping, we needed speedy and accurate feedback from our services in production.

So we asked, “What would happen if we applied what we cared about from test automation, using what we knew about production monitoring?”

And of course - we are engineers. Once we cracked that, we found we could do more complex measuring and monitoring.

#aginext.io london #feedback #automation #observability #measurement #resilience #automated testing #aginext.io london 2020 #agile conferences #culture & methods #devops