theta } = - 2 $ $ $ $ \ left ( r ^ 2 + \ frac { 1 } { r ^ 2 } \ right ) + 4 \ cos ^ 2 { \ theta } = 10 $ $ from these equations, one may deduce that a solution is $ r = \ phi + \ sqrt { \ phi } $ and $ \ cos { \ theta } = 1 / \ phi $, where $ \ phi = ( 1 + \ sqrt { 5 } ) / 2 $ is the golden ratio. thus the poles take the form $ $ z _ k = \ pm \ left ( \ phi \ pm \ sqrt { \ phi } \ right ) e ^ { \ pm i \ arctan { \ sqrt { \ phi } } } $ $ now we have to find the residues of the integrand at these 8 poles. we can break this task up by computing : $ $ \ sum _ { k = 1 } ^ 8 \ operatorname * { res } _ { z = z _ k } \ left [ \ frac { 8 ( z ^ 2 - 1 ) ( z ^ 4 - 6 z ^ 2 + 1 ) \ log ^ 2 { z } } { z ^ 8 + 4 z ^ 6 + 70z ^ 4 + 4 z ^ 2 + 1 } \ right ] = \ sum _ { k = 1 } ^ 8 \ operatorname * { res } _ { z = z _ k } \ left [ \ frac { 8 ( z ^ 2 - 1 ) ( z ^ 4 - 6 z ^ 2 + 1 ) } { z ^ 8 + 4 z ^ 6 + 70z ^ 4 + 4 z ^ 2 + 1 } \ right ] \ log ^ 2 { z _ k } $ $ here things got very messy, but the result is rather unbelievably simple : $ $ \ operatorname * { res } _ { z = z _ k } \ left [ \ frac { 8 ( z ^ 2 - 1 ) ( z ^ 4 - 6 z ^ 2 + 1 ) } { z ^ 8 + 4 z ^ 6 + 70z ^ 4 + 4 z ^ 2 + 1 } \ right ] = \ text { sgn } [ \ cos { ( \ arg { z _ k } ) } ] $ $ edit actually, this is a very simple computation. inspired by @ sos440, one may express the rational function of $ z $ in a very simple


form : $ $ \ frac { 8 ( z ^ 2 - 1 ) ( z ^ 4 - 6 z ^ 2 + 1 ) } { z ^ 8 + 4 z ^ 6 + 70z ^ 4 + 4 z ^ 2 + 1 } = - \ left [ \ frac { p'( z ) } { p ( z ) } + \ frac { p'( - z ) } { p ( - z ) } \ right ] $ $ where $ $ p ( z ) = z ^ 4 + 4 z ^ 3 + 10 z ^ 2 + 4 z + 1 $ $ the residue of this function at the poles are then easily seen to be $ \ pm 1 $ according to whether the pole is a zero of $ p ( z ) $ or $ p ( - z ) $. end edit that is, if the pole has a positive real part, the residue of the fraction is $ + 1 $ ; if it has a negative real part, the residue is $ - 1 $. now consider the log piece. expanding the square, we get 3 terms : $ $ \ log ^ 2 { | z _ k | } - ( \ arg { z _ k } ) ^ 2 + i 2 \ log { | z _ k | } \ arg { z _ k } $ $ summing over the residues, we find that because of the $ \ pm1 $ contributions above, that the first and third terms sum to zero. this leaves the second term. for this, it is crucial that we get the arguments right, as $ \ arg { z _ k } \ in [ 0, 2 \ pi ) $. thus, we have $ $ \ begin { align } i = \ int _ 0 ^ { \ infty } dv \ frac { 8 ( v ^ 2 - 1 ) ( v ^ 4 - 6 v ^ 2 + 1 ) } { v ^ 8 + 4 v ^ 6 + 70v ^ 4 + 4 v ^ 2 + 1 } \ log { v } & = \ frac12 \ sum _ { k = 1 } ^ 8 \ text { sgn } [ \ cos { ( \ arg { z _ k } ) } ] ( \ arg { z _ k } ) ^ 2 \ \ & = \ frac12 [ 2 ( \ arctan { \ sqrt { \ phi } } ) ^ 2 + 2 ( 2 \ pi - \ arctan { \ sqrt { \


phi } } ) ^ 2 \ \ & - 2 ( \ pi - \ arctan { \ sqrt { \ phi } } ) ^ 2 - 2 ( \ pi + \ arctan { \ sqrt { \ phi } } ) ^ 2 ] \ \ & = 2 \ pi ^ 2 - 4 \ pi \ arctan { \ sqrt { \ phi } } \ \ & = 4 \ pi \, \ text { arccot } { \ sqrt { \ phi } } \ \ \ end { align } $ $


no, it's not possible : at least, not in an asymptotic sense, where you require the problem to keep getting strictly easier, forever, as $ n \ to \ infty $. let $ t ( n ) $ be the best possible running time for solving such a problem, where $ n $ is the size of the input. note that the running time is a count of the number of instructions executed by the algorithm, so it has to be a non - negative integer. in other words, $ t ( n ) \ in \ mathbb { n } $ for all $ n $. now if we consider a function $ t : \ mathbb { n } \ to \ mathbb { n } $, we see there is no such function that is strictly monotonically decreasing. ( whatever $ t ( 0 ) $ is, it has to be finite, say $ t ( 0 ) = c $ ; but then since $ t $ is monotonically strictly decreasing, $ t ( c ) \ le 0 $ and $ t ( c + 1 ) \ le - 1 $, which is impossible. ) for similar reasons, there is no function that is asymptotically strictly decreasing : we can similarly prove that there's no running time function $ t ( n ) $ where there exists $ n _ 0 $ such that for all $ n \ ge n _ 0 $, $ t ( n ) $ is monotonically strictly decreasing ( any such function would have to become eventually negative ). so, such a problem cannot exist, for the simple reason that running times have to be non - negative integers. note that this answer covers only deterministic algorithms ( i. e., worst - case running time ). it doesn't rule out the possibility of randomized algorithms whose expected running time is strictly monotonically decreasing, forever. i don't know whether it's possible for such an algorithm to exist. i thank beni cherniavsky - paskin for this observation.


that's a great question! what you are asking about is one of the missing links between classical and quantum gravity. on their own, the einstein equations, $ g _ { \ mu \ nu } = 8 \ pi g t _ { \ mu \ nu } $, are local field equations and do not contain any topological information. at the level of the action principle, $ $ s _ { \ mathrm { eh } } = \ int _ \ mathcal { m } d ^ 4 x \, \ sqrt { - g } \, \ mathbf { r } $ $ the term we generally include is the ricci scalar $ \ mathbf { r } = \ mathrm { tr } [ r _ { \ mu \ nu } ] $, which depends only on the first and second derivatives of the metric and is, again, a local quantity. so the action does not tell us about topology either, unless you're in two dimensions, where the euler characteristic is given by the integral of the ricci scalar : $ $ \ int d ^ 2 x \, \ mathcal { r } = \ chi $ $ ( modulo some numerical factors ). so gravity in 2 dimensions is entirely topological. this is in contrast to the 4d case where the einstein - hilbert action appears to contain no topological information. this should cover your first question. all is not lost, however. one can add topological degrees of freedom to 4d gravity by the addition of terms corresponding to various topological invariants ( chern - simons, nieh - yan and pontryagin ). for instance, the chern - simons contribution to the action looks like : $ $ s _ { cs } = \ int d ^ 4 x \ frac { 1 } { 2 } \ left ( \ epsilon _ { ab } { } ^ { ij } r _ { cdij } \ right ) r _ { abcd } $ $ here is a very nice paper by jackiw and pi for the details of this construction. there's plenty more to be said about topology and general relativity. your question only scratches the surface. but there's a goldmine underneath! i'll let someone else tackle your second question. short answer is " yes ".


i think this approach is mistaken, but perhaps it will be more helpful if i explain why. wanting to know the best model given some information about a large number of variables is quite understandable. moreover, it is a situation in which people seem to find themselves regularly. in addition, many textbooks ( and courses ) on regression cover stepwise selection methods, which implies that they must be legitimate. unfortunately, however, they are not, and the pairing of this situation and goal is quite difficult to successfully navigate. the following is a list of problems with automated stepwise model selection procedures ( attributed to frank harrell, and copied from here ) : it yields r - squared values that are badly biased to be high. the f and chi - squared tests quoted next to each variable on the printout do not have the claimed distribution. the method yields confidence intervals for effects and predicted values that are falsely narrow ; see altman and andersen ( 1989 ). it yields p - values that do not have the proper meaning, and the proper correction for them is a difficult problem. it gives biased regression coefficients that need shrinkage ( the coefficients for remaining variables are too large ; see tibshirani [ 1996 ] ). it has severe problems in the presence of collinearity. it is based on methods ( e. g., f tests for nested models ) that were intended to be used to test prespecified hypotheses. increasing the sample size does not help very much ; see derksen and keselman ( 1992 ). it allows us to not think about the problem. it uses a lot of paper. the question is, what's so bad about these procedures / why do these problems occur? most people who have taken a basic regression course are familiar with the concept of regression to the mean, so this is what i use to explain these issues. ( although this may seem off - topic at first, bear with me, i promise it's relevant. ) imagine a high school track coach on the first day of tryouts. thirty kids show up. these kids have some underlying level of intrinsic ability to which neither the coach nor anyone else, has direct access. as a result, the coach does the only thing he can do, which is have them all run a 100m dash. the times are presumably a measure of their intrinsic ability and are taken as such. however, they are probabilistic ; some proportion of how well someone does is based on their actual ability, and some proportion is random


. imagine that the true situation is the following : set. seed ( 59 ) intrinsic _ ability = runif ( 30, min = 9, max = 10 ) time = 31 - 2 * intrinsic _ ability + rnorm ( 30, mean = 0, sd =. 5 ) the results of the first race are displayed in the following figure along with the coach's comments to the kids. note that partitioning the kids by their race times leaves overlaps on their intrinsic ability - - this fact is crucial. after praising some, and yelling at some others ( as coaches tend to do ), he has them run again. here are the results of the second race with the coach's reactions ( simulated from the same model above ) : notice that their intrinsic ability is identical, but the times bounced around relative to the first race. from the coach's point of view, those he yelled at tended to improve, and those he praised tended to do worse ( i adapted this concrete example from the kahneman quote listed on the wiki page ), although actually regression to the mean is a simple mathematical consequence of the fact that the coach is selecting athletes for the team based on a measurement that is partly random. now, what does this have to do with automated ( e. g., stepwise ) model selection techniques? developing and confirming a model based on the same dataset is sometimes called data dredging. although there is some underlying relationship amongst the variables, and stronger relationships are expected to yield stronger scores ( e. g., higher t - statistics ), these are random variables, and the realized values contain error. thus, when you select variables based on having higher ( or lower ) realized values, they may be such because of their underlying true value, error, or both. if you proceed in this manner, you will be as surprised as the coach was after the second race. this is true whether you select variables based on having high t - statistics, or low intercorrelations. true, using the aic is better than using p - values, because it penalizes the model for complexity, but the aic is itself a random variable ( if you run a study several times and fit the same model, the aic will bounce around just like everything else ). unfortunately, this is just a problem intrinsic to the epistemic nature of reality itself. i hope this is helpful.


tungsten's melting point of 3422 °c is the highest of all metals and second only to carbon's, for which melting occurs only at high pressure ( there's no standard melting point ). this is why tungsten is used in rocket nozzles and reactor linings. there are refractory ceramics and alloys that have higher melting points, notably $ \ ce { ta4hfc5 } $ with a melting point of 4215 °c, hafnium carbide at 3900 °c and tantalum carbide at 3800 °c. carbon cannot be used to hold molten tungsten because they will react to form tungsten carbide. sometimes ladles and crucibles used to prepare or transport high melting point materials like tungsten are lined with the various higher melting ceramics or alloys. more typically tungsten and other refractory materials are fabricated in a non - molten state. a process known as powder metallurgy is used. this process uses 4 basic steps : powder manufacture - a variety of techniques are available to generate small particles of the material being worked powder blending - routine procedures are used to blend the constituent particles into a uniform mixture compacting - the blended powder is placed in a mold and subjected to high pressure sintering - the compacted material is subjected to high temperature and some level of bonding occurs between particles.


claim : $ l $ is context - free. proof idea : there has to be at least one difference between the first and second half ; we give a grammar that makes sure to generate one and leaves the rest arbitrary. proof : for sake of simplicity, assume a binary alphabet $ \ sigma = \ { a, b \ } $. the proof readily extends to other sizes. consider the grammar $ g $ : $ \ qquad \ begin { align } s & \ to ab \ mid ba \ \ a & \ to a \ mid aaa \ mid aab \ mid baa \ mid bab \ \ b & \ to b \ mid aba \ mid abb \ mid bba \ mid bbb \ end { align } $ it is quite clear that it generates $ \ qquad \ mathcal { l } ( g ) = \ { \ underbrace { w _ 1 } _ k x \ underbrace { w _ 2v _ 1 } _ { k + l } y \ underbrace { v _ 2 } _ l \ mid | w _ 1 | = | w _ 2 | = k, | v _ 1 | = | v _ 2 | = l, x \ neq y \ } \ subseteq \ sigma ^ * ; $ the suspicious may perform a nested induction over $ k $ and $ l $ with case distinction over pairs $ ( x, y ) $. the length of a word in $ \ mathcal { l } ( g ) $ is $ 2 ( k + l + 1 ) $. the letters $ x $ and $ y $ occur on positions $ k + 1 $ and $ 2k + l + 2 $, respectively. when we split the word in half, i. e. after $ ( k + l + 1 ) $ letters, then the first half contains the letter $ x $ on position $ k + 1 $ and the second half has the letter $ y $ on position $ k + 1 $. therefore, $ x $ and $ y $ have the same position ( in their respective half ), which implies $ \ mathcal { l } ( g ) = l $ because $ g $ imposes no other restrictions on its language. the interested reader may enjoy two follow - up problems : exercise 1 : come up with a pda for $ l $! exercise 2 : what about $ \ { xyz \ mid | x | = | y | = | z |, x \ neq


y \ lor y \ neq z \ lor x \ neq z \ } $?


i'm not sure i'm doing it the best way, but here is an example where i read a compressed gzip fastq file and write the records in block gzip fastq : from bio import seqio, bgzf # used to convert the fastq stream into a file handle from io import stringio from gzip import open as gzopen records = seqio. parse ( # there is actually simpler ( thanks @ peterjc ) # stringio ( gzopen ( " random _ 10. fastq. gz " ). read ( ). decode ( " utf - 8 " ) ), gzopen ( " random _ 10. fastq. gz ", " rt " ), format = " fastq " ) with bgzf. bgzfwriter ( " test. fastq. bgz ", " wb " ) as outgz : seqio. write ( sequences = records, handle = outgz, format = " fastq " )


but what does frequency spectrum means in case of images? the " mathematical equations " are important, so don't skip them entirely. but the 2d fft has an intuitive interpretation, too. for illustration, i've calculated the inverse fft of a few sample images : as you can see, only one pixel is set in the frequency domain. the result in the image domain ( i've only displayed the real part ) is a " rotated cosine pattern " ( the imaginary part would be the corresponding sine ). if i set a different pixel in the frequency domain ( at the left border ) : i get a different 2d frequency pattern. if i set more than one pixel in the frequency domain : you get the sum of two cosines. so like a 1d wave, that can be represented as a sum of sines and cosines, any 2d image can be represented ( loosely speaking ) as a sum of " rotated sines and cosines ", as shown above. when we take fft of a image in opencv, we get weird picture. what does this image denote? it denotes the amplitudes and frequencies of the sines / cosines that, when added up, will give you the original image. and what is its application? there are really too many to name them all. correlation and convolution can be calculated very efficiently using an fft, but that's more of an optimization, you don't " look " at the fft result for that. it's used for image compression, because the high frequency components are usually just noise.


think about it. what exactly do you envision a " 256 bit " processor being? what makes the bit - ness of a processor in the first place? i think if no further qualifications are made, the bit - ness of a processor refers to its alu width. this is the width of the binary number that it can handle natively in a single operation. a " 32 bit " processor can therefore operate directly on values up to 32 bits wide in single instructions. your 256 bit processor would therefore contain a very large alu capable of adding, subtracting, oring, anding, etc, 256 bit numbers in single operations. why do you want that? what problem makes the large and expensive alu worth having and paying for, even for those cases where the processor is only counting 100 iterations of a loop and the like? the point is, you have to pay for the wide alu whether you then use it a lot or only a small fraction of its capabilities. to justify a 256 bit alu, you'd have to find an important enough problem that can really benefit from manipulating 256 bit words in single instructions. while you can probably contrive a few examples, there aren't enough of such problems that make the manufacturers feel they will ever get a return on the significant investment required to produce such a chip. if it there are niche but important ( well - funded ) problems that can really benefit from a wide alu, then we would see very expensive highly targeted processors for that application. their price, however, would prevent wide usage outside the narrow application that it was designed for. for example, if 256 bits made certain cryptography applications possible for the military, specialized 256 bit processors costing 100s to 1000s of dollars each would probably emerge. you wouldn't put one of these in a toaster, a power supply, or even a car though. i should also be clear that the wide alu doesn't just make the alu more expensive, but other parts of the chip too. a 256 bit wide alu also means there have to be 256 bit wide data paths. that alone would take a lot of silicon area. that data has to come from somewhere and go somewhere, so there would need to be registers, cache, other memory, etc, for the wide alu to be used effectively. another point is that you can do any width arithmetic on any width processor. you can add a 32 bit memory word into another 32 bit memory word on a pic 18 in 8 instructions


, whereas you could do it on the same architecture scaled to 32 bits in only 2 instructions. the point is that a narrow alu doesn't keep you from performing wide computations, only that the wide computations will take longer. it is therefore a question of speed, not capability. if you look at the spectrum of applications that need to use particular width numbers, you will see very very few require 256 bit words. the expense of accelerating just those few applications with hardware that won't help the others just isn't worth it and doesn't make a good investment for product development.


the cdc has made available online its ncov test kit. briefly, the kit contains primers and probes for real - time reverse - transcriptase pcr, as well as instructions for appropriate use and ( critically ) controls and guidelines to avoid false positives and negatives. kits from different countries may use slightly different primers and probes, though since they are all working from the same sequences and the same principles they should be broadly quite similar. explaining how quantitative pcr works and the details of the primers and probes is out of the scope of this se. a layman's introduction was written by john timmer at ars technica.


for fluid to flow from a wound there needs to be a significant pressure gradient between where it is now and the outside of the body. your skin generally does not have a strong compressive effect, which is why a deep cut exposing fat will not lead to the fatty tissue being expulsed from the body any more than the interstitial fluid is. blood, however, flows. for it to circulate there needs to be a pressure gradient between where it is now and where it is going. since veins ( including the vena cava, which channels blood back into the heart ) do not have vascular walls strong enough to create a suction effect ( i. e. lower pressure than the surrounding tissue ), you can conclude that the pressure of blood vessels is always higher than that of surrounding tissues, and thus higher than the pressure outside of your body. this is why all blood vessels, including veins, will bleed, whereas less pressurized systems such as interstitial fluid will not.


things are not empty space. our classical intuition fails at the quantum level. matter does not pass through other matter mainly due to the pauli exclusion principle and due to the electromagnetic repulsion of the electrons. the closer you bring two atoms, i. e. the more the areas of non - zero expectation for their electrons overlap, the stronger will the repulsion due to the pauli principle be, since it can never happen that two electrons possess exactly the same spin and the same probability to be found in an extent of space. the idea that atoms are mostly " empty space " is, from a quantum viewpoint, nonsense. the volume of an atom is filled by the wavefunctions of its electrons, or, from a qft viewpoint, there is a localized excitation of the electron field in that region of space, which are both very different from the " empty " vacuum state. the concept of empty space is actually quite tricky, since our intuition " space is empty when there is no particle in it " differs from the formal " empty space is the unexcited vacuum state of the theory " quite a lot. the space around the atom is definitely not in the vacuum state, it is filled with electron states. but if you go and look, chances are, you will find at least some " empty " space in the sense of " no particles during measurement ". yet you are not justified in saying that there is " mostly empty space " around the atom, since the electrons are not that sharply localized unless some interaction ( like measurements ) takes place that actually forces them to. when not interacting, their states are " smeared out " over the atom in something sometimes called the electron cloud, where the cloud or orbital represents the probability of finding a particle in any given spot. this weirdness is one of the reasons why quantum mechanics is so fundamentally different from classical mechanics – suddenly, a lot of the world becomes wholly different from what we are used to at our macroscopic level, and especially our intuitions about " empty space " and such fail us completely at microscopic levels. since it has been asked in the comments, i should probably say a few more words about the role of the exclusion principle : first, as has been said, without the exclusion principle, the whole idea of chemistry collapses : all electrons fall to the lowest 1s orbital and stay there, there are no " outer " electrons, and the world as we know it would not work. second, consider the situation of two equally charged classical particles : if you only invest


enough energy / work, you can bring them arbitrarily close. the pauli exclusion principle prohibits this for the atoms – you might be able to push them a little bit into each other, but at some point, when the states of the electrons become too similar, it just won't go any further. when you hit that point, you have degenerate matter, a state of matter which is extremely difficult to compress, and where the exclusion principle is the sole reason for its incompressibility. this is not due to coulomb repulsion, it is that that we also need to invest the energy to catapult the electrons into higher energy levels since the number of electrons in a volume of space increases under compression, while the number of available energy levels does not. ( if you read the article, you will find that the electrons at some point will indeed prefer to combine with the protons and form neutrons, which then exhibit the same kind of behaviour. then, again, you have something almost incompressible, until the pressure is high enough to break the neutrons down into quarks ( that is merely theoretical ). no one knows what happens when you increase the pressure on these quarks indefinitely, but we probably cannot know that anyway, since a black hole will form sooner or later ) third, the kind of force you need to create such degenerate matter is extraordinarily high. even metallic hydrogen, the probably simplest kind of such matter, has not been reliably produced in experiments. however, as mark a has pointed out in the comments ( and as is very briefly mentioned in the wikipedia article, too ), a very good model for the free electrons in a metal is that of a degenerate gas, so one could take metal as a room - temperature example of the importance of the pauli principle. so, in conclusion, one might say that at the levels of our everyday experience, it would probably enough to know about the coulomb repulsion of the electrons ( if you don't look at metals too closely ). but without quantum mechanics, you would still wonder why these electrons do not simply go closer to their nuclei, i. e. reduce their orbital radius / drop to a lower energy state, and thus reduce the effective radius of the atom. therefore, coulomb repulsion already falls short at this scale to explain why matter seems " solid " at all – only the exclusion principle can explain why the electrons behave the way they do


a similar question was asked on mathematica. stackexchange. my answer over there evolved and got quite long in the end, so i'll summarize the algorithm here. abstract the basic idea is : find the label. find the borders of the label find a mapping that maps image coordinates to cylinder coordinates so that it maps the pixels along the top border of the label to ( [ anything ] / 0 ), the pixels along the right border to ( 1 / [ anything ] ) and so on. transform the image using this mapping the algorithm only works for images where : the label is brighter than the background ( this is needed for the label detection ) the label is rectangular ( this is used to measure the quality of a mapping ) the jar is ( almost ) vertical ( this is used to keep the mapping function simple ) the jar is cylindrical ( this is used to keep the mapping function simple ) however, the algorithm is modular. at least in principle, you could write your own label detection that does not require a dark background, or you could write your own quality measurement function that can cope with elliptical or octagonal labels. results these images were processed fully automatically, i. e. the algorithm takes the source image, works for a few seconds, then shows the mapping ( left ) and the un - distorted image ( right ) : the next images were processed with a modified version of the algorithm, were the user selects the left and right borders of the jar ( not the label ), because the curvature of the label cannot be estimated from the image in a frontal shot ( i. e. the fully automatic algorithm would return images that are slightly distorted ) : implementation : 1. find the label the label is bright in front of a dark background, so i can find it easily using binarization : src = import [ " binary = fillingtransform [ deletebordercomponents [ binarize [ src ] ] ] i simply pick the largest connected component and assume that's the label : labelmask = image [ sortby [ componentmeasurements [ binary, { " area ", " mask " } ] [ [ all, 2 ] ], first ] [ [ - 1, 2 ] ] ] 2. find the borders of the label next step : find the top / bottom / left / right borders using simple derivative convolution masks : topborder = deletesmallcomponents [ imageconvolve [ labelmask, { { 1 }


, { - 1 } } ] ] ; bottomborder = deletesmallcomponents [ imageconvolve [ labelmask, { { - 1 }, { 1 } } ] ] ; leftborder = deletesmallcomponents [ imageconvolve [ labelmask, { { 1, - 1 } } ] ] ; rightborder = deletesmallcomponents [ imageconvolve [ labelmask, { { - 1, 1 } } ] ] ; this is a little helper function that finds all white pixels in one of these four images and converts the indices to coordinates ( position returns indices, and indices are 1 - based { y, x } - tuples, where y = 1 is at the top of the image. but all the image processing functions expect coordinates, which are 0 - based { x, y } - tuples, where y = 0 is the bottom of the image ) : { w, h } = imagedimensions [ topborder ] ; masktopoints = function [ mask, { # [ [ 2 ] ] - 1, h - # [ [ 1 ] ] + 1 } & / @ position [ imagedata [ mask ], 1. ] ] ; 3. find a mapping from image to cylinder coordinates now i have four separate lists of coordinates of the top, bottom, left, right borders of the label. i define a mapping from image coordinates to cylinder coordinates : arcsinseries = normal [ series [ arcsin [ \ [ alpha ] ], { \ [ alpha ], 0, 10 } ] ] clear [ mapping ] ; mapping [ { x _, y _ } ] : = { c1 + c2 * ( arcsinseries /. \ [ alpha ] - > ( x - cx ) / r ) + c3 * y + c4 * x * y, top + y * height + tilt1 * sqrt [ clip [ r ^ 2 - ( x - cx ) ^ 2, { 0. 01, \ [ infinity ] } ] ] + tilt2 * y * sqrt [ clip [ r ^ 2 - ( x - cx ) ^ 2, { 0. 01, \ [ infinity ] } ] ] } this is a cylindrical mapping, that maps x / y - coordinates in the source image to cylindrical coordinates. the mapping has 10 degrees of freedom for height / radius / center / perspective / tilt. i used the taylor series


to approximate the arc sine, because i couldn't get the optimization working with arcsin directly. the clip calls are my ad - hoc attempt to prevent complex numbers during the optimization. there's a trade - off here : on the one hand, the function should be as close to an exact cylindrical mapping as possible, to give the lowest possible distortion. on the other hand, if it's to complicated, it gets much harder to find optimal values for the degrees of freedom automatically. ( the nice thing about doing image processing with mathematica is that you can play around with mathematical models like this very easily, introduce additional terms for different distortions and use the same optimization functions to get final results. i've never been able to do anything like that using opencv or matlab. but i never tried the symbolic toolbox for matlab, maybe that makes it more useful. ) next i define an " error function " that measures the quality of a image - > cylinder coordinate mapping. it's just the sum of squared errors for the border pixels : errorfunction = flatten [ { ( mapping [ # ] [ [ 1 ] ] ) ^ 2 & / @ masktopoints [ leftborder ], ( mapping [ # ] [ [ 1 ] ] - 1 ) ^ 2 & / @ masktopoints [ rightborder ], ( mapping [ # ] [ [ 2 ] ] - 1 ) ^ 2 & / @ masktopoints [ topborder ], ( mapping [ # ] [ [ 2 ] ] ) ^ 2 & / @ masktopoints [ bottomborder ] } ] ; this error function measures the " quality " of a mapping : it's lowest if the points on the left border are mapped to ( 0 / [ anything ] ), pixels on the top border are mapped to ( [ anything ] / 0 ) and so on. now i can tell mathematica to find coefficients that minimize this error function. i can make " educated guesses " about some of the coefficients ( e. g. the radius and center of the jar in the image ). i use these as starting points of the optimization : leftmean = mean [ masktopoints [ leftborder ] ] [ [ 1 ] ] ; rightmean = mean [ masktopoints [ rightborder ] ] [ [ 1 ] ] ; topmean = mean [ masktopoints [ topborder ] ] [ [ 2 ] ] ; bottom


##mean = mean [ masktopoints [ bottomborder ] ] [ [ 2 ] ] ; solution = findminimum [ total [ errorfunction ], { { c1, 0 }, { c2, rightmean - leftmean }, { c3, 0 }, { c4, 0 }, { cx, ( leftmean + rightmean ) / 2 }, { top, topmean }, { r, rightmean - leftmean }, { height, bottommean - topmean }, { tilt1, 0 }, { tilt2, 0 } } ] [ [ 2 ] ] findminimum finds values for the 10 degrees of freedom of my mapping function that minimize the error function. combine the generic mapping and this solution and i get a mapping from x / y image coordinates, that fits the label area. i can visualize this mapping using mathematica's contourplot function : show [ src, contourplot [ mapping [ { x, y } ] [ [ 1 ] ] /. solution, { x, 0, w }, { y, 0, h }, contourshading - > none, contourstyle - > red, contours - > range [ 0, 1, 0. 1 ], regionfunction - > function [ { x, y }, 0 < = ( mapping [ { x, y } ] [ [ 2 ] ] /. solution ) < = 1 ] ], contourplot [ mapping [ { x, y } ] [ [ 2 ] ] /. solution, { x, 0, w }, { y, 0, h }, contourshading - > none, contourstyle - > red, contours - > range [ 0, 1, 0. 2 ], regionfunction - > function [ { x, y }, 0 < = ( mapping [ { x, y } ] [ [ 1 ] ] /. solution ) < = 1 ] ] ] 4. transform the image finally, i use mathematica's imageforwardtransform function to distort the image according to this mapping : imageforwardtransformation [ src, mapping [ # ] /. solution &, { 400, 300 }, datarange - > full, plotrange - > { { 0, 1 }, { 0, 1 } } ] that gives the


results as shown above. manually assisted version the algorithm above is full - automatic. no adjustments required. it works reasonably well as long as the picture is taken from above or below. but if it's a frontal shot, the radius of the jar can not be estimated from the shape of the label. in these cases, i get much better results if i let the user enter the left / right borders of the jar manually, and set the corresponding degrees of freedom in the mapping explicitly. this code lets the user select the left / right borders : locatorpane [ dynamic [ { { xleft, y1 }, { xright, y2 } } ], dynamic [ show [ src, graphics [ { red, line [ { { xleft, 0 }, { xleft, h } } ], line [ { { xright, 0 }, { xright, h } } ] } ] ] ] ] this is the alternative optimization code, where the center & radius are given explicitly. manualadjustments = { cx - > ( xleft + xright ) / 2, r - > ( xright - xleft ) / 2 } ; solution = findminimum [ total [ minimize /. manualadjustments ], { { c1, 0 }, { c2, rightmean - leftmean }, { c3, 0 }, { c4, 0 }, { top, topmean }, { height, bottommean - topmean }, { tilt1, 0 }, { tilt2, 0 } } ] [ [ 2 ] ] solution = join [ solution, manualadjustments ]


i found a good way of thinking intuitively of kalman gain $ k $. if you write $ k $ this way $ \ displaystyle \ quad \ \ bf { k _ k } = \ bf { p _ k ^ - \, h _ k ^ { \ rm t } ( h _ k p _ k ^ - \, h _ k ^ { \ rm t } + r _ k ) ^ { - 1 } } = \ bf { \ frac { p _ k ^ - \, h _ k ^ { \ rm t } } { h _ k p _ k ^ - \, h _ k ^ { \ rm t } + r _ k } } $ you will realize that the relative magnitudes of matrices ( $ r _ k $ ) and ( $ p _ k $ ) control a relation between the filter's use of predicted state estimate ( $ x _ { k } ⁻ $ ) and measurement ( $ y _ k $ ). $ \ displaystyle \ quad \ \ lim \ limits _ { \ bf { r _ k \ to 0 } } \ bf { { p _ k ^ - \, h _ k ^ { \ rm t } } \ over \ { h _ k p _ k ^ - \, h _ k ^ { \ rm t } + r _ k } } \ = \ bf { h _ k ^ { - 1 } } $ $ \ displaystyle \ quad \ \ lim \ limits _ { \ bf { p _ k \ to 0 } } \ bf { { p _ k ^ - \, h _ k ^ { \ rm t } } \ over \ { h _ k p _ k ^ - \, h _ k ^ { \ rm t } + r _ k } } \ = \ bf 0 $ substituting the first limit into the measurement update equation $ \ displaystyle \ quad \ \ bf { \ hat x _ k } = \ bf { x _ k ^ - } + \ bf { k _ k } ( \ bf { \ tilde y _ k } - \ bf { h _ k } \ bf { x _ k ^ - } ) $ suggests that when the magnitude of $ r $ is small, meaning that the measurements are accurate, the state estimate depends mostly on the measurements. when the state is known accurately, then $ h p ^ ⁻ h ^ t $ is small compared to $ r $, and the filter mostly ignores the measurements relying instead on the prediction derived from the previous


state ( $ x _ k⁻ $ ).


it's for on - the - go, to select which device is the host or slave : the otg cable has a micro - a plug on one side, and a micro - b plug on the other ( it cannot have two plugs of the same type ). otg adds a fifth pin to the standard usb connector, called the id - pin ; the micro - a plug has the id pin grounded, while the id in the micro - b plug is floating. the device that has a micro - a plugged in becomes an otg a - device, and the one that has micro - b plugged becomes a b - device. the type of the plug inserted is detected by the state of the pin id.


i found this page answers your question clearly. i quote the relevant parts below. the bc1. 2 outlines three distinct types of usb port and two key monikers. a " charging " port is one that delivers currents higher than 500ma. a " downstream " port signals data as per usb 2. 0. the bc1. 2 specification also establishes both how each port should appear to the end device, and the protocol to identify what type of port is implemented. the three usb bc1. 2 port types are sdp, dcp, and cdp ( see figure 1 ) : standard downstream port ( sdp ) this port features 15kω pulldown resistors on both the d + and d - lines. the current limits are those discussed above : 2. 5ma when suspended, 100ma when connected, and 500ma when connected and configured for higher power. dedicated charging port ( dcp ) this port does not support any data transfer, but is capable of supplying charge currents beyond 1. 5a. it features a short between the d + and d - lines. this type of port allows for wall chargers and car chargers with high - charge capability without the need for enumeration. downstream port ( cdp ) this port allows for both high - current charging and data transfer fully compliant with usb 2. 0. it features the 15kω pulldown resistors necessary for the d + and d - communication, and also has internal circuitry that is switched in during the charger detection phase. this internal circuitry allows the portable device to distinguish a cdp from other port types. even with the bc1. 2 specification available, some electronics manufacturers develop custom protocols for their dedicated chargers. when you attach one of their devices to a fully compliant bc1. 2 charging port, you may still get the error message, " charging is not supported with this accessory. " despite this message, these devices may still charge, but the charge currents can be extremely small. fortunately, almost all of these proprietary dedicated chargers identify themselves by a dc level set on the d + and d - lines by a resistor - divider between 5v and ground added comment : one might consider data signal levels are 0. 0 – 0. 3 v for logical low, and 2. 8 – 3. 6 v for logical high. without a voltage dividing network to two shorted data pins, the voltage on them is free to float. even though twisted data wires providing some shielding from stray electromagnetic signals, they can still potentially induce unpredictable voltages on the


line. on the other hand, a voltage dividing network clamps the voltage at a safe 2. 5v. for more details, check out the page i sourced or take a look at usb. org's pdf describing the usb battery charging bc 1. 2 specification


let me first answer why i think c + + interfaces to mpi have generally not been overly successful, having thought about the issue for a good long time when trying to decide whether we should just use the standard c bindings of mpi or building on something at higher level : when you look at real - world mpi codes ( say, petsc, or in my case deal. ii ), one finds that maybe surprisingly, the number of mpi calls isn't actually very large. for example, in the 500k lines of deal. ii, there are only ~ 100 mpi calls. a consequence of this is that the pain involved in using lower - level interfaces such as the mpi c bindings, is not too large. conversely, one would not gain all that much by using higher level interfaces. my second observation is that many systems have multiple mpi libraries installed ( different mpi implementations, or different versions ). this poses a significant difficulty if you wanted to use, say, boost : : mpi that don't just consist of header files : either there needs to be multiple installations of this package as well, or one needs to build it as part of the project that uses boost : : mpi ( but that's a problem in itself again, given that boost uses its own build system, which is unlike anything else ). so i think all of this has conspired against the current crop of c + + interfaces to mpi : the old mpi c + + bindings didn't offer any advantage, and external packages had difficulties with the real world. this all said, here's what i think would be the killer features i would like to have from a higher - level interface : it should be generic. having to specify the data type of a variable is decidedly not c + + - like. of course, it also leads to errors. elemental's mpimap class would already be a nice first step ( though i can't figure out why the heck the mpimap : : type variable isn't static const, so that it can be accessed without creating an object ). it should have facilities for streaming arbitrary data types. operations that require an mpi _ op argument ( e. g., reductions ) should integrate nicely with c + +'s std : : function interface, so that it's easy to just pass a function pointer ( or a lambda! ) rather than having to clumsily register something. boost : : mpi


actually satisfies all of these. i think if it were a header - only library, it'd be a lot more popular in practice. it would also help if it supported post - mpi 1. 0 functions, but let's be honest : this covers most of what we need most of the time.


the simple answer is that unlike rgb, hsv separates luma, or the image intensity, from chroma or the color information. this is very useful in many applications. for example, if you want to do histogram equalization of a color image, you probably want to do that only on the intensity component, and leave the color components alone. otherwise you will get very strange colors. in computer vision you often want to separate color components from intensity for various reasons, such as robustness to lighting changes, or removing shadows. note, however, that hsv is one of many color spaces that separate color from intensity ( see ycbcr, lab, etc. ). hsv is often used simply because the code for converting between rgb and hsv is widely available and can also be easily implemented. for example, the image processing toolbox for matlab includes functions rgb2hsv and hsv2rgb.


i'm not entirely familiar with what's now done for cubatures ( multidimensional integration ), so i'll restrict myself to quadrature formulae. there are a number of effective methods for the quadrature of oscillatory integrals. there are methods suited for finite oscillatory integrals, and there are methods for infinite oscillatory integrals. for infinite oscillatory integrals, two of the more effective methods used are longman's method and the modified double exponential quadrature due to ooura and mori. ( but see also these two papers by arieh iserles. ) longman's method relies on converting the oscillatory integral into an alternating series by splitting the integration interval, and then summing the alternating series with a sequence transformation method. for instance, when integrating an oscillatory integral of the form $ $ \ int _ 0 ^ \ infty f ( t ) \ sin \, t \ mathrm dt $ $ one converts this into the alternating sum $ $ \ sum _ { k = 0 } ^ \ infty \ int _ { k \ pi } ^ { ( k + 1 ) \ pi } f ( t ) \ sin \, t \ mathrm dt $ $ the terms of this alternating sum are computed with some quadrature method like romberg's scheme or gaussian quadrature. longman's original method used the euler transformation, but modern implementations replace euler with more powerful convergence acceleration methods like the shanks transformation or the levin transformation. the double exponential quadrature method, on the other hand, makes a clever change of variables, and then uses the trapezoidal rule to numerically evaluate the transformed integral. for finite oscillatory integrals, piessens ( one of the contributors of quadpack ) and branders, in two papers, detail a modification of clenshaw - curtis quadrature ( that is, constructing an chebyshev polynomial expansion of the nonoscillatory part of the integrand ). levin's method, on the other hand, uses a collocation method for the quadrature. ( i am told there is now a more practical version of the old standby, filon's method, but i've no experience with it. ) these are the methods i remember offhand ; i'm sure i've forgotten other good methods for osci


##llatory integrals. i will edit this answer later if i remember them.


understanding why this works turns out to be quite deep. this answer is kind of a long story, but there's no maths. at the end ('a more formal approach') there is an outline of how the maths works : skip to that if you don't want the story. insect geometry consider a little insect or something who lives on the surface of the paper. this insect can't see off the paper, but it can draw straight lines and measure angles on the paper. how does it draw straight lines? well it does it in two ways : either it takes two points, draws lines between them on the paper, and finds the shortest line between them, which it calls'straight'; or alternatively it draws a line in such a way that it is parallel to itself and calls this'straight '. there is a geometrical trick for constructing such'parallel - to - themselves'lines which i won't go into. and it turns out that these two sorts of lines are the same. i'm not sure how it measures angles : perhaps it has a little protractor. so now our insect can do geometry. it can draw various triangles on the paper, and it can measure the angles at the corners of these triangles. and it's always going to find that the angles add up to $ \ pi $ ( $ 180 ^ \ circ $ ), of course. you can do this too, and check the insect's results, and many people do just this at school. the insect ( let's call it'euclid') can develop an entire system of geometry on its sheet of paper, in fact. other insect artists will make pictures and sculptures of it, and the book on geometry it writes will be used in insect schools for thousands of years. in particular the insect can construct shapes out of straight lines and measure the areas inside them and develop a bunch of rules for this : rectangles have areas which are equal to $ w \ times h $ for instance. i didn't specify something above : i didn't tell you if the paper was lying flat on a desk, or if it was curved in your hand. that's because it does not matter to the insect : the insect can't tell whether we think the paper is curved, or whether we think it's flat : the lines and angles it measures are exactly the same. and that's because, in a real sense, the insect is right and we're


wrong : the paper is flat, even when we think it's curved. what i mean by this is that there is no measurement you can do, on the surface of the paper which will tell you if it is'curved'or'flat '. so now shake the paper, and cause one of the insects to fall off and land on a tomato. this insect starts doing its geometry on the surface of the tomato, and it finds something quite shocking : on a small scale everything looks ok, but when it starts trying to construct large figures things go horribly wrong : the angles in its triangles add up to more than $ \ pi $. lines which start parallel, extended far enough, meet twice, and there is in fact no global notion of parallelism at all. and when it measures the area inside shapes, it finds it is always more than it thinks it should be : somehow there is more tomato inside the shapes than there is paper. the tomato, in fact, is curved : without ever leaving the surface of the tomato the insect can know that the surface is somehow deformed. eventually it can develop a whole theory of tomato geometry, and later some really smart insects with names like'gauss'and'riemann'will develop a theory which allows them to describe the geometry of curved surfaces in general : tomatoes, pears and so on. intrinsic & extrinsic curvature to be really precise, we talk about the sheet of paper being'intrinsically flat'and the surface of the tomato being'intrinsically curved': what this means is just that, by doing measurements on the surface alone we can tell if the rules of euclidean geometry hold or not. there is another sort of curvature which is extrinsic curvature : this is the kind of curvature which you can measure only by considering an object as being embedded into some higher - dimensional space. so in the case of sheets of paper, the surfaces of these are two dimensional objects embedded in the three dimensional space where we live. and we can tell whether these surfaces are extrinsically curved by constructing normal vectors to the surfaces and checking whether they all point in the same direction. but the insects can't do this : they can only measure intrinsic curvature. and, critically, something can be extrinsically curved while being intrinsically flat. ( the converse is not true, at least in the case of paper : if it's intrinsically curved it's extrinsically curved as well. ) stretching & compressing there's


a critical thing about the difference between intrinsically flat and intrinsically curved surfaces which i've mentioned in passing above : the area inside shapes is different. what this means is that the surface is stretched or compressed : in the case of the tomato there is more area inside triangles than there is for flat paper. what this means is that, if you want to take an intrinsically flat object and deform it so that it is intrinsically curved, you need to stretch or compress parts of it : if we wanted to take a sheet of paper and curve it over the surface of a sphere, then we would need to stretch & compress it : there is no other way to do it. that's not true for extrinsic curvature : if i take a bit of paper and roll it into a cylinder, say, the surface of the paper is not stretched or compressed at all. ( in fact, it is a bit because paper is actually a thin three - dimensional object, but ideal two - dimensional paper is not. ) why curving paper makes it rigid finally i can answer the question. paper is pretty resistant to stretching & compressing : if you try and stretch a ( dry ) sheet of paper it will tear before it has streched really at all, and if you try and compress it it will fold up in some awful way but not compress. but paper is really thin so it is not very resistant to bending ( because bending it only stretches it a tiny tiny bit, and for our ideal two dimensional paper, it doesn't stretch it at all ). what this means is that it's easy to curve paper extrinsically but very hard to curve it intrinsically. and now i will wave my hands a bit : if you curve paper into a'u'shape as you have done, then you are curving it only extrinsically : it's still intrinsically flat. so it doesn't mind this, at all. but if it starts curving in the other direction as well, then it will have to curve intrinsically : it will have to stretch or compress. it's easy to see this just be looking at the paper : when it's curved into a'u'then to curve it in the other direction either the top of the'u'is going to need to stretch or the bottom is going to need to compress. and this is why curving paper like that makes it rigid : it'uses up'the ability to extri


##nsically curve the paper so that any further extrinsic curvature involves intrinsic curvature too, which paper does not like to do. why all this is important as i said at the start, this is quite a deep question. the mathematics behind this is absolutely fascinating and beautiful while being relatively easy to understand once you have seen it. if you understand it you get some kind of insight into how the minds of people like gauss worked, which is just lovely. the mathematics and physics behind it turns out to be some of the maths that you need to understand general relativity, which is a theory all about curvature. so by understanding this properly you are starting on the path to understanding the most beautiful and profound theory of modern physics ( i was going to write'one of the most...'but no : there's gr and there's everything else ). the mathematics and physics behind it also is important in things like engineering : if you want to understand why beams are strong, or why car panels are rigid you need to understand this stuff. and finally it's the same maths : the maths you need to understand various engineered structures is pretty close to the maths you need to understand gr : how cool is that? a more formal approach : a remarkable theorem the last section above involved some handwaving : the way to make it less handwavy is due to the wonderful theorema egregium ('remarkable theorem') due to gauss. i don't want to go into the complete detail of this ( in fact, i'm probably not up to it any more ), but the trick you do is, for a two dimensional surface you can construct the normal vector $ \ vec { n } $ in three dimensions ( the vector pointing out of the surface ), and you can consider how this vector changes direction ( in three dimensions ) as you move it along various curves on the surface. at any point in the surface there are two curves which pass through it : one on which the vector is changing direction fastest along the curve, and one along which is changing direction slowest ( this follows basically from continuity ). we can construct a number, $ r $ which describes how fast the vector is changing direction along a curve ( i've completely forgotten how to do that, but i think it's straightforward ), and for these two maximum & minimum curves we can call the two rates $ r _ 1 $ and $ r _ 2 $. $ r _ 1 $ & $


r _ 2 $ are called the two principal curvatures of the surface. then the quantity $ k = r _ 1r _ 2 $ is called the gaussian curvature of the surface, and the theorema egregium says that this quantity is intrinsic to the surface : you can measure it just by measuring angles et cetera on the surface. the reason the theorem is remarkable is that the whole definition of $ k $ involved things which are extrinsic to the surface, in particular the two principal curvatures. because $ k $ is intrinsic, our insects can measure it! euclidean geometry is true ( in particular the parallel postulate is true ) for surfaces where $ k = 0 $ only. and we can now be a bit more precise about the whole'stretching & compressing'thing i talked about above. if we're not allowed to stretch & compress the sheet of paper, then all the things we are allowed to do to it don't alter any measurement that the insects can do : lengths or angles which are intrinsic, that is to say measured entirely in the surface of the paper, can't change unless you stretch or compress the paper. changes to the paper which preserve these intrinsic properties are called isometries. and since $ k $ is intrinsic it is not altered by isometries. now consider a sheet of paper which is flat in three dimensions. it's obvious that $ r _ 1 = r _ 2 = 0 $ ( the normal vector always points in the same direction ). so $ k = 0 $. now fold the paper in a'u'shape : now it's clear that $ r _ 1 \ ne 0 $ - - if you draw a curve across the valley in the paper then the normal vector from that curve changes direction. but this folding is an isometry : we didn't stretch or compress the paper. so $ k $ must still be $ 0 $ : the paper is still intrinsically flat. but since $ k = r _ 1r _ 2 $ and $ r _ 1 \ ne 0 $ this means that $ r _ 2 = 0 $. and what this means is that the other principal curvature must be zero. this principal curvature is along the line that goes down the valley of the'u '. in other words the paper can't bend in the other direction without becoming intrinsically curved ( $ k \ ne 0 $ ), which means it needs to stretch. ( i have still handwaved a bit


here : i have not defined how you compute $ r $, and i've not shown that there is not some other curve you can draw along the paper which has $ r = 0 $ apart from the obvious one. ) one of the reasons that this is all quite interesting is that this maths is the beginning of the maths you need to understand general relativity, which also is about curvature. failure and folding of course, if you take the u - shaped bit of paper and try to bend it in the other direction at some point it will fail suddenly and become folded in some complicated way. i think there's a whole area of study which thinks about that. i suspect that when this happens ( during the sudden failure, not after it i think ) there must be, locally, non - zero intrinsic curvature at places on the paper. i'm sure there is a lot of interesting maths about this ( apart from anything else it must be very interesting for engineered structures ), but i don't know it.


the first rom devices had to have information placed in them via some mechanical, photolithographic, or other means ( before integrated circuits, it was common to use a grid where diodes could be selectively installed or omitted ). the first major improvement was a " fuse - prom " - - a chip containing a grid of fused diodes, and row - drive transistors that were sufficiently strong that selecting a row and forcing the state of the output one could blow the fuses on any diodes one didn't want. although such chips were electrically writable, most of the devices in which they would be used did not have the powerful drive circuitry necessary to write to them. instead, they would be written using a device called a " programmer ", and then installed in the equipment that needed to be able to read them. the next improvement was an implanted - charge memory device, which allowed charges to be electrically implanted but not removed. if such devices were packaged in uv - transparent packages ( eprom ), they could be erased with about 5 - 30 minutes'exposure to ultraviolet light. this made it possible to reuse devices whose contents were found not to be of value ( e. g. buggy or unfinished versions of software ). putting the same chips in an opaque package allowed them to be sold more inexpensively for end - user applications where it was unlikely anyone would want to erase and reuse them ( otprom ). a succeeding improvement made it possible to erase the devices electrically without the uv light ( early eeprom ). early eeprom devices could only be erased en masse, and programming required conditions very different from those associated with normal operation ; consequently, as with prom / eprom devices, they were generally used in circuitry which could read but not write them. later improvements to eeprom made it possible to erase smaller regions, if not individual bytes, and also allowed them to be written by the same circuitry that used them. nonetheless, the name did not change. when a technology called " flash rom " came on the scene, it was pretty normal for eeprom devices to allow individual bytes to be erased and rewritten within an application circuit. flash rom was in some sense a step back functionally since erasure could only take place in large chunks. nonetheless, restricting erasure to large chunks made it possible to store information much more compactly than had been possible with eeprom. further, many flash devices have faster write cycles but slower erase cycles than


would be typical of eeprom devices ( many eeprom devices would take 1 - 10ms to write a byte, and 5 - 50ms to erase ; flash devices would generally require less than 100us to write, but some required hundreds of milliseconds to erase ). i don't know that there's a clear dividing line between flash and eeprom, since some devices that called themselves " flash " could be erased on a per - byte basis. nonetheless, today's trend seems to be to use the term " eeprom " for devices with per - byte erase capabilities and " flash " for devices which only support large - block erasure.


to answer the question as asked, for people googling. for bed6, in python : # contigs. tsv contians chromosome names and lengths in two columns for line in open ( " contigs. tsv " ) : fields = line. strip ( ). split ( " \ t " ) print fields [ 0 ], ". ", " contig ", " 1 ", str ( fields [ 1 ] ), ". ", " + ", ". ", " id = % s " % fields [ 0 ] for line in open ( " my _ bed _ file. bed " ) : fields = line. strip ( ). split ( " \ t " ) # note : bed is 0 - based, half - open, gff is 1 - based, closed start = str ( int ( fields [ 1 ] ) + 1 ) print fields [ 0 ], " bed ", " interval ", fields [ 1 ], fields [ 2 ], fields [ 4 ], fields [ 5 ], ". ", " id = % s ; parent = % s " % ( fields [ 3 ], fields [ 0 ] ) for bed12, in python : # contigs. tsv contians chromosome names and lengths in two columns for line in open ( " contigs. tsv " ) : fields = line. strip ( ). split ( " \ t " ) print fields [ 0 ], ". ", " contig ", " 1 ", str ( fields [ 1 ] ), ". ", " + ", ". ", " id = % s " % fields [ 0 ] for line in open ( " my _ bed12. bed " ) : fields = line. strip ( ). split ( " \ t " ) contig = fields [ 0 ] # note : bed is 0 - based, half - open, gff is 1 - based, closed start = int ( fields [ 1 ] ) + 1 ) end = fields [ 2 ] name = fields [ 3 ] score = fields [ 4 ] strand = fields [ 5 ] print contig, " bed ", " interval ", str ( start ), end, score, strand, ". ", " id = % s ; parent = % s " % ( name, contig ) block _ starts = map ( int, fields [ 11 ]. split ( ",


" ) ) block _ sizes = map ( int, fields [ 10 ]. split ( ", " ) ) for ( block, ( bstart, blen ) ) in enumerate ( zip ( block _ starts, block _ sizes ) ) : bend = start + bstart + blen print contig, " bed ", " block ", str ( start + bstart ), str ( bend ), score, strand, ". ", " id = % s _ % i ; parent = % s " % ( name, block, name )


i'd say the most well known barriers to solving $ p = np $ are relativization ( as mentioned by ran g. ) natural proofs - under certain cryptographic assumptions, rudich and razborov proved that we cannot prove $ p \ neq np $ using a class of proofs called natural proofs. algebrization - by scott aaronson and avi wigderson. they prove that proofs that algebrize cannot separate $ p $ and $ np $ another one i'm familiar with is the result that no lp formulation can solve tsp ( it was proved by yannakakis for symmetric lps and very recently extended to general lps ). here is a blog post discussing the result.


your example makes me think of graphs. imagine some nice, helpful fellow came along, and made a big graph of every math concept ever, where each concept is one node and related concepts are connected by edges. now you can take a copy of this graph, and color every node green based on whether you " know " that concept ( unknowns can be grey ). how to define " know "? in this case, when somebody mentions that concept while talking about something, do you immediately feel confused and get the urge to look the concept up? if no, then you know it ( funnily enough, you may be deluding yourself into thinking you know something that you completely misunderstand, and it would be classed as " knowing " based on this rule - but that's fine and i'll explain why in a bit ). for purposes of determining whether you " know " it, try to assume that the particular thing the person is talking about isn't some intricate argument that hinges on obscure details of the concept or bizarre interpretations - it's just mentioned matter - of - factly, as a tangential remark. when you are studying a topic, you are basically picking one grey node and trying to color it green. but you may discover that to do this, you must color some adjacent grey nodes first. so the moment you discover a prerequisite node, you go to color it right away, and put your original topic on hold. but this node also has prerequisites, so you put it on hold, and... what you are doing is known as a depth first search. it's natural for it to feel like a rabbit hole - you are trying to go as deep as possible. the hope is that sooner or later you will run into a wall of greens, which is when your long, arduous search will have born fruit, and you will get to feel that unique rush of climbing back up the stack with your little jewel of recursion terminating return value. then you get back to coloring your original node and find out about the other prerequisite, so now you can do it all over again. dfs is suited for some applications, but it is bad for others. if your goal is to color the whole graph ( ie. learn all of math ), any strategy will have you visit the same number of nodes, so it doesn't matter as much. but if you are not seriously attempting to learn everything right now, dfs is not the best


choice. so, the solution to your problem is straightforward - use a more appropriate search algorithm! immediately obvious is breadth - first search. this means, when reading an article ( or page, or book chapter ), don't rush off to look up every new term as soon as you see it. circle it or make a note of it on a separate paper, but force yourself to finish your text even if its completely incomprehensible to you without knowing the new term. you will now have a list of prerequisite nodes, and can deal with them in a more organized manner. compared to your dfs, this already makes it much easier to avoid straying too far from your original area of interest. it also has another benefit which is not common in actual graph problems : often in math, and in general, understanding is cooperative. if you have a concept a which has prerequisite concept b and c, you may find that b is very difficult to understand ( it leads down a deep rabbit hole ), but only if you don't yet know the very easy topic c, which if you do, make b very easy to " get " because you quickly figure out the salient and relevant points ( or it may be turn out that knowing either b or c is sufficient to learn a ). in this case, you really don't want to have a learning strategy which will not make sure you do c before b! bfs not only allows you to exploit cooperativities, but it also allows you to manage your time better. after your first pass, let's say you ended up with a list of 30 topics you need to learn first. they won't all be equally hard. maybe 10 will take you 5 minutes of skimming wikipedia to figure out. maybe another 10 are so simple, that the first google image diagram explains everything. then there will be 1 or 2 which will take days or even months of work. you don't want to get tripped up on the big ones while you have the small ones to take care of. after all, it may turn out that the big topic is not essential, but the small topic is. if that's the case, you would feel very silly if you tried to tackle the big topic first! but if the small one proves useless, you haven't really lost much energy or time. once you're doing bfs, you might as well benefit from the other, very nice and clever twists on it, such as di


##jkstra or a *. when you have the list of topics, can you order them by how promising they seem? chances are you can, and chances are, your intuition will be right. another thing to do - since ultimately, your aim is to link up with some green nodes, why not try to prioritize topics which seem like they would be getting closer to things you do know? the beauty of a * is that these heuristics don't even have to be very correct - even " wrong " or " unrealistic " heuristics may end up making your search faster.


nope. alcohols consist of an - $ \ ce { oh } $ group bonded to a saturated carbon ( $ \ mathrm { sp ^ 3 } $ hybridized, no multiple bonds ). iupac says : alcohols compounds in which a hydroxy group, - $ \ ce { oh } $, is attached to a saturated carbon atom $ \ ce { r3coh } $. the term'hydroxyl'refers to the radical species, $ \ ce { ho ^. } $. and phenols compounds having one or more hydroxy groups attached to a benzene or other arene ring, e. g., 2 - naphthol : ( source : iupac. org ) a phenol consists of an - $ \ ce { oh } $ bonded to an unsaturated $ \ mathrm { sp ^ 2 } $ carbon. thus, it does not qualify as an alcohol. one can classify it as an enol, though. really, to me, the classification doesn't matter. classifications are artificial, what is important is, how well the properties fit in the classification. many of the alcohol properties depend upon : its unsaturated nature : oxidation to ketone / aldehyde / acid the weaker $ \ ce { r - o } $ bond and its ability to easily break and form an $ \ ce { r + } $ cation ( this makes it a good participant in $ \ mathrm { s _ n1 } $ reactions ) phenol can obviously not be oxidised at the $ \ ce { oh } $ to a ketone / acid ( though one can do stuff to make it into a quinone ). phenylic carbocations are unstable, thus we don't get any $ \ mathrm { s _ n1 } $ reactions, and the $ \ ce { ph - o } $ bond stays put. on the other hand, most of the reactions of phenol depend upon its aromatic phenyl ring : all the eas reactions weaker $ \ ce { o - h } $ bond ( i. e., acidic nature ) : reimer - tiemann reaction, etc. thus phenols and alcohols don't have too many reactions in common. so, in this case, they have been classified in a sensible manner - - if phenols were classified as alcohols, we would basically be clubbing two radically different classes of compounds under one umbrella


see ( sorry, i would have put that in a comment but i've registered just to post this so i can't post comments yet ). but since i'm writing it as an answer, i'll also write the method : $ $ e = \ frac { m _ { 00 } + m _ { 11 } } { 2 } ; f = \ frac { m _ { 00 } - m _ { 11 } } { 2 } ; g = \ frac { m _ { 10 } + m _ { 01 } } { 2 } ; h = \ frac { m _ { 10 } - m _ { 01 } } { 2 } \ \ q = \ sqrt { e ^ 2 + h ^ 2 } ; r = \ sqrt { f ^ 2 + g ^ 2 } \ \ s _ x = q + r ; s _ y = q - r \ \ a _ 1 = \ mathrm { atan2 } ( g, f ) ; a _ 2 = \ mathrm { atan2 } ( h, e ) \ \ \ theta = \ frac { a _ 2 - a _ 1 } { 2 } ; \ phi = \ frac { a _ 2 + a _ 1 } { 2 } $ $ that decomposes the matrix as follows : $ $ m = \ pmatrix { m _ { 00 } & m _ { 01 } \ \ m _ { 10 } & m _ { 11 } } = \ pmatrix { \ cos \ phi & - \ sin \ phi \ \ \ sin \ phi & \ cos \ phi } \ pmatrix { s _ x & 0 \ \ 0 & s _ y } \ pmatrix { \ cos \ theta & - \ sin \ theta \ \ \ sin \ theta & \ cos \ theta } $ $ the only thing to guard against with this method is that $ g = f = 0 $ or $ h = e = 0 $ for atan2. i doubt it can be any more robust than that ( update : see alex eftimiades'answer! ). the reference is : ( given by rahul there ) which comes from the bottom of this blog post : update : as noted by @ victorliu in a comment, $ s _ y $ may be negative. that happens if and only if the determinant of the input matrix is negative as well. if that's the case and you


want the positive singular values, just take the absolute value of $ s _ y $.


elephant, rhinoceros, & c all have much thicker legs in proportion. the answer, i think, lies in the fact that the animals you mention all evolved as cursorial animals ( that is, they run to escape predators ). less mass in the lower leg means it swings easier, so the animal can run faster. there are two things you're apparently not noticing in that picture. first, the the horse's lower leg is almost entirely bone ( and some tendon ), and it's bone that does the supporting. the propulsive power comes from the large muscles of the hip, thighs, and shoulders. second, the lower part of the leg ( with the white wrappings ) is not anatomically equivalent to the human's lower leg, but to the bones of the hand and foot. you can see this if you look closely at the rear leg in that picture. the femur, equivalent to the human's thigh, ends at the knee just above the belly line. then the tibia extends about halfway down, ending at another joint which you might think is the knee, but which is called the'hock'in horse - speak. the white - wrapped part is a metatarsal, equivalent to human foot bones, then there pastern bones equivalent to human toe bones, ending in the hoof / toenail. so consider that you can, if reasonably fit, walk around on tiptoe without crushing your foot and toe bones, then imagine the end result of your ancestors having done this for the last several tens of millions of years : - ) ps : with horses, there is some effect from human selection, too. racing & show breeds tend to have thin lower legs, draft horses & working breeds have proportionately thicker ones. my first horse, a thorobred / arab mix, had legs about as thick as my wrists ( granted, i'm a fairly muscular guy ) ; my current mustang, about the same height & weight, has legs about twice as thick.


the important thing when choosing iterative solvers is the spectrum of the operator, see this paper. however, there are so many negative results, see this paper where no iterative solver wins for all problems and this paper in which they prove they can get any convergence curve for gmres for any spectrum. thus, it seems impossible to predict the behavior of iterative solvers except in a few isolated cases, therefore, your best option is to try them all, using a system like petsc, which also has direct solvers.


translating code to mathematics given a ( more or less ) formal operational semantics you can translate an algorithm's ( pseudo - ) code quite literally into a mathematical expression that gives you the result, provided you can manipulate the expression into a useful form. this works well for additive cost measures such as number of comparisons, swaps, statements, memory accesses, cycles some abstract machine needs, and so on. example : comparisons in bubblesort consider this algorithm that sorts a given array a : bubblesort ( a ) do 1 n = a. length ; 2 for ( i = 0 to n - 2 ) do 3 for ( j = 0 to n - i - 2 ) do 4 if ( a [ j ] > a [ j + 1 ] ) then 5 tmp = a [ j ] ; 6 a [ j ] = a [ j + 1 ] ; 7 a [ j + 1 ] = tmp ; 8 end 9 end 10 end 11 end 12 let's say we want to perform the usual sorting algorithm analysis, that is count the number of element comparisons ( line 5 ). we note immediately that this quantity does not depend on the content of array a, only on its length $ n $. so we can translate the ( nested ) for - loops quite literally into ( nested ) sums ; the loop variable becomes the summation variable and the range carries over. we get : $ \ qquad \ displaystyle c _ { \ text { cmp } } ( n ) = \ sum _ { i = 0 } ^ { n - 2 } \ sum _ { j = 0 } ^ { n - i - 2 } 1 = \ dots = \ frac { n ( n - 1 ) } { 2 } = \ binom { n } { 2 } $, where $ 1 $ is the cost for each execution of line 5 ( which we count ). example : swaps in bubblesort i'll denote by $ p _ { i, j } $ the subprogram that consists of lines i to j and by $ c _ { i, j } $ the costs for executing this subprogram ( once ). now let's say we want to count swaps, that is how often $ p _ { 6, 8 } $ is executed. this is a " basic block ", that is a subprogram that is always executed atomically and has some constant cost ( here, $ 1 $ ). contracting such blocks is one useful simplification that we


often apply without thinking or talking about it. with a similar translation as above we come to the following formula : $ \ qquad \ displaystyle c _ { \ text { swaps } } ( a ) = \ sum _ { i = 0 } ^ { n - 2 } \ sum _ { j = 0 } ^ { n - i - 2 } c _ { 5, 9 } ( a ^ { ( i, j ) } ) $. $ a ^ { ( i, j ) } $ denotes the array's state before the $ ( i, j ) $ - th iteration of $ p _ { 5, 9 } $. note that i use $ a $ instead of $ n $ as parameter ; we'll soon see why. i don't add $ i $ and $ j $ as parameters of $ c _ { 5, 9 } $ since the costs do not depend on them here ( in the uniform cost model, that is ) ; in general, they just might. clearly, the costs of $ p _ { 5, 9 } $ depend on the content of $ a $ ( the values a [ j ] and a [ j + 1 ], specifically ) so we have to account for that. now we face a challenge : how do we " unwrap " $ c _ { 5, 9 } $? well, we can make the dependency on the content of $ a $ explicit : $ \ qquad \ displaystyle c _ { 5, 9 } ( a ^ { ( i, j ) } ) = c _ 5 ( a ^ { ( i, j ) } ) + \ begin { cases } 1 &, \ mathtt { a ^ { ( i, j ) } [ j ] > a ^ { ( i, j ) } [ j + 1 ] } \ \ 0 &, \ text { else } \ end { cases } $. for any given input array, these costs are well - defined, but we want a more general statement ; we need to make stronger assumptions. let us investigate three typical cases. the worst case just from looking at the sum and noting that $ c _ { 5, 9 } ( a ^ { ( i, j ) } ) \ in \ { 0, 1 \ } $, we can find a trivial upper bound for cost : $ \ qquad \ displaystyle c _ { \ text { swaps } } ( a ) \ leq \ sum _ { i = 0 }


^ { n - 2 } \ sum _ { j = 0 } ^ { n - i - 2 } 1 = \ frac { n ( n - 1 ) } { 2 } = \ binom { n } { 2 } $. but can this happen, i. e. is there an $ a $ for this upper bound is attained? as it turns out, yes : if we input an inversely sorted array of pairwise distinct elements, every iteration must perform a swap¹. therefore, we have derived the exact worst - case number of swaps of bubblesort. the best case conversely, there is a trivial lower bound : $ \ qquad \ displaystyle c _ { \ text { swaps } } ( a ) \ geq \ sum _ { i = 0 } ^ { n - 2 } \ sum _ { j = 0 } ^ { n - i - 2 } 0 = 0 $. this can also happen : on an array that is already sorted, bubblesort does not execute a single swap. the average case worst and best case open quite a gap. but what is the typical number of swaps? in order to answer this question, we need to define what " typical " means. in theory, we have no reason to prefer one input over another and so we usually assume a uniform distribution over all possible inputs, that is every input is equally likely. we restrict ourselves to arrays with pairwise distinct elements and thus assume the random permutation model. then, we can rewrite our costs like this² : $ \ qquad \ displaystyle \ mathbb { e } [ c _ { \ text { swaps } } ] = \ frac { 1 } { n! } \ sum _ { a } \ sum _ { i = 0 } ^ { n - 2 } \ sum _ { j = 0 } ^ { n - i - 2 } c _ { 5, 9 } ( a ^ { ( i, j ) } ) $ now we have to go beyond simple manipulation of sums. by looking at the algorithm, we note that every swap removes exactly one inversion in $ a $ ( we only ever swap neighbours³ ). that is, the number of swaps performed on $ a $ is exactly the number of inversions $ \ operatorname { inv } ( a ) $ of $ a $. thus, we can replace the inner two sums and get $ \ qquad \ displaystyle \ mathbb { e } [ c


_ { \ text { swaps } } ] = \ frac { 1 } { n! } \ sum _ { a } \ operatorname { inv } ( a ) $. lucky for us, the average number of inversions has been determined to be $ \ qquad \ displaystyle \ mathbb { e } [ c _ { \ text { swaps } } ] = \ frac { 1 } { 2 } \ cdot \ binom { n } { 2 } $ which is our final result. note that this is exactly half the worst - case cost. note that the algorithm was carefully formulated so that " the last " iteration with i = n - 1 of the outer loop that never does anything is not executed. " $ \ mathbb { e } $ " is mathematical notation for " expected value ", which here is just the average. we learn along the way that no algorithm that only swaps neighbouring elements can be asymptotically faster than bubblesort ( even on average ) - - the number of inversions is a lower bound for all such algorithms. this applies to e. g. insertion sort and selection sort. the general method we have seen in the example that we have to translate control structure into mathematics ; i will present a typical ensemble of translation rules. we have also seen that the cost of any given subprogram may depend on the current state, that is ( roughly ) the current values of variables. since the algorithm ( usually ) modifies the state, the general method is slightly cumbersome to notate. if you start feeling confused, i suggest you go back to the example or make up your own. we denote with $ \ psi $ the current state ( imagine it as a set of variable assignments ). when we execute a program p starting in state $ \ psi $, we end up in state $ \ psi / \ mathtt { p } $ ( provided p terminates ). individual statements given just a single statement s ;, you assign it costs $ c _ s ( \ psi ) $. this will typically be a constant function. expressions if you have an expression e of the form e1 ∘ e2 ( say, an arithmetic expression where ∘ may be addition or multiplication, you add up costs recursively : $ \ qquad \ displaystyle c _ e ( \ psi ) = c _ { \ circ } + c _ { e _ 1 } ( \ psi ) + c _ { e _ 2 } ( \


psi ) $. note that the operation cost $ c _ { \ circ } $ may not be constant but depend on the values of $ e _ 1 $ and $ e _ 2 $ and evaluation of expressions may change the state in many languages, so you may have to be flexible with this rule. sequence given a program p as sequence of programs q ; r, you add the costs to $ \ qquad \ displaystyle c _ p ( \ psi ) = c _ q ( \ psi ) + c _ r ( \ psi / \ mathtt { q } ) $. conditionals given a program p of the form if a then q else r end, the costs depend on the state : $ \ qquad \ displaystyle c _ p ( \ psi ) = c _ a ( \ psi ) + \ begin { cases } c _ q ( \ psi / \ mathtt { a } ) &, \ mathtt { a } \ text { evaluates to true under } \ psi \ \ c _ r ( \ psi / \ mathtt { a } ) &, \ text { else } \ end { cases } $ in general, evaluating a may very well change the state, hence the update for the costs of the individual branches. for - loops given a program p of the form for x = [ x1,..., xk ] do q end, assign costs $ \ qquad \ displaystyle c _ p ( \ psi ) = c _ { \ text { init _ for } } + \ sum _ { i = 1 } ^ k c _ { \ text { step _ for } } + c _ q ( \ psi _ i \ circ \ { \ mathtt { x : = xi \ } } ) $ where $ \ psi _ i $ is the state before processing q for value xi, i. e. after the iteration with x being set tox1,..., xi - 1. note the extra constants for loop maintenance ; the loop variable has to be created ( $ c _ { \ text { init _ for } } $ ) and assigned its values ( $ c _ { \ text { step _ for } } $ ). this is relevant since computing the next xi may be costly and a for - loop with empty body ( e. g. after simplifying in a best - case setting with a specific cost ) does not have zero cost if it performs iterations. while - loops given a


program p of the form while a do q end, assign costs $ \ qquad \ displaystyle c _ p ( \ psi ) \ \ \ qquad \ = c _ a ( \ psi ) + \ begin { cases } 0 &, \ mathtt { a } \ text { evaluates to false under } \ psi \ \ c _ q ( \ psi / \ mathtt { a } ) + c _ p ( \ psi / \ mathtt { a ; q } ) &, \ text { else } \ end { cases } $ by inspecting the algorithm, this recurrence can often be represented nicely as a sum similar to the one for for - loops. example : consider this short algorithm : while x > 0 do 1 i + = 1 2 x = x / 2 3 end 4 by applying the rule, we get $ \ qquad \ displaystyle c _ { 1, 4 } ( \ { i : = i _ 0 ; x : = x _ 0 \ } ) \ \ \ qquad \ = c _ < + \ begin { cases } 0 &, x _ 0 \ leq 0 \ \ c _ { + = } + c _ / + c _ { 1, 4 } ( \ { i : = i _ 0 + 1 ; x : = \ lfloor x _ 0 / 2 \ rfloor \ } ) &, \ text { else } \ end { cases } $ with some constant costs $ c _ { \ dots } $ for the individual statements. we assume implicitly that these do not depend on state ( the values of i and x ) ; this may or may not be true in " reality " : think of overflows! now we have to solve this recurrence for $ c _ { 1, 4 } $. we note that neither the number of iterations not the cost of the loop body depend on the value of i, so we can drop it. we are left with this recurrence : $ \ qquad \ displaystyle c _ { 1, 4 } ( x ) = \ begin { cases } c _ > &, x \ leq 0 \ \ c _ > + c _ { + = } + c _ / + c _ { 1, 4 } ( \ lfloor x / 2 \ rfloor ) &, \ text { else } \ end { cases } $ this solves with elementary means to $ \ qquad \ displaystyle c


_ { 1, 4 } ( \ psi ) = \ lceil \ log _ 2 \ psi ( x ) \ rceil \ cdot ( c _ > + c _ { + = } + c _ / ) + c _ > $, reintroducing the full state symbolically ; if $ \ psi = \ { \ dots, x : = 5, \ dots \ } $, then $ \ psi ( x ) = 5 $. procedure calls given a program p of the form m ( x ) for some parameter ( s ) x where m is a procedure with ( named ) parameter p, assign costs $ \ qquad \ displaystyle c _ p ( \ psi ) = c _ { \ text { call } } + c _ m ( \ psi _ { \ text { glob } } \ circ \ { p : = x \ } ) $. note again the extra constant $ c _ { \ text { call } } $ ( which might in fact depend on $ \ psi $! ). procedure calls are expensive due to how they are implemented on real machines, and sometimes even dominate runtime ( e. g. evaluating the fibonacci number recurrence naively ). i gloss over some semantic issues you might have with the state here. you will want to distinguish global state and such local to procedure calls. let's just assume we pass only global state here and m gets a new local state, initialized by setting the value ofp to x. furthermore, x may be an expression which we ( usually ) assume to be evaluated before passing it. example : consider the procedure fac ( n ) do if ( n < = 1 ) do 1 return 1 2 else 3 return n * fac ( n - 1 ) 4 end 5 end as per the rule ( s ), we get : $ \ qquad \ displaystyle \ begin { align * } c _ { \ text { fac } } ( \ { n : = n _ 0 \ } ) & = c _ { 1, 5 } ( \ { n : = n _ 0 \ } ) \ \ & = c _ { \ leq } + \ begin { cases } c _ 2 ( \ { n : = n _ 0 \ } ) &, n _ 0 \ leq 1 \ \ c _ 4 ( \ { n : = n _ 0 \ } ) &, \ text { else } \ end { cases } \ \ & = c


_ { \ leq } + \ begin { cases } c _ { \ text { return } } &, n _ 0 \ leq 1 \ \ c _ { \ text { return } } + c _ * + c _ { \ text { call } } + c _ { \ text { fac } } ( \ { n : = n _ 0 - 1 \ } ) &, \ text { else } \ end { cases } \ end { align * } $ note that we disregard global state, as fac clearly does not access any. this particular recurrence is easy to solve to $ \ qquad \ displaystyle c _ { \ text { fac } } ( \ psi ) = \ psi ( n ) \ cdot ( c _ { \ leq } + c _ { \ text { return } } ) + ( \ psi ( n ) - 1 ) \ cdot ( c _ * + c _ { \ text { call } } ) $ we have covered the language features you will encounter in typical pseudo code. beware hidden costs when analysing high - level pseudo code ; if in doubt, unfold. the notation may seem cumbersome and is certainly a matter of taste ; the concepts listed can not be ignored, though. however, with some experience you will be able to see right away which parts of the state are relevant for which cost measure, for instance " problem size " or " number of vertices ". the rest can be dropped - - this simplifies things significantly! if you think now that this is far too complicated, be advised : it is! deriving exact costs of algorithms in any model that is so close to real machines as to enable runtime predictions ( even relative ones ) is a tough endeavour. and that's not even considering caching and other nasty effects on real machines. therefore, algorithm analysis is often simplified to the point of being mathematically tractable. for instance, if you don't need exact costs, you can over - or underestimate at any point ( for upper resp. lower bounds ) : reduce the set of constants, get rid of conditionals, simplify sums, and so on. a note on asymptotic cost what you will usually find in literature and on the webs is the " big - oh analysis ". the proper term is asymptotic analysis which means that instead of deriving exact costs as we did in the examples, you only give costs up


to a constant factor and in the limit ( roughly speaking, " for big $ n $ " ). this is ( often ) fair since abstract statements have some ( generally unknown ) costs in reality, depending on machine, operating system and other factors, and short runtimes may be dominated by the operating system setting up the process in the first place and whatnot. so you get some perturbation, anyway. here is how asymptotic analysis relates to this approach. identify dominant operations ( that induce costs ), that is operations that occur most often ( up to constant factors ). in the bubblesort example, one possible choice is the comparison in line 5. alternatively, bound all constants for elementary operations by their maximum ( from above ) resp. their minimum ( from below ) and perform the usual analysis. perform the analysis using execution counts of this operation as cost. when simplifying, allow estimations. take care to only allow estimations from above if your goal is an upper bound ( $ o $ ) resp. from below if you want lower bounds ( $ \ omega $ ). make sure you understand the meaning of landau symbols. remember that such bounds exist for all three cases ; using $ o $ does not imply a worst - case analysis. further reading there are many more challenges and tricks in algorithm analysis. here is some recommended reading. how to come up with the runtime of algorithms? how to describe algorithms, prove and analyse them? why use comparisons instead of runtime for comparing two algorithms? how can we assume that basic operations on numbers take constant time? what constitutes one unit of time in runtime analysis? solving or approximating recurrence relations for sequences of numbers basics of amortised analysis there are many questions tagged algorithm - analysis around that use techniques similar to this.


that's a grommet, not to be confused with gromit. gromit, of wallace and gromit fame.


the simplest manner is to not use a wald test, but rather an lrt with a reduced model lacking the factor of interest : dds = deseq ( dds, test = " lrt " reduced = ~ geno + geno : treatment ) the above would give you results for treatment regardless of level while still accounting for a possible interaction ( i. e., a " main effect of treatment, regardless of the type of treatment " ). as an aside, this is probably a case where the edger - preferred way of creating groups of genotype - treatment combinations and then using a model of ~ 0 + group might make your life a bit easier. you'll get the same results ( more or less ) regardless, but it'll probably be easier for you to think in those terms rather than remembering that the base level will be treatment hs30 and geno prg1.


great picture and great find. but unfortunately i don't think that is a new species of bird... or even a bird at all! it looks like a hummingbird hawk - moth, macroglossum stellatarum. here you can really see the'little trunk'( as you described it ) known as a proboscis, which it uses to feed on flowers. fun fact : it's believed not to be a mimic of the hummingbird, but rather an example of convergent evolution.


first of all i wish to thanks aron ahmadia for pointing me to this thread. as for opencl in scientific code : opencl is meant to be a low - level api, thus it is crucial to wrap this functionality in some way in order to reach a reasonable productivity. moreover, as soon as several compute kernels are involved, code can get very dirty if opencl kernel and memory handles need to be heavily passed around within an application. i don't know ocltools, thus i can't say whether they are useful in this regard. as for viennacl : i'm the head of viennacl, so i've worked recently with the library. : - ) in the following i'll treat the request for a comparison with cusp in a slightly larger scope, namely viennacl versus the cuda - based math libraries cusp and magma. only the present state is considered, even though there is a lot of ongoing development ( at least on our side ). functionality. magma provides blas - functionality for dense matrices via the usual function interfaces. most of this functionality is also provided with viennacl 1. 2. 0 using operator overloads and other syntactic sugar. the same three iterative solvers ( cg, bicgstab, gmres ) are provided with cusp and viennacl. the set of preconditioners differs notably : cusp provides diagonal, sa - amg and various bridson preconditioners. viennacl offers incomplete lu factorizations, diagonal preconditioners, and recently various amg flavors and sparse approximate inverse preconditioners. to my knowledge, all cusp preconditioners run entirely on the gpu, while viennacl relies particularly during the setup phase on cpu - based computations. currently, the number of sparse matrix formats is larger in cusp : coo, csr, dia, ell, hyb, while viennacl 1. 2. 0 provides coo and csr. there are a number of additional features provided with viennacl, which are not part of either magma or cusp : structured matrix types ( circulant, hankel, etc. ), fast fourier transform, reordering algorithms ( e. g. cuthill - mckee ) and wrappers for linear algebra types from other libraries. performance. the larger set of features and hardware support in viennacl typically comes at the cost of lower performance when compared to cuda - based implementations. this


is also partly due to the fact that cuda is tailored to the architecture of nvidia products, while opencl represents in some sense a reasonable compromise between different many - core architectures. overall, viennacl is at present slower than magma, particularly at blas level 3. the reasons is the different focus of viennacl ( sparse instead of dense linear algebra ) and thus the higher degree of optimization in magma. particularly blas level 3 operations are currently considerably faster in magma. similarly, cusp provides slightly better overall performance in general. however, since sparse matrix operations are usually memory bandwidth limited, differences are considerably smaller and often negligible compared to data setup and the like. the choice of the preconditioner and its parameters usually has a higher impact on the overall execution time than any performance differences in sparse matrix - vector multiplications. portability. as for hardware portability, viennacl can use cpus and gpus from all major vendors thanks to opencl. in contrast, cusp and magma rely on a suitable nvidia gpu. viennacl is header - only, can be compiled on a wide range of c + + compilers and only needs to be linked with the opencl library if gpu - support is required. in principle, the generic algorithms in viennacl can also be used without any opencl linkage, while cusp and magma require the nvidia compiler for compilation and the cuda library on the target system for execution. magma also requires a blas library, which can sometimes be a bit of a hassle to find or install on a new system. api. magma provides blas - style function interfaces for blas functionality. the c + + interface of cusp also uses some functions from blas, but no operator overloads. since most interfaces in viennacl are intentionally similar to boost. ublas and feature syntactic sugar such as operator overloads, viennacl is also intended to be used like boost. ublas. thus, in addition to just calling a predefined set of operations and algorithms, our intention is to make a transition from purely cpu - based execution to gpu code as simple as possible, even if non - standard algorithms are to be used. in the case that a dedicated opencl kernel is required, there is also a framework for integrating your own opencl kernels in viennacl. thus, viennacl aims a lot more towards high productivity in the sense that the time required for implementing new algorithms on the gp


##u is minimized. these savings can significantly outweigh any performance penalty ( if any ) compared to cusp and magma. ( it has also be mentioned in the thread on unit testing that code development time is a precious resource in science. ) there are certainly a number of ideological issues ( e. g. cuda vs. opencl, blas - interface vs. operator overloads ) throughout my comparison, but their discussion is beyond the scope of the initial question.


a few possibilities : falcon try falcon and falcon - unzip. these are designed exactly for your problem and your data : not falcon if you think you have assembled haplotypes ( which seems reasonable to expect given enough coverage ), you should be able to see the two haplotypes by just doing all pairwise alignments of your contigs. haplotypes should show up as pairs of contigs that are much more similar ( even with a lot of between - haplotype divergence ) than other pairs. once you have all such pairs, you can simply select one of each pair to polish.


there are a number of well - studied strategies ; which is best in your application depends on circumstance. improve worst case runtime using problem - specific insight, you can often improve the naive algorithm. for instance, there are $ o ( c ^ n ) $ algorithms for vertex cover with $ c < 1. 3 $ [ 1 ] ; this is a huge improvement over the naive $ \ omega ( 2 ^ n ) $ and might make instance sizes relevant for you tractable. improve expected runtime using heuristics, you can often devise algorithms that are fast on many instances. if those include most that you meet in practice, you are golden. examples are sat for which quite involved solvers exist, and the simplex algorithm ( which solves a polynomial problem, but still ). one basic technique that is often helpful is branch and bound. restrict the problem if you can make more assumptions on your inputs, the problem may become easy. structural properties your inputs may have properties that simplify solving the problem, e. g. planarity, bipartiteness or missing a minor for graphs. see here for some examples of graph classes for which clique is easy. bounding functions of the input another thing to look at is parameterised complexity ; some problems are solvable in time $ o ( 2 ^ kn ^ m ) $ for $ k $ some instance parameter ( maximum node degree, maximum edge weight,... ) and $ m $ constant. if you can bound $ k $ by a polylogarithmic function in $ n $ in your setting, you get polynomial algorithms. saeed amiri gives details in his answer. bounding input quantities furthermore, some problems admit algorithms that run in pseudo - polynomial time, that is their runtime is bounded by a polynomial function in a number that is part of the input ; the naive primality check is an example. this means that if the quantities encoded in your instances have reasonable size, you might have simple algorithms that behave well for you. weaken the result this means that you tolerate errorneous or incomplete results. there are two main flavors : probabilistic algorithms you only get the correct result with some probability. there are some variants, most notable monte - carlo and las - vegas algorithms. a famous example is the miller - rabin primality test. approximation algorithms you no longer look for optimal solutions but almost optimal ones. some algorithms admit relative ( " no worse than double the optimum " ), others absolute ( " no worse than


$ 5 $ plus the optimum " ) bounds on the error. for many problems it is open how well they can be approximated. there are some that can be approximated arbitrarily well in polynomial time, while others are known to not allow that ; check the theory of polynomial - time approximation schemes. refer to algorithmics for hard problems by hromkovic for a thorough treatment. simplicity is beauty : improved upper bounds for vertex cover by chen jianer, iyad a. kanj, ge xia ( 2005 )