EPigeonServer
Constructor Summary
| Public Constructor | ||
| public |
|
Member Summary
| Public Members | ||
| public |
Clients that was connected a least one time |
| Private Members | ||
| private |
_net: NetServerProxy Interface that is used to send message |
|
| private |
List of message that doesn't know the destination client and wait that it connect |
Method Summary
| Public Methods | ||
| public |
serve(port: int) Serve on this port |
|
| public |
stop() Stop the server |
| Private Methods | ||
| private |
_clearResendAction(message: *) |
|
| private |
_confirmMessage(socket: *, message: *) |
|
| private |
_findFromMessageTo(message: MessagePrototype, clients: ClientStorage[]): ClientStorage[] Find the destinator(s) of the message |
|
| private |
_findFromSocket(socket: Socket | any): ClientStorage find a client from his socket |
|
| private |
|
|
| private |
_notifyClientsOfAConnection(connectedClient: *) |
|
| private |
_notifyClientsOfADisconnection(disconnectedClient: *) |
|
| private |
_onAuth(socket: *, uuid: *) |
|
| private |
_onClientsList(socket: *) |
|
| private |
_onData(socket: *, data: *) |
|
| private |
_onMessageConfirm(socket: *, uid: *) |
|
| private |
_onMessageNew(socket: *, message: *): * |
|
| private |
_onMessageRetry(socket: *, id: *) |
|
| private |
_onSessionUpdate(socket: *, session: *) |
|
| private |
_onSocketDisconnect(socket: *) |
|
| private |
_retryMessage(socket: *, id: *) |
|
| private |
_sendClientsList(socket: *) |
|
| private |
_sendMessage(socket: *, message: *) |
|
| private |
_sendMessageWithRetry(socket: *, message: *) |
|
| private |
_tryToSendUnknowDestinatoryMessage(clients: *) |
|
| private |
_updateMessageId(client: *, message: *) |
Public Constructors
public constructor() source
Public Members
Private Members
private _unknowList: MessagePrototype[] source
List of message that doesn't know the destination client and wait that it connect
Public Methods
public serve(port: int) source
Serve on this port
Params:
| Name | Type | Attribute | Description |
| port | int | Number of the port |
Private Methods
private _clearResendAction(message: *) source
Params:
| Name | Type | Attribute | Description |
| message | * |
private _confirmMessage(socket: *, message: *) source
Params:
| Name | Type | Attribute | Description |
| socket | * | ||
| message | * |
private _findFromMessageTo(message: MessagePrototype, clients: ClientStorage[]): ClientStorage[] source
Find the destinator(s) of the message
Params:
| Name | Type | Attribute | Description |
| message | MessagePrototype | the message that contanin the destinator |
|
| clients | ClientStorage[] | the clients that we need to find in a destinator |
private _findFromSocket(socket: Socket | any): ClientStorage source
find a client from his socket
Params:
| Name | Type | Attribute | Description |
| socket | Socket | any | of the client |
private _initEvents() source
private _notifyClientsOfAConnection(connectedClient: *) source
Params:
| Name | Type | Attribute | Description |
| connectedClient | * |
private _notifyClientsOfADisconnection(disconnectedClient: *) source
Params:
| Name | Type | Attribute | Description |
| disconnectedClient | * |
private _onAuth(socket: *, uuid: *) source
Params:
| Name | Type | Attribute | Description |
| socket | * | ||
| uuid | * |
private _onClientsList(socket: *) source
Params:
| Name | Type | Attribute | Description |
| socket | * |
private _onData(socket: *, data: *) source
Params:
| Name | Type | Attribute | Description |
| socket | * | ||
| data | * |
private _onMessageConfirm(socket: *, uid: *) source
Params:
| Name | Type | Attribute | Description |
| socket | * | ||
| uid | * |
private _onMessageNew(socket: *, message: *): * source
Params:
| Name | Type | Attribute | Description |
| socket | * | ||
| message | * |
Return:
| * |
private _onMessageRetry(socket: *, id: *) source
Params:
| Name | Type | Attribute | Description |
| socket | * | ||
| id | * |
private _onSessionUpdate(socket: *, session: *) source
Params:
| Name | Type | Attribute | Description |
| socket | * | ||
| session | * |
private _onSocketDisconnect(socket: *) source
Params:
| Name | Type | Attribute | Description |
| socket | * |
private _retryMessage(socket: *, id: *) source
Params:
| Name | Type | Attribute | Description |
| socket | * | ||
| id | * |
private _sendClientsList(socket: *) source
Params:
| Name | Type | Attribute | Description |
| socket | * |
private _sendMessage(socket: *, message: *) source
Params:
| Name | Type | Attribute | Description |
| socket | * | ||
| message | * |
private _sendMessageWithRetry(socket: *, message: *) source
Params:
| Name | Type | Attribute | Description |
| socket | * | ||
| message | * |
private _tryToSendUnknowDestinatoryMessage(clients: *) source
Params:
| Name | Type | Attribute | Description |
| clients | * |
|
private _updateMessageId(client: *, message: *) source
Params:
| Name | Type | Attribute | Description |
| client | * | ||
| message | * |


TeamBuilder 9000
All your Human-Resource are belong to us
MR me
- 1
-<EMAIL_ADDRESS>- Manager
- Corner123
MR you
- 2
-<EMAIL_ADDRESS>- Engineer
-<EMAIL_ADDRESS>MR you jr
- 3
-<EMAIL_ADDRESS>- Engineer
-<EMAIL_ADDRESS>Coffee Slave
- 4
-<EMAIL_ADDRESS>- Intern
- VMI
Coffee Slave jr
- 5
-<EMAIL_ADDRESS>- Intern
- UT


While not my first experience with codeine, this was certainly the most interesting. I took four Tylenol-3 tablets, each with 300mg acetaminophen, 30mg codeine, and 15mg caffeine. The tablets were leftovers from getting my wisdom teeth out. Well, here I am in first year University, faced with eleven days between final exams, so I figured why not experiment with my leftover pharmaceuticals.
The night before this experience I had consumed two tablets and felt minor effects, but they may have been modified because I spent a few hours roaming around outside in the cold. Because of this I didn't really get a feeling of warmth, as Ontario in December is not warm. I was walking around with a roommate and exploring and attempted to saw down a tree with a switchblade. That was unsuccessful but the entire night felt very giddy and I was very content. I remember being tired and thinking I could lay down anywhere to sleep. I went to bed around 6:30am.
The following night I took four tablets, as I said, and experienced dramatic effects. I had been puttering around in my room doing various cleaning. I'd had quite the stacks of papers and notes and random bits scattered around and felt the need to get that part of my life in order, so I set to work doing that and took the tablets during that time. Not long after I began to feel warm and drowsy and not quite myself, and I looked at the clock to see it was about 12:40am. Now, having had my sleeping pattern lately as going to bed at 6am, waking up at 4-6pm, I welcomed this opportunity to correct it and went to bed.
I remember feeling extremely content bundled up under the covers, very warm and happy. Before I get onto specifics I would like to note that I did experience a few adverse effects, namely dry mouth (had a glass of water nearby, though), and slight momentary nausea if I was shifting in bed to get more comfortable.
Things started with me experiencing very vivid memories, or at least it seems like they were memories. It felt like I was accessing information that normally would be filtered out or left behind in my brain, so the memories were very complete and true to life. Makes me think that our brain records a complete record of all events we ever go through but that we simply cannot access most of the information, usually. I seem to recall the memories being a sort of live action memory, and then they would eventually spin off into huge, meandering new scenarios of events. Now, this is not unusual for me as my dreams most usually take the form of dreaming up situations and scenarios and strange worlds. But the intensity and complexity of these experiences were amazing, truly engaging and I was very much kept interested.
I did get unsettled now and again, at one point I heard some noise or another in my building, a pipe of flowing water or the like, and it startled me. The wind whooshing through the window screen and hitting the side of the building also produced a shrieking like sounds that made my mind race momentarily, but it was only for a split second that I felt scared or alarmed. It did not build into an unpleasant tide, but merely alarm and fear at the precise instant. I remember slipping in and out of sleep and the experiences washing over me regardless of waking.
Interesting also is that I was unable to sleep for a sustained time until 5:30am, perhaps because of the 60mg of caffeine, but I suspect not, as a strong cup of coffee usually only seems to effect me for about an hour. Despite taking the tablets at about 12:15am, I remember looking at the clock at 5:30am, and did not fall asleep immediately after that, either.
I was surprised by the power of the experience - I think that maybe the dose of two tablets the night before may have served to 'warm up' for this experience with four tablets, and left me more susceptible to its effects, but I could be mistaken. Having taken two and only feeling 'whooshy,' taking four seemed to introduce exponential effects. Very interesting, would do again. I have six more here and am debating how to split up the doses.
Experience Reports are the writings and opinions of the individual authors who submit them.
Some of the activities described are dangerous and/or illegal and none are recommended by Erowid.


Ruleset Code Size Rules
Language -
Description
The Code Size Ruleset contains a collection of rules that find code size related problems.
Rule NPathComplexity::
TOC
Description
The NPath complexity of a method is the number of acyclic execution paths through that method.
A threshold of 200 is generally considered the point where measures should be taken to reduce complexity.
- Message
- The method {0}() has an NPath complexity of {1}
- Class
- net.sourceforge.pmd.rules.design.NpathComplexity
- Reference
- -
- ExternalInfoUrl
- http://pmd.sourceforge.net/rules/codesize.html#NPathComplexityh
- TypeResolution
- -
- Priority
- -
Example
Example code snippet of this rule.
public class Foo {
void bar() {
// lots of complicated code
}
}
Properties
Following properties are defined:
- Name
- minimum
- Description
- The npath reporting threshold
- Value
-
200
TOC
Rule ExcessiveMethodLength::
TOC
Description
Violations of this rule usually indicate that the method is doing
too much. Try to reduce the method size by creating helper methods and removing any copy/pasted code.
- Message
- Avoid really long methods.
- Class
- net.sourceforge.pmd.rules.design.LongMethodRule
- Reference
- -
- ExternalInfoUrl
- http://pmd.sourceforge.net/rules/codesize.html#ExcessiveMethodLength
- TypeResolution
- -
- Priority
- 3
Example
Example code snippet of this rule.
public class Foo {
public void doSomething() {
System.out.println("Hello world!");
System.out.println("Hello world!");
// 98 copies omitted for brevity.
}
}
Properties
Following properties are defined:
- Name
- minimum
- Description
- The method size reporting threshold
- Value
-
100
TOC
Rule ExcessiveParameterList::
TOC
Description
Long parameter lists can indicate that a new object should be created to
wrap the numerous parameters. Basically, try to group the parameters together.
- Message
- Avoid really long parameter lists.
- Class
- net.sourceforge.pmd.rules.design.LongParameterListRule
- Reference
- -
- ExternalInfoUrl
- http://pmd.sourceforge.net/rules/codesize.html#ExcessiveParameterList
- TypeResolution
- -
- Priority
- 3
Example
Example code snippet of this rule.
public class Foo {
public void addData(
int p0, int p1, int p2, int p3, int p4, int p5,
int p5, int p6, int p7, int p8, int p9, int p10) {
}
}
}
Properties
Following properties are defined:
- Name
- minimum
- Description
- The parameter count reporting threshold
- Value
-
10
TOC
Rule ExcessiveClassLength::
TOC
Description
Long Class files are indications that the class may be trying to
do too much. Try to break it down, and reduce the size to something
manageable.
- Message
- Avoid really long classes.
- Class
- net.sourceforge.pmd.rules.design.LongClassRule
- Reference
- -
- ExternalInfoUrl
- http://pmd.sourceforge.net/rules/codesize.html#ExcessiveClassLength
- TypeResolution
- -
- Priority
- 3
Example
Example code snippet of this rule.
public class Foo {
public void bar() {
// 1000 lines of code
}
}
Properties
Following properties are defined:
- Name
- minimum
- Description
- The class size reporting threshold
- Value
-
1000
TOC
Rule CyclomaticComplexity::
TOC
Description
Complexity is determined by the number of decision points in a method plus one for the
method entry. The decision points are 'if', 'while', 'for', and 'case labels'. Generally,
1-4 is low complexity, 5-7 indicates moderate complexity, 8-10 is high complexity,
and 11+ is very high complexity.
- Message
- The {0} ''{1}'' has a Cyclomatic Complexity of {2}.
- Class
- net.sourceforge.pmd.rules.CyclomaticComplexity
- Reference
- -
- ExternalInfoUrl
- http://pmd.sourceforge.net/rules/codesize.html#CyclomaticComplexity
- TypeResolution
- -
- Priority
- 3
Example
Example code snippet of this rule.
// Cyclomatic Complexity = 12
public class Foo {
1 public void example() {
2 if (a == b) {
3 if (a1 == b1) {
fiddle();
4 } else if a2 == b2) {
fiddle();
} else {
fiddle();
}
5 } else if (c == d) {
6 while (c == d) {
fiddle();
}
7 } else if (e == f) {
8 for (int n = 0; n < h; n++) {
fiddle();
}
} else{
switch (z) {
9 case 1:
fiddle();
break;
10 case 2:
fiddle();
break;
11 case 3:
fiddle();
break;
12 default:
fiddle();
break;
}
}
}
}
Properties
Following properties are defined:
- Name
- reportLevel
- Description
- The Cyclomatic Complexity reporting threshold
- Value
-
10
TOC
Rule ExcessivePublicCount::
TOC
Description
A large number of public methods and attributes declared in a class can indicate the
class may need to be broken up as increased effort will be required to thoroughly test it.
- Message
- This class has a bunch of public methods and attributes
- Class
- net.sourceforge.pmd.rules.ExcessivePublicCount
- Reference
- -
- ExternalInfoUrl
- http://pmd.sourceforge.net/rules/codesize.html#ExcessivePublicCount
- TypeResolution
- -
- Priority
- 3
Example
Example code snippet of this rule.
public class Foo {
public String value;
public Bar something;
public Variable var;
// [... more more public attributes ...]
public void doWork() {}
public void doMoreWork() {}
public void doWorkAgain() {}
// [... more more public methods ...]
}
Properties
Following properties are defined:
- Name
- minimum
- Description
- The public item reporting threshold
- Value
-
45
TOC
Rule TooManyFields::
TOC
Description
Classes that have too many fields could be redesigned to have fewer fields, possibly
through some nested object grouping of some of the information. For example, a class with
city/state/zip fields could instead have one Address field.
- Message
- Too many fields
- Class
- net.sourceforge.pmd.rules.design.TooManyFields
- Reference
- -
- ExternalInfoUrl
- http://pmd.sourceforge.net/rules/codesize.html#TooManyFields
- TypeResolution
- -
- Priority
- 3
Example
Example code snippet of this rule.
public class Person {
String one;
int two;
int three;
[... many more public fields ...]
}
Properties
Following properties are defined:
- Name
- maxfields
- Description
- The field count reporting threshold
- Value
-
15
TOC
Rule NcssMethodCount::
TOC
Description
- Message
- The method {0}() has an NCSS line count of {1}
- Class
- net.sourceforge.pmd.rules.codesize.NcssMethodCount
- Reference
- -
- ExternalInfoUrl
- http://pmd.sourceforge.net/rules/codesize.html#NcssMethodCount
- TypeResolution
- -
- Priority
- -
Example
Example code snippet of this rule.
public class Foo extends Bar {
public int methd() {
super.methd();
//this method only has 1 NCSS lines
return 1;
}
}
Properties
Following properties are defined:
- Name
- minimum
- Description
- The method NCSS count reporting threshold
- Value
-
100
TOC
Rule NcssTypeCount::
TOC
Description
- Message
- The type has an NCSS line count of {0}
- Class
- net.sourceforge.pmd.rules.codesize.NcssTypeCount
- Reference
- -
- ExternalInfoUrl
- http://pmd.sourceforge.net/rules/codesize.html#NcssTypeCount
- TypeResolution
- -
- Priority
- -
Example
Example code snippet of this rule.
public class Foo extends Bar {
public Foo() {
//this class only has 6 NCSS lines
super();
super.foo();
}
}
Properties
Following properties are defined:
- Name
- minimum
- Description
- The type NCSS count reporting threshold
- Value
-
1500
TOC
Rule NcssConstructorCount::
TOC
Description
- Message
- The constructor with {0} parameters has an NCSS line count of {1}
- Class
- net.sourceforge.pmd.rules.codesize.NcssConstructorCount
- Reference
- -
- ExternalInfoUrl
- http://pmd.sourceforge.net/rules/codesize.html#NcssConstructorCount
- TypeResolution
- -
- Priority
- -
Example
Example code snippet of this rule.
public class Foo extends Bar {
public Foo() {
super();
//this constructor only has 1 NCSS lines
super.foo();
}
}
Properties
Following properties are defined:
- Name
- minimum
- Description
- The constructor NCSS count reporting threshold
- Value
-
100
TOC


Catholic is a Church website template created for churches, charities and other non profits. To customize this template, You should know some basic HTML and Computer Knowledge. If you don't have this knowledge, you can contact any Web Designer to do this task. Editing this template with out knowing things means, it will break the layout and design.
You can customize this template with any Code editing software. I recommend Dreamweaver if you are on Windows and Sublime Text for Mac users. Even you can customize the template with Notepad. So don't worry if you don't have these software.
To change the current logo to your Logo, Create it separately in any Graphic software and Export it in PNG format, so that the background will be transparent. You can use any width, but do not exceed 260px.
Once you've created the logo, copy it to HTML/images/ folder. Then link it in the Logo section in HTML file. If you are using same name, no need to change it in the HTML then.
Eg:

Customizing gallery is simple. Just replace the big images and thumbnail with yours. You can also add/remove images by editing it in the HTML.
Here is how a single image code looks like

Email Subscription is powered by Mailchimp. You need a mailchimp account to get the form working. You will get an API code and List ID from Mailchimp dashboard. Copy it in subscribe.php (You also need a PHP server to check it. It will not work locally on your computer)
Eg:
$apiKey = 'PASTE_YOUR_API_KEY_HERE'; $listId = 'YOUR_LIST_ID'; ... ... $submit_url = "http://us8.api.mailchimp.com/1.3/?method=listSubscribe"; /* Replace "us8" with your actual datacenter */
To make the contact form working, Open contact.php file and change the email id to your email. No need to change any other code. Save and upload to your PHP server to test.
Contact form will work only on PHP servers. not on your local machine.
To customize event calendar, First you should setup a calendar in Google
You must first make your Google Calendar public:
Then, you must obtain your calendar's XML feed URL:
Once you completed this steps, Open event-calendar.html file in a code editor and scroll to very bottom where you can see the script for Event Calendar. There is commented line for your easyness. You can paste your Feed URL inside quotes.
To change the embed maps in the contact page, Open maps.google.com and search your address. Then click on the settings (Cog) icon on the right bottom. Then click Embed & share. Click on the next tab where you can see Embed code starting with <iframe ....
Copy the code and replace the existing code in contact.html file. You can also remove the width & height attribute as we area already giving the value via CSS.
You can add new pages by copy pasting the HTML file and renaming. Choose a matchng HTML page, eg: if you are creating new Ministry page, you can duplicate the ministry.html and rename it to ministry-xxx.html. Then you can edit this page.
If you want to delete a page, Just delete the HTML file and remove the link from all other HTML pages.
Please note that this an HTML template and not connected with any Content Management system, so the blog you see is just static. If you want you can integrate it to any CMS like Wordpress, Tumblr etc. This is not a part of this Template.
For other customizations like Text changing, you can simply do it in any code editing software. Just replace the current text with your text. Then Save it. That's all
You are entitled to get future updates of this template. You can re-download the file from Themeforest => Download page. If you have any suggstions or feature request or if you found any bug with existing template, you can send an email to<EMAIL_ADDRESS>I will update it in my next version.
If you have any issues customizing, or if you need any help regarding this template, or to just Say Hi, Please contact me on<EMAIL_ADDRESS>Great Images provided by Unsplash. A big thanks to the team


Video
HTML5 Video
This demonstrates support for the HTML5 VIDEO (once it gets implemented)
To Do
- Add Rotation when video in fullscreen - there's a bug causing the navigation bar to shift under the status bar if Rotation is enabled
- Support for the different kinds of attributes to map to properties of media player
- Hide text contained in recognized tags
YouTube in IFRAME


--- layout: archive title: Zulip Chat Archive permalink: /stream/113488-general/topic/What.20is.20worth.20a.20paper.3F.html ---
While I understand what is worth writing a paper in pure mathematics, I have no idea what mathlib
-related activities might be worth a paper, what journals would accept such paper, and which of those journals are good/bad.
You can have a look at the list of papers at https://leanprover-community.github.io/links/
The most relevant to you are the papers about Hensel lemma, Cap set problem, Continuum hypothesis, perfectoid spaces.
If I look at my own contributions, then may be the most significant ones are in analysis
: MVT, Gronwall's inequality and uniqueness of solutions of an ODE, Darboux theorem.
May be we should write a paper about the current status of analysis/calculus in Lean, including derivatives, manifolds, and integrals.
This would be one more reason to have #1944 finalized & merged.
The issue is that only manifolds are a new formalization target. Publishing about stuff that was already formalized in some other proof assistant is trickier. You would need a convincing story about how things were different (and better) in your case.
Talking about ODEs, what is the status of the inverse function theorem? You started something, but was it ever finished?
Analysis is difficult for publications because Isabelle already has a huge analysis library.
Btw @Patrick Massot the publication page is mission Leo and Sebastian's macro paper and my pointer optimization paper
Sébastien can probably tell us whether you and him already did some stuff beyond what is in Isabelle (apart from the manifold folder, but Sébastien seems to be tired of pushing that bit, or maybe he wants analytical manifolds).
I'm not maintaining that list, but I'm sure Rob is open to PR to this page.
I'll try to PR the inverse function theorem today or tomorrow.
#2228 Proof works, still needs polishing
@Yury G. Kudryashov Will there also be a version for manifolds?
Not in the first PR.
We don't have submanifolds yet. Last time I asked Sébastien he no precise plans for submanifolds in mathlib.
Simon Hudon said:
Btw the publication page is mission Leo and Sebastian's macro paper and my pointer optimization paper
https://github.com/leanprover-community/leanprover-community.github.io/pull/6
{% endraw %}Last updated: Apr 24 2020 at 19:02 UTC


Use your CartoDB tables with a Leaflet map.
Leaflet is a modern, lightweight open-source JavaScript library for mobile-friendly interactive maps. It is developed by CloudMade. It still has all the features most developers ever need for online maps, while providing a fast, pleasant user experience.
The code is available on Github. If you have any question there is a complete documentation or you can ask in the CartoDB mailing list.
Using the library is really easy. It accepts the following parameters to manage the behavior of your CartoDB layers:
| Parameter name | Description | Type | Callback variables | Required |
| map | The Leaflet Map object. | Object | Yes | |
| username | Your CartoDB user name. | String | Yes | |
| table_name | Your CartoDB table name. | String | Yes | |
| query | A SQL query. Default: "SELECT * FROM {{table_name}}" | String | Yes | |
| opacity | If you want to change the opacity of the CartoDB layer. Default: 1 | Number | No | |
| interactivity | If you want to add interactivity to the layer without making requests. | String (columns separated by commas) | No | |
| featureOver | A callback when hovers in a feature | Function |
event: Mouse event object latlng: The LatLng leaflet object where was clicked pos: Object with x and y position in the DOM map element data: The CartoDB data of the clicked feature with the `interactivity` param. |
No (But only will work with interactivity specified) |
| featureOut | A callback when hovers out a feature | Function | No (But only will work with interactivity specified) | |
| featureClick | A callback when clicks in a feature | Function |
event: Mouse event object latlng: The LatLng leaflet object where was clicked pos: Object with x and y position in the DOM map element data: The CartoDB data of the clicked feature with the `interactivity` param. |
No (But only will work with interactivity specified) |
| tile_style | If you want to add other style to the layer. | String | No | |
| auto_bound | If you want to zoom in the area where the layer is positioned. | Boolean | No | |
| debug | If you want to debug the library, set to true. | Boolean | No | |
| tiler_protocol | Protocol for the tiler URL. Default: "http" | String | No | |
| tiler_domain | Base domain of the tiler URL. Default: "cartodb.com" | String | No | |
| tiler_port | Port of the tiler URL. Default: "80" | String | No | |
| sql_protocol | SQL API protocol (opcional - default = "http"). | String | No | |
| sql_domain | SQL API domain (opcional - default = "cartodb.com"). | String | No | |
| sql_port | SQL API port as a string (opcional - default = "80"). | String | No |
If you want to get a feature clicked || hover data (via the interactivity parameter), the columns must be in a string separated by commas. If you don't want to write the name of the table several times, you can use {{table_name}} in the query or tile_style parameters. We strongly recommend the use of the files available in this repository. These are tested, and if you decide use updated ones, the library could not work.
First of all add the necessary script and css files:
<link rel="stylesheet" href="http://cdn.leafletjs.com/leaflet-0.3.1/leaflet.css" /> <!--[if IE]> <link rel="stylesheet" href="http://cdn.leafletjs.com/leaflet-0.3.1/leaflet.ie.css" /> <![endif]--> <link href="css/cartodb-leaflet.css" rel="stylesheet" type="text/css"> <script src="http://cdn.leafletjs.com/leaflet-0.3.1/leaflet.js"></script> <script type="text/javascript" src="js/wax.leaf.min-7.0.0dev1-touched.js"></script> <script type="text/javascript" src="dist/cartodb-leaflet-min.js"></script>
When the document is loaded, start creating the map:
var map = new L.Map('map'); var cloudmadeUrl = 'http://{s}.tile.cloudmade.com/BC9A493B41014CAABB98F0471D759707/997/256/{z}/{x}/{y}.png', cloudmadeAttrib = 'Map data © 2011 OpenStreetMap contributors, Imagery © 2011 CloudMade', cloudmade = new L.TileLayer(cloudmadeUrl, {maxZoom: 18, attribution: cloudmadeAttrib}); map.addLayer(cloudmade);
Then create the CartoDB layer:
var cartodb_leaflet = new L.CartoDBLayer({ map: map, user_name:'example', table_name: 'earthquakes', query: "SELECT * FROM {{table_name}}", tile_style: "#{{table_name}}{marker-fill:red}", interactivity: "cartodb_id, magnitude", featureClick: function(ev, latlng, pos, data) {alert(data)}, featureOut: function() {}, featureOver: function(ev, latlng, pos, data) {}, auto_bound: true });
And finally add it to the map:
map.addLayer(cartodb_leaflet);
New funcionalities are coming, in the meantime you can use:
removeLayer: Removes the cartodb layer from the map.
map.removeLayer(cartodb_leaflet);
hide: Hide the cartodb layer from the map.
cartodb_leaflet.hide();
show: Show again the cartodb layer in the map.
cartodb_leaflet.show();
setInteraction: Set the interaction of your layer to true or false.
cartodb_leaflet.setInteraction(false);
setOpacity: Change the opacity of the CartoDB layer.
cartodb_leaflet.setOpacity(0.3);
setQuery: Change the query parameter for the layer.
cartodb_leaflet.setQuery("SELECT * FROM {{table_name}} WHERE cartodb_id > 10");
setStyle: Change the style of the layer tiles.
cartodb_leaflet.setStyle("#{{table_name}}{marker-fill:blue}");
isVisible: Get the visibility of the layer.
cartodb_leaflet.isVisible();
setInteractivity: Change the columns you want to get data (it needs to reload the tiles).
cartodb_leaflet.setInteractivity("cartodb_id, the_geom, magnitude");
setBounds: Set bounds in the map using a new query or the default one
cartodb_leaflet.setBounds(); || cartodb_leaflet.setBounds("SELECT * FROM {{table_name}} WHERE cartodb_id < 100");
setOptions: Change any parameter at the same time refreshing the tiles once
cartodb_leaflet.setOptions({query: "SELECT * FROM {{table_name}} WHERE cartodb_id<100", interactivity: "cartodb_id,the_geom,magnitude"});
setLayerOrder: _Not available yet_ -> Waiting for this ticket fixed: https://github.com/CloudMade/Leaflet/issues/505
If you want to use the cartodb custom popup, you need to add the script in the html:
<script type="text/javascript" src="dist/cartodb-popup-min.js"></script>
Create the CartoDB popup:
var popup = new L.CartoDBPopup();
And then use as you want:
... featureClick: function(ev,latlng,pos,data) { // Set popup content // You can pass an Object, an Array or a String popup.setContent(data); // Set latlng popup.setLatLng(latlng); // Show it! map.openPopup(popup); }, ...
You can see an example using it here.
Visit our support area and get some help from the community.
Yes we have. Contact us for getting more information. We are quite friends of academics so, you will get a lot of benefits.
Need us to help you with your visualization or application? Does your organization have unique requirements that don’t quite fit our plans? Contact us.


Our privacy policy is simple: we don’t collect
or share any of your personal
information
We don't store your search history. We therefore have nothing
to sell to advertisers
that track you across the internet.
Other search engines track your searches even when you're
in private browsing mode. We
don't track you - period.
Share DuckDuckGo and help
friends take their privacy back!


Photography
Animals
Insects
Landscape
Nature
Mother nature at it's finest showcasing some breath-taking sceneries.


PORTALS
Wikipedia states that:' Places linked by a portal include a different spot in the same universe (in which case it might be an alternative for teleportation); a parallel world (inter-dimensional portal); the past or the future (time portal); and other planes of existence, such as heaven, hell or other afterworlds. A parallel world, such as C. S. Lewis's Wood between the Worlds in his Chronicles of Narnia, may exist solely to contain multiple portals, perhaps to every parallel world in existence.'
In this case this portal page behaves like a gateway to different sources and stories. Every page excists parralel to the other, which makes them as important as every other page.


Right, do any of these boats look familiar to you?
No but the boat has to be here somewhere!
I'm totally excited. Are you excited?
Dory, wake up. Wake up. Come on!
Duck!
That's not a duck, that's a...
Pelican!
Whaaaaaaaaa
Whaaaaaa
No!
I haven't come this far to be breakfast!
Hey Nigel. Would you look at that.
Wut.. what.. what?
Sun's barely up and already Gerald's had more than he can handle
Yeah, reckon somebody ought to help the poor guy.
Yeah.. Yeah.. Yeah.. Yeah.. Right.. Yeah.. Yeah.. Yeah.. Yeah.. Right..
Without everybody fly off at once...
All right Gerald, what is it.
Fish got your tongue?
Whaaaaaaa
Love a duck!
I got to find my son Nemo!
Nemo?
Hey hey hey! He's that fish you know the one we've been talking about,
the one that's been fighting the whole ocean!
Hey I know where you're son i...
Huh?
Hey wait! Come back! Stop!
Keep going, he's crazy!
I got something to tell ya!
MINE
OK. Don't make any sudden moves.
Hop inside my mouth if you want to live.
Hop in your mouth, ha? And how does that make me live.
MINE?
Becaaaauuuse I can take you to your son!
Yeah right.
No! I know your son! He's orange, he's got a gimpy fin on one si...
That's Nemoooo!
Whaaaa
WhaaaaAAAA
Fasten your seatbelts!
Whoooeeee
Hoehoe!
Hahaaaaaa! ha ha ha ha ha!
Aaaaahhhhhh!
Everybody hold oooonnn!
Whaaaaaaaa
Whaaaaaaaa


Other APIs require “side files” to be maintained in
parallel with programs. For example JavaBeans requires a BeanInfo
class to be maintained in parallel with a bean, and Enterprise
JavaBeans (EJB) requires a deployment descriptor. It would
be more convenient and less error-prone if the information in these
side files were maintained as annotations in the program
itself.
The Java platform has always had various ad hoc annotation
mechanisms. For example the transient
modifier is an
ad hoc annotation indicating that a field should be ignored by the
serialization subsystem, and the @deprecated
javadoc
tag is an ad hoc annotation indicating that the method should no
longer be used. The platform has a general
purpose annotation (also known as metadata) facility that
permits you to define and use your own annotation types. The
facility consists of a syntax for declaring annotation types, a
syntax for annotating declarations, APIs for reading annotations, a
class file representation for annotations, and annotation processing support provided by the javac
tool.
Annotations do not directly affect program semantics, but they do affect the way programs are treated by tools and libraries, which can in turn affect the semantics of the running program. Annotations can be read from source files, class files, or reflectively at run time.
Annotations complement javadoc tags. In general, if the markup is intended to affect or produce documentation, it should probably be a javadoc tag; otherwise, it should be an annotation.
Typical application programmers will never have to define an
annotation type, but it is not hard to do so. Annotation type
declarations are similar to normal interface declarations. An
at-sign (@
) precedes the interface
keyword. Each method declaration defines an element of the
annotation type. Method declarations must not have any parameters
or a throws
clause. Return types are restricted to
primitives, String
,
Class
,
enums, annotations, and arrays of the
preceding types. Methods can have default values. Here is an
example annotation type declaration:
/** * Describes the Request-For-Enhancement(RFE) that led * to the presence of the annotated API element. */ public @interface RequestForEnhancement { int id(); String synopsis(); String engineer() default "[unassigned]"; String date() default "[unimplemented]"; }
Once an annotation type is defined, you can use it to annotate
declarations. An annotation is a special kind of modifier, and can
be used anywhere that other modifiers (such as public
,
static
, or final
) can be used. By
convention, annotations precede other modifiers. Annotations
consist of an at-sign (@
) followed by an annotation
type and a parenthesized list of element-value pairs. The values
must be compile-time constants. Here is a method declaration with
an annotation corresponding to the annotation type declared
above:
@RequestForEnhancement( id = 2868724, synopsis = "Enable time-travel", engineer = "Mr. Peabody", date = "4/1/3007" ) public static void travelThroughTime(Date destination) { ... }
An annotation type with no elements is termed a marker annotation type, for example:
/** * Indicates that the specification of the annotated API element * is preliminary and subject to change. */ public @interface Preliminary { }
It is permissible to omit the parentheses in marker annotations, as shown below:
@Preliminary public class TimeTravel { ... }
In annotations with a single element, the element should be
named value
, as shown below:
/** * Associates a copyright notice with the annotated API element. */ public @interface Copyright { String value(); }
It is permissible to omit the element name and equals sign
(=
) in a single-element annotation whose element name
is value
, as shown below:
@Copyright("2002 Yoyodyne Propulsion Systems") public class OscillationOverthruster { ... }
To tie it all together, we'll build a simple annotation-based test framework. First we need a marker annotation type to indicate that a method is a test method, and should be run by the testing tool:
import java.lang.annotation.*; /** * Indicates that the annotated method is a test method. * This annotation should be used only on parameterless static methods. */ @Retention(RetentionPolicy.RUNTIME) @Target(ElementType.METHOD) public @interface Test { }
Note that the annotation type declaration is itself annotated.
Such annotations are called meta-annotations. The first
(@Retention(RetentionPolicy.RUNTIME)
) indicates that
annotations with this type are to be retained by the VM so they can
be read reflectively at run-time. The second
(@Target(ElementType.METHOD)
) indicates that this
annotation type can be used to annotate only method
declarations.
Here is a sample program, some of whose methods are annotated with the above interface:
public class Foo { @Test public static void m1() { } public static void m2() { } @Test public static void m3() { throw new RuntimeException("Boom"); } public static void m4() { } @Test public static void m5() { } public static void m6() { } @Test public static void m7() { throw new RuntimeException("Crash"); } public static void m8() { } }
Here is the testing tool:
import java.lang.reflect.*; public class RunTests { public static void main(String[] args) throws Exception { int passed = 0, failed = 0; for (Method m : Class.forName(args[0]).getMethods()) { if (m.isAnnotationPresent(Test.class)) { try { m.invoke(null); passed++; } catch (Throwable ex) { System.out.printf("Test %s failed: %s %n", m, ex.getCause()); failed++; } } } System.out.printf("Passed: %d, Failed %d%n", passed, failed); } }
The tool takes a class name as a command line argument and
iterates over all the methods of the named class attempting to
invoke each method that is annotated with the Test
annotation type (defined above). The reflective query to find out
if a method has a Test
annotation is highlighted in
green. If a test method invocation throws an exception, the test is
deemed to have failed, and a failure report is printed. Finally, a
summary is printed showing the number of tests that passed and
failed. Here is how it looks when you run the testing tool on the
Foo
program (above):
$ java RunTests Foo Test public static void Foo.m3() failed: java.lang.RuntimeException: Boom Test public static void Foo.m7() failed: java.lang.RuntimeException: Crash Passed: 2, Failed 2While this testing tool is clearly a toy, it demonstrates the power of annotations and could easily be extended to overcome its limitations.


Most of my own atmospheric chemistry research as a PhD student at MIT is based in Delhi. Thus, for this tutorial, we will take a deeper look at the air quality data made available to us through OpenAQ. We will begin by figuring out exactly what data is available to us, and then further examine the most relevant and up-to-date sources. We will take a look at longer trends for some pollutants where possible.
import pandas as pd
import seaborn as sns
import matplotlib as mpl
import matplotlib.pyplot as plt
import openaq
import warnings
warnings.simplefilter('ignore')
%matplotlib inline
# Set major seaborn asthetics
sns.set("notebook", style='ticks', font_scale=1.0)
# Increase the quality of inline plots
mpl.rcParams['figure.dpi']= 500
First, let’s figure out which locations we should use for our analysis.
Let’s grab all locations
from Delhi for all parametrs:
api = openaq.OpenAQ()
locations = api.locations(city='Delhi', df=True)
locations.location
0 Anand Vihar
1 Anand Vihar, Delhi - DPCC
2 Aya Nagar, Delhi - IMD
3 Burari Crossing, Delhi - IMD
4 CRRI Mathura Road, Delhi - IMD
5 Civil Lines
6 Delhi College Of Engineering
7 Delhi Technological University
8 Delhi Technological University, Delhi - CPCB
9 East Arjun Nagar
10 East Arjun Nagar-Delhi CPCB
11 IGI Airport
12 IGI Airport Terminal-3, Delhi - IMD
13 IHBAS
14 IHBAS, Delhi - CPCB
15 Income Tax Office
16 Income Tax Office, Delhi - CPCB
17 Lodhi Road, Delhi - IMD
18 Mandir Marg
19 Mandir Marg, Delhi - DPCC
20 NSIT Dwarka
21 NSIT Dwarka, Delhi - CPCB
22 North Campus, Delhi - IMD
23 Punjabi Bagh
24 Punjabi Bagh, Delhi - DPCC
25 Pusa, Delhi - IMD
26 Pusa2 IMD
27 R K Puram
28 R K Puram, Delhi - DPCC
29 RK Puram
30 Shadipur
31 Shadipur, Delhi - CPCB
32 Siri Fort
33 Sirifort, Delhi - CPCB
34 US Diplomatic Post: New Delhi
Name: location, dtype: object
Let’s go ahead and filter our results to only grab locations that have been updated in 2017 and have at least 100 data points.
locations = locations.query("count > 100").query("lastUpdated >= '2017-03-01'")
locations.location
0 Anand Vihar
1 Anand Vihar, Delhi - DPCC
2 Aya Nagar, Delhi - IMD
3 Burari Crossing, Delhi - IMD
4 CRRI Mathura Road, Delhi - IMD
7 Delhi Technological University
8 Delhi Technological University, Delhi - CPCB
10 East Arjun Nagar-Delhi CPCB
12 IGI Airport Terminal-3, Delhi - IMD
13 IHBAS
14 IHBAS, Delhi - CPCB
15 Income Tax Office
16 Income Tax Office, Delhi - CPCB
17 Lodhi Road, Delhi - IMD
18 Mandir Marg
19 Mandir Marg, Delhi - DPCC
20 NSIT Dwarka
21 NSIT Dwarka, Delhi - CPCB
22 North Campus, Delhi - IMD
23 Punjabi Bagh
24 Punjabi Bagh, Delhi - DPCC
25 Pusa, Delhi - IMD
27 R K Puram
28 R K Puram, Delhi - DPCC
30 Shadipur
31 Shadipur, Delhi - CPCB
32 Siri Fort
33 Sirifort, Delhi - CPCB
34 US Diplomatic Post: New Delhi
Name: location, dtype: object
Now that we have several up-to-date locations in Delhi we can use, let’s see what parameters we have to play with!
params = []
for i, r in locations.iterrows():
[params.append(x) for x in r.parameters if x not in params]
params
['pm10', 'pm25', 'so2', 'o3', 'co', 'no2']
Great. Now we have a list of parameters that we can evaluate.
The rest of this tutorial will be finished in the future when I have away from writing manuscripts (unless someone wants to take a stab at it and send a pull request!)…


Introduction
The purpose of this document is to facilitate contributions to LAPACK and ScaLAPACK by documenting their design and implementation guidelines. The long-term goal is to provide guidelines for both LAPACK and ScaLAPACK. However, the parallel ScaLAPACK code has more open issues, so this document primarily concerns LAPACK. Details on threading and other issues likewise have been deferred and will be shaped by future contributions discussions.
These are style and design guidelines, exceptions may be allowed if accompanied by sound reasons and good documentation. To enable development and use of automated tools, rules regarding issues like formatting are far less flexible. Copyright and licensing rules are completely inflexible; see the section on [licensing] below.
Many parts of the current code may not live up to these guidelines. Fixes are greatly appreciated. See the section on [maintenance] and the "TODO" notes in each section.
Not all of the guidelines have been completely decided. Questions to contributors are listed after relevant sections.
Please coordinate possible contributions with<EMAIL_ADDRESS>and<EMAIL_ADDRESS>High-Level Design Choices
These guidelines follow from some considerations of implementation languages, memory managements, and performance goals.
We do not have the resources or desire to throw away the existing code and recode the algorithms from scratch in a new language. Our plans are to keep the code primarily in Fortran. Existing code is primarily in the dialect of Fortran 77 available in the 1990s. New code may adopt newer language features so long as they
-
are widely available in compilers,
-
improve ease of use,
-
improve ease of maintenance, and
-
do not impose a significant cost in performance or memory usage.
Current prohibitions and warnings on new language features are discussed in [fortran] .
Some components and routines may be in written in C. Current C components include
-
the reference Extended Precision BLAS implementation, and
-
ScaLAPACK’s communication substrate, the PBLAS and BLACS, as well as such support routines as REDIST.
Future C components will be considered on a case-by-case basis. Interoperability with C is important but difficult to achieve both simply and portably. Some considerations are listed in [c-interop].
LAPACK strives to accommodate both users who want control over memory allocation as well as users who want automatic workspace allocation. We have decided not to use dynamic allocation within LAPACK computational routines. Instead, we will provide a programmatic mechanism to query routines and determine necessary workspace, see [workspace]. Concerns about memory usage and performance also drive decisions on language features in [fortran] .
Our design should enable writing user-friendlier wrappers in other high-level languages (including full-featured F95), but the design of these wrappers is not the subject of this document.
Reproducibility
Reproducing exact results between runs on the same data for debugging or certification is challenging. We must balance common needs for reproducibility against performance gains from randomized algorithms and parallel processing. The trade-offs and design considerations are not completely clear at this point, but we must support reproducible results whenever possible.
To allow users to compute reproducible results whenever a platform allows, the following rules apply to uses of randomization in LAPACK:
-
Use the LAPACK PRNGs (Pseudo-Random Number Generators) like xLARUV and xLARNV. These are portable routines. When given the same seed, they generate the same numbers on all platforms.
-
Testing and timing code must set the seed to a constant in the source.
-
LAPACK library routines also must use a constant seed whenever possible. Constant seeds are not possible if the code’s randomized performance or correctness relies on not having static bad cases. If a routine cannot use a static seed, it must allow users to input a seed value in order to support debugging.
-
The impact of tuning parameters on the numerical results must be documented.
We cannot control the reproducibility of tuned platform BLAS. Users should be able to use the reference BLAS when necessary.
There are many unresolved issues regarding reproducing numerical results on parallel platforms. At the very least, ScaLAPACK must provide options to control communication and ensure reproducibility for a particular process layout. Discussions of and contributions towards distributed and shared-memory parallel reproducibility are welcome.
Copyrights and Licensing
All code must have the same license. We have chosen the Modified BSD license, available both in the COPYING file in the next distribution as well as at http://www.opensource.org/licenses/bsd-license.php.
Before a contribution can be accepted into LAPACK or ScaLAPACK, the contributors must submit documentation that
-
states that the contributor grants all necessary copyright and patent licenses of the contribution so we can include it in LAPACK and ScaLAPACK under the Modified BSD license, and
-
declares the contributor to have necessary legal authority to grant the above.
The document makes claims only regarding the contribution to LAPACK, not on any other uses of the same material. The necessary form is available at http://www.netlib.org/lapack-dev/LAPACK_contributors_agreement.txt.
Citing the authors of the software
The original authors of the software will be listed in the code first, followed by authors of important changes. Contributors will be listed in both the source distribution and the Users' Guide.
Documentation
Each type of documentation has a specific purpose. This section provides an overview of what topics the documentation should address.
- Source Code
-
Inform users on how to call a routine.
- Users' Guide
-
Tie routines together and provide examples.
- Working Notes
-
Document the mathematical details and design considerations.
Source Code
Each source file for an exported routine (e.g. SRC/*.f
) must
contain documentation on how to use the routine. The
documentation should
-
briefly describe the routine’s purpose,
-
describe each argument,
-
optionally provide a reference for further details.
The documentation’s format is explained in [src-format] along with other aspects of source formatting.
LAPACK Users' Guide
The LAPACK Users' Guide (LUG) provides higher-level information about the routines and their interfaces without the full technical and mathematical details that drive the design. The current LUG is available through SIAM and electronically at http://www.netlib.org/lapack/lug/index.html.
Each published interface must be incorporated into the LUG. The precise form will depend on the routines. The goals are to provide user with
-
the relationships between routines,
-
mathematical and design details needed for users to chose an appropriate routine,
-
brief examples of common uses, and
-
high-level advice to users.
The interface documentation from the source code will be reproduced at the end of the LUG. Therefore there is no need to duplicate this detailed interface documentation in the earlier LUG sections.
LAPACK Working Notes (LAWNs)
Details about mathematical derivations and design decisions belong in the LAPACK Working Notes (LAWNs). These notes will be published through the LAPACK repository at Netlib; the current notes are available at http://www.netlib.org/lapack/lawns/index.html. We make no restrictions on other publications of the same material.
Every major routine should have a LAWN documenting the algorithm, error analysis, performance, and testing. LAWNs describing new routines must address the following points:
-
Purpose
-
Usage
-
Error conditions and returns
-
Applicability and restrictions (including arithmetic, see below for current arithmetic restrictions in LAPACK)
-
Discussion of the method and algorithm
-
Algorithm design decisions
-
Accuracy
-
Tuning parameters
-
Test cases
-
Timing tests
-
References
Currently the only arithmetic restrictions are in the eigenvalue routines (IEEE exception handling in EGR and EBZ algorithms, monotonicity and rounding accuracy in EBZ, guard digits in EDC). For further details, grep for "IEEE" and "arithmetic" in the SRC directory.
Keep in mind that LAWNs are static publications, but LAPACK is evolving code. The LAWNs provide snapshots of design decisions. Engineering choices in the routines' designs may change once the code is reviewed.
Workspace and Memory Management
It is natural to ask whether we should dynamically allocate workspace inside LAPACK routines, and so do away with complicated workspace counting code and asking the user to allocate it. Many users would like this. However, there are also important users who want to control their own workspace, both for performance reasons and so to be ensure memory allocation errors cannot occur (e.g. in real-time control loops). To make everyone happy (except perhaps us developers) we currently plan to handle this as follows:
-
Change all routines that need workspace to be queryable for how much workspace is needed. This means that users can quickly ask how much space is necessary and handle it appropriately themselves, and it will let us more easily write wrappers in various languages that provide automatic memory allocation. This option is already available in much of LAPACK by using LWORK=-1; our goal is to extend this feature to all of LAPACK.
-
Routines that call other routines needing workspace will in turn have to query those other routines to determine the total amount of workspace. In other words, no assumptions about workspace needs of other routines should be built in. This will both help eliminate bugs and permit innovations and bug fixes that change workspace to be made to one routine without changing lots of others too.
-
We are not sure how many "levels" of workspace query to provide: a routine could have different values for
-
the smallest possible workspace for correct functioning
-
the right amount for reasonable speed given various block size values (from querying ILAENV)
-
maximum space for very fast functioning. For example, DC needs 3n2 + O(n) total space, MRRR needs 2n2 + O(n) and QR needs only n2 + O(n) for the dense symmetric eigenproblem. So a smart driver could call any of these, depending on workspace.
-
Options (a), (b) and (c) could be implemented using other negative values of LWORK. This is also discussed below in the section on "Determining the Block Size for Block Algorithms".
The routines xGEESX and xGGESX are the only exceptions using LWORK for a workspace query. For these routines, the value of LWORK is dependent upon the dimension of the invariant subspace (SDIM), and is not known on entry to the routine.
We are considering new drivers that split the functionality of xGEESX and xGGESX into two subroutine calls, so that at the end of the first call all the eigenvalues are known, and the second routine is given the specific desired subset of these eigenvalues, whose cardinality is then known. This means both routines could determine their workspace needs in advance.
Testing and timing code can dynamically allocate memory. Arrays larger than some systems' caches may require dynamic allocation for some compilers (e.g. Sun’s).
Routine Naming and Design
Routine Naming
The LAPACK project intends to maintain backwards compatibility. New routines get new names. Fixes to old routines that preserve the interface can keep the names. If the only change to the interface is to decrease the amount of workspace needed, the old routine name can be kept.
We are no longer limited to 6 characters for routine names. Underscores are ok. At present, this causes problems in a variety of codes that assume 6 character names when they parse input springs (e.g. ILAENV, XERBLA, xOPLA, etc.). We are working to address these issues (see [maintenance]).
Internal Design and Name Usage
Recursion is permitted. But beware of excessive stack usage; it should not be used as a substitute for workspace allocation as discussed in [workspace]. Roughly speaking, as long as the stack only grows to O(log n) then there should be no problem. If the alternative is a non-recursive routine that uses the same space, and if the recursive routine is more readable, prefer the recursive version.
We will use the BLAS and extended BLAS names from BLAST Forum in new code. There is a new BLAS standard [blast], but a partial reference implementation exists only for the extended (and sparse) BLAS. We would like new LAPACK routines to use the new interface and provide a reference implementation that simply calls the appropriate old BLAS routine. Over time this will encourage developers and vendors to migrate to the new BLAS. We will provide an extended BLAS release as part of LAPACK, since it is needed for the new iterative refinement codes.
We prohibit the use of I/O within LAPACK computational routines, with a natural exception for parallel communication. Policies regarding any future out-of-core routines will be considered along with the routines. There should be no terminal or user I/O outside the default XERBLA ([err-handling]).
Error Handling and the Diagnostic Argument INFO
All documented routines have a diagnostic argument INFO that indicates the success or failure of the computation, as follows:
-
INFO = 0: successful termination
-
INFO < 0: illegal value of one or more arguments — no computation performed
-
INFO > 0: failure in the course of computation
All driver and auxiliary routines check that input arguments such as N or LDA or option arguments of type character have permitted values. If an illegal value of the ith argument is detected, the routine sets INFO = -i, and then calls an error-handling routine XERBLA.
The standard version of XERBLA issues an error message and halts execution, so that no LAPACK routine would ever return to the calling program with INFO < 0. However, this might occur if a non-standard version of XERBLA is used.
Determining Machine Arithmetic Parameters
The xLAMCH interfaces for returning machine arithmetic parameters will be maintained and will be made thread-safe. New code must use xLAMCH.
Many Fortran language queries provide equivalent information. For reference, the table below summarizes the widely available Fortran 95 query functions that are equivalent to xLAMCH calls.
| xLAMCH parameter | F95 intrinsic | Description |
|---|---|---|
| E | EPSILON | Epsilon |
| B | RADIX | Base |
| N | DIGITS | Significand digits |
| M | MINEXPONENT | Min. exponent |
| U | TINY | Underflow threshold |
| L | MAXEXPONENT | Max. exponent |
| O | HUGE | Overflow threshold |
The two queries "P" and "S" can be derived from F95 intrinsics as follows (example are given for double precision quantities):
-
P: Product of epsilon and the base
EPSILON(0.0d0) * RADIX(0.0d0)
-
S: Safe minimum such that 1/xLAMCH(S) does not overflow
SFMIN = TINY(0.0d0)
SMALL = 1.0d0/HUGE(0.0d0)
if (SMALL >= SFMIN) SFMIN = SMALL * (1+EPSILON(0.0d0))
xLAMCH("R") has no corresponding query function in Fortran 95 but grep reveals no use of this query in LAPACK. Likewise, SLAMC1’s test for round-to-nearest and SLAMC2’s test for compliance to IEEE-754 have no corresponding queries in Fortran 95. Fortran 2003 provides these and additional useful predicates (e.g. IEEE_IS_NAN) when an implementation supports IEEE-754 arithmetic, but these compilers are not yet widely available.
C89 provides similar support in float.h. C99 includes greatly improved support for IEEE-754 arithmetic in float.h and math.h. This support is in widely available C compilers, but some system libraries do not fully support fused multiply-add and flag tests.
Determining the Block Size for Block Algorithms
LAPACK routines that implement block algorithms need to determine what block size to use. The intention behind the design of LAPACK is that the choice of block size should be hidden from users as much as possible, but at the same time easily accessible to installers of the package when tuning LAPACK for a particular machine.
LAPACK routines call an auxiliary enquiry function ILAENV, which returns the optimal block size to be used as well as other parameters. The version of ILAENV supplied with the package contains default values that led to good behavior over a reasonable number of our test machines, but to achieve optimal performance, it may be beneficial to tune ILAENV for your particular machine environment. Ideally a distinct implementation of ILAENV is needed for each machine environment (see also Chapter 6 of the LUG). The optimal block size also may depend on
-
the routine,
-
the combination of option arguments (if any),
-
the problem dimensions, and
-
the available workspace.
We ultimately plan to determine these values by an automatic tuning process akin to the one used in ATLAS and related packages.
If ILAENV returns a block size of 1, then the routine performs the unblocked algorithm, calling Level 2 BLAS, and makes no calls to Level 3 BLAS.
Some LAPACK routines require a work array whose size is proportional to the block size (see subsection 5.1.7 of the LUG). The actual length of the work array is supplied as an argument LWORK. The description of the arguments WORK and LWORK typically goes as follows:
WORK
(workspace) REAL array, dimension (LWORK)
On exit, if INFO = 0, then WORK(1) returns the optimal
LWORK.
LWORK
(input) INTEGER
The dimension of the array WORK. LWORK >= max(1,N).
For optimal performance LWORK >= N*NB, where NB is the
optimal block size returned by ILAENV. The routine
determines the block size to be used by the following
steps: ...
For such a routine, if LWORK >= max(1,N),
-
the optimal block size is determined by calling ILAENV;
-
if the value of LWORK indicates that enough workspace has been supplied, the routine uses the optimal block size;
-
otherwise, the routine determines the largest block size that can be used with the supplied amount of workspace;
-
if this new block size does not fall below a threshold value (also returned by ILAENV), the routine uses the new value;
-
otherwise, the routine uses the unblocked algorithm.
The minimum value of LWORK that would be needed to use the optimal block size is returned in WORK(1) (see [workspace]).
Thus, the routine uses the largest block size allowed by the amount of workspace supplied, as long as this is likely to give better performance than the unblocked algorithm. WORK(1) is not always a simple formula in terms of N and NB.
The specification of LWORK gives the minimum value for the routine to return correct results. If the supplied value is less than the minimum — indicating that there is insufficient workspace to perform the unblocked algorithm — the value of LWORK is regarded as an illegal value, and is treated like any other illegal argument value (see subsection 5.1.9 of the LUG).
If in doubt about how much workspace to supply, users must use the query mechanism described in [workspace]. That section is still in flux. There is no mechanism that will work for the entire library at this point, but that is being addressed. The query mechanism will be available for all routines that use workspace.
Fortran Language Features
We have considered what features of Fortran to use beyond those in the F77 dialect we have used so far, and what features to deprecate. The following summarizes our current plans, based on availability of Fortran compilers, and sometimes conflicting desires of users for ease of use, high performance, and memory safety.
New code should meet the following guidelines. Assistance in converting existing code to the guidelines would be gratefully accepted. These guidelines are far more flexible in testing and timing code.
- Use DO WHILE and DO / END DO
-
DO WHILE was adopted by Fortran 90 and is widely available. Using DO with END DO rather than a numbered CONTINUE makes the code more readable both by people and parsers.
- No new common blocks
-
Currently there are no common blocks in the SRC code, just TESTING and TIMING. These create thread safety problems, and also create problems in TESTING and TIMING, because they assume 6 character routine names, a restriction we are eliminating (see below).
- No equivalence statements
-
New Fortran language features make them unnecessary for many uses.
- No save statements
-
SAVE statements often impose thread safety problems. The next release will provide SAVE-free versions of xLAMCH, xLACON, and other SAVE-using source routines. xLAMCH routines will preserve the interface. Removing SAVE statements from xLACON and others would require changing the interface. Instead, we provide and use functions contributed by Sven Hammarling and NAG Ltd. The release notes will provide more information on the new routines.
- Use internal procedures rather than statement functions
-
Statement functions are an "obsolescent" Fortran language feature. See [obsolescent] for a full list.
- Provide INTERFACE blocks in include files
-
INTERFACE blocks provide argument type-checking within the Fortran language without needing external tools like ftnchek or NAG’s utilities. See [src-format] for guidelines about include files.
- Do not use assumed-shape arrays in interfaces
-
Assumed-shape argument arrays, those defined like
REAL A(:,:)
add information to the low-level arguments passed into the routine, complicating language interoperability. Additionally, passing arrays as assumed-shape arguments may impose performance and memory costs. The F95 wrappers may use assumed arrays in the style of LAPACK95 [lapack95], as opposed to LAPACK3E [lapack3e].
The preferred mechanism for passing arrays is described in [src-format].
- Modules are limited to arbitrary / high-precision routines
-
We likely will need modules to provide arbitrary precision versions of LAPACK routines. We will approach this by parsing the module-free code and automatically generating new code with modules inserted to redefine the arithmetic. Fortran abstractions available only through modules permit a variety of longer fixed or variable precision packages to be used (QUAD, ARPREC, MPFR, etc.). Modules may also be used for the F95 wrappers.
- Derived types (structures) cannot appear in interfaces
-
Derived types are Fortran’s structured data type, and they suffer from many language restrictions.
-
They may appear in INTERFACE blocks only when the derived type is defined in another module.
-
Two separate derived type declarations for the same name may be represented differently unless the SEQUENCE keyword appears. SEQUENCE packs the elements in declaration order, requiring careful attention to alignment for high performance.
-
Fortran prior to F03 does not provide any guarantees for interoperability between derived types and other languages.
Thus, we cannot use derived types in interfaces or pass them between externally visible routines without modules. Work on the arbitrary precision versions may require modules for this reason. We will address interoperability concerns at some future point, possibly by relying on F03’s BIND(C).
-
- Be careful with WHERE masks and FORALL assignments
-
Fortran 95 WHERE masks and FORALL assignments have strict evaluation semantics. Both require that the mask and right-hand side be fully evaluated before the WHERE or FORALL is executed. If the mask or right-hand side is an expression, or if there are data dependencies or possible aliasing issues, the compiler may dynamically allocate space to hold an intermediate evaluation.
- Be careful with array slicing
-
Modern Fortran allows MATLAB™-like ranges and array slicing. Used with care, these can make code much more readable. However, slicing arrays declared with LAPACK’s explicit leading dimension style (see [src-format.lda]) may lead to intermediate copies. Many compilers provide options to warn when the particular compiler decides to use intermediate allocations, but the decision varies according to the compiler, the sequence of optimizations applied, and the language requirements.
If in doubt, write a loop.
- Use BLAS routines rather than intrinsics (e.g. MATMUL)
-
For similar reasons as the above. We know the memory behavior of the BLAS, but not of the compilers' array intrinsics.
Interoperability with C
We must mix C and Fortran internally to call the reference extended precision BLAS as well as ScaLAPACK’s PBLAS and BLACS substrate. We are actively investigating how best to handle C and Fortran interoperability both internally and for external interfaces. We would prefer a light-weight solution as opposed to systems like Babel [babel].
Currently, we assume the following types share the same low-level machine representation. C89 does not provide complex numbers or operators, but C99 guarantees the associations between C89 and C99 below.
| Fortran | C99 | C89 |
|---|---|---|
| INTEGER | int | int |
| REAL | float | float |
| DOUBLE PRECISION | double | double |
| COMPLEX | float _Complex | float[2] |
| DOUBLE COMPLEX | double _Complex | double[2] |
Thus, we assume that an array COMPLEX A(5, 6) on the Fortran side corresponds to an array float _Complex a[30] in C99 and float a[60] in C89. The (2,3) entry of the Fortran A would be located at a[2 + 3*5] in C99. In C89, the real part would be located at a[2*(2 + 3*5)], and the imaginary part at a[2*(2 + 3*5)+1].
One prohibition to types in cross-language interfaces must apply:
- Do not use C’s enum in header files that will be parsed by C++
-
C specifies that all enums are the same size. C
explicitly allows different enums to have different sizes. Many compilers happen to use the C definition in C
, but that is not guaranteed.
Obsolescent Fortran
The following is an incomplete list of features declared obsolescent by or deleted from the 1995 and 2003 Fortran standards. If the item is listed as "not used", then they almost certainly do not appear in LAPACK. If the item is "likely not used", then searching has not turned up instances, but we are not completely sure.
- Real DO variables
-
Obsolescent in Fortran 1995, deleted in Fortran 2003. Likely not used in LAPACK.
- Branching to an END IF from outside the IF block
-
Obsolescent in Fortran 1995, deleted in Fortran 2003. Likely not used in LAPACK. Can be replaced by a CONTINUE after the END IF.
- PAUSE
-
Obsolescent in Fortran 1995, deleted in Fortran 2003. Likely not used in LAPACK.
- ASSIGN and assigned GO TO statements
-
Obsolescent in Fortran 1995, deleted in Fortran 2003. Likely not used in LAPACK.
- The H edit descriptor
-
Obsolescent in Fortran 1995, deleted in Fortran 2003. Not used in LAPACK.
- Arithmetic IF statements
-
Obsolescent in Fortran 2003. (We have not searched for these.)
- Termination of multiple DO loops on the same statement
-
Obsolescent in Fortran 2003. (We have not searched for these.)
- Using one CONTINUE or statement for multiple DO loops
-
Obsolescent in Fortran 2003. (We have not searched for these.)
- Alternate returns
-
Obsolescent in Fortran 2003. Likely not used in LAPACK.
- Computed GO TO
-
Obsolescent in Fortran 2003. There are a few computed GO TOs in xLACON and xLACN2, at least.
- Statement functions
-
Obsolescent in Fortran 2003. Replace with internal procedures (CONTAINS). Used as CABS1 and ZABS1, at least.
- DATA statements intermixed with executable statements
-
Obsolescent in Fortran 2003. Likely not used in LAPACK.
- Assumed length character functions
-
Obsolescent in Fortran 2003. Not used in LAPACK.
- Fixed-format source
-
Obsolescent in Fortran 2003. We do not expect compilers to forget how to parse fixed-format source, so we do not prohibit its use.
- CHARACTER*len
-
Obsolescent in Fortran 2003. Replace with CHARACTER(len). The CHARACTER*1 form currently is used for option arguments.
New code must not use these features, and existing code should have them removed.
Source Formatting
In general, follow existing LAPACK style. The LAPACK routines conform to a single set of conventions for their design and documentation. To accommodate ease of parsing just described, we will insist on a uniform format.
The structure of a LAPACK routine includes:
-
the SUBROUTINE or FUNCTION statement, followed by statements declaring the type and dimensions of the arguments;
-
an IMPLICIT NONE declaration;
-
a summary of the Purpose of the routine;
-
descriptions of each of the Arguments in the order of the argument list;
-
(optionally) Further Details (only in the code, not in the generated LUG pages in Part 2)
-
Internal Parameters if any are used (only in the code, not in the generated LUG pages in Part 2).
We are no longer limited to 6 characters for variable names, and underscores are ok.
File Names and Organization
Computational routines and drivers are placed in the SRC directory of the LAPACK distribution. Each file holds one routine. Testing and timing codes are in subdirectories under TESTING and TIMING, respectively. More information about testing and timing codes is in [test-time].
Fortran sources in fixed format and using only Fortran 77 features shall have the extension ".f".
Fortran files designed to be included in other source files, say for defining common constants, shall have extension ".fh". Such files must be formatted for both fixed- and free-format source. There will be no characters in the first six columns, and lines will be at most 72 characters wide. Do not use continuations in include files. These files are to be included using the now-standard Fortran INCLUDE statement and not the C preprocessor. We are not supporting C preprocessing in Fortran at this time.
Order of Arguments
Arguments of an LAPACK routine appear in the following order:
-
arguments specifying options;
-
problem dimensions;
-
array or scalar arguments defining the input data; some of them may be overwritten by results;
-
other array or scalar arguments returning results;
-
work arrays (and associated array dimensions);
-
diagnostic argument INFO.
This is not a hard and fast rule. It may make sense to cluster arguments according to other considerations.
Argument Descriptions
The style of the argument descriptions is illustrated by the following example:
N
(input) INTEGER
The number of columns of the matrix A. N >= 0.
A
(input/output) REAL array, dimension (LDA,N)
On entry, the m-by-n matrix to be factored. On exit, the
factors L and U from the factorization A = P*L*U; the unit
diagonal elements of L are not stored.
The description of each argument gives:
-
a classification of the argument as (input), (output), (input/output), (input or output), (workspace) or (workspace/output);
-
the type of the argument;
-
(for an array) its dimension(s);
-
a specification of the value(s) that must be supplied for the argument (if it’s an input argument), or of the value(s) returned by the routine (if it’s an output argument), or both (if it’s an input/output argument). In the last case, the two parts of the description are introduced by the phrases "On entry" and "On exit".
-
(for a scalar input argument) any constraints that the supplied values must satisfy (such as "N >= 0" in the example above).
Option Arguments
Arguments specifying options are usually of type CHARACTER(1). The meaning of each valid value is given, as in this example:
UPLO
(input) CHARACTER(1)
= 'U': Upper triangle of A is stored;
= 'L': Lower triangle of A is stored.
The corresponding lower-case characters may be supplied (with the same meaning), but any other value is illegal (see subsection 5.1.9 of the LUG).
A longer character string can be passed as the actual argument, making the calling program more readable, but only the first character is significant; this is a standard feature of Fortran 77. For example:
CALL SPOTRS('upper', . . . )
Problem Dimensions
It is permissible for the problem dimensions to be passed as zero, in which case the computation (or part of it) is skipped. Negative dimensions are regarded as erroneous.
Array Arguments
Each two-dimensional array argument is immediately followed in the argument list by its leading dimension, whose name has the form LD<array-name>. For example:
A
(input/output) REAL/COMPLEX array, dimension (LDA,N)
...
LDA
(input) INTEGER
The leading dimension of the array A. LDA max(1,M).
It should be assumed, unless stated otherwise, that vectors and matrices are stored in one- and two-dimensional arrays in the conventional manner. That is, if an array X of dimension (N) holds a vector x, then X(i) holds x_i for i = 1, …, n. If a two-dimensional array A of dimension (LDA,N) holds an m-by-n matrix A, then A(i,j) m). See Section 5.3 of the LUG for more about storage of matrices.
Note that array arguments are usually declared in the software as assumed-size arrays (last dimension *), for example:
REAL A( LDA, * )
although the documentation gives the dimensions as (LDA,N). The latter form is more informative since it specifies the required minimum value of the last dimension. However an assumed-size array declaration has been used in the software, in order to overcome some limitations in the Fortran 77 standard. In particular it allows the routine to be called when the relevant dimension (N, in this case) is zero. However actual array dimensions in the calling program must be at least 1 (LDA in this example).
Testing and Timing Routines
Testing routines
-
Test with various NB
-
If the new code replaces a current implementation, ensure it passes the current tests.
-
If the code introduces a new interface,
-
test all the functionality for typical inputs,
-
test any extra accuracy claims with a few examples,
-
test all the possible INFO returns, and
-
test with all relevant dimensions equal to zero.
-
-
All testing routines should be deterministic. Seeds for generating pseudorandom numbers must be constant to allow for debugging. See the section on [repro].
Timing routines
In the future timing will not be a default part of the installation procedure, but optional. If the routine is providing a new function, or is a better version of an old routine that is remaining in the library, new timing code should be added to the existing code. If the new routine simply replaces an old routine, the existing timing code can be used. For example, the new QR and QZ routines will use the old timing code.
Suggested Maintenance Projects
List of projects we would greatly appreciate someone handling, and that make for a good introduction to the code. They are time-consuming jobs but they do not require a deep familiarity with the mathematics or algorithms within LAPACK.
-
Ensure IMPLICIT NONE is in all routines, and add necessary declarations.
-
Remove COMMON blocks.
-
Replace obsolescent language features.
-
Replace fixed-length CHARACTER*6s throughout. Such declarations that appear in argument lists can be replaced by variable-length strings (CHARACTER(*)) without harm. Fixing local arrays and common block declarations will take more work. The testing and timing code has the most serious issues.
-
Make the testing and timing code useful for other developers. It would be widely useful if outside implementations could run in exactly the same test and timing harness as LAPACK routines. This would provide one standard for comparison.
-
Clean up the build system. Distributors may appreciate some form of automatic configuration. The GNU autoconf system does not handle cross-compilation well, and that is required for some resource-constrained platforms like vector machines and embedded systems. Portable linker scripts could be useful for controlling which symbols are exported; see [shared-lib] for examples on ELF-based systems.
-
Add tests for the random number generators that compare the first, say, 1000 generated numbers to 1000 reference numbers.
Reference Notes
On-line copies of the Fortran 66, Fortran 77 and MIL-STD 1753 documents are available through http://www.fortran.com/stds_docs.html. The Fortran 95 standard is insanely expensive, but the contents are summarized in [f95handbook].
The Fortran 2003 standard is available for around $30 electronically from ANSI. The "Final Committee Draft", which is essentially the same as the standard, is available at http://j3-fortran.org/doc/standing/2003/007.pdf and http://std.dkuug.dk/jtc1/sc22/open/n3661.pdf. The 1999 C standard also is available electronically through ANSI for a reasonable price.
Bibliography
-
[f95handbook] Adams, Bainerd, Martin, Smith, and Wegener. Fortran 95 Handbook; Complete ISO/ANSI Reference. MIT Press. ISBN 0-262-51096-0.
-
[blast] Blackford, et al. Basic Linear Algebra Subprograms Technical Forum Standard. International Journal of High Performance Computing, 15(3-4), 2001. http://www.netlib.org/blas/blast-forum/
-
[lapack95] Barker, Blackford, Dongarra, Du Croz, Hammarling, Marinova, Wasniewski, and Yalamov. LAPACK95 Users' Guide. SIAM, 2001. http://www.netlib.org/lapack95/
-
[lapack3e] Anderson. LAWN 158: LAPACK3E - A Fortran 90-enhanced version of LAPACK. http://www.netlib.org/lapack3e/lawn158.pdf
-
[shared-lib] Drepper. How To Write Shared Libraries. http://people.redhat.com/drepper/dsohowto.pdf
-
[babel] Dahlgren, Epperly, Kumfert, and Leek. Babel Users' Guide. 2005. http://www.llnl.gov/casc/components/docs.html


Constructor
new StrategyResolver(strategy: any, state: any): StrategyResolver
Creates an instance of the StrategyResolver class.
Parameters
strategy: any
state: any
new StrategyResolver(strategy: any, state: any): StrategyResolver
Creates an instance of the StrategyResolver class.


Row #1
Row #2
Row #3
Row #4
Row #5
Row #6
Row #7
Row #8
Row #9
Row #10
Check all
Uncheck all
Check all


Concept Mutable_InfiniteRangeRunStorage
Mutable_InfiniteRangeRunStorage
Notation
- S
- A type playing the role of mutable-infinite-range-run-storage-type in the Mutable_InfiniteRangeRunStorage concept.
- s
- Object of type S
- r
- Object of type run_type
- v
- Object of type value_type
Models
- boost::time_series::dense_series<double>