text:
# zbMATH — the first resource for mathematics

Multidimensional scaling. 2nd ed. (English) Zbl 1004.91067
Monographs on Statistics and Applied Probability. 88. Boca Raton, FL: Chapman & Hall/ CRC. ix, 308 p. (2001).
The book under review is a comprehensive and rather self-contained text on Multidimensional (MD) Scaling. It includes classical MD scaling and its relation with Principal Components Analyis, Nonmetric scaling, Correspondence Analysis, Biplots, and more. It contains several fully elaborated examples and applications, from the classical $$m$$-judges $$n$$-wiskies setting to that of allocating 3 people in 2 rooms. This second edition further includes recent work by the authors (on Reciprocal Averaging) and others.
For a review of the first ed. (1994) see Zbl 0853.62047.

##### MSC:
 91C15 One- and multidimensional scaling in the social and behavioral sciences 91-01 Introductory exposition (textbooks, tutorial papers, etc.) pertaining to game theory, economics, and finance 62-01 Introductory exposition (textbooks, tutorial papers, etc.) pertaining to statistics 62H25 Factor analysis and principal components; correspondence analysis 62H99 Multivariate analysis
##### Keywords:
multivariate analysis; multidimensional scaling


text:
# Elm Chat Client for Typescript Chat Server

Since writing the Typescript chat server and client, I delved pretty deep into all of the fancy frontend frameworks and got to know them pretty well. They are fun to work in, but there is so much overhead involved, I started craving more similarity to my backend roots. I found some articles on Elm, and it peaked my interest. It looks so much like my favorite language (Haskell) that I wanted to try it out. When I first read the articles, the barrier to entry seemed enormous. There was a HUGE tutorial page for getting even the simplest thing to work in Elm. After a while, articles about using Elm in production started rolling in and the reviews weren’t bad. So I decided to take another look, and thankfully things had improved drastically. The documentation is clear and easy to follow, and I felt like I could get started quickly. So I decided to rewrite the chat client in Elm.

## Setup

First you need to install Elm and all the fancy tools that come bundled with it. This page was extermely helpful in everything from installing Elm, to describing each of the command line tools, to describing the language itself. I highly recommend taking a quick peek through all of the articles to get familiar with the language. After installing, let’s write some code!

## Dependencies

Dependency management for Elm relies on the elm-package.json file. This file can be updated manually or using the awesome elm-package dependency management tool. Here is what my elm-package.json looks like:

{
"version": "1.0.0",
"summary": "Chat Client",
"repository": "https://github.com/nprice1/elmChatClient.git",
"source-directories": [
"."
],
"exposed-modules": [],
"dependencies": {
"elm-lang/core": "5.1.1 <= v < 6.0.0",
"elm-lang/html": "2.0.0 <= v < 3.0.0",
"elm-lang/websocket": "1.0.2 <= v < 2.0.0"
},
"elm-version": "0.18.0 <= v < 0.19.0"
}

This should look very familiar for anybody who has looked at an npm package.json file. It shows the dependencies and all versions for those dependencies. Add this file to the root of your project. Run elm-package install to make sure all the packages are properly installed.

## The Code

Now we can get down to actually writing the code. The Elm Guide Architecture page provides a very helpful blueprint for all Elm code that looks like this:

import Html exposing (..)

-- MODEL

type alias Model = { ... }

-- UPDATE

type Msg = Reset | ...

update : Msg -> Model -> Model
update msg model =
case msg of
Reset -> ...
...

-- VIEW

view : Model -> Html Msg
view model =
...

All we need to do is fill in the gaps. The Elm architecture enforces the non-mutatable state ideas that are suggested by the Redux state management pattern. This means we can make some pretty direct comparisons to the original TypeScript Client. The Model will be our Redux state, the Update will be our Reducers, and the View will be our React components. So let’s start filling in this skeleton.

## Imports

First let’s import all the libraries we will need. First we import everything we need for our view:

import Html exposing (..)
import Html.Attributes exposing (..)
import Html.Events exposing (onInput, onClick)

The Html package gives us all of the HTML elements we need in order to actually render our view (div’s, span’s, input, etc.). The Html.Attributes package gives us the attributes we need for any of our view elements (like class, value, etc.). We actually only need value, but I’m just pulling in everything. We also need some events that we will be firing. For this app we only use text fields and buttons, so we only need the onClick and onInput events.

This app will be using Websockets, so we need to make sure to pull that in:

import WebSocket

Finally, we will be dealing with JSON payloads sent to/received from the server, so we need the JSON libraries from Elm to both encode and decode our messages:

import Json.Decode exposing (..)
import Json.Encode exposing (..)

As an extra bonus I also imported the Debug package to make sure I could log to the console in case anything fails:

import Debug exposing (..)

Now that we have all of our imports, we can move on to figuring out what our application state will look like.

## Model

The Model will represent our application state. Since we already did this when writing the TypeScript client, let’s look at what we did there:

import { Message as MessageModel } from 'type-script-server/src/models';

export interface ChatState {
messages: MessageModel[],
users: string[]
}

Our application state was pretty simple, we kept track of the current users (well really it was just the current user), and all of the messages that have been sent. We also had a type representing what our Message would look like:

export interface Message {
name: string;
message: string;
}

Since we already have these defined, let’s just move them over to Elm. First we will create a type to represent a message:

type alias Message = {
name : String,
message : String
}

Very straightforward conversion thankfully. Converting the Redux state to our application state is a tiny bit more complicated, though. In our React/Redux application, some of our components had their own internal state (like the current values in a text field) that we now have to keep track of in our core application state. Elm may have a way of separating this out, but since I’m just starting out I’m keeping it all in the same place. So here is our consolidated state:

type alias Model = {
currentMessage: String,
users : List String,
messages : List Message
}

The currentUserName and currentMessage are going to keep track of the current data in text fields, and then we have the users and message list like the React/Redux state.

The Elm application expects an init function that provides the inital Model and the command to run. Our init funciton is pretty simple:

init : (Model, Cmd Msg)
init =
(Model "" "" [] [], Cmd.none)

We provide a model with no username, no message, empty user list, and empty message list. We are also providing no command, because nothing needs to be done to init.

That’s it for the model, now we need to define how that model will be updated.

In our React/Redux application, our reducers handled the state updates. We had two reducers, one for adding users and one for adding messages. Since our application state is a bit more complicated, we will need a few more. To start, we define the Elm messages that we expect to receive:

type Msg =
UpdateMessage String |
NewUser |
SendMessage |

Here is the summary for each of these messages:

1. UpdateUserName: This replaces the React view that maintained its own state about the current user name for the login form. This updates the current user name. The parameter passed for this update is the new user name.
2. UpdateMessage: Like the UpdateUserName, this replaces the React view state that kept track of the current message before sending it. This updates the current message. The parameter passed to this message is the new message.
3. NewUser: This logins a user and updates the user list. Right now this is only fired when the current user logs in, not when other users login. This takes the place of the ADD_USER reducer. There is no parameter passed for this message, it uses data from the model.
4. SendMessage: Fired when the user sends a message. This will use the currentMessage state and send it using the Websocket. In our React/Redux application this was handled by a React component. No parameter is passed for this message, it uses data from the model.
5. ReceiveMessage: This is fired when we recieve a message from the WebSocket and we add it to the current list of messages. This takes the place of the ADD_MESSAGE reducer. The parameter passed to this message is the stringified JSON payload from the server.

### JSON Decoding/Encoding

All of this work hinges on something that it turns out is not as trivial as I was hoping in Elm: JSON parsing. Handling JSON in Elm relies on decoding (JSON to an Elm type) and encoding (Elm type to JSON), so we need to setup some helper methods to do that. First we will define the decoder:

messageDecoder : Decoder Message
messageDecoder = map2 Message (field "name" Json.Decode.string) (field "message" Json.Decode.string)

This function is used to create an Elm Decoder which can be passed a parameter and turn it into a given Elm type. This decoder says that when handed the parameter it is expecting a field called "name" which is a string, and a field called "message" which is a string and it constructs a Message with those two values. Now that we have the Decoder, we can make a function that takes stringified JSON and turns it into a message like so:

jsonToMessage : String -> Message
jsonToMessage messageJson =
case decodeString messageDecoder messageJson of
Ok message -> message

Err err ->
Debug.log ("Failed to decode message" ++ err)
(Message "" "")

This function takes in stringified JSON we get from the chat server and uses the Elm decodeString function which uses the decoder we created above to finally spit out a Message. We also get our first glimpse into some Elm error handling. The decodeString function returns a Result, which will either be Ok with the result, or Err with an error message. We are doing some very basic error handling here, logging if it failed and returning an empty message.

Next we need to define our encoder:

messageEncoder : Message -> Json.Encode.Value
messageEncoder message =
Json.Encode.object [ ("name", Json.Encode.string message.name), ("message", Json.Encode.string message.message) ]

This encoder takes in a Message and tells Elm how to create a JSON object out of it. The result of the encoder is always a Json.Encode.Value, which can be various things. In this case we want a JSON object with a string field "name" and a string field "message". Now that we have an encoder function we can create a helper function to get us our JSON:

messageToJson : Message -> String
messageToJson message =
encode 4 (messageEncoder message)

This function just uses the Elm encode function and uses 4 space indentation for the resulting JSON string.

Now we have everything we need to write our actual Update function:

update : Msg -> Model -> (Model, Cmd Msg)
update msg {currentUserName, currentMessage, users, messages} =
case msg of

UpdateMessage newMessage -> (Model currentUserName newMessage users messages, Cmd.none)

NewUser -> (Model currentUserName currentMessage (currentUserName :: users) messages, WebSocket.send webSocketAddress (createUserMessageJson "joined the chat" currentUserName))

SendMessage -> (Model currentUserName "" users messages, WebSocket.send webSocketAddress (createUserMessageJson currentMessage currentUserName))

ReceiveMessage userMessage -> (Model currentUserName currentMessage users (jsonToMessage userMessage :: messages), Cmd.none)

The update function takes in the Msg that was fired and the current Model for our application. We MUST handle all of the messages we have defined or else the compiler will complain. The result of the update function is the updated Model and any Cmd that needs to be run. The only Cmd we have is sending our messages using the Websocket. Here is an explanation for each of the modifications we make for the messages:

1. UpdateUserName: We get handed the new user name as the user types it in the text box, and we update the model with a new currentUserName. No commands is required.
2. UpdateMessage: Like the UpdateUserName, this updates the currentMessage and leaves everything else unchanged. No command is required.
3. NewUser: When we receive this message we add the current user (pulled from the currentUserName) to our list of users, and now we actually need to use a command. When a user joins the chat we need to send a message to the server. So, we use the WebSocket.send function and our createUserMessageJson helper function defined above to send our JSON payload for a user joining the chat.
4. SendMessage: First we reset the currentMessage field to reset the text input, and we send the JSON payload with the current message (before being erased).
5. ReceiveMessage: Whenever we receive a message from the server, we first convert it to a Message using our decoding helper function, then we add it to our messages list.

NOTE: The {...} syntax is used to spread values for a type, so we are just expanding the Model object into individual parameters. We also have a webSocketAddress constant defined here, you can see that value in the full code below.

## Subscriptions (WebSocket)

We have one way of firing a message from outside of our View, and that is the WebSocket. To make sure we catch when messages are sent we need to create a subscription for our WebSocket, which just fires a Msg whenever something is received from the server:

subscriptions : Model -> Sub Msg
subscriptions model =

I don’t pretend to fully understand this model, but my best guess is Elm allows subsriptions for certain events to fire Msg's. This one is telling Elm that whenever you receive a message from the given WebSocket, fire the ReceiveMessage message. The other way to fire Msg's is to use the view.

## View

Time to setup user interaction and actually rendering our app. Our view is very easy in this case:

view : Model -> Html Msg
view model =
case model.users of
[] ->
div []
[
input [ type_ "text", placeholder "User Name", onInput UpdateUserName, Html.Attributes.value model.currentUserName ] [],
button [ onClick NewUser ] [ text "Login" ]
]
_  ->
div []
[
input [ type_ "text", placeholder "Message", onInput UpdateMessage, Html.Attributes.value model.currentMessage ] [],
button [ onClick SendMessage ] [ text "Send Message" ],
div [] (List.map viewMessage (List.reverse model.messages))
]

viewMessage : Message -> Html msg
viewMessage msg =
div [] [ text (msg.name ++ ": " ++ msg.message) ]

We have two views here, one when we don’t have any users and one where we do. When we don’t have users we show a simple login form that updates the current user name in the model and a button that sends the NewUser message. After the user logs in we see a simple message form with a div underneath that displays all of the messages. Each HTML element in Elm has two arrays associated with them. The first array are the attributes, and the second is the content. Most of what we are doing here is related to attributes, the important ones being what we are using for the onInput, onClick, and Html.Attributes.value entries. The onInput and onClick attributes both point to a Msg that will be fired with the event. As a user inputs into the text box for the login form, for example, the UpdateUserName Msg will be fired with the current value in the text box, allowing us to keep track of the current username with all input. Then, the onClick for our button will send the NewUser Msg that sends the message to the server informing a user has logged in. The Html.Attributes.value points to the value in the model so that when we update the model (like clearing out the current message), it is reflected in the View.

## Putting it All Together

The last thing we need to do is tell Elm all of the pieces of our application. We do that with a Program that describes the model, view, updates, and subscriptions. Here is what our Program looks like:

main : Program Never Model Msg
main =
Html.program
{
init = init,
view = view,
update = update,
subscriptions = subscriptions
}

Each of these values correspond to what we added throughout this tutorial. Here is our full source code:

import Html exposing (..)
import Html.Attributes exposing (..)
import Html.Events exposing (onInput, onClick)
import WebSocket
import Json.Decode exposing (..)
import Json.Encode exposing (..)
import Debug exposing (..)

main : Program Never Model Msg
main =
Html.program
{
init = init,
view = view,
update = update,
subscriptions = subscriptions
}

-- MODEL

type alias Message = {
name : String,
message : String
}

type alias Model = {
currentMessage: String,
users : List String,
messages : List Message
}

init : (Model, Cmd Msg)
init =
(Model "" "" [] [], Cmd.none)

-- UPDATE

type Msg =
UpdateMessage String |
NewUser |
SendMessage |

update : Msg -> Model -> (Model, Cmd Msg)
update msg {currentUserName, currentMessage, users, messages} =
case msg of

UpdateMessage newMessage -> (Model currentUserName newMessage users messages, Cmd.none)

NewUser -> (Model currentUserName currentMessage (currentUserName :: users) messages, WebSocket.send webSocketAddress (createUserMessageJson "joined the chat" currentUserName))

SendMessage -> (Model currentUserName "" users messages, WebSocket.send webSocketAddress (createUserMessageJson currentMessage currentUserName))

ReceiveMessage userMessage -> (Model currentUserName currentMessage users (jsonToMessage userMessage :: messages), Cmd.none)

createUserMessageJson : String -> String -> String
createUserMessageJson message currentUserName =
messageToJson (Message currentUserName message)

messageDecoder : Decoder Message
messageDecoder = map2 Message (field "name" Json.Decode.string) (field "message" Json.Decode.string)

messageEncoder : Message -> Json.Encode.Value
messageEncoder message =
Json.Encode.object [ ("name", Json.Encode.string message.name), ("message", Json.Encode.string message.message) ]

jsonToMessage : String -> Message
jsonToMessage messageJson =
case decodeString messageDecoder messageJson of
Ok message -> message

Err err ->
Debug.log ("Failed to decode message" ++ err)
(Message "" "")

messageToJson : Message -> String
messageToJson message =
encode 4 (messageEncoder message)

-- SUBSCRIPTIONS

subscriptions : Model -> Sub Msg
subscriptions model =

-- VIEW

view : Model -> Html Msg
view model =
case model.users of
[] ->
div []
[
input [ type_ "text", placeholder "User Name", onInput UpdateUserName, Html.Attributes.value model.currentUserName ] [],
button [ onClick NewUser ] [ text "Login" ]
]
_  ->
div []
[
input [ type_ "text", placeholder "Message", onInput UpdateMessage, Html.Attributes.value model.currentMessage ] [],
button [ onClick SendMessage ] [ text "Send Message" ],
div [] (List.map viewMessage (List.reverse model.messages))
]

viewMessage : Message -> Html msg
viewMessage msg =
div [] [ text (msg.name ++ ": " ++ msg.message) ]

Now we can finally run it.

## Running the Client

In order to run this, you need to have the TypeScript Chat Server installed and running. Next, in the directory with your Elm Chat Client you can run elm-reactor. This will start a web server listening on port 8000. So when you visit http://localhost:8000/App.elm you should see an input field and a button (the login form). After entering a username and logging in, you should see a similar form that allows inputting messages. You can open a new tab in your browser at the same address and start chatting.

## Improvements

This chat client is pretty bare bones, shocking I know. There are a ton of things that can be done to improve how it works, but here are the things that jump out the most in my mind.

1. UI: The chat app looks like an MIT professors blog, bare bones HTML. Add some CSS to make it look like an actual application.
2. User List: Our user list state is meant to keep track of all users currently logged in, but right now it only tracks the current user. Getting this to actually keep track of users would be a nice touch. You can parse the nasty "joined the chat" message to get the user name, but the preferred approach would be to have the WebSocket send different messages for logging in and sending messages. If you wanted the real list of users, you would also need some persistence in the server.
3. Separate the State: A nice benefit of our React/Redux application was different React components can maintain there own state without polluting the core application state. Right now the currentUserName and currentMessage fields are cruft we hopefully don’t need to have in our core model. Elm hopefully supports breaking the state into individual pieces, otherwise the state would get bonkers pretty fast.

## Conclusion

All in all I really enjoyed writing this. Elm is a pleasant language and I can’t help but love anything that takes some ideals from Haskell. The architecture makes sense, and I love when programs can enforce “good” practices since I can safely admit that I, as a human programmer, can be super dumb sometimes. However, I do have two small complaints, both of which would only really be a problem at scale and may already have solutions I am unaware of:

1. JSON Handling is Annoying. We are dealing with very simple JSON objects here and it is already getting bloated, I can’t imagine what it would look like with large nested JSON objects.
2. Views could get gnarly. With large complex views, I’m not sure how readable or maintainable this representation of HTML will be. As long as you can modularize the view easily it wouldn’t be so bad, but this is just asking for mega 1000 line don’t-look-directly-at-it-you’ll-go-blind views.

In case it wasn’t obvious I am far from an expert on Elm and I make some assumptions in this post. If you notice anything incorrect please let me know in the comments!

format: plain


text:
# Number of elements

Printable View

• November 30th 2009, 07:32 AM
Sampras
Number of elements
Suppose $R(k) = \{(i,j): a_{i,j} \leq k \}$. Why does $|R(k)|= \left \lfloor \frac{k}{1} \right \rfloor + \left \lfloor \frac{k}{2} \right \rfloor+ \cdots + \left \lfloor \frac{k}{k} \right \rfloor$, where $k$ is a positive integer?


text:
# On the symplectic phase space of KdV

Kappeler, T; Serier, F; Topalov, P (2008). On the symplectic phase space of KdV. Proceedings of the American Mathematical Society, 136(5):1691-1698.

## Abstract

We prove that the Birkhoff map $\Omega$ for KdV constructed on $H^{-1}_0(\mathbb{T})$ can be interpolated between $H^{-1}_0(\mathbb{T})$ and $L^2_0(\mathbb{T})$. In particular, the symplectic phase space $H^{1/2}_0(\mathbb{T})$ can be described in terms of Birkhoff coordinates.

## Abstract

We prove that the Birkhoff map $\Omega$ for KdV constructed on $H^{-1}_0(\mathbb{T})$ can be interpolated between $H^{-1}_0(\mathbb{T})$ and $L^2_0(\mathbb{T})$. In particular, the symplectic phase space $H^{1/2}_0(\mathbb{T})$ can be described in terms of Birkhoff coordinates.

## Statistics

### Citations

3 citations in Web of Science®
3 citations in Scopus®

### Altmetrics

Detailed statistics

Item Type: Journal Article, refereed, original work 07 Faculty of Science > Institute of Mathematics 510 Mathematics English 2008 14 Jan 2009 16:04 04 Jan 2018 08:02 American Mathematical Society 0002-9939 First published in Kappeler, T; Serier, F; Topalov, P (2008). On the symplectic phase space of KdV. Proceedings of the American Mathematical Society, 136(5):1691-1698, published by the American Mathematical Society. https://doi.org/10.1090/S0002-9939-07-09120-4 http://arxiv.org/abs/0710.1381

Preview
Content: Accepted Version
Filetype: PDF
Size: 163kB


text:
Jul 15, 2020 • 20 min read

Modern businesses in e-commerce, banking, insurance, manufacturing and many other areas generate huge amounts of data every day. Effectively utilizing that data helps increase business value by making the right decisions at the right time based on insights generated from targeted data analytics.

In this article we describe our real-time cloud based Anomaly Detection Solution. We will cover its design and applicability to the most common use cases: monitoring, root cause analysis, data quality, and intelligent alerting. The solution is AI driven and implements a flexible approach based on normal state and behaviour patterns extraction, but does not rely on purely statistical methods. Therefore it can catch not only suddenly occurring outliers but can also reveal changes in the distribution of very noisy data.

The solution is configurable for various types of components and services and detects  abnormal behaviour in networks of connected services and collected data profiles. It can visualize abnormal places and make intelligent notifications based on them and provides tools for further deep analysis and RCA.

## Overview

Most application systems consist of multiple services and middleware components. This includes databases, queues, search engines, storage, identity services, caches, and in-memory data grids. They also include multiple stateful or stateless microservices and mobile application proxies — all connected by data and processing flows.

Each component produces system and application logs and usually collects system and application metrics through metric collection agents. In addition, data itself may contain important information that represents the state or behaviour of a service, process, or user. All of these can be aggregated and served as data sources for future analysis and real-time anomaly detection using the Anomaly Detection Solution.

The solution covers the following use cases:

1. Monitoring and root cause analysis - The solution features the Anomaly Detection Dashboard, which enables users to monitor the state of all components in real-time and provides functionality to build dependencies graphs. It displays services as nodes, and logical data workflows or functional relations between them as graph edges. Each service can have several metrics and graphs can show states of services for specified time points and histories. Thus graphs can be used to visualize an anomaly detection domain, a “degree of destruction” for subsystems if an issue was raised, or an impact of each component on one another via anomalies.There is the additional option to use an Anomaly Statistic chart. This highlights anomaly impacts in two dimensions: abnormal metrics count at specified time, and anomalies density. So the graphs and the statistics charts are good starting points for deep root cause analysis.
2. Data quality anomaly detection - A data profile is a collected statistic or an informative summary of the state of data. The solution provides mechanisms for detecting anomalies in the quality of data profiles. For example, it could be summary information about user feedback, system transactions, access actions and so on, which are onboarded to the anomaly detection pipeline as metrics. The only thing the customer needs to do is to create an ETL process, which transfers data from its source to Amazon Kinesis and defines an ingest configuration. Following that, ingested data will be available for anomaly detection and by creating the dependencies graph between data domains and their metrics, it is possible to accurately monitor anomalies in data quality.
3. Intelligent alerting - Alerting is implemented via emails that are configured in the Anomalies Detection Dashboard. Alert configurations can be created for one or more anomalies graphs. Each email contains information about abnormal metrics, time points, and anomaly distribution charts.

An alert is a more high-level entity than just an anomaly. It is essentially a group of anomalies and the number and density of them are determined by business rules that are set via the dashboard.

Experiments have been run with the current solution based on real-world data. They  showed a decrease in false positives (non-important abnormal cases) as well as false negatives (missed important abnormal cases). As an example, the following are evaluation metric values achieved for real-world e-commerce domain service anomaly detections:

• Precision ~ 0.9
• Recall ~ 0.92
• F1 score ~  0.909

To measure the classification metrics, which provides information about the anomaly detection quality, significant effort is required because a huge volume of metrics and timepoints must be analyzed and marked as normal or abnormal. The solution proposes to analyse only abnormal cases and related KPI’s (see Anomaly Detection KPI’s). It uses the solution labeling tool to collect user experiences in the anomaly importance verification process.

The solution is part of Grid Dynamics’ Analytical Data Platform. It consumes Amazon Services including AWS S3, RDS, EKS, Cloud Map, Secret Manager, Cloud Formation, Kinesis, Lambda, EMR, Sagemaker, etc., and has been published to Amazon Marketplace.

The current solution is an implementation of the Neocortex Neural Networks approach described in the Grid Dynamics Insights white paper [1] with Amazon Cloud Services. It is based on the Nupic HTM framework [4] integration and anomaly detection is based on the likelihood calculation for prediction errors (anomaly scores) distribution.

The solution provides complete implementation of a real-time anomaly detection workflow, including its deployment and scaling, external data onboarding, configuration, and tuning of ML models for specific tasks and domains.

The following features are available:

• A metrics and anomalies generator to simulate data for tools study and enterprise cases.
• Service dependencies graph design (Anomalies Graph).
• Real world services metrics data ingest for anomaly detection via streaming channel.
• Real-time anomaly detection.
• Time series, anomalies, ML models behaviour visualization.
• Abnormal behaviour in the Anomalies Graph visualization.
• Labeling tool to collect user experience in anomalies validation for further analysis, ML models tuning, alerting with machine learning approach.

Let’s now walk through the solution design.

## Design

### Anomaly Detection Workflow

The solution implements an anomaly detection workflow. It covers the end-to-end process from data collection through to information delivery on abnormal behaviours.

The first step occurs in the data domain. It consists of application, system, and analytics metrics values collected from monitoring of services and middleware components, data quality profiles, and logs. This data is pushed to one of the available channels: Elasticsearch index and streaming.

The Elasticsearch index is used for showcase purposes but at the same time demonstrates the capability to ingest data from data sources connected via the HTTP protocol. The streaming channel is ready for enterprise tasks and is a datasource for real-world customers’ data onboarding to the anomaly detection ecosystem.

The next step is data processing. It prepares ingested data to be input for ML models training and inference in real-time. The anomaly detection inference is a ML models prediction, where anomaly scores are calculated to obtain the likelihood (probability of abnormal cases) for comparison with the threshold.

The last step is anomaly visualization and notifications to recipients. It includes signal distribution and anomaly statistics charts as well as anomaly dependencies graphs.

The anomaly detection pipeline includes a data workflow. It consists of cells where each cell is a combination of the data input pin, configuration pin, data processing unit, and data output pin.

The data processing unit contains algorithms for one or more anomaly detection workflow steps. The data processing configuration is a set of parameters for data processing algorithms. The following diagram shows the processing units and transitions for the solution data workflow:

Each step is configured with settings stored in the relational DB. Data is persisted to and fetched for the next steps from Elasticsearch indices. The root point of the workflow is the ETL job implemented outside the solution by the customer to onboard real-world data to the anomaly detection ecosystem.

The anomaly detection core is the HTM Model together with its inference and the anomaly likelihood calculation logic. Neocortext Neural Network and Nupic HTM framework [4] integration is described in the Realtime Machine Learning section where we describe the ML model’s life cycle, their deployment units, and helper processes. However, to provide a brief description of the process:

• Each analyzed metric has its own HTM model.
• All models are hosted and run outside the data processing unit.
• The data processing unit invokes ML model endpoint for anomalies scores and likelihood calculations.
• Anomaly detection is logic to make a decision about current behaviour of a signal on an analyzed time period, abnormal or not.

### Deployment

Grid Dynamics designed and published the solution for the Analytical Data Platform (ADP). It provides the number of components deployed using Amazon Cloud Services to implement data and machine learning pipelines. All supported pipelines cover various business areas that consume data ingest, batch, and streaming data processing algorithms, etc.

Machine learning tasks are represented by computer vision, programmatic marketing, data quality, and anomaly detection. The anomaly detection case uses ADP components that provide the toolset, services, and resources for real-time processing and streaming. The following diagram represents the ADP components consumed by the anomaly detection elements.

The copy of the anomaly detection solution is run as an ADP use case or single item via Amazon Marketplace. It is a “one-click” deployment including configuration of ADP and anomaly detection parameters.

All anomaly detection resources and components are registered in the AWS Cloud Map for internal system discovery and discovery for user access. All credentials are generated in deployment time and available via AWS Secret Manager.

AWS Account allows the user to touch and consume all components of the solution. Only the Anomaly Detection Dashboard site is available via public network (ethernet). It is protected by the fact that credentials are created automatically during the deployment phase to access the site. All other components are available from the AWS VPCs or with port forwarding with kubernetes CLIs from a local desktop or laptop. Grafana is also available in the “viewer” mode from ethernet proxied by the Anomaly Detection Dashboard.

HTM models are hosted and run using the Amazon Sagemaker endpoint. One model version is hosted by only one endpoint instance. The current solution deployment provides only one Sagemaker endpoint for all HTM models. The solution design additionally only allows one instance per endpoint. Our default VM configuration for instance is ml.m4.xlarge. The maximum number of hosted HTM models is about 50. It’s possible to increase the number of models by scaling up the Sagemaker endpoint VM properties (instance type) or by scaling up horizontally the number of Sagemaker endpoints.

## Anomaly Detection KPIs

To measure the classification metrics that provide information about the quality of the anomaly detection process, significant effort is required. This is because a huge volume of metrics and timepoints need to be analyzed and marked as normal or abnormal.

Playing with various real-world domain data and simulations, we concluded that the true positives metric works sufficiently well. At the same time, the false positives metric should be decreased to avoid or decrease the number of noise alerts.

The labeling tool allows the user to mark abnormal cases as normal or abnormal. The precision metrics are calculated using labeled data:

$$Precision = \frac{TP}{TP + FP}$$

where:

• TP = True Positives = number of important abnormal cases,
• FP = False positives = number of handled abnormal cases that aren’t important.

The labeling sparsity (LS) is a measure of labeling coverage:

$$LS = \frac{Labeled Anomalies}{Total Anomalies}$$

So the precision and labeling sparsity allow for the construction of KPIs for the anomaly detection quality:

• LS >= 0.5
• Precision >= 0.9

The first one is achieved by the labeling tool consuming effort. It is required for the precision calculation and relevance. The expected precision is achieved by tuning the likelihood threshold and in some cases by more relevant metrics onboarding to the anomaly detection.  For example, when garbage collector metrics have changes in their signal distribution and lead anomalies, but the application is not impacted, then it is required to replace those metrics by a more relevant system or application metrics such as: heap size, available memory, latency, throughput, etc.

In cases where it is not possible to achieve an appropriate value for precision via the listed ways, it is necessary to conduct the tuning in the alerts configuration step. There are two threads to do it:

1. The graph anomalies business rule - this allows users to configure manual business rules to decrease the number of noise alerts.
2. AI Alerting - this is an automatically trained, evaluated, and deployed machine learning model that classifies anomalies to be sent as alerts using the user experience collected by the labeling tool.

## Tools

The solution internal processes are not visible for an end-user but it is possible to provide or modify their configuration, onboard data, and visualize processes behaviour and output. All these things are available via the solution tools:

• Anomaly Detection Dashboard
• Grafana Dashboards

### Anomaly Detection Dashboard

The Anomaly Detection Dashboard web application is the solution entrypoint and management portal. It provides tools to configure data ingest, new domains onboarding, ML models, and anomaly detection parameters.

The tool is designed to minimize the data science effort in ML models design and tuning. All model hyperparameters are configured with default values that are appropriate for most cases. It means that any analyst or production engineer can start to work with anomaly detection. At the same time the solution allows for tuning of the hyperparameters by creating a new version of the model and validating anomaly detection in real-time for new parameter values.

There are two types of hyperparameters:

• SDR encoder parameters - encoders transform metric values into sparse distributed representations (SDR). SDR is the core binary representation of data for the Neocortex model components sequence: input, encoder, spatial pooler, sequence memory, prediction.
• Likelihood calculation parameters - likelihood is based on the tail Gausian distribution function calculation for moving Z-scores for prediction errors obtained from HTM model neuron state statistics. See [2] for details.

It is possible to manage the training and detection processes using Train and Detect flags. The Detect flag enables HTM model prediction and anomaly detection logic. The Train flag enables HTM model learning (training). The HTM model is trained in real-time. Each new metric value is used for model training and for model inference (anomaly detection). So it is possible to suspend training if a user makes a decision that a signal pattern has been defined and all future changes of a signal behaviour can be explained as abnormal. Conversely, if the user needs to continue learning to define new pattern properties, then it is possible to resume training using this flag.

The Anomaly Detection Dashboard configures notifications about anomalies as emails sent to recipients such as production and support engineers or customers. It also provides a labeling tool to collect user experiences in anomaly validation.

The Anomaly Detection Dashboard is an anomaly monitoring panel. It visualizes anomaly statistics and service dependencies graphs to assist in Root Cause Analysis (RCA). It highlights anomalies and anomaly graph states in real-time or may be used for historical anomaly analysis.

It also provides a Metric Generator, which allows for the building of a simulation of user services and metrics, or trying various ingest channels and anomalies. This essentially allows users to trial a wide range of metrics and services to gain a comprehensive picture of the solution and tools.

### Grafana Dashboards

Grafana is used by thousands of companies to monitor everything from infrastructure like power plants to applications and beehives. The anomaly detection solution provides Grafana dashboards to visualize metrics time series, anomalies highlights, ML models behaviour as distribution of anomaly scores and likelihood.

Grafana dashboards are referenced by metrics links visualized in Anomalies graph in the Anomaly Detection Dashboard.

Now it is time to describe anomaly detection use-cases covered by the solution implementation.

## Use Cases

### Monitoring and Root Cause Analysis

The Anomaly Detection Dashboard contains a predefined anomalies graph “Showcase” built with simulated metrics and services. Users can modify or create new graphs to run simulations with real-world components and data.

Anomalies graph is a services/components/subsystems domain dependencies chart. It displays services as nodes and logical data workflow or functional relations between them as graph edges. All nodes are “green” in the normal state. But if the solution detects an abnormal case for a metric then its service will be shown in “red”.

The graph shows states for specified time points and stores their histories. It means that by browsing time points (via calendar control), users can obtain current and historical states of the graph.

If a user clicks on any node of the graph then a list of all its metrics available for a specified time point is shown. Those with anomalies are shown in red for the select times.

It is possible to enable auto refresh to show the current state of the graph every minute.

Any graph plays several roles:

• It visualizes an anomaly detection domain.
• It visualizes a “degree of destruction” for the subsystem if an issue was raised.
• It visualizes impacts on components by other components via anomalies. So it is the starting point of deep root cause analysis (RCA).

The Showcase anomalies graph demonstrates the high-level design of the current solution and simulates real-world domains. Each component of the architecture contains a list of simulated metrics. For example, the Airflow service contains the CPU Load and Available Memory metrics.

On the screen below, the abnormal state of the graph is shown:

Three related services are in an abnormal state: Airflow, Sagemaker Model Endpoint, and Dashboard API. The Airflow CPU Load metric has an anomaly. The Sagemaker Model Endpoint also has an abnormal case for the Latency metric: the Available Memory metric is abnormal for Dashboard API.

So it is possible to create the following hypothesis for the root cause analysis (RCA):

• The Sagemaker Model Endpoint service has some issues that impacted its latency. For example, some HTM model training cycles require a large amount of time to complete.
• Airflow DAG’s multithreaded or parallel tasks invoked model training and inference. But their execution required a very large time period because Sagemaker endpoint latency was dramatically increased. So the first portion of parallel tasks was not completed and the next portion of tasks was started in the same time range. So CPU load was increased.
• It also seems that Dashboard API requests that invoked Sagemaker Endpoint had delays and did not free up service memory in time. In addition, throughput was impacted so in this scenario it appears that users should wait for the next time point.

The Anomaly Detection Dashboard also contains the Statistic chart. It is a very useful component of the dashboard because it highlights anomaly impacts across two dimensions:

• Abnormal metrics count at a specified time - if there are many abnormal cases at observed time points then the number of abnormal metrics will be increased, which is a cause for concern.
• Anomalies density - this refers to the density of abnormal cases during a selected time period. If users regularly observe anomaly cases then the system will likely have long term issues or down time.

### Data Quality Anomaly Detection

This section details the solution application for real-world cases for example, anomaly detection in the data quality profile. The customer business system collects data, which is then split across several data domains:

• Feedbacks
• Transactions
• Access

Each domain has the same list of data quality metrics:

• Number of empty values - empty values indicate information is missing from the data set.
• Dark amount - how much information is unusable due to data quality problems?
• Time-to-value - how long does it take for the business to derive value from the information?

Data profiles are also described by data business markers:

• Pos state ratio - how many records have “some positive business” state? For example, the number of completed transactions or positive feedbacks.
• Neg state ratio - how many records have “some negative business” state? For example, the number of incomplete transactions or number of negative feedbacks.

We assume that data domains have dependencies. Access data metrics impact transaction and feedback domain metrics and feedback domain metrics impact transactions.

The first step in the anomaly detection process is data ingestion from a client data source into the anomaly detection ecosystem. The solution provides the Amazon Kinesis data stream configured for the client to transfer data.

Data records should have a valid JSON format with corresponding schema. Data example:

[{
"service_name": "Transactions",
"metric_name": "Dark Amount",
"metric_unit": "AMT"
"time":  "2020-04-21T08:23:00Z",
"value": 25.0,
"source": "Data Quality"
}]

There are various ways to implement the ETL process for this step. For example, users can create an Airflow DAG fetching their data from the original datasource and push records to the destination data stream consuming the Kinesis data stream hook.

As soon as data begins being sent via the ETL job to the solution data stream, it is necessary to add the data ingest configuration to allow the data to be onboarded for the anomaly detection pipeline. This step allows for the data source to be defined, ingest tasks partitioning, and criteria to be filtered for data pushed to the data stream. It also allows for the creation of metrics names to be represented on the solution side with specified patterns. It is managed by the Data Ingest Configuration tool provided in the Anomaly Detection Dashboard:

Ingested data is now available for anomaly detection. The time series for ingested data can be analyzed with the Grafana Anomalies dashboard to get minimal and maximal values or to consume original knowledge about data distribution. The anomaly detection is enabled by configuring HTM models for each metric. Its behaviour is visualized via the Grafana Anomalies dashboard:

Corresponding to default configuration and likelihood calculation logic, the anomaly detection will begin producing scores immediately however, real likelihood values (greater than 0.5) will be generated after lkh_learning_period + lkh_estimation_samples (288 + 100 = 388) minutes.

Designing the dependencies graph between data domains and their metrics with the solution Graph Management tool, it is possible to create a new panel to monitor data quality anomalies and visualize abnormal states for further RCA:

Alerting is implemented with emails sent by the solution job, which is configured with the Anomalies Detection Dashboard. The anomaly detection solution allows for the configuring of parameters within the SMTP server and credentials via AWS Cloud Map and AWS Secret Manager.

Alert configuration is created for one or more anomaly graphs. Each email contains information about abnormal metrics, time points, and anomaly distribution charts as attachments. The alerts machinery calculates aggregations for metrics of those graphs.

The business rule is a logical expression that contains logical and comparison operations and aggregations names as variables. Logical expression is constructed using JSON-like DSL. It’s schema is shown below:

{
"$id": "https://www.griddynamics.com/ai4ops.alert.rule.schema.json", "$schema": "http://json-schema.org/draft-07/schema#",
"type": "object",
"properties": {
"and": {
"$ref": "#/definitions/conditions" }, "or": { "$ref": "#/definitions/conditions"
}
},
"oneOf": [
{"required": ["and"]},
{"required": ["or"]}
],
"definitions": {
"condition": {
"type": "object",
"properties": {
"agg": {"type": "string", "enum": ["event_counter", "metric_counter"]},
"lt": {"type": "number"},
"gt": {"type": "number"},
"eq": {"type": "number"},
"le": {"type": "number"},
"ge": {"type": "number"},
"ne": {"type": "number"}
},
"oneOf": [
{"required": ["agg", "lt"]},
{"required": ["agg", "gt"]},
{"required": ["agg", "le"]},
{"required": ["agg", "ge"]},
{"required": ["agg", "eq"]},
{"required": ["agg", "ne"]}
]
},
"conditions": {
"type": "array",
"minItems": 1,
"items": [
{
"type": "object",
"properties": {
"and": {
"$ref": "#/definitions/conditions" } } }, { "type": "object", "properties": { "or": { "$ref": "#/definitions/conditions"
}
}
},
{
"\$ref": "#/definitions/condition"
}
]
}
}
}

From the schema there are two aggregation variables:

• Event_counter - the number of abnormal events along the analyzed time period.
• Metric_counter - the number of unique metrics where abnormal cases were found along the analyzed time period.

For example:

{
"and": [
{
"agg": "event_counter",
"ge": 5
}
]
}

It means that the logical expression is TRUE if the number of abnormal cases is greater or equal to 5 along the analyzed time period. If the logical expression (rule) has value TRUE, then a notification is sent.

The user can change existing alerts or create new ones by filling out additional email and job properties:

The following is an example of the expected alert email content that recipients would receive:

### User Experience Collection

The solution allows users to collect user experiences in the anomaly validation process. This is achieved via the Labeling Tool, which asks each user (analyst, production engineer, data engineer etc) only one question about each anomaly along the analyzed time period: “Is the anomaly important?”. The users' answers are then stored to the Elasticsearch index.

This experience can then be used for model and algorithm tuning, threshold configurations, and alerts design with supervised machine learning.

The Labeling Tool is available with the corresponding page in the dashboard for each configured anomalies graph.

It visualizes metrics distribution and abnormal places at selected time points. Users answer questions for all anomalies detected along the time period.

## Real-time Machine Learning

Each analyzed metric must have its own HTM model. There can be several versions of the model for a metric with different hyperparameters but there can only be one active version of the model that performs predictions.

In the Anomaly Detection Solution the HTM model consists of two artifacts: a NuPIC HTM model and an appropriate NuPIC Anomaly Likelihood object. The lifecycle of the model is as follows. Right after the creation of the HTM model, it contains the raw NuPIC model and likelihood objects tuned with the specified hyperparameters and is ready for training and predictions.

As described in the Anomaly Detection Dashboard section, the HTM model can be in two states: train or detect. After some time, a user can turn off model training, after which the model will only make predictions. It also periodically makes backups of the model in storage, no matter what state the model is in.

A Spark Streaming job executes inference logic: every minute it sends data for an individual metric to an appropriate HTM model to generate an anomaly score and anomaly likelihood. If the received data was known for the model, then the anomaly score is zero. If the data was not known, then the score is one. Partially known data has a score between zero and one.

The anomaly likelihood shows the probability of anomaly behaviour in the context of historical changes of metric data. If the received anomaly likelihood is greater than the predefined likelihood threshold for this metric, then the data point is an anomaly.

The HTM model is hosted on a SageMaker Endpoint in a custom Docker container. One SageMaker model contains several HTM models. Each HTM model is loaded to RAM for the purposes of real-time training and inferences.

There are two ways for HTM models to be loaded to a SageMaker Endpoint. The first is to create a new model via a user request and the second is to import an already existing HTM model from the Amazon S3 bucket to a SageMaker Endpoint.

The creation process of a new HTM model is shown on the HTM model workflows diagram and labeled with the number 1. In this case, meta information about the model (including its hyperparameters and parameters of likelihood calculation) is persisted to the database. Anomaly likelihood objects and a new NuPIC HTM model are then created in RAM and immediately persisted to the Amazon S3 bucket. It is necessary to be able to import this new model if the user changes the endpoint of the model for example.

The import functionality is implemented by using Apache Airflow (the process is labeled with the number 2 on the workflows diagram). Import DAG periodically checks whether the HTM models are loaded into the appropriate endpoints. It retrieves the mapping between the HTM models and SageMaker Endpoints from the database, then sends requests to endpoints to determine whether it needs to import an HTM model or not. If a SageMaker Endpoint does not contain a specified HTM model then it downloads it from S3 bucket. At the same time, the Import DAG periodically checks the status of that process and notifies if any errors have occurred.

The Anomaly Detection Solution provides export functionality, which allows for the periodical backup of all HTM models to S3 bucket and thereby saves their learning progress. It is also implemented using Apache Airflow (the process is labeled with the number 3 on the workflows diagram).

The logic of the Export DAG is as follows. It first maps the HTM models and SageMaker Endpoints from the database and sends export requests to the appropriate endpoints. Each endpoint prepares the HTM models for export: temporarily disables learning of the model and packs it with an appropriate likelihood into a single artifact. As soon as Export DAG knows that the artifact is ready, it downloads it to the filesystem of the Airflow virtual machine, fits the artifact to the specific structure, then uploads it to S3 bucket.

## Conclusion

The current solution is built to implement an end-to-end real-time anomaly detection pipeline. It contains tools to manage data processing units, build ML models, and visualize abnormal behaviour.

The solution is available as an Amazon marketplace service. It contains showcases with simulated data, which allows the user to touch and use all the features and steps of the pipeline. It is ready for real-world anomaly detection cases and customer data onboarding and is able to be scaled up to increase the number of processed metrics.

The core property of the solution is real-time machine learning. It is implemented with the Nupic framework and helper processes, which are integrated to the anomaly detection workflow.

It is deployed with a “one-click” procedure, which requires that the user configure the deployment properties only. It consumes Amazon Cloud Services and components are deployed and configured with Grid Dynamics’ Analytical Data Platform.

Grid Dynamics proposes that the solution can be extended and further customized for specific business cases spanning computer vision, NLP, fraud detection, and many other potential uses.

## References

1. Unsupervised real time anomaly detection, Alex Rodin, white paper, Grid Dynamics Blog
2. Unsupervised real-time anomaly detection for streaming data, Subutai Ahmad, Alexander Lavin, Scott Purdy, Zuha Agha, Neurocomputing
3. Why neurons have thousands of synapses, a theory of sequence memory in neocortex Front. J. Hawkins, S. Ahmad, Neural Circuits., 10 (2016), pp. 1-13
4. Numenta Platform for Intelligent Computing, GitHub


text:
# Are low interest rates dangerous?

Interest rates keep dropping. In my country in northern Europe we now have negative interest rate - banks have to pay the central bank for lending it their money.

I have two questions:

1. Why are interest rates lower than any time ever before?

2. Are low interest rates dangerous? The low interest rates will make it easier to borrow money for projects that would otherwise not have been possible. Irresponsible lending has proven dangerous in the past.

Are the low interest rates a way that the central banks are "artificially resuscitating" a poor economy which may finally lead to a crash?

Adding that we have never seen this situation before I ask if this situation with extremely low interest rates is dangerous?

One aspect of the question is: Are these low interest rates expected to stay low or are they considered an extreme value in a cyclic variation?

• – serakfalcon Mar 8 '15 at 8:02
• also, I suggest asking the related question as a separate question. – serakfalcon Mar 8 '15 at 8:03
• I agree. Could OP remove the first part of the question (since there was a first attempt to answer 2.) into a new question? – FooBar Mar 8 '15 at 13:39
• I think the question is significantly different from the question quoted in the comments. The answer that has come is related to the question as a whole. I therefore wish to keep the question as it is. / With "dangerous" I naturally mean (as said) that some kind of economic crash (e.g. stock market) may occur. – cvr Mar 8 '15 at 13:51
• @ycc_swe you still have 2 separate questions: i) historical evidence ii) is this dangerous. There is no need to have both together. It's the other way around, the stack exchange system is optimized at having every question deal with a separate issue. – FooBar Mar 8 '15 at 14:55

If by dangerous it is meant they add possible downwards volatility of assets, that could easily be argued for as:

$PV = D / (1+r)^t$

Where D denotes any future income. This is especially the case if the reason for the low rates is very easy monetary policy, as such policy cannot be maintained and thus the rate is not equilibrium rate and must rise, causing a crash in asset values when that happens.

Central banks determinate the interest rates in the short run, their policies are targeted to lower rates, thus a low rate. The other reason is that of supply and demand. There is not much demand for credit (no profitable ideas, no more room for consumer credit) and on the other hand the supply of credit is significant due to central bank action. High supply and low demand equals a low rate.

• But that formula for discounting future $D$ only holds for $t$ in the future if $r$ is expected to be the interest rate until $t$. If $t$ is far in the future, then it is unlikely that this can come about due to the central bank, whose control of real interest rates is inherently a short-to-medium term thing (as you mention). This puts a limit on the extent to which a central bank can affect asset prices, at least through this channel. – nominally rigid May 9 '15 at 16:49
• @nominallyrigid That's not the correct interpretation of the equation. But I think this is easier to interpret through supply and demand, if the central bank stops demanding, prices crash. After all the interest rate just signals about the drop in demand. However, to arrive at the correct interpretation, think you bought a govt bond yielding 5 %, with bond interest rates obviously at 5%. Now interest rates rise to 10%. Your bond just lost half its value as you can get bond yielding 10 % for same price as you bought the 5% yielding with. Thus future rates have no bearing, r is the current rate. – Dole May 11 '15 at 22:55

A central bank sets the interest rates for banks (i.e. not us mere mortals) to borrow from it.

Low interest rates are a central bank's tool to try and encourage banks to lend, thereby encouraging all sorts of helpful behaviours like investment and home-buying. (If rates are low, that should mean borrowing for mortals is cheap, because you'd hope the banks pass on those low central bank rates to their customers!)

But if there's something fundamentally "wrong" with the economy, banks won't lend and/or people won't want to invest/borrow however low the interest rates get. After all, the idea of being in debt might be worrying to people per se, not just because of the interest repayments.

So the central banks have been lowering and lowering rates, desperate to kickstart the economy, but it's not been working, because there's something just "wrong" with the economy, and it's got nothing to do with interest rates.

That could be to do with banks being scared to lend (not enough money in their safety cushions perhaps?) or people/firms being too scared to borrow/invest (worries that things will get worse in the near future maybe?)

So rates get ever lower, and still the economy doesn't get moving.

• What does "kickstart the economy" actually mean? – user253751 Dec 20 '19 at 12:59
• That's a great question @user253751. Worthy of it's own question on this site in fact! Put a link to this answer in your new question. – LondonRob Jan 6 '20 at 15:00

Zero rates don't seem to have helped resuscitate Japan's economy to the point where they can be raised again and negative rates are a big unknown.

We're only going to see what its effects are in the years going forward, but it is fair to say that market valuations have been greatly distorted by this sort of free money.

Perhaps a better form of stimulus than going negative rates would be a guaranteed universal basic income. They benefit everybody rather than just those who are in a position to borrow for free and/or to get paid to borrow.


text:
# Inverse of Matrix Calculator

X

X

## How To Use Inverse of Matrix Calculator

Lets first understand, what is the inverse of a matrix and how we can find the inverse of a matrix?

Definition: A matrix is an ordered rectangular array of numbers or functions. The numbers or functions are called the elements or the entries of the matrix.

A matrix having m rows and n columns is called a matrix of order m × n or simply m × n matrix (read as an m by n matrix).

We denote matrices by capital letters. Some examples of matrices:

$A= \begin{bmatrix} a & b & c \\ d & e & f \end{bmatrix}, B=\begin{bmatrix} g & h \\ i & j \\ k & l \end{bmatrix}$ $C= \begin{bmatrix} m & n & o \\ p & q & r \\ s & t & u \end{bmatrix}$

Square matrix

A matrix in which the number of rows are equal to the number of columns, is said to be a square matrix.

$P= \begin{bmatrix} 1 & 2 & 3 \\ 4 & 5 & 6 \\ 7 & 8 & 9 \end{bmatrix}$

Identity matrix

A square matrix in which elements in the diagonal are all 1 and rest are all zero is called an identity matrix.

$I_{1}=\begin{bmatrix} 1 \end{bmatrix},I_{2}=\begin{bmatrix} 1 & 0 \\ 0 & 1 \end{bmatrix}$ $I_{3}= \begin{bmatrix} 1 & 0 & 0 \\ 0 & 1 & 0 \\ 0 & 0 & 1 \end{bmatrix}$

Ones matrix

A matrix is said to be ones matrix if all its elements are one.

$A= \begin{bmatrix} 1 & 1 & 1 \\ 1 & 1 & 1 \\ 1 & 1 & 1 \end{bmatrix}$

Invertible matrices

Definition: If A is a square matrix of order m, and if there exists another square matrix B of the same order m, such that AB = BA = I, then B is called the inverse matrix of A and it is denoted by A-1. In that case A is said to be invertible.

$A=\begin{bmatrix} 4 & 3 \\ 2 & 1 \end{bmatrix}, B=\begin{bmatrix} -0.5 & 1.5 \\ 1 & -2 \end{bmatrix}$ $AB= BA= \begin{bmatrix} 1 & 0 \\ 0 & 1 \end{bmatrix} =I$

Note:

1. A rectangular matrix does not possess inverse matrix, since for products BA and AB to be defined and to be equal, it is necessary that matrices A and B should be square matrices of the same order.

2. If B is the inverse of A, then A is also the inverse of B.

For calculating the inverse of a matrix using above matrix inverse calculator, you have to first set the order of matrix, then enter the matrix and press confirm button, after that choose the operation, then you will get the resultant matrix in the Result section.


text:
Intended for healthcare professionals

Research

# Five year outcomes in a cohort study of physicians treated for substance use disorders in the United States

BMJ 2008; 337 (Published 04 November 2008) Cite this as: BMJ 2008;337:a2038
1. A Thomas McLellan, chief executive officer1,
2. Gregory S Skipper, medical director2,
3. Michael Campbell, research scientist3,
4. Robert L DuPont, president3
1. 1Treatment Research Institute, 600 Public Ledger Building, 150 S Independence Mall, Philadelphia, PA 19106, USA
2. 2Alabama Physician Assistance Program, Montgomery, AL, USA
3. 3Institute for Behavior and Health, Rockville, MD, USA
1. Correspondence to: A T McLellan tmclellan{at}tresearch.org
• Accepted 28 August 2008

## Abstract

Objective To evaluate the effectiveness of US state physician health programmes in treating physicians with substance use disorders.

Design Five year, longitudinal, cohort study.

Setting Purposive sample of 16 state physician health programmes in the United States.

Participants 904 physicians consecutively admitted to one of the 16 programmes from September 1995 to September 2001.

Main outcome measures Completion of the programme, continued alcohol and drug misuse (regular urine tests), and occupational status at five years.

Results 155 of 802 physicians (19.3%) with known outcomes failed the programme, usually early during treatment. Of the 647 (80.7%) who completed treatment and resumed practice under supervision and monitoring, alcohol or drug misuse was detected by urine testing in 126 (19%) over five years; 33 (26%) of these had a repeat positive test result. At five year follow-up, 631 (78.7%) physicians were licensed and working, 87 (10.8%) had their licences revoked, 28 (3.5%) had retired, 30 (3.7%) had died, and 26 (3.2%) had unknown status.

Conclusion About three quarters of US physicians with substance use disorders managed in this subset of physician health programmes had favourable outcomes at five years. Such programmes seem to provide an appropriate combination of treatment, support, and sanctions to manage addiction among physicians effectively.

## Introduction

About 10-12% of physicians in the United States develop a substance use disorder.1 Those whose condition is detected and who are confronted—typically by their colleagues—are usually referred to the state physician health programmes for intervention, treatment, professional support, and long term monitoring. These programmes began in the United States in the 1970s as volunteer groups of physicians to assist colleagues with alcohol, drug, and mental health problems. The groups evolved into formal agencies operating under the authority of state physician licensing boards. The aim was to reduce public health problems caused by “impaired physicians” through early detection, treatment, and monitoring of substance use and other health problems that cause impairment.

Affected physicians typically are referred to one of these programmes by colleagues or regulatory agencies (for example, hospital board, state licensing board) under the allegation or formal charge of “impaired performance” due to problems with substance use or mental health. Once a formal evaluation has determined that a physician has a problem, a signed contract is arranged under which no further reporting or action occurs pending satisfactory completion of formal treatment, followed by five years of regular monitoring (urine testing).2 Thus there is a substantial incentive for physicians to complete treatment and monitoring to enable them to continue practising medicine.3

It is important to emphasise that the physician health programmes do not treat physicians. They provide evaluation and diagnosis, develop a contract detailing treatment or monitoring, coordinate and facilitate formal treatment and ongoing professional support, and carry out regular monitoring through random visits to places of work and regular screenings for alcohol and drugs—typically for five years.2 The programmes also act as intermediaries between the physician and various regulatory parties (for example, licensing boards, insurers, hospital practice boards). Although variability in the number of affected physicians across the 49 active state programmes (5 to 180 physicians) is considerable, the average programme manages about 65-75 physicians, at an operating annual cost of about $521 000 (£301 000; €381 000)—paid for primarily through a charge appended to all physicians’ licensing fees (about$23 for each physician in most states). These operating costs do not, however, include formal treatment costs for the physicians. Such costs range from about $5000 to$40 000 (depending on the mix of outpatient and residential care) and are typically paid for by a combination of the physician’s health insurance and out of pocket expenses. A full report of the structure and function of physician health programmes is documented in a companion article.2

Given the potential public health and safety problems caused by addiction among physicians, evaluation of the effectiveness of care and supervision provided by physician health programmes is important. This is made more important by the fact that studies of these programmes have been short term self evaluations of individual programmes.4 5 6 7 Although most of the results from these studies have been positive, few have been independently audited or have provided longer term results.5 7 These are important gaps in information. Colleagues need to know whether it is prudent to refer a physician to one of these programmes. Licensing boards, insurers, and patients have the right to know the effectiveness of these programmes. Outcomes from mainstream addiction treatment in the general population have consistently shown poor compliance rates during treatment, and relapse rates of 40-60% within six months of completing treatment.8 9 10 11 12

We carried out a two stage independent evaluation of physician health programmes in the United States. In the first study we surveyed 42 of 49 active programmes, describing the personal and professional histories, substance use, and other health problems of the physicians, as well as the intervention, evaluation, referral for treatment, and monitoring activities after treatment provided by those programmes.2 This second longitudinal cohort study reports the outcomes in 904 physicians consecutively admitted to a purposive sample of 16 of those programmes and followed for five years. We focused on three outcomes, measured through audited medical records and laboratory tests: completion of the programme, continued alcohol and drug misuse, and occupational status at five years.

## Methods

We carried out a retrospective, longitudinal, cohort study over five years from 1 September 1995 to 1 September 2001 of all physicians consecutively admitted to one of the 16 physician health programmes sampled. We examined the laboratory and medical records of the physicians during the five years.

### Setting, participants, and outcomes

The 42 programmes that participated in the first study were eligible to participate in this second study. Requirements were the availability of records on alcohol and drug testing in a computer analysable format (n=20) and the ability to retrieve information on personal characteristics, participation in treatment, and outcomes of the physicians from their records (n=16). All eligible programmes were included in the study.

The programmes that did and did not participate in the follow-up study were not statistically or clinically significantly different for evaluation, referral, treatment, supervision, support, and monitoring practices. The 16 participating programmes tended to be large: 31% were in the largest quarter of programmes. The mean number of physicians in each programme was 76 (range 11-119).2 Although these 16 programmes may not be considered nationally representative, they showed no obvious clinical, administrative, or organisational differences from those not participating.

All 904 physicians with a diagnosis of substance misuse or dependence admitted to the 16 programmes from 1 September 1995 to 1 September 2001 met the inclusion criteria. We restricted the evaluation to objective data from official records (for example, treatment services, attendance, sanctions by the programme, reports to licensing boards) and from laboratory records (urine tests and other specimens).

### Review of medical records

To protect the confidentiality of the physicians, data were collected by members of each programme’s medical records department. Data were collected between November 2006 and January 2007 under training, supervision, and monitoring by the authors.

#### Lost to follow-up

During the study 102 of the 904 (11.3%) participants moved out of their state programme’s jurisdiction. We had no access to any continuing records for those participants (figure). We therefore carried out analyses on the remaining 802 physicians.

Flow of physicians through trial

#### Missing data

As we used official records there were few instances of missing data (<4%). We report simple descriptive statistics with no substitution procedures for missing values.

### Participants’ characteristics

The participants were predominantly men (87%). The average age was 44 years. Sixty three per cent were married, 18.0% were divorced or separated, and 15.9% were single. Five medical specialties represented more than 50% of physicians: family medicine (20.0%), internal medicine (13.1%), anaesthesiology (10.9%), emergency medicine (7.1%), and psychiatry (6.9%).

The primary drug problems were alcohol (50.3%), opiates (35.9%), stimulants (7.9%), or other substances (5.9%). Fifty per cent reported misusing more than one substance and 13.9% reported a history of intravenous drug use. The average duration of substance misuse was five years. Seventeen per cent had been arrested for an alcohol or drug related offence and 17.0% reported previous treatment for substance misuse.

Fifty five per cent of participants were formally mandated to enter the physician health programme by a licensing board, hospital, insurer, or other agency. The remaining 45% were informally mandated by families, colleagues, employers, or some combination, with the implicit threat of formal action pending results of care.

### Clinical and monitoring procedures

The typical programme consisted of two stages: formal treatment at a specialty addiction programme followed by supervision after treatment.2

#### Formal treatment

Overall, 78% of physicians entered residential treatment (mean 72 days, range 30-90), always followed by outpatient treatment (1-3 nights a week) for a recommended 6-9 months. The remaining 22% went directly to outpatient treatment. With good compliance and positive progress, physicians were eligible to return to work under supervision about six months after the start of treatment.

Regardless of setting or duration, most treatment (95%) comprised 12 steps, with the goal of total abstinence from alcohol and other drugs of misuse.13 14 The physicians were expected to attend Alcoholics Anonymous or other 12 step groups (92%). Most were encouraged to attend meetings of the Caduceus Society (support group for healthcare providers’ recovery) throughout the remaining years of their contract.

Use of addiction pharmacotherapy as a component of treatment was rare. Only one of these physicians was prescribed methadone for an opiate misuse problem; 46 (6%) were prescribed naltrexone for treatment of alcohol or opiate misuse. In total, 257 physicians (32%) were prescribed an antidepressant for comorbid depression or anxiety disorders.

#### Supervision after treatment

After completion of formal treatment the physicians received coordinated monitoring in several forms.

#### Alcohol and drug testing

A key component of monitoring was random drug testing. Urine was tested in 99.2% of physicians, with rare use of hair (0.2%), saliva (0.1%), and breath (0.6%). Participants were required to phone their programme each workday to find out whether they should report for testing that day, on the basis of random selection. Testing was carried out four times a month early in care, tapering to one or two times a month throughout the monitoring period. The frequency of monitoring was, however, contingent on results of urine testing and compliance with other elements of the care plan.

About 75% of urine sample collections were directly observed by staff responsible for collection. In other cases dry room collection procedures were used. Testing included more than the usual five substance test panel. A typical panel covered 20 substances, including amphetamines, barbiturates, benzodiazepines, opiates, several opioids, cocaine, cannabinoids, and ethyl alcohol.

#### Additional monitoring and response to problems

Participants were expected to attend scheduled appointments for clinical evaluation. They also received random, unannounced visits at their place of work from programme monitors.

If substance use was detected by testing or identified from any other source, almost all the programmes reacted clinically, with combinations of re-evaluation (54%), increased monitoring (43%), and intensified treatment (46%). Forty two per cent of programmes also reported the incident to a licensing board, hospital, or other entity, and an additional 16% started confidential probationary periods without referral to the licensing board or other agency.

The same increases in monitoring occurred for physicians with more than one incident of substance misuse, but almost always with a formal report to the licensing board. In turn, licensing boards did one or more of the following: limited practice (n=129), temporarily suspended the licence (n=94), revoked the licence (n=32), placed the physician’s name in the national monitoring databank (n=121), or restricted the licence to limit prescription of controlled drugs, such as opioids and benzodiazepines (n=56).

## Results

Overall, 102 of 904 physicians (11.3%) moved out of their physician health programme’s jurisdiction and were lost to follow-up. Seventy eight had transferred to another state programme and these physicians were of generally good status at the time of transfer. The remaining 24 moved away without contacting the programme and with no record of referral. This suggests an attempt to avoid monitoring and treatment. As a result of the lack of records for five years on these participants they were lost to follow-up.

Of the remaining 802 physicians with known outcomes, 155 (19.3%) failed to complete their contracted period of formal treatment and supervision. More than half of these (n=85) voluntarily stopped their licences during monitoring owing to factors such as advanced age, financial problems, or psychiatric or other health problems. An additional 48 physicians who failed to complete their contract had their licences revoked owing to significant relapse, usually accompanied by a failure to accept treatment or monitoring. Twenty two physicians died (six from suicide) during participation and another eight died by the five year follow-up (table 1).

Table 1

Occupational status of physicians at five year follow-up of being in a state physician health programme for substance use disorders. Values are numbers (percentages) of participants

View this table:

In total, 515 physicians (64.2%) completed their contracted period. Sixty seven of these physicians voluntarily elected to continue being monitored after completion of their contract, usually as a hedge against relapse.

One hundred and thirty two physicians (16.5%) had their contracts extended beyond the monitoring period. The reasons for continued monitoring included relapse (low severity of relapse that did not endanger patients); failure to comply with requirements, such as group attendance or therapy, or, in some cases, because of previous relapse.

### Alcohol and other drug use during supervision

After formal treatment the physicians were permitted to return to practice under monitoring. Table 2 summarises the results of drug testing for the 647 physicians who completed their contract or had their contracts extended; 81% of the total group. Fifty seven of 515 physicians who completed their contract and 69 of 132 physicians with extended contracts had a positive alcohol or drug test result at some point during a mean of 56 months, with testing twice a month. Across both groups 33 of the 126 with a positive test result retested positive.

Table 2

Results of drug tests throughout monitoring period for 647 physicians who completed their contract with a physician health programme or had it extended

View this table:

Of 159 documented incidents of substance misuse (126 initial positive test results and 33 repeat positive results, across both groups), 10 (6%) were in the context of medical practice, such as on duty or on call. One episode of patient harm (over-prescribing drugs) was noted in the records. These records, however, captured only important, detected negative consequences. It was not possible to capture other important but less obvious consequences of substance use not recorded in the charts.

### Occupational status after supervision

Records showed that five years after the start of the contracts 631 of the 802 physicians (78.7%) were licensed without restriction and either practising medicine or working in a non-clinical capacity (table 1). An additional 28 physicians (4%) had retired or voluntarily left practice, 87 (11%) had their licence revoked, 30 (4%) had died (7 substance misuse, 6 suicides, 17 other), and 26 (3%) had missing data.

The status of the physicians at five year follow-up varied as a function of their completion status of the physician health programme. For example, 95% of physicians who had completed their contract and 82% who had their contract extended were still licensed and less than 1% had died. In contrast, 21% of the physicians who did not complete their contract were still licensed and 17% had died.

## Discussion

About three quarters of US physicians treated for substance use disorders in physician health programmes had favourable outcomes throughout five years. Such programmes seem to provide an appropriate combination of treatment, support, and sanctions to manage addiction among physicians effectively.

Physician health programmes share the dual role of helping addicted physicians attain sobriety and personal recovery as well as providing assurance to colleagues, hospitals, insurers, licensing boards, and the general public that these physicians can practise safe care. The processes used by these programmes include clinical assessment, referral for treatment, and support and monitoring after treatment, usually for five years. Many questions have been raised about the effectiveness of these programmes—one was stopped owing to allegations of poor monitoring.15 16

We carried out a longitudinal, retrospective cohort study of 904 physicians consecutively admitted to 16 state physician health programmes. Objective outcomes were derived exclusively from laboratory results of urine testing and audit of official records.

All the participants entered some period of professional, specialty treatment, typically 60-90 days in a residential setting, followed by continuing outpatient care. Formal treatment was followed by a return to work conditional on continued participation in 12 step support groups, formal meetings with the programme monitor, random alcohol and drug testing, and random visits by programme staff at the workplace. We know of no comparably intensive or protracted form of treatment and monitoring provided to any other group of addicted people in the United States.8 9 10 12

At five year follow-up 14% of the physicians had stopped practising medicine (voluntarily or forcibly) as a result of their identification by and participation in a physician health programme. It is difficult to determine whether this rate for termination of licences is evidence of close monitoring and tough sanctions or inadequate monitoring and lax standards. The urine test results in the 647 physicians who completed their contract with the programme and those whose contract was extended may provide the best evidence.

Over the average course of 56 months of random testing (about 94 urine tests of 20 panels each), combined with unannounced visits to the physicians’ workplace by a programme monitor, the records showed that 81% had no identified substance misuse at any time. Nineteen per cent, however, had at least one incident of substance misuse during the five years of monitoring. Ten of these incidents were in the context of patient care (on duty or on call) and one instance of patient harm was recorded (over-prescribing drugs). It might be expected that any detection of alcohol or other misuse of drugs would result in immediate suspension or revocation of a licence. This was the case only when there had been a period of non-compliance or if the circumstances of the relapse were dangerous. Instead, most of the programmes in this sample increased the intensity of clinical care as well as the frequency of drug testing and supervisory visits—typically with reports to the licensing board. The more serious sanctions included restrictions on, or suspensions of, the licence or prescription privileges. Evidence suggests that this may be a sensible approach as only 26% of the 126 physicians who tested positive retested positive.

### Limitations

Our study has several limitations. Firstly, the sample cannot be considered nationally representative of physician health programmes in the United States. Because of financial and time constraints we needed to audit primary, objective outcome measures rapidly and efficiently, and only 16 of the 42 programmes that volunteered had electronic clinical and laboratory records continuously available from 2001 to 2007; we selected all of these programmes. That these 16 programmes started to keep electronic records seven years ago suggests that they may have been among the best funded or best led programmes at that time. Data from the phase one survey indicated that the programmes included larger samples (mean census 76 v 68), with correspondingly larger budgets; but, importantly, the duration of the programmes, their clinical, administrative, and sanctioning approaches, and the procedural elements of care did not differ.

A second limitation is that we recorded only objective, verifiable information from records, such as drug testing, sanctions, and modifications to licences. We are confident of the validity of these records, and our results are consistent with most other published studies of physicians with substance use disorders.4 5 6 7 However, the official records provide only a limited picture of the broader functional status and personal health of these physicians. A prospective study is needed to enrich these data, with additional information on clinical and administrative processes and a broader range of measures for functional status.

Finally, the focus on official records made it impossible to track 102 physicians who moved out of their programmes’ jurisdiction during the course of care. Although most of these physicians (n=78) were in good standing at the time of transfer, longer term results cannot be inferred. It is a concern that 24 of these physicians moved away without contacting their programme and with no formal referral for continued monitoring. This suggests an effort to avoid detection and is thus a potential danger to patients.

### Conclusions

From a clinical perspective we interpret these results as evidence that the combination of identification, intervention, formal treatment, professional support, and monitoring by physician health programmes is effective in rehabilitating most of these addicted physicians, over at least five years. From a public safety perspective we believe these data indicate that most physicians who could not or would not stop their misuse of substances were detected early during the course of formal treatment and this usually resulted in voluntary or involuntary cessation of practice. From a policy perspective we conclude that affected physicians are well advised to enter the supervision of a physician health programme voluntarily, and that regulatory boards are well advised to continue supporting these programmes.

It is not possible from the evidence here to prove whether this form of support and monitoring for physicians with substance use disorders is appropriate, too harsh, or too permissive. Any episode of substance use in the context of patient care has the potential for considerable harm. Thus it will always feel more powerful to invoke sanctions alone in a “get tough” policy. But sanctions without the prospect of help in achieving recovery could simply reduce colleagues’ willingness to refer affected physicians—or licensing boards to exercise harsh sanctions—potentially increasing the true prevalence of the problem. On the basis of these data, and considering available alternatives, physician health programmes seem to provide the best available measures for protecting patients and for recovering physicians’ careers.

#### What is already known on this topic

• 10-12% of physicians in the United States become addicted to alcohol and other drugs

• Addicted physicians receive treatment through physician health programmes, operating under jurisdiction of state licensing boards

• Most US physicians with substance use disorders managed in physician health programmes had favourable outcomes at five years

• During monitoring 81% had negative urine test results

• Most (95%) who completed monitoring were licensed and working as physicians at five years

## Notes

Cite this as: BMJ 2008;337:a2038

## Footnotes

• We thank the Robert Wood Johnson Foundation for unrestricted career award funds and the Federation of State Physician Health Programs for its cooperation and access to the data.

• Contributors: ATMcL oversaw data collection and audits, participated in the analyses and writing of the paper, and is guarantor. ATMcL and RLDuP designed the study and secured funding. GSS designed the study and data collection, supervised data collection, and participated in the analyses and writing of the paper. GSS and RLDuP liaised and communicated with the Federation of State Physician Health Programs. MC was responsible for the preparation and storage of the data and analyses and participated in the writing of the paper. RLDuP assisted in the design of the data collection instrument, oversaw audits of data, and participated in the analyses and writing of the paper.

• Funding: This study was supported by the Robert Wood Johnson Foundation.

• Competing interests: GSS is the director of the Alabama State Physician Health Program. His contribution to the work was invaluable in securing cooperation from the Federation of State Physician Health Programs and in providing guidance as we structured the data collection survey. GSS did not direct or influence the data analyses.

• Ethical approval: This study was approved by the institutional review board of the Treatment Research Institute, Philadelphia.

This is an open-access article distributed under the terms of the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

View Abstract


text:
# smartref package conflicts with babel option frenchb

I've unsuccessfuly searched for an answer to this problem. I'd like to use the smartref package together with babel with option frenchb, but there seems to be a conflict : command \chapterref in the following MWE :

\documentclass{book}[11pt]
\usepackage{smartref}         %Pour \chapterref
\usepackage[frenchb]{babel}

\begin{document}

\chapter{A chapter}

Here is some text, see \S\ \chapterref{sec:try}.

\section{tata}

\section{toto}
\label{sec:try}

\end{document}

produces the following error :

! Missing \endcsname inserted.
\unskip
l.14 ...is some text, see \S\ \chapterref{sec:try}

If I replace \usepackage[frenchb]{babel} with \usepackage[english]{babel}, the document compiles correctly and produces the expected result. I tried swapping both usepackage's commands, but compiling fails all the same.

I'm using Babel v3.8d with frenchb v2.6e (according to the log), and smartref version 1.9 (according to CTAN, 1.82 according to the readme file) just downloaded from CTAN.

I guess a private hacked babel frenchb would solve the problem, but I know too little of TeX (csname's etc...) to dig into this by myself. Does somebody have a hint ?

• Welcome to TeX.SX! The frenchb babel setting makes the colon : active, which I suspect is the problem. – Nicola Talbot Sep 2 '14 at 13:14

The problem is exactly in the colon in the label, for which smartref has no protection mechanism like \ref has.

A quick patch is the following:

\documentclass{book}[11pt]
\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}
\usepackage{smartref}         %Pour \chapterref
\usepackage[frenchb]{babel}

\usepackage{regexpatch}
\makeatletter
{([^1])\cP.\cP.2}%                        replace all ##2 not preceded by 1
{\1\c{detokenize}\cB\{\cP\#\cP\#2\cE\}}%  with \detokenize{##2}
{}{}
\makeatother

\begin{document}

\chapter{A chapter}

Here is some text, see \S~\chapterref{sec:try}.

\section{tata}

\section{toto}
\label{sec:try}

\end{document}

Beware that this disallows macros in the argument to \label (more precisely, those that you intend to use with \chapterref or similar smartef commands) which doesn't seem a big limitation.


text:
# Uniform convergence of complex series

Been studying some complex series recently, and still quite unsure how to fully show problems such as:

Show that the following series does not converge uniformly on $B(0,1):$

$$\sum_{n=1}^{\infty} \frac{z^n}{n}$$

How do we properly write a proof to show such series does not converge uniformly?

Note that for real $z_n = (1 - 1/n) \in B(0,1)$ as $n \to \infty$
$$\left|\sum_{k=n+1}^{2n}\frac{z_n^k}{k} \right| > \frac{n}{2n}(1- 1/n)^{2n} \to \frac{e^{-2}}{2} \neq 0$$
For uniform convergence it is necessary that for any $\epsilon > 0$ there exists a positive integer $N$ such that for all $m > n > N$ and for all $z \in B(0,1)$ we have
$$\left|\sum_{k=n+1}^{m}\frac{z^k}{k} \right| < \epsilon$$
Assume that it were, then it is uniformly Cauchy, we have for any $\epsilon>0$ some $N$ such that \begin{align*} \left|\sum_{k=n}^{m}\dfrac{z^{k}}{k}\right|<\epsilon \end{align*} for all $z$ with $|z|<1$ and $m\geq n\geq N$. Then letting $z\rightarrow 1^{-}$ we have \begin{align*} \sum_{k=n}^{m}\dfrac{1}{k}\leq\epsilon \end{align*} for all $m\geq n\geq N$, but this means that the sum $\displaystyle\sum_{k=1}^{\infty}\dfrac{1}{k}$ is convergent, a contradiction.