text:
# Stellar Power(Luminosity) Flux

So I was applying some mathematical techniques I learned to physics, and one thing that captured my interest, is the power or luminosity flux of a star. So modeling the situation, taking the scalar field of Luminosity($L$), and the vector surface(stellar surface), $S$, I began by setting up a Surface (Flux, in this case) integral of

$$\iint_{S}L\,dS$$

Where,

$$S=\langle r\sin\theta \cos\phi,r\sin\theta \sin\phi,r\cos\theta \rangle \;,\; \theta \, \epsilon \, [0,\pi] \wedge \phi \, \epsilon \, [0,2\pi]$$ $$L = 4\pi r^{2}\sigma T^{4}$$

$r$ in this model is the invariant stellar radius. Following logic, since $L$ has no explicit dependency on $\theta$ or $\phi$, I rearranged as:

$$4\pi r^{2} \sigma T^{4} \iint_{S} dS$$

Since the integral of dS over S is merely surface area, and our surface is a sphere of radius $r$, this expression reduces to:

$$16\pi^{2} r^{4} \sigma T^{4}$$

The dimensional analysis for this breaks down to $W \cdot m^{2}$. Isn't flux supposed to be quantity per area?

• Why would you integrate luminosity over area? Luminosity is energy per time. Flux is energy per area per time. You could integrate flux over area to get luminosity. But I don't understand what you're trying to do here. – kleingordon Dec 7 '13 at 9:26
• If this is the case, then how should the problem of finding the flux of luminosity be stated initially? – Doryan Miller Dec 8 '13 at 7:49
• Using conventional definitions, there is no "flux of luminosity." Again, consider the units. Luminosity is energy per time. Flux is energy per area per time. The two are related because you can integrate flux over area to obtain luminosity. For a blackbody emitter, the flux is $\sigma T^4$. And if the emitter is spherically symmetric, then the luminosity is equal to the spherical surface area times the flux: $L = 4 \pi r^2 \sigma T^4$. – kleingordon Dec 8 '13 at 10:54
• Ah! That makes sense. So the essence of what I was doing was finding the flux of the flux, which is meaningless in this case. Aye? – Doryan Miller Dec 9 '13 at 5:19
• More or less. You were taking something with units of energy per time, and then integrating over a surface to get something with units of energy per time multiplied by area, which does not have much physical relevance. I think what you really wanted to do was to start with something with units of flux (energy per time per area), like $\sigma T^4$, and then integrate over a surface to get something with units of energy per time, or luminosity. The relevant relation that emerges is $L = 4 \pi r^2 \sigma T^4$, which you quoted. I think that is the final result you are proving here. – kleingordon Dec 9 '13 at 5:58

$L = \int \int {\bf F} \cdot d{\bf s}$
is where you should start, where $F$ is the flux in units of Watts/m$^2$.
Blackbody flux is given by $\sigma T^4$ and hence an isotropic flux integrated over a sphere
$$L = \int^{2\pi}_{0} \int^{\pi}_{0} \sigma T^4 r^2 \sin \theta\, d\theta\,d\phi = 4\pi r^2 \sigma T^4$$
$L$, the term for Luminousity, IS the power flux across a stellar surface. I've been trying to find what I already had. Doing so then resulted in multiplying the flux in essence by distance units $m$, but in the fourth order of magnitude.


text:
Calc

# Fractions Calculators

Use the first calculator to add, subtract, multiply or divide fractions. Use the second calculator to simplify fractions, using the greatest common factor. Finally, use the third calculator to convert a decimal to a fraction. Should you need any help with calculating fractions manually, please see the information at the bottom of this page.

## Mixed fractions calculator

For simple fractions, enter the fraction with a slash (/). Example: 3/4. For mixed numbers, use spaces. Example: 16 3/4.

## Simplify a fraction

Find the common factor of a fraction and then simplify it to its lowest form. A decimal conversion is also provided.

## Convert a decimal number to a fraction

Change a decimal to a fraction. To convert a repeating decimal, enter into the second box the number of digits from the end of the decimal to repeat.

#### Disclaimer

Whilst every effort has been made in building this fractions calculator, we are not to be held liable for any special, incidental, indirect or consequential damages or monetary losses of any kind arising out of or in connection with the use of the converter tools and information derived from the web site. This fractions calculator is here purely as a service to you, please use it at your own risk. Do not use calculations for anything where loss of life, money, property, etc could result from inaccurate conversions.

## Calculating fractions with repeating decimals

My decimal to fraction calculator (featured in the third tab above) gives you the ability to enter repeating decimals by utilising the 'Number of trailing decimal places to repeat' box. To use it, simply enter the number of digits from the end of the decimal to repeat. For other non-repeating decimals, keep the default value at 0.

As an example, if you want to convert a repeating decimal such as 1.5476... then you should enter 1.5476 into the Decimal box and 4 into the Number of trailing decimal places to repeat box (signifying that the last 4 digits of the number should repeat).

## Fractions calculator - FAQ

I've been asked to provide some information about how the fractions calculator works out its results. So, I've included the formulae below along with some examples. Note that you need to have JavaScript enabled in your browser for these fraction formulae and examples to appear correctly formatted.

In order to add fractions together, use the following formula:

$$\dfrac{a}{b} + \dfrac{c}{d} = \dfrac{ad + bc}{bd}$$

Example of how to add fractions:

$$\dfrac{2}{3} + \dfrac{1}{4} = \dfrac{(2\times4) + (3\times1)}{3\times4} = \dfrac{11}{12}$$

### Subtracting fractions

To subtract fractions, the following formula can be used:

$$\dfrac{a}{b} - \dfrac{c}{d} = \dfrac{ad - bc}{bd}$$

Example of how to subtract fractions:

$$\dfrac{2}{3} - \dfrac{1}{4} = \dfrac{(2\times4) - (3\times1)}{3\times4} = \dfrac{5}{12}$$

### Multiplying fractions

When multiplying fractions, this formula will help:

$$\dfrac{a}{b} \times \dfrac{c}{d} = \dfrac{ac}{bd}$$

Example of how to multiply fractions:

$$\dfrac{2}{3} \times \dfrac{1}{4} = \dfrac{(2\times1)}{(3\times4)} = \dfrac{2}{12} = \dfrac{1}{6}$$

### Dividing fractions

If you are looking to divide two fractions, give this formula a try:

$$\dfrac{a}{b} \div \dfrac{c}{d} = \dfrac{ad}{bc}$$

Example of how to divide fractions:

$$\dfrac{2}{3} \div \dfrac{1}{4} = \dfrac{(2\times4)}{(3\times1)} = \dfrac{8}{3}$$

To learn how to calculate fractions using these formulae, take a look at our article how to add, subtract, multiply and divide fractions.

If you would like help with converting between decimals and fractions, see our article how to convert a decimal to a fraction.

format: plain


text:
Velocity required for orbit of satellite

I am very confused about orbital velocity for satellite launched from earth. It is states that: $$v=\sqrt{\frac{GM}{r}}$$ Some says that it is equal to 8000 m/s and some say 3.1 km/s. Please remove my doubt.

-

As the formula you wrote suggests, it depends on $r$, the distance between the satellite and the centre of mass. $3.1\:\mathrm{km/s}$ is for geostationary orbit, and $8000\:\mathrm{m/s} = 8\:\mathrm{km/s}$ is for low Earth orbit. Please see Wikipedia for more details.

-

The mass $M$ in the equation for orbital velocity would be equal to the mass of the Earth (assuming that the mass of the satellite can be neglected) and thus constant. The gravitational constant, $G$, like the name suggests is constant as well. But the radius of the (circular) orbit, $r$, can vary. So by using different altitudes at which the satellite would orbit Earth would yield different orbital velocities.

The product of the gravitational constant and the mass of a celestial body (like Earth) is often called the gravitational parameter and can be measured more accurately than the each of them separately. The gravitational parameter of Earth is equal to: $$\mu_{\oplus}=3.986004418\times 10^{14}\ m^3s^{−2}$$

If you would like to know which velocity would be needed to have an satellite in LEO (low Earth orbit) you could use a radius slightly bigger than Earths equatorial radius, $r_{\oplus}=6.3781\times10^6\ m$, say at $300\ km$ above the surface. Plugging these numbers into the equation yields an orbital velocity of: $$v_{LEO}=\sqrt{\frac{\mu_{\oplus}}{r_{\oplus}+h}}=7725.8\ ms^{-1}$$ This is close to your first value. If you would look at the equation you can see that the orbital velocity will increase the decreasing the radius. So to get closer to $8000\ ms^{-1}$ you would have to decrease the altitude even more. However I suspect that it is rounded up, since the altitude required to have that orbital velocity will put you underneath Earths surface.

And like Nathaniel said, $3.1\ km\ s^{-1}$ is the orbital velocity of a geostationary orbit, which has a radius of roughly $42164\ km$. A quick check yields an orbital velocity of $3.0747\ km\ s^{-1}$.

-


text:
## POSIX-Portable Operating System Interface based on uniX Cheatsheet Commands

This is a quick reference guide, mostly made of standard Unix commands.Basically because I got fed up of googling them all the time. (POSIX utilities, every Unix / Linux distribution has these POSIXstands for Portable Operating System Interface based on uniX).

For more information about each command, refer to a Unix manual or the man (stands for manual) command. Type man command at a TelNet/SSH Client Software prompt etc… to get info about using the “man” command.

### at

: execute commands at a specified time/date.

### awk

: a scripting language, especially useful for manipulating text and automation.

### bash

: invokes the Bourne Again Shell (standard on most boxes).

### batch

: execute commands when load permits.

### bc

: interactive C-like calculator (integers only).

### cal

: displays a calender, also lets you choose month/year using parameters.

### calender

: invoke a reminder service.

### cancel

: cancel request to calender.

### cat

: concatenate files (displays a file without scrolling ability. Simply dumps it to the standard output. Can be useful when chaining multiple applications to do complicated jobs, so one application can use another’s output as input).

### cd

: change the current working directory.

### chgrp

: change group ownership of a file.

### chmod

: change access patterns (permissions) to files.

### chown

: change user ownership of files.

### clear

: clear the screen.

### cmp

: compare two files.

: copy files.

### cpio

: archive and extract files.

### cron

: clock deamon (executes “batch” and “at” commands).

### crontab

: schedules commands at regular intervals.

### crypt

: encrypt , decrypt files using altered DES, standard to Unix passwords (restricted distribution).

### csh

: invoke the C shell.

### csplit

: split file into several other files.

### cu

: call up another unix terminal.

### cut

: cut selected fields from each line of file.

### date

: displays the time and date (can also change it if you’re root).

### dd

: convert and copy a file.

### df

: reports space (free, total etc’) on all mounted file systems.

### diff

: compare two files.

### diff3

: compare 3 or more files.

### dircmp

: compare two directories.

### du

: report disk usage.

### echo

: echo argument to standart output.

### ed

: line oriented editor.

### egrep

: extended version of grep (searches for extended regular expressions).

### fgrep

: same as grep, only it interprets patterns as a list of fixed strings.

### expr

: evaluate boolean and arithmetic expression.

### false

: return nonzero (false) exit status.

### file

: report type of file.

### find

: find matching files and run specified programs on them (optional).

### finger

: report user information (operates remotely only if a finger server is running on the remote host).

### ftp

: (file transfer protocol) a client for FTP servers.

### grep

: search files for regular expression matches.

### haltsys

: gracefully shutdown sytem (can only be run by root. halt in Linux).

: display first 10 lines of a file.

### join

: display the combination (lines with command field) of two fields.

### kill

: send a signal to terminate a process.

### ksh

: invoke the korn shell.

### line

: read a specific line out of a file (shell script usage).

### ln

: create a link to a file/directory.

### whoami

: which user you are logged in as at the moment. If you, for example, switch to a different user, logname will show the original username you logged in as, and whoami will show the current user.

### lpr

: sends a request to printer.

### lprint

: prints on local printer.

### lpstat

: reports printer status.

: same as above.

### ls

: lists the contents of directory.

### mail

: send and recieve mail.

### man

: displays manual pages.

### mesg

: grant or deny permissions to recieve messages from other users using the write command.

### mkdir

: create a new directory .

### mknod

: build a special file.

### more

: display file one page at a time.

### mount

: mount a storage device.

### mv

: move or rename a file.

### news

: display news item from NNTP servers.

### nice

: change priorities of processes.

### nohup

: run a command after logout (ignores hangup signals).

### nroff

: format files for printing.

### nslookup

: retrieve information from DNS servers.

### od

: displays a file in 8-based octals.

### paste

: merge lines of files.

### pr

: format and print file.

### ps

: reports status of active processes.

### pstat

: report system status.

### pwcheck

: check /etc/passwd (default) file.

### pwd

: display current working directory.

### rm

: remove (erase) files or directories (unrecoverable).

### rmdir

: remove an empty directory.

### rsh

: invoke Restricted Bourne Shell.

### sed

: the stream editor.

### set

: assign value to variable.

### setenv

: assign value to enviroment variable.

### sh

: invoke Bourne shell.

### sleep

: suspend execution of a command for a given period.

### sort

: sort and merge files.

### spell

: find spelling errors.

### split

: split file to smaller files.

### stty

: set options for a terminal.

### su

: spawns a subshell with a different username, requires other user’s password, unless you’re root.

### sum

: compute checksums and number of blocks for files.

### tabs

: set tabs on a terminal.

### tail

: display last 10 lines of file.

### tar

: a simple compression tool that merges multiple files into a single one, originally made to make backing up materials on backup tapes easier.

### tee

: create a tee in a pipe.

### telnet

: access remote systems using the telnet protocol.

### test

: test various expressions and files.

### time

: display elapsed time (execution, process, and system times) for a command.

### touch

: change time/date stamps of files.

### tr

: substitutes sets of characters.

### translate

: translates files to different format.

### troff

: format files to phototypester.

### true

: return zero (true) exit status.

### tset

: set terminal mode.

### tty

: report a name of a terminal.

: set file-creation mode (permissions) mask.

### umount

: unmount a device.

### uname

: display the name of the current system.

### uniq

: report any duplicate line in a file.

### units

: convert numbers from one unit to another.

### unzip

: extract files from zip archive.

### uptime

: report system activity.

### uucp

: copy files between two unix systems (oldie but still beautiful).

### uulog

: report uucp status.

### uuname

: list uucp sites known to this site.

### uudecode

: decode to binary after “uuencode” transmission.

### uuencode

: encode binary file for email transmission.

### uustat

: report status of uucp or cancel a job.

### uupick

: receive public files sent by uuto.

### uuto

: send files to another public Unix system.

### uux

: execute command to remote Unix system.

### vi

: a screen oriented (visual) editor (cool ,but Vim is better).

### wall

: sends message to all users (root only).

### wait

: await completion of background process.

### wc

: count lines, words, bytes etc’ in one or more files.

### who

: report active users.

### whois

: search for user information.

### write

: send a message for another user (see mesg).

### zip

: archive file or files in zip format.

## Examining Virality

Virality: The act of content on the web being spread by users sharing it, bringing new users to the original content and therefore adding additional utility.

Virality is the noun for the adverb viral and it has been thrown about these days when it comes to the online world. Virality refers to a sort of new metric system used to determine the “pace” in which information is transmitted over the internets.Borrowed from biology and perhaps misused from the silicon tech and digital marketing community. Ironically the words “infection” or “infected” have been left out of the social media jargon perhaps due to the negative connotation it might have. Coming to think of it users who abstain  from social media platforms are immune  to virality.  So abstainace helps your “immune” system and keeps you in the dark ages. But humour aside an attempt should be made to formulate this phenomenon from a digital point of view.

The success of a viral application relies on number of posible receptors in an online ecosystem and the percentage of users that where indeed infected or converted. The formula below depicts the virality coefficient.

$k=icdot conv%$

The virality coefficient $kappa$  , where $i$ equals the number of posible receptors(or invites) and $conv%$ the conversion percentage. The assumption here is that each user sends his invites once is a single batch.

The following formula measures users over time.

$U(t)=U(0)cdotfrac{K^{(frac{1}{p}+1)}-1}{K-1}$

The time need for a new user to send invites is given by p. The number of epochs the invite process has gone through is represented by $frac{t}{p}$. The significance of introducing $p$ in the formula is that it shows that it’s easier to increace $U(t)$ by reducing $p$ rather than increasing $K$.

Verbalizing the aforementioned, lowering the amount fo time necessary for a user to invite other users to a site may be more effective than increasing the numer of invitations users send or the rate at which invited non-users convert. Lowering $p$ increases the power while increasing $K$ only increases the base.

In most cases $p$ is ignored. It is more likely than $K$ to be amenable to change. So perhaps it would be a good idea to invest in minimizing $p$.

An example of how the formula works is shown on the table below indicating how invitations increase the size of a user base over time. Say $K=2$ and $U(0)=5$ and $N$ the number of completed Epochs.

Epochs 0 1 2 3 4 5
New Users added this Epoch 10 20 40 80 160
Total Users 5 15 35 75 155 315

It is apparant that the New Users  row doubles every round. The number of New Users for round $i$  , is given by

$U(0)K^i$

and the Total Users  is the running sum of New Users; hence the total number of users is given by the summation

$U(t)=sumlimits_{i=0}^N U(0)K^i = U(0)cdot sumlimits_{i=0}^N K^i$

There is a known identity for sums of powers.

$sumlimits_{i=0}^{M-1}r^i=frac{1-r^M}{1-r}$

We use it here with $N=M-1$

$U(0)cdotsumlimits_{i=0}^{N}K^i=U(0)cdotfrac{1-K^{(N+1)}}{1-K}$

Multiply the term on the right by $-1/-1$

$U(0)cdotfrac{1-K^{(N-1)}}{K-1}$

Replace $N$  with $frac{t}{p}$

$U(t)=U(0)cdotfrac{K^{(frac{1}{p}+1)}-1}{K-1}$

Bringing us back to the original formula; hence in oder to increace $U(t)$ maximize $K$ and minimize $p$.

In one sentence: Make the users send out more invites and most importantly faster, you knew it, now you got the proof  :-)

Now that you know the math you understand why online poker became so popular the past 10 years.

$LaTeX$ for wordpress gotta love it.

## Special thanx

Special thanks to the great programmers of these libraries :

* FatFree PHP Framework: http://fatfree.sourceforge.net/

* Elastic CSS Framework: http://elasticss.com/

* HTML5 Boilerplate.com: http://html5boilerplate.com/

* SimplePie: http://simplepie.org/

* jQuery: http://jquery.com/

* WideImage: http://wideimage.sourceforge.net/

* iScroll: http://cubiq.org/iscroll

* modernizr: http://www.modernizr.com/

* keyboard shortcuts: http://www.openjs.com/scripts/events/keyboard_shortcuts/

*zazar: http://www.zazar.net

## Video Art I like part1

I liked both of these videos, good work! In order to show respect to the composers I post them on my blog instead of sharing them on FB. I think posting and sharing on FB has lost it’s value, just doesn’t have the gravity it does when you mention something on your blog.

Both videos are directed by  Mary Clerté & Edouard Bertrand and I found them on vimeo.

## Temptation

Temptation: You dont know why, you dont know what is going to happen. The unknown unknowns, you might do it and things might get better or you might find yourself in a rather unpleasant situation.

Curiosity : Is a cat killer and a human intelligence improver.

You are tempted, there it is in front of your face staring at you. There is no one around. Do you do it? It could be a laugh or things could get messy. What do you do? Time is ticking… you grab it, you store it, you upload it … your clean. You think to yourself just  for a few days no harm done. The little angel on your shoulder is on holiday. The road is open and the old yeller has been put to sleep. Pedal to the medal. You sweat , you smoke, you think the whole world knows. It’s a conspiracy, no it’s not. Sleeples night. Everything orbits the issue. The next day you go back, no one has noticed anything, no-one cares, no-one appreciates. You check, you double check, yep they have shoved it in the recycle bin. They really don’t care they never did. But you own the copy and you dont care.

## Desk@work

My desk has 2 screens three if you count the laptop. This might be a good way to get a tan. *this post is primarily written for test purposes. Published using a blackberry bold. Long live java.


text:
# Exporting Burst Data¶

This notebook is part of a tutorial series for the FRETBursts burst analysis software.

In this notebook, show a few example of how to export FRETBursts burst data to a file.

Please cite FRETBursts in publications or presentations!

We start by loading FRETBursts:

In [1]:
from fretbursts import *

 - Optimized (cython) burst search loaded.
- Optimized (cython) photon counting loaded.
--------------------------------------------------------------
You are running FRETBursts (version 0.6.5+5.g5243bc2).

If you use this software please cite the following paper:

FRETBursts: An Open Source Toolkit for Analysis of Freely-Diffusing Single-Molecule FRET
Ingargiola et al. (2016). http://dx.doi.org/10.1371/journal.pone.0160716

--------------------------------------------------------------

In [2]:
sns = init_notebook()

The full list of smFRET measurements used in the FRETBursts tutorials can be found on Figshare.

In [3]:
url = 'http://files.figshare.com/2182601/0023uLRpitc_NTP_20dT_0.5GndCl.hdf5'

You can change the url variable above to download your own data file. This is useful if you are executing FRETBursts online and you want to use your own data file. See First Steps.

Here, we download the data file and put it in a folder named data, inside the notebook folder:

In [4]:
download_file(url, save_dir='./data')

URL:  http://files.figshare.com/2182601/0023uLRpitc_NTP_20dT_0.5GndCl.hdf5
File: 0023uLRpitc_NTP_20dT_0.5GndCl.hdf5

NOTE: If you modified the url variable providing an invalid URL the previous command will fail. In this case, edit the cell containing the url and re-try the download.

Here, we can directly define the file name to be loaded:

In [5]:
filename = "./data/0023uLRpitc_NTP_20dT_0.5GndCl.hdf5"
filename

Out[5]:
'./data/0023uLRpitc_NTP_20dT_0.5GndCl.hdf5'

Let's check that the file exists:

In [6]:
import os
if os.path.isfile(filename):
print("Perfect, file found!")
else:

Perfect, file found!

In [7]:
d = loader.photon_hdf5(filename)

# μs-ALEX parameters¶

At this point, timestamps and detectors numbers are contained in the ph_times_t and det_t attributes of d. Let's print them:

In [8]:
d.ph_times_t, d.det_t

Out[8]:
([array([     146847,      188045,      294124, ..., 47999863658,
47999877783, 47999955353])],
[array([0, 1, 1, ..., 1, 1, 0], dtype=uint32)])

We need to define some ALEX parameters:

In [9]:
d.add(det_donor_accept = (0, 1),
alex_period = 4000,
offset = 700,
D_ON = (2180, 3900),
A_ON = (200, 1800))

Here the parameters are:

• det_donor_accept: donor and acceptor channels
• alex_period: length of excitation period (in timestamps units)
• D_ON and A_ON: donor and acceptor excitation windows
• offset: the offset between the start of alternation and start of timestamping (see also Definition of alternation periods).

To check that the above parameters are correct, we need to plot the histogram of timestamps (modulo the alternation period) and superimpose the two excitation period definitions to it:

In [10]:
bpl.plot_alternation_hist(d)

If the previous alternation histogram looks correct, the corresponding definitions of the excitation periods can be applied to the data using the following command:

In [11]:
loader.alex_apply_period(d)

# Total photons (after ALEX selection):     2,259,522
#  D  photons in D+A excitation periods:      721,537
#  A  photons in D+A excitation periods:    1,537,985
# D+A photons in  D  excitation period:     1,434,842
# D+A photons in  A  excitation period:       824,680

If the previous histogram does not look right, the parameters in the d.add(...) cell can be modified and checked by running the histogram plot cell until everything looks fine. Don't forget to apply the parameters with loader.usalex_apply_period(d) as a last step.

NOTE: After applying the ALEX parameters a new array of timestamps containing only photons inside the excitation periods is created (name d.ph_times_m). To save memory, by default, the old timestamps array (d.ph_times_t) is deleted. Therefore, in the following, when we talk about all-photon selection we always refer to all photons inside both excitation periods.

# Background and burst search¶

In [12]:
d.calc_bg(bg.exp_fit, time_s=30, tail_min_us='auto', F_bg=1.7)

 - Calculating BG rates ... [DONE]

In [13]:
d.burst_search(L=10, m=10, F=6)

 - Performing burst search (verbose=False) ...[DONE]
- Calculating burst periods ...[DONE]
- Counting D and A ph and calculating FRET ...
- Applying background correction.
[DONE Counting D/A]

First we filter the bursts to avoid creating big files:

In [14]:
ds = d.select_bursts(select_bursts.size, th1=60)

# Exporting Burst Data¶

By burst-data we mean all the scalar burst parameters, e.g. size, duration, background, etc...

We can easily get a table (a pandas DataFrame) with all the burst data as follows:

In [15]:
bursts = bext.burst_data(ds, include_bg=True, include_ph_index=True)
bursts.head(5)  # display first 5 bursts

Out[15]:
E S bg_aa bg_ad bg_da bg_dd bg_period i_start i_stop na naa nd nda nt size_raw t_start t_stop width_ms spot
0 0.324223 0.571004 1.738086 2.993976 0.249776 1.795806 0 5276 5422 26.006024 60.261914 54.204194 -0.249776 140.472131 147 1.732456 1.735530 3.074012 0
1 0.420886 0.648480 1.630940 2.809410 0.234378 1.685103 0 5961 6173 56.190590 72.369060 77.314897 0.765622 205.874547 213 1.792993 1.795878 2.884513 0
2 0.451800 0.467038 1.578611 2.719270 0.226858 1.631036 0 6757 6986 47.280730 119.421389 57.368964 -0.226858 224.071083 230 2.023545 2.026337 2.791962 0
3 0.166462 0.984595 1.336586 2.302365 0.192077 1.380973 0 10403 10515 17.697635 1.663414 88.619027 -0.192077 107.980076 113 3.113880 3.116244 2.363913 0
4 0.137702 0.998409 1.887150 3.250750 0.271197 1.949821 0 10548 10625 9.749250 0.112850 61.050179 -0.271197 70.912280 78 3.129707 3.133044 3.337650 0

Once we have the DataFrame, saving it to disk in CSV format is trivial:

In [16]:
bursts.to_csv('%s_burst_data.csv' % filename.replace('.hdf5', ''))

# Exporting Bursts Timestamps¶

Exporting timestamps and other photon-data for each bursts is a little trickier because the data is less uniform (i.e. each burst has a different number of photons). In the following example, we will save a csv file with variable-length columns. Each burst is represented by to lines: one line for timestamps and one line for the photon-stream (excitation/emission period) the timestamps belongs to.

Let's start by creating an array of photon streams containing one of the values 0, 1, 2 or 3 for each timestamp. These values will correspond to the DexDem, DexAem, AexDem, AemAem photon streams respectively.

In [17]:
ds.A_ex

Out[17]:
[array([False,  True,  True, ..., False,  True, False], dtype=bool)]
In [18]:
#{0: DexDem, 1:DexAem, 2: AexDem, 3: AemAem}

In [19]:
(ds.A_ex[0].view('int8') << 1) + ds.A_em[0].view('int8')

Out[19]:
array([1, 3, 3, ..., 1, 3, 0], dtype=int8)

Now we define an header documenting the file format. Ww will also include the filename of the measurement.

This is just an example including nanotimes:

In [20]:
header = """\
# BPH2CSV: %s
# Lines per burst: 3
# - timestamps (int64): in 12.5 ns units
# - nanotimes (int16): in raw TCSPC unit (3.3ps)
# - stream (uint8): the photon stream according to the mapping {0: DexDem, 1: DexAem, 2: AexDem, 3: AemAem}
""" % filename

# BPH2CSV: ./data/0023uLRpitc_NTP_20dT_0.5GndCl.hdf5
# Lines per burst: 3
# - timestamps (int64): in 12.5 ns units
# - nanotimes (int16): in raw TCSPC unit (3.3ps)
# - stream (uint8): the photon stream according to the mapping {0: DexDem, 1: DexAem, 2: AexDem, 3: AemAem}

And this is header we are going to use:

In [21]:
header = """\
# BPH2CSV: %s
# Lines per burst: 2
# - timestamps (int64): in 12.5 ns units
# - stream (uint8): the photon stream according to the mapping {0: DexDem, 1: DexAem, 2: AexDem, 3: AemAem}
""" % filename

# BPH2CSV: ./data/0023uLRpitc_NTP_20dT_0.5GndCl.hdf5
# Lines per burst: 2
# - timestamps (int64): in 12.5 ns units
# - stream (uint8): the photon stream according to the mapping {0: DexDem, 1: DexAem, 2: AexDem, 3: AemAem}

We can now save the data to disk:

In [22]:
out_fname = '%s_burst_timestamps.csv' % filename.replace('.hdf5', '')
dx = ds
ich = 0

bursts = dx.mburst[ich]
timestamps = dx.ph_times_m[ich]
stream = (dx.A_ex[ich].view('int8') << 1) + dx.A_em[ich].view('int8')
with open(out_fname, 'wt') as f:
for times, period in zip(bl.iter_bursts_ph(timestamps, bursts),
bl.iter_bursts_ph(stream, bursts)):
times.tofile(f, sep=',')
f.write('\n')
period.tofile(f, sep=',')
f.write('\n')

Done!

For consistency check, we can read back the data we just saved. As an exercise we will put the results in a pandas DataFrame which is more convenient than an array for holding this data.

In [23]:
import pandas as pd

In [24]:
with open(out_fname) as f:
lines = []
while lines[-1].startswith('#'):

# BPH2CSV: ./data/0023uLRpitc_NTP_20dT_0.5GndCl.hdf5
# Lines per burst: 2
# - timestamps (int64): in 12.5 ns units
# - stream (uint8): the photon stream according to the mapping {0: DexDem, 1: DexAem, 2: AexDem, 3: AemAem}

In [25]:
stream_map = {0: 'DexDem', 1: 'DexAem', 2: 'AexDem', 3: 'AemAem'}

Out[25]:
(4, 2)

As a test, we load the data for the first burst into a dataframe, converting the numerical column "streams" into photon-stream names (strings). The new column is of type categorical, so it will take very little space:

In [26]:
burstph = (pd.read_csv(out_fname, skiprows=header_len, nrows=nrows, header=None).T
.rename(columns={0: 'timestamp', 1: 'stream'}))
burstph.stream = (burstph.stream
.apply(lambda x: stream_map[pd.to_numeric(x)])
.astype('category', categories=['DexDem', 'DexAem', 'AexDem', 'AemAem'], ordered=True))
burstph

Out[26]:
timestamp stream
0 138596500 AemAem
1 138622303 DexDem
2 138626950 DexDem
3 138641792 AemAem
4 138643022 DexDem
... ... ...
142 138788833 AemAem
143 138790337 DexDem
144 138790703 DexAem
145 138790873 DexAem
146 138842421 DexDem

147 rows × 2 columns

For reading the whole file I use a different approach. First, I load the entire file in two lists of lists (one for timestamps and one for the stream). Next, I create a single DataFrame with a third column indicating the burst index.

In [27]:
import csv
from builtins import int  # python 2 workaround, can be removed on python 3

# Read data in two list of lists
t_list, s_list = [], []
with open(out_fname) as f:
t_list.append([int(v) for v in row])

# Turn the inner list into pandas.DataFrame
d_list = []
for ib, (t, s) in enumerate(zip(t_list, s_list)):
d_list.append(
pd.DataFrame({'timestamp': t, 'stream': s}, columns=['timestamp', 'stream'])
.assign(iburst=ib)
)

# Concatenate dataframes
burstph = pd.concat(d_list, ignore_index=True)

# Convert stream column into categorical
burstph.stream = (burstph.stream
.apply(lambda x: stream_map[pd.to_numeric(x)])
.astype('category', categories=['DexDem', 'DexAem', 'AexDem', 'AemAem'], ordered=True))
burstph

Out[27]:
timestamp stream iburst
0 138596500 AemAem 0
1 138622303 DexDem 0
2 138626950 DexDem 0
3 138641792 AemAem 0
4 138643022 DexDem 0
... ... ... ...
232327 47909435404 DexAem 987
232328 47909438825 DexAem 987
232329 47909451409 DexDem 987
232330 47909458878 DexAem 987
232331 47909462189 DexDem 987

232332 rows × 3 columns

In [28]:
burstph.dtypes

Out[28]:
timestamp       int64
stream       category
iburst          int64
dtype: object

This was just an example. There are certainly more efficient ways to read the file into a DataFrame. Please feel free to contribute new methods to illustrate a different (more efficient or simpler) approach.

Executed: Sat Nov 18 15:59:43 2017

Duration: 8 seconds.

Autogenerated from: Example - Exporting Burst Data Including Timestamps.ipynb


text:
Categories: Physics, Plasma physics.

# Coulomb logarithm

In a plasma, particles often appear to collide, although actually it is caused by Coulomb forces, i.e. the “collision” is in fact Rutherford scattering. In any case, the particles’ paths are deflected, and it would be nice to know whether those deflections are usually large or small.

Let us choose $$\pi/2$$ as an example of a large deflection angle. Then Rutherford predicts:

\begin{aligned} \frac{q_1 q_2}{4 \pi \varepsilon_0 |\vb{v}|^2 \mu b_\mathrm{large}} = \tan\!\Big( \frac{\pi}{4} \Big) = 1 \end{aligned}

Isolating this for the impact parameter $$b_\mathrm{large}$$ then yields an effective radius of a particle:

\begin{aligned} b_\mathrm{large} = \frac{q_1 q_2}{4 \pi \varepsilon_0 |\vb{v}|^2 \mu} \end{aligned}

Therefore, the collision cross-section $$\sigma_\mathrm{large}$$ for large deflections can be roughly estimated as the area of a disc with radius $$b_\mathrm{large}$$:

\begin{aligned} \sigma_\mathrm{large} = \pi b_\mathrm{large}^2 = \frac{q_1^2 q_2^2}{16 \pi \varepsilon_0^2 |\vb{v}|^4 \mu^2} \end{aligned}

Next, we want to find the cross-section for small deflections. For sufficiently small angles $$\theta$$, we can Taylor-expand the Rutherford scattering formula to first order:

\begin{aligned} \frac{q_1 q_2}{4 \pi \varepsilon_0 |\vb{v}|^2 \mu b} = \tan\!\Big( \frac{\theta}{2} \Big) \approx \frac{\theta}{2} \quad \implies \quad \theta \approx \frac{q_1 q_2}{2 \pi \varepsilon_0 |\vb{v}|^2 \mu b} \end{aligned}

Clearly, $$\theta$$ is inversely proportional to $$b$$. Intuitively, we know that a given particle in a uniform plasma always has more “distant” neighbours than “close” neighbours, so we expect that small deflections (large $$b$$) are more common than large deflections.

That said, many small deflections can add up to a large total. They can also add up to zero, so we should use random walk statistics. We now ask: how many $$N$$ small deflections $$\theta_n$$ are needed to get a large total of, say, $$1$$ radian?

\begin{aligned} \sum_{n = 1}^N \theta_n^2 \approx 1 \end{aligned}

Traditionally, $$1$$ is chosen instead of $$\pi/2$$ for convenience. We are only making rough estimates, so those two angles are close enough for our purposes. Furthermore, the end result will turn out to be logarithmic, and is thus barely affected by this inconsistency.

You can easily convince yourself that the average time $$\tau$$ between “collisions” is related as follows to the cross-section $$\sigma$$, the density $$n$$, and relative velocity $$|\vb{v}|$$:

\begin{aligned} \frac{1}{\tau} = n |\vb{v}| \sigma \qquad \implies \qquad 1 = n |\vb{v}| \tau \sigma \end{aligned}

Therefore, in a given time interval $$t$$, the expected number of collision $$N_b$$ for impact parameters between $$b$$ and $$b\!+\!\dd{b}$$ (imagine a ring with these inner and outer radii) is given by:

\begin{aligned} N_b = n |\vb{v}| t \: \sigma_b = n |\vb{v}| t \:(2 \pi b \dd{b}) \end{aligned}

In this time interval $$t$$, we can thus turn our earlier sum into an integral of $$N_b$$ over $$b$$:

\begin{aligned} 1 \approx \sum_{n = 1}^N \theta_n^2 = \int N_b \:\theta^2 \dd{b} = n |\vb{v}| t \int 2 \pi \theta^2 b \dd{b} \end{aligned}

Using the formula $$n |\vb{v}| \tau \sigma = 1$$, we thus define $$\sigma_{small}$$ as the effective cross-section needed to get a large deflection (of $$1$$ radian), with an average period $$t$$:

\begin{aligned} \sigma_\mathrm{small} = \int 2 \pi \theta^2 b \dd{b} = \int \frac{2 \pi q_1^2 q_2^2}{4 \pi^2 \varepsilon_0^2 |\vb{v}|^4 \mu^2 b^2} b \dd{b} \end{aligned}

Where we have replaced $$\theta$$ with our earlier Taylor expansion. Here, we recognize $$\sigma_\mathrm{large}$$:

\begin{aligned} \sigma_\mathrm{small} = \frac{q_1^2 q_2^2}{2 \pi \varepsilon_0^2 |\vb{v}|^4 \mu^2} \int \frac{1}{b} \dd{b} = 8 \sigma_\mathrm{large} \int \frac{1}{b} \dd{b} \end{aligned}

But what are the integration limits? We know that the deflection grows for smaller $$b$$, so it would be reasonable to choose $$b_\mathrm{large}$$ as the lower limit. For very large $$b$$, the plasma shields the particles from each other, thereby nullifying the deflection, so as upper limit we choose the Debye length $$\lambda_D$$, i.e. the plasma’s self-shielding length. We thus find:

\begin{aligned} \boxed{ \sigma_\mathrm{small} = 8 \ln\!(\Lambda) \sigma_\mathrm{large} = \frac{q_1^2 q_2^2 \ln\!(\Lambda)}{2 \pi \varepsilon_0^2 |\vb{v}|^4 \mu^2} } \end{aligned}

Here, $$\ln\!(\Lambda)$$ is known as the Coulomb logarithm, with the plasma parameter $$\Lambda$$ defined below, equal to $$9/2$$ times the number of particles in a sphere with radius $$\lambda_D$$:

\begin{aligned} \boxed{ \Lambda \equiv \frac{\lambda_D}{b_\mathrm{large}} = 6 \pi n \lambda_D^3 } \end{aligned}

The above relation between $$\sigma_\mathrm{small}$$ and $$\sigma_\mathrm{large}$$ gives us an estimate of how much more often small deflections occur, compared to large ones. In a typical plasma, $$\ln\!(\Lambda)$$ is between 6 and 25, such that $$\sigma_\mathrm{small}$$ is 2-3 orders of magnitude larger than $$\sigma_\mathrm{large}$$.

Note that $$t$$ is now fixed as the period for small deflections to add up to $$1$$ radian. In more useful words, it is the time scale for significant energy transfer between partices:

\begin{aligned} \frac{1}{t} = n |\vb{v}| \sigma_\mathrm{small} = \frac{q_1^2 q_2^2 \ln\!(\Lambda) \: n}{2 \pi \varepsilon_0^2 \mu^2 |\vb{v}|^3} \sim \frac{n}{T^{3/2}} \end{aligned}

Where we have used that $$|\vb{v}| \propto \sqrt{T}$$, for some temperature $$T$$. Consequently, in hotter plasmas, there is less energy transfer, meaning that a hot plasma is hard to heat up further.

## References

1. P.M. Bellan, Fundamentals of plasma physics, 1st edition, Cambridge.
2. M. Salewski, A.H. Nielsen, Plasma physics: lecture notes, 2021, unpublished.

© Marcus R.A. Newman, a.k.a. "Prefetch". Available under CC BY-SA 4.0.


text:
[This article was first published on Category: R | Todd W. Schneider, and kindly contributed to R-bloggers]. (You can report issue about the content on this page here)
Want to share your content on R-bloggers? click here if you have a blog, or here if you don't.

If you’ve been on a New York City subway platform since January 2018, you should have noticed a countdown clock that displayed an estimate of when the next train would arrive. Although there’s no official record of when trains actually stopped at each station, the countdown clock data can be used to approximate. Over the past 5 months, I’ve collected and processed some 24 million stops’ worth of this data to try to make sense of New York’s vast and troubled subway system. The code is all available on GitHub.

## Which NYC subway lines have the longest wait times?

The chart below shows how long you should expect to wait for each train line, assuming you arrive on the platform at a random time on a weekday between 7:00 AM and 8:00 PM.

The top four trains with the shortest waits—the L, 7, 1, and 6—are the only trains that run on dedicated tracks, which presumably helps avoid delays due to trains from other lines merging in and out on different schedules. The L train is also the only line that uses modern communications-based train control (CBTC), which allows trains to operate in a more automated fashion. The 7 train, the second most reliable according to my data, is currently running “partial” CBTC, and is slated for full CBTC in 2018.

Systemwide CBTC is the cornerstone of the recently announced ambitious plan to fix the subways. I’ll have a bit more to say on that in a moment…

(Note that expected wait time is different from time between trains. See the appendix for a more mathematical treatment on converting between time between trains and expected wait time. Note also that in some cases, different lines can serve as substitutes. For example, if you’re traveling from Union Square to Grand Central, the 4, 5, and 6 lines will all get you there, so your effective wait time would be shorter than if you had to rely on one specific line.)

## How long will you have to wait for your train?

The above graph is restricted to weekdays between 7:00 AM and 8:00 PM, but wait times vary from hour to hour. In general, wait times are shortest during morning and evening rush hours, though keep in mind that the data doesn’t know about cases where trains might be too crowded to board, forcing you to wait for the next train.

Choose your line below, and you can see how long you should expect to wait for a train by time of day, based on weekday performance from January to May 2018.

## How crowded should you want the platform to be when you arrive?

Most New Yorkers intuitively understand that when they get to a subway platform, they don’t want it to be too empty or too crowded. An empty platform means that you probably just missed the last train, so it’s unlikely another one will be arriving very soon. Even worse, an extremely crowded platform means that something is probably wrong, and maybe the train will never arrive. There’s a Goldilocks zone in the middle: a healthy amount of crowding that suggests it’s been a few minutes since the last train, but not so long that things must be screwed up.

I used the same data to compute conditional wait time distributions: given that it’s been N minutes since the last train, how much longer should you expect to wait? In most cases, the shortest conditional wait time occurs when it’s been 5 to 8 minutes since the last train.

Choose your line to view conditional wait times.

In general when you arrive on the platform, you can’t directly observe when the last train departed, but you can make a guess based on the number of people who are waiting. First you would have to estimate—or maybe even measure from the MTA’s public turnstile data—the number of people who arrive on the platform each minute. Then, if you know the shortest conditional wait occurs when it’s been 6 minutes since the last train, and you estimated that, say, 20 people arrive on the platform each minute, you should hope to see 120 people on the platform when you arrive. Of course these parameters vary by platform and time of day, so make sure to take that into account when making your own estimates!

## A back-of-the-envelope economic case for subway upgrades (that you shouldn’t take too seriously)

The recently released Fast Forward plan from Andy Byford, president of the NYC Transit Authority, proposes that it will take 10 years to implement CBTC across most of the system. The NYT further reports an estimated price tag of $19 billion. If every line were as efficient as the CBTC-equipped L, I estimate that the average wait time would be around 3 minutes shorter. At 5.7 million riders per weekday, that’s potentially 285,000 hours of time saved per weekday. Reasonable people might disagree about the economic value of deadweight subway waiting time, but$20 per hour doesn’t strike me as crazy, and would imply a savings of $5.7 million per weekday. Weekends have about half as many riders as weekdays, and time is probably worth less, so let’s value a weekend day’s savings at 25% of a weekday’s. Overall that would imply a total savings of over$1.6 billion per year, and that’s before accounting for the fact that CBTC-equipped trains also probably travel faster from station to station, so time savings would come from more than reduced platform wait times. And if people had more confidence in the system, they wouldn’t have to budget so much extra travel time as a safety buffer. Other potential benefits could come from lower operating and repair costs, and less above-ground traffic congestion if people switched from cars to the presumably more efficient subway.

To be fair, there are all kinds of things that could push in the other direction too: maybe it’s unrealistic that other lines would be as efficient as the L, since the L has the benefit of being on its own dedicated track that it doesn’t share with any other crisscrossing lines, or maybe the better subway would be a victim of its own success, causing overcrowding and other capacity problems. And perhaps the most obvious criticism: that the plan will end up taking longer than 10 years and costing more than $19 billion. I don’t think this quick back-of-the-envelope calculation should be taken too seriously when there are so many variables to consider, but I do think it’s not hard to get to a few billion dollars a year in economic value, assuming some reasonable parameters. Reasonable people might again argue about discount rates and amortization schedules, but a total cost in the neighborhood of$19 billion over 10 years strikes me as eminently worth it.

## Anatomy of a subway delay

The NYT recently published a great interactive story that demonstrated via simulation how a single train delay can cause cascading problems behind it. The week after that story was published, I was (un)fortunate enough to participate in a real-life demonstration of the phenomenon. On May 16, 2018, I found myself on a downtown F train from Midtown. Around 10:00 AM at 34th Street, the conductor made an announcement that there was a stalled train in front of us at W 4th Street, and that we’d be delayed. The delay lasted about 30 minutes, and then the train carried on as normal.

Here’s a graphical representation of downtown F trains that morning, with major delays highlighted in red. My train was the second train in the major delay on the right-center of the graph.

Although I wasn’t on the train that had mechanical problems at W 4th Street, my train and the two trains behind it were forced to wait for the problem train. Further back, the train dispatcher switched a few F trains to the express tracks from 47-50 Sts–Rockefeller Center to W 4th Street, which is why you see a few steeper line segments in the graph that appear to cut through the delay. The empty diagonal gash in the graph below the delay shows that riders felt the effects all the way down the line. If you were waiting for an F train at 2nd Avenue just after 10:00 AM, you would have had to wait a full 30 minutes, compared to only a few minutes if you had arrived on the platform at 9:55 AM.

I’m a bit surprised that the MTA didn’t deliberately slow down some of the trains in front of the delay. It’s well-known that even spacing is a key to minimizing system-wide wait time, the MTA once even made a video about it, but in this case it appears they didn’t practice what they preach. Slowing down a train in front of a delay will make some riders worse off, namely the ones at future stops who would have made the train had it not been slowed down. But it will also make some riders much better off: the ones who would have missed the train had it not been slowed down, and then had to suffer an abnormally long wait for the delayed train itself.

You can use the graph to convince yourself that slowing down the train ahead of the delay would have been a good thing. Downtown F trains stopped at 2nd Avenue at 9:58 and 10:00 AM. If the 10:00 AM train had been intentionally delayed 10 minutes to 10:10 AM, all of the people who arrived on the platform between 10:00 and 10:10 would have been saved from waiting until 10:30, an average 20 minute savings per person. On the other hand, the folks who arrived between 9:58 and 10:00 would have been penalized an average of 10 minutes per person. But there were likely five times as many people in the 10:00–10:10 range than there were in the 9:58–10:00 range, so the weighted average tells us we just saved an average of 15 minutes per person.

Compare the W 4th Street delay to the delay earlier that morning at 7:40 AM at 57th Street, highlighted on the left side of the graph. That delay, although shorter, also caused a lasting gap between trains. However, the gap was later mitigated when the train in front of the delayed train slowed down a bit between York and Jay streets. I suspect that slowdown was unintentional, but it was probably beneficial, and had it happened further up the line, say between 42nd and 34th streets, it would have produced more even spacing throughout the line, and likely lowered total rider wait time.

In fairness to the MTA, in real life it’s not as simple as “always slow down the train in front of the delay” because there are other considerations—dispatchers don’t know how long the delay will last, not every platform is equally popular, and there other options like rerouting trains to other tracks—but a healthier system could have dealt with this delay better.

## Subway performance over time

The subway’s deteriorating performance has been covered at great length by many outlets. I’d recommend the NYT’s coverage in particular, but it seems like there are so many people writing about the subway recently that there’s no shortage of stories to choose from.

In addition to the dataset I collected starting in January 2018, the MTA makes some real-time snapshots available going back to September 2014. These snapshots are only available for the 1, 2, 3, 4, 5, 6, and L trains, and they’re in 5-minute increments as opposed to the 1-minute increments of my tracker. Additionally, there is a gap in historical coverage from November 2015 until January 2017.

The historical data shows that expected wait times have remained fairly unchanged since 2014, but travel times from station to station have gotten a bit slower, at least on the 2, 3, 4, and 5 trains, where a weekday daytime trip in 2018 takes 3-5% longer on average than the same trip in 2014. The 1 and 6 trains have not experienced similar slowdowns, and the L is somewhere in the middle.

On a 15-minute trip, 3-5% is an average of 30-45 seconds slower, which doesn’t sound particularly catastrophic, but there are plenty of other issues not reflected in these numbers that might make the subway “better” or “worse” over time. I’ve tried to exclude scheduled maintenance windows from the expected wait time calculations, but in reality scheduled maintenance and station closures can be a huge nuisance. The MTA data also doesn’t tell us anything about when trains are so crowded that they can’t pick up new passengers, when air conditioning systems are broken, and other general quality-of-ride characteristics.

It’s also possible that the 1-6 and L lines—the ones with historical data—happen to have deteriorated less than the other lettered lines, and if we had full historical data for the other lines, we’d see more dramatic effects over time. There’s no question that the popular narrative is that the subway has gotten worse in recent years, though part of me can’t help but wonder if the feedback loop provided by nonstop media coverage might be a contributing factor…

## The NYC subway as a directed graph

I used the igraph package in R to construct a weighted directed graph of the subway system, where the nodes are the 472 subway stations, the edges are the various subway lines and transfers that connect them, and the weights are the expected travel times along each edge. For train edges, the weight is calculated as the median wait time on the platform plus the median travel time from station to station, and for transfer edges, the weight is taken from estimates provided by the MTA—typically 3 minutes if you have to change platforms, 0 if you don’t.

With the graph in hand, we can answer a host of fun (and maybe informative) questions, as igraph does the heavy lifting to calculate shortest possible paths from station to station across the system.

I used the directed graph to find the “center” of the subway system, defined as the station that has the closest farthest-away station. That honor goes to the Chambers Street–World Trade Center/Park Place station, from where you can expect to reach any other subway station in 75 minutes or less. Here’s a map highlighting the Chambers Street station, plus the routes you could take to the farthest reaches of Manhattan, Brooklyn, Queens, and the Bronx.

The directed graph might even be a good real estate planning tool. You might not care about the outer extremities of the city, but if you provide a list of neighborhoods you do frequent, the graph can tell you the most central station where you can minimize your worst-case travel times.

For example, if your personal version of NYC stretches from the Upper West Side to the north, Park Slope to the south, and Bushwick to the east, then the graph suggests W 4th Street in Greenwich Village as your subway center: you can get to all of your neighborhoods in a maximum of 26 minutes.

The graph can be used to calculate all sorts of other fun routes. I’ve seen attempts to find the longest possible subway trip that doesn’t involve any backtracking, which is all well and good, but what about finding the longest trip from A to B with the constraint that it’s also the fastest subway-only trip from A to B? Based on my calculations, the longest possible such trip stretches from Wakefield–241st Street in the Bronx to Far Rockaway–Beach 116th Street in Queens via the 2, 5, A, and Rockaway Park Shuttle. It would take a median time of 2:28—about as long as it takes the Acela to travel from Penn Station to Baltimore.

The fastest way to hit all 4 subway boroughs is from 138th St–Grand Concourse in the South Bronx to Greenpoint Avenue in North Brooklyn: 41 minutes via the 6, 4, E, and G trains. And the “centers” of each borough:

• Manhattan: 59th Street–Columbus Circle, 35 minutes max to any other stop in Manhattan
• Brooklyn: Jay Street–MetroTech, 45 minutes max to any other stop in Brooklyn
• Bronx: 149th Street–Grand Concourse, 41 minutes max to any other stop in the Bronx
• Queens: Halsey Street, 66 minutes max to any other stop in Queens

## Further work

The directed graph is a bit silly: in many cases it wouldn’t make sense to rely only on the subway when other transportation options would be more sensible. I’ve written previously about taxi vs. Citi Bike travel times, and a logical extension would be to expand the edges of the directed graph to take into account more transportation options.

Of course, a more practical idea might be to use Google Maps travel time estimates, which already do some of the work combining subways, bikes, ferries, buses, cars, and walking. Still, there’s something nice about estimating travel times based on historical trips that actually happened, as opposed to using posted schedules.

There’s probably something interesting to learn by combining the MTA’s public turnstile data with the train location data. For example, the turnstiles might provide insights into when dispatchers should be more aggressive about maintaining even train spacing following delays. As the tracker collects more data, it might be interesting to see how weather affects subway performance, perhaps segmenting by routes that are above or below ground.

All eyes will be on the subway system in the months and years to come, as people wait to see how the current “fix the subway” drama unfolds. Hopefully the MTA’s real-time data can serve as a resource to measure progress along the way.

## The code and how it works

Although there’s no official record of when trains actually stopped at each station, the MTA provides a public API of the real-time data that powers the countdown clocks, which can be used to estimate train performance.

Starting in January 2018, I’ve been collecting the countdown clock information every minute for every line in the NYC subway system, then calculating my best guesses as to when each train stopped at each station. Between January and May 2018, I observed some 900,000 trains that collectively made 24 million stops. The MTA’s data is very messy, and occasionally makes no sense at all, so I spent a considerable amount of time trying to clean up the data as best possible. For more technical details, including all of the code used in this post to collect and analyze the data, head over to GitHub.

The countdown clock system uses bluetooth receivers installed on trains and in stations: when a train passes through a station, it notifies the system of its most recent stop. The MTA has acknowledged the system’s less than perfect accuracy, but it’s much better than the status quo from only a few years ago when we really had no idea where the trains were.

## Appendix: converting from “time between trains” to “expected wait time”

Putting aside messy data issues, the MTA’s real-time feeds tell us the amount of time between trains. But riders probably care more about how long they should expect to wait when they arrive at the platform, and those two quantities can be different.

As a hypothetical example, imagine a system where trains arrive exactly every 10 minutes on the 0s: 12:00, 12:10, etc. In that world, riders who arrive on the platform at 12:01 will wait 9 minutes for the next train, riders who arrive at 12:02 will wait 8 minutes, and so on down to riders who arrive at 12:09 who will wait 1 minute. If we assume a continuous uniform distribution of arrival times for people on the platform, the average person’s wait time will be one half of the time between trains, 5 minutes in this example.

Now imagine trains arrive alternating 5 and 15 minutes apart, e.g. 12:00, 12:05, 12:20, 12:25, etc., while people still arrive following a uniform distribution. The people who happen to arrive during one of the 5-minute gaps will average a 2.5 minute wait, while the people who arrive during one of the 15-minute gaps will average a 7.5 minute wait. The catch is that only 25% of all people will arrive during a 5-minute window while the other 75% will arrive during a 15-minute window, which means the global average wait time is now (2.5 * 0.25) + (7.5 * 0.75) = 6.25 minutes. That’s 1.25 minutes worse than the first scenario where trains were evenly spaced, even though in both scenarios the average time between trains is 10 minutes.

If you work out the math for the general case, you should find that average wait time is proportional to the sum of the squares of each individual gap between trains.

This means that given an average gap time, expected wait time will be minimized when the gaps are all identical. In practice, it very well could be worth increasing average gap time if it means you can minimize gap time variance. Looking back to our toy example, not only is the average of 52 and 152 greater than 102, it’s greater than 112, which means that trains spaced evenly every 11 minutes will produce less average wait time than trains alternating every 5 and 15 minutes, even though the latter scenario would have a shorter average gap between trains. For another take on this, I’d recommend Erik Bernhardsson’s NYC subway math post from 2016.

Often we want more than the expected wait time, we want the distribution of wait times, so that we can calculate percentile outcomes. Normally this is where I’d say something like “just write a Monte Carlo simulation”, but I think in this particular case it’s actually easier and more useful to do the empirical calculation.

Let’s say you have a list of the times at which trains stopped at a particular station, and you’d like to calculate the empirical distribution of rider wait times, assuming riders arrive at the platform following a uniform distribution. I’d reframe that problem as drawing balls out of a box, following the process below:

2. For each train, add N balls to the box, labeled 1 to N, where N is the number of seconds the train arrived after the train in front of it

Once you’ve done that, you’re pretty much done, as your box is now full of balls with numbers on them, and the probability of a rider having to wait some specific number of seconds t is equal to the number of balls labeled t divided by the total number of balls in the box. Note that you might want to filter trains by day of week or time of day, both because train schedules vary, and people don’t actually arrive on platforms uniformly, but if you restrict to within narrow enough time intervals, it’s probably close enough.

In terms of the actual NYC subway lines during weekdays between 7:00 AM and 8:00 PM, the 7 train has the shortest median time between trains, but the L does a better job at minimizing the occasional long gaps between trains, which is why we saw earlier that the L has shorter average wait times than the 7.

The A train has a notably flat and wide distribution, which explains why the first graph in this post showed that the A had the worst 75th and 90th percentile outcomes, even though its median performance is middle-of-the-pack.


text:
## Cryptology ePrint Archive: Report 2013/262

An efficient FHE based on the hardness of solving systems of non-linear multivariate equations

Gérald Gavin

Abstract: We propose a general framework to develop fully homomorphic encryption schemes (FHE) without using the Gentry's technique. The security relies on the difficulty of solving systems of non-linear equations (which is a $\mathcal{NP}$-complete problem). While the security of our scheme has not been reduced to a provably hard instance of this problem, security is globally investigated.

Category / Keywords: FHE, homomorphic cryptosystem

Date: received 8 May 2013, last revised 19 May 2013

Contact author: gavin at univ-lyon1 fr

Available format(s): PDF | BibTeX Citation

Note: In this second version, Problem 1 and Problem 2 are slightly modified (see Section 2). The symmetric functions s_j should be constrained to be polynomials : this is needed In the proof of Proposition 1 to ensure that s_j(y_1,y_2,....)=s_j(y_2',y_1',...).

[ Cryptology ePrint archive ]


text:
# NCERT Class 12-Mathematics: Chapter – 6 Application of Derivatives Part 3 (For CBSE, ICSE, IAS, NET, NRA 2022)

Glide to success with Doorsteptutor material for NSO-Level-2 : fully solved questions with step-by-step explanation- practice your way to success.

Question 8:

Find the condition for the curves o intersect orthogonally.

Let the curves intersect at . Therefore,

Slope of tangent at the point of intersection

Again

For orthoganality,

Question 9:

Find all the points of local maxima and local minima of the function

. Therefore, is point of local maxima

. Therefore, is point of local minima

. Therefore is point of local maxima.

Question 10:

Show that the local maximum value of is less than local minimum value.

Let

Hence local maximum value of is at and the local maximum value .

Local minimum value of is at and local minimum value .

Therefore, local maximum value is less than local minimum value .

## Long Answer Type (L. A.)

Question 11:

Water is dripping out at a steady rate of rough a tiny hole at the vertex of the conical vessel, whose axis is vertical. When the slant height of water in the vessel is , find the rate of decrease of slant height, where the vertical angle of the conical vessel is

Given that , where v is the volume of water in the conical vessel.

From the Fig 6.2,

Therefore,

Therefore,

Therefore, the rate of decrease of slant height

Question 12:

Find the equation of all the tangents to the curve , that are parallel to the line .

Given that

Or

Since tangent is parallel to , therefore slope of tangent

Therefore,

Since .

Therefore,

Therefore,

Thus, satisfy equation (ii)

Hence, the points are

Therefore, equation of tangent at and equation of tangent at


text:
# Gaussian Mixture Models.. GMMs

## Gaussian Mixture Models

• A probabilistic model
• Assumes all data points are generated from a mixture of finite no. of gaussian
distributions
• The parameters of the gaussian distributions are unknown.
• It is a way of generalizing k-mean(or k-medoid or k-mode for that matter) clustering to use the
co-variance structure/stats as well as the mean/central-tendency measures of latent
gaussians.

## scikit-learn

### Pros:

• Fastest for learning mixture models
• No bias of means towards zero, or bias cluster sizes to have specific structures

### Cons:

• When there’s not enough points per mixture, estimating covariance matrices becomes
difficult
• Number of components; will always use all the components it has access to, so might need
missing or test-reserved data..

• No. of components can be chosen based on BIC criterion.

• Variational Bayesian Gaussian mixture avoids having to specify number of components

# Word_2_vector.. (aka word embeddings)

## Word 2 vector:

• word 2 vector is a way to take a big set of text and convert into a matrix with a word at
each row.
• It is a shallow neural-network(2 layers)
• Two options/training methods (

### CBOW(Continuous-bag-of-words assumption)

• — a text is represented as the bag(multiset) of its words
• — disregards grammar
• — disregards word order but keeps multiplicity
• — Also used in computer vision

### skip-gram() — it is a generalization

of n-grams(which is basically a markov chain model, with (n-1)-order)
* — It is a n-1 order markov model
* — Used in Protein sequencing, DNA Sequencing, Computational
linguistics(character and word)
* — Models sequences, using the statistical properties of n-grams
* — predicts $x_i$ based on $x_(i-(n-1)), ....,x_(i-1)$.
* — in language modeling independence assumptions are made so that each
word depends only on n-1 previous words.(or characters in case of
character level modeling)
* — The probability of a word conditional on previous n-1 words follows a
Categorical Distribution
* — In practice, the probability distributions are smoothed by assigning non-zero probabilities to unseen words or n-grams.

• — Finding the right ‘n’ for a model is based on the Bias Vs Variance tradeoff we’re wiling to make

## Smoothing Techniques:

• — Problems of balance weight between infrequent n-grams.
• — Unseen n-grams by default get 0.0 without smoothing.
• — Use pseudocounts for unseen n-grams.(generally motivated by
bayesian reasoning on the sub n-grams, for n < original n)

• — Skip grams also allow the possibility of skipping. So a 1-skip bi(2-)gram would create bigrams while skipping the second word in a three sequence.

• — Could be useful for languages with less strict subject-verb-object order than English.

• Depends on Distributional Hypothesis
• Vector representations of words called “word embeddings”
• Basic motivation is that compared to audio, visual domains, the word/text domain treats
them as discrete symbols, encoding them as sparse dataset. Vector based representation
works around these issues.
• Also called as vector Space models
• Two ways of training: a, CBOW(Continuous-Bag-Of-Words) model predicts target words, given
a group of words, b, skip-gram is ulta. aka predicts group of words from a given word.

• Trained using the Maximum Likelihood model

• Ideally, Maximizes probability of next word given the previous ‘h’ words in terms of a softmax function
• However, calculating the softmax values requires computing and normalizing each probability using score for all the other words in context at every step.
• Therefore a logistic regression aka binary classification objective functionis used.
• The way this is achieved is called negative sampling

# Squeeze theorem

To quote from “The girl next door”
The first lesson of politics is “Always know whether the squeeze is worth the juice”. Now i was trying to finally make a genuine effort at understanding Central Limit theorem. Throughout my life(30 years), i have always been suspicious whenever statistics goes beyond the mean, median, mode, SD and Variance. (i.e to say, whenever any stat goes above first and second moments). Part of it because i never really learnt or rather never paid enough attention to convince myself of the theorems involved in reasoning with distributions. Anyways, i figured Central limit theorem would be a good place to start and in learning by teaching am summarizing what i’ve learnt so far.

It started off as i came across this post on HN and going through comments and critique realized the demo is more of a special case and while i did get that specific example(and sure of what CLT says) am still unsure of why Central limit theorem is true or how one formulate it in math terms. It is important for me to understand those, if i am ever to be able to question someone claiming some implication of CLT. Anyway, i came across the squeeze theorem in one of the HN comments and since it seems it’s part of the proof for CLT, I ended up reading and here’s the result of that.

Anyway, enough story. Let’s go onwards. So here goes straight from the wikipedia page:

Assumptions:
There are three functions $f,g,h$ defined over a limit $l$.
$a$ is a limit point.
$f,g,h$ may not be defined at $a$, since it is the limit point.

$g(x) leq f(x) leq h(x)$

$lim_{x to a} g(x) = lim_{x to a} h(x) = L$

To be proved:
$lim_{x to a} f(x) = L$

Proof:

Limits:

I’ll try and clarify what is a limit as mathematically defined, and hopefully without equations,but words only.
Well, according to wikipedia page, limit of a function f(x) means that the function f(x) can be made as close to a value (say L),
by making x sufficiently close to c.

Or to write out the equation
$lim_{x to c}f(x) = L$

# Dynamic linker tricks: Using LD_PRELOAD to cheat, inject features and investigate programs

Dynamic linker tricks: Using LD_PRELOAD to cheat, inject features and investigate programs

Awesome… View On WordPress
from Tumblr http://ift.tt/1TEv6GJ
via IFTTT

# The “when is cheryl’s birthday?” problem — ipython solving steps

Cool, step by step solving of the recently viral when is cheryl’s birthday problem?.
http://ift.tt/1GsacIS

from The “when is cheryl’s birthday?” problem — ipython solving steps

from Tumblr http://ift.tt/1TTBDwS

via IFTTT

from The “when is cheryl’s birthday?” problem — ipython solving steps

from Tumblr http://ift.tt/1NIPglP

via IFTTT

from The “when is cheryl’s birthday?” problem — ipython solving steps

from Tumblr http://ift.tt/1WePwvL

via IFTTT

from The “when is cheryl’s birthday?” problem — ipython solving steps

from Tumblr http://ift.tt/1NITLwP

via IFTTT

from The “when is cheryl’s birthday?” problem — ipython solving steps

from Tumblr http://ift.tt/1OTDyoV

via IFTTT

from The “when is cheryl’s birthday?” problem — ipython solving steps

from Tumblr http://ift.tt/1NIX1Io

via IFTTT

from The “when is cheryl’s birthday?” problem — ipython solving steps
from Tumblr http://ift.tt/1TAPniI
via IFTTT

# Stack Ranking

Why stack-ranking is always a case of ‘the house always wins’:

Disclaimer:

1. It’s partly a defendant’s argument, and I am biased towards my client(i.e the employee).

2.I’ve little experience managing a group of people and don’t claim to know all the challenges involved.

3.My research/reading has been restricted to supporting ideas/theories/assumptions only. Not the thorough, covering all other bases(and unbiased) kind of literature survey.(**wink** stack ranking vs performance/vitality curve distinction)

At first look it looks like a wonderful meritocratic setup. It uses relative comparison with peers(not unlike pagerank algorithm/ eigen morality. . On the face of it is a very brilliant idea or a good idea that works well, when measuring quantities that haven’t been quantified before enough. In fact, if I were trying to do science on measuring performance, it’s a reasonably sane and tried approach. However, there are problems with using it.
I understand why it makes it easier to make decisions(especially big organizations), you get a single number that’s guaranteed to fall within some expected values(in the probability theory sense) and forcing a curve simply makes it easier to fit a fixed amount for bonuses and incentives. However, here’s the challenge how do you know your employees’/managers’/directors’ performance falls into a bell curve*? Maybe your company’s hiring practices always get bad performing employees or average performing employees or high performing employees(all three in comparison to the general population)?. In which case, aren’t you alienating a high performing employee, because his peers did better(perhaps in revenue)? The catch is revenue has more factors influencing than the performance of your employees.

Here’s a quote from here. :

“You have to have an objective when you do stuff like this. At GE there was only one objective, and that was to force honesty. That’s all it ever was—to force an honest discussion between your manager and you. And there’s nothing that quite forces that more than employees knowing that they expect to know how that manager ranks them, and then asking that manager, ‘Tell me where I rank and tell me why.’”

See anything wrong in that argument? Try replacing ‘honesty’ with ‘dishonesty’ and the argument still is logically consistent and sounds right. Guess why, because there’s an underlying assumption, stack-ranking raises honesty(or honest communication). While I agree, it’s a good way to force managers to give feedback(especially negative) to their employees, am not convinced it’s good or encourages honesty. I get that people(and managers) are more likely to avoid giving negative feedback and they are also subject to confirmation bias. . All of which can create bloated inefficient departments/teams. Here’s the catch, when you force something like this you’re eventually pushing the lowest ranks to people who are bad negotiators(with their managers) and therefore don’t push back when given negative feedback. Over half a decade or so you get a whole company of employees, who are all very good negotiators(no correlation positive or negative with performance).
In the end that defense sounds way too much like someone (who’s a reformer) and is stuck in the values/virtues node aka holy priest(I know, I’ve been guilty of it so often and probably right now). Enough of debate-level arguments, here’s an attempt at discussion of why it becomes something bad.
In theory, it can encourage managers to be honest to give negative feedback to their hires/employees, but in practice, it comes down to compromises/favours/future promises traded between the employee and the manager. You’re forcing the manager to make compromise/favour/future promise to one employee to pay the other. Even then, if it is still one number and some subjective reasoning between manager and employee it has some hopes of being a measure**. Now that post doesn’t make it clear why it’s a bad idea to use a normal curve on measuring performance, but it’s basic necessity before we can talk about using/finalizing measures of a hitherto unquantified phenomenon. For that we need to understand where does this vitality curve concept comes from.
Here goes the google scholar search result showing up nothing.I’ve been trying to find what research went into the whole stack ranking idea. A google search shows up Vitality curve. Ok where could Jack Welch have picked up this insane idea of vitality curve? The closest I can find is

Central Limit Theorem in Statistics.
The basic premise of this theorem is that if we take enough number of samples of random variable of unknown distribution, the average of the samples will form a normal standard distribution.

This is not the strongest form of the theorem, but is the basic one the rest of the theorems are based on.

Now let’s look at what this means. When you’re examining a measurable quantity, whose distribution is unknown, you can essentially take samples(enough no. of times and enough size) and average it to form a normal distribution, if there’s enough samples and sample sizes.
Why/How is this useful?

Well it becomes useful when you want to compare two random variables and see if they have anything in correlation or common causal factors.

Especially, when you have figured out ways to manipulate/control one of the variables, we can simply design experiments that measure both of these variables, plot the difference of their averages(of the samples) and see how much it varies from the standard normal curve. This can give us whether they are positively or negatively correlated or simply unrelated. This is how experimental sciences work. Ofcourse, it’s not perfect, but it’s the best we have.**

On top of all this it breaks down at a critical assumption of IID***

Now, let’s get back to the original topic, if your organization/manager is implementing a stack ranking and if they refer to central limit theorem(you’re in luck, I haven’t heard any manager relate both of these, or name any of these.) you can question where does their idea of normality comes from. There’ll be cases, where your manager will tell you, your performance was average/below-average/above-average with respect to the rest of the team/organization’s. You get to question, how did they arrive at the normal curve’s values( most likely answer would be past year’s performance).

But here’s the catch, if they understand the experimentation process, the challenge then is to prove/question the current curve has seen enough samples. I don’t think it’s possible in most organizations/most roles. Of course, in very well established industries, with very specifically defined roles, it makes sense and is possible, but I’m not sure it applies well in the modern business environment.

Now the bigger your organization, more likely your performance is rated among different aspects/vectors/areas, which essentially multiplies the number of variables, and actually complicates the problem(requiring more samples to normalize).

What are the basic premises of the “Central Limit Theorem”?
Well, for one that you are comparing two distributions of random variables. (aka random distributions).

* — A quick read based on the blog here suggests not all companies use standard normal distribution, but normal/gaussian distribution with different spreads. facebook seems to have a narrower spread than amazon( which makes me think of the differences in corporate culture and what this model entails for it, but that’s more thinking and perhaps another blog post, about nash equilibrium competition vs co-operation.Hunch/Guess: more competition than co-operation at facebook and vice-versa at amazon.). It’s not clear what google uses.

** — Scientists, don’t get angry with this. I know there are more nuances that go into statistical inferences, but think this is core value/process, and can be explained simply. Besides, am not a real scientist, just a guy who went out of the academics.

*** — Making this assumption about a lot of the variables, I’ve seen used in a performance review is rather comical (like this).

P.S: To put a cynical quip (paraphrasing i think Douglas Adams), The universe is either mildly malevolent or neutral(i.e: definitely not benevolent), the modern workplace is definitely malevolent(either mildly or fatally).

from Stack Ranking

from Tumblr http://ift.tt/1TTC9Lj

via IFTTT

from Stack Ranking

from Tumblr http://ift.tt/1NIPGIY

via IFTTT

from Stack Ranking

from Tumblr http://ift.tt/1WePFPA

via IFTTT

from Stack Ranking

from Tumblr http://ift.tt/1NITQAv

via IFTTT

from Stack Ranking

from Tumblr http://ift.tt/1OTDaGS

via IFTTT

from Stack Ranking

from Tumblr http://ift.tt/1NIWTZw

via IFTTT

from Stack Ranking
from Tumblr http://ift.tt/1TAPB9q
via IFTTT

# HTTP protocol.. RFC study notes

Alright, I sholud have done this atleast 2 years ago and was too much of an idiot to not do this, better late than never.

Study Notes — http protocol (RFC 7230 – 7235)*

RFC 7230 — Message syntax and Routing

Key parties:
1. HTTP Server: the sytem that responds to http requets with http responses
2. User Agent/http client: the system that sends the http requests

Intermediaries:
There are some intermediate parties in the communication between 1 and 2. (Because of how tcp/ip works).
Note: these are relevant because, some of the keywords are related to these. (aka, this is where the http vs tcp/ip abstraction leaks)
1. proxy:
message-forwarding agent selected by client(via configurable rules),
commonly used to group an organizations’ requests
2. gateway:
an intermediary that acts as origin(http) server for a outbound connection but translates the requests and forwards them inbound to other servers.
3. tunnel:
Tunnel is a blind relay between 2 connections, that passes on messages. it differs from gateway, but not translating the requests, but blindly passing them on. Generally used in situations like TLS + https secure communication via a firewall proxy

Caches:
Details in RFC 7234.
1. Local store of previous response messages
2. A response may or may not be cached based on :
a, cacheable flag is set.
b, A set of constraints defined in rfc7234

Versioning:
A Message has atleast these fields:
Version is .

HTTP-version = HTTP-name “/” DIGIT “.” DIGIT
HTTP-name = %x48.54.54.50 ; “HTTP”, case-sensitive

Major version denotes http messaging syntax, while minor version is the client’s communication capabilities.
Hmm.. these two don’t seem well-defined so far in the rfc.
My guess is the major version corresponds to tell the server which protocol-specific syntax, (ie: http/https/ftp/etc.) to connect with the server is used for the request.
While minor version is which version client understands, so the response can be formatted in a compatible manner.
My guess about major num is wrong.

The intention of HTTP’s versioning design is that the major number
will only be incremented if an incompatible message syntax is
introduced, and that the minor number will only be incremented when
changes made to the protocol have the effect of adding to the message
semantics or implying additional capabilities of the sender.
However, the minor version was not incremented for the changes
introduced between [RFC2068] and [RFC2616], and this revision has
specifically avoided any such changes to the protocol.

Uniform Resource Identifiers:
1. identifies resources
For the URI syntax, I’ll just quote from the links on the rfc.

URI-reference =
absolute-URI =
relative-part =
scheme =
authority =
uri-host =
port =
path-abempty =
segment =
query =
fragment =

absolute-path = 1*( “/” segment )
partial-URI = relative-part [ “?” query ]

http URI Scheme:

* — Original RFC was 2616 http://ift.tt/1qWngNQ, but it was superseded by these.

from HTTP protocol.. RFC study notes

from Tumblr http://ift.tt/1TJ1z20

via IFTTT

from HTTP protocol.. RFC study notes

from Tumblr http://ift.tt/1YUABVk

via IFTTT

from HTTP protocol.. RFC study notes
from Tumblr http://ift.tt/1RmDqIV
via IFTTT

# Pure math.. — Definition for Explain like I’m 5

Why Do We Pay Pure Mathematicians?

Brilliant writing as mathwithbaddrawings always comes up with.

from Pure math.. — Definition for Explain like I’m 5

from Tumblr http://ift.tt/1TTC6PB

via IFTTT

from Pure math.. — Definition for Explain like I’m 5

from Tumblr http://ift.tt/1NIPutn

via IFTTT

from Pure math.. — Definition for Explain like I’m 5
from Tumblr http://ift.tt/1WePPqi
via IFTTT

# What I would change about python?

1. The semantics of the ‘or’ keyword. I know it’s supposed to make it readable, as it currently exists(i.e: read boolean values of left side expression, and if false read right side of the expression and return whichever is true. False if both are false.). I’d rather have it return True or False instead. I think that’s more logical for a programmer, and perhaps that’s part of python being not a purely-functional language.

2. The distinction between expression and statement.

3. Side-Effects: While it’s possible to write code that provides functional interface, it(interpreter) does not guarantee no side-effects/assignments.

from What I would change about python?

from Tumblr http://ift.tt/1TJ0M11

via IFTTT

from What I would change about python?

from Tumblr http://ift.tt/1YUBayt

via IFTTT

from What I would change about python?
from Tumblr http://ift.tt/1RmDB70
via IFTTT

Why do I read fiction? Or what do I get out of reading fiction?
Vivek haldar here talks about how he doesn’t read fiction because it does nothing to him, or rather means nothing to him.
It set me thinking like a knot in my brain, or a thorn in the brain. I read it long time ago, and my first thought was am the opposite.
I prefer reading fiction. In the time since, I have held the question in my mind for some time and come up with the following possibilities:

0. Theory of mind– there’s some (scanty,debatable)evidence reading fiction helps understanding how other minds work.
Here’s the study
And I do have a tendency to retreat into reading fiction, when I am upset/confused or trying figure out what’s the right decision(usually regarding people in my life) to make.

1. I find it kinda enhances or clears my head to goad into logical thinking.* i.e: once am done reading through the fiction to completion.

2.It definitely affords a comfortable/guilt-free thing to do, without being(nay feeling) guilty of procrastination, supposedly reading is always considered a good thing(socially).

3.It could also simply be my way of dealing with the modern world’s craziness. Much like VGR refers here.

4. It helps as good practice for thought experiments and therefore makes it easier to consider alternative explanations**.

5. It definitely helps to clear out the emotional components from my decision-making/thinking. More specifically in the (alertness/arousal) scale, it helps lowering out arousal level, and therefore raising the alertness/arousal ratio. (One of my hypothesis is that rational thinking directly proportional to ratio of alertness to arousal levels).

*– Might simply be wishful thinking on my part.
P.S: The above is a rather descriptive attempt. Some of the points may and probably do have overlap with other points. The bullet point format is simply organized for communication, instead of empirical hypothesis testing.

from Tumblr http://ift.tt/1TTC6iz

via IFTTT