Equational

Having good intuition about rare events is actually pretty difficult. Thinking in terms of the plots below helps me with the subject. This is all in this Jupyter notebook . (Note: formatting below is iffy as original is in Jupyter notebook) #!/usr/bin/env python3 % matplotlib inline import numpy as np import matplotlib.pyplot as plt An illustration of how some things are rare, and others common Our "test" population is a thousand In [2]: n =1000 Rare numbers are numbers that are special one way of another. Here rarity means "uniformly randomly generated number between 0 and 1 near to one". We can find them by raising the numbers to a high power (e.g. 100). If they are not close enough to one, they get "crushed" to 0. In [3]: def mk_rare ():      return np . power(np . random . uniform( 0.0 , 1.0 , n), 100 ) rare = mk_rare()   The plot of the rare numbers: In [4]: plt . plot(rare) plt . show() The common numbers are all random numbers that are no...

Asked about my feelings about Python, “speckle noise” came to mind.  The bigger subject here is Python's limited types and inherent noisiness in capturing deeper invariant properties (and therefore my speckle remark).  Speckle noise ,  is the  noise  that arises due to the effect of environmental conditions on the imaging sensor during image acquisition.  The analogy is that there is inherent noise in how one captures ideas in Python, and that this noise has "good Pythonic character". By noise, I mean something that cannot be precisely mastered.  Note that "real" speckle noise is not "good" or "bad", it just is. All programming languages are "noisy". Yet to the developer, the way that noise affect you varies greatly. "Messiness" of computer languages may hurt you, as it may also help you (e.g. by improving your team's productivity). Said differently, sometime "cleanliness" is unproductive.  The main idea is t...

 This week a took a day off to walk in the alps with my son. And while doing so noticed that my blog view count was 24999. So I quickly asked my son to be the next view!  My blog has been around for more than ten years, and a tenth of a second is all a site like Google would need to achieve the same hit count. Still, I write this infrequent blog because it helps me find what is relevant to me and to others, and helps me communicate better. And encourages me to do my best, because I do care about my audience. I write infrequently mostly because I do not have the time. Also, my topics tend to be complex, and sometimes even sensitive, and therefor take time. Still, I often jot down a title, sometimes with a page or two of content. These then become public if I happen to have free evening or weekend. For example, these are my unpublished blog titles going back to early 2019: Balancing productivity, tempo, and success Program = complementary Some retrospectives in busines...

2025 Update:  Wikipedia now states: The BIGMIN problem has first been stated and its solution shown in Tropf and Herzog.[10] For the history after the puplication see [11].  What is below seems to be a variant of BIGMIN, with the advantage of running in log bit length. The original BIGMIN is proportional to the bit length. Many years ago, while doing my thesis, I played a bit with z-order / Morton coding (see   https://en.wikipedia.org/wiki/Z-order_curve ). Therefore I share here a little snippet of code from ~1995, that I happened to fall upon while cleaning up an old laptop. I have not noted that the equivalent logic has already been shared, therefore I took an hour to write it up in Python ( Jupyter notebook style uploaded here ). I would be curious to know if it can be found elsewhere. First a bit of historical context. My first job (before my PhD) had me writing a Design Rule Checker (DRC) for the world's first analog CAD tool, developed at the CSEM   https...