todd8

Beware of Bacillus Cereus:

https://rightasrain.uwmedicine.org/body/food/leftover-rice-b...

I'm running the latest MacOS right now on a modest m4 Mini and it doesn't seem slow to me at all. I use Windows for gaming and Linux for several of my machines as well and I don't "feel" like MacOS is slow.

In any case, Chrome opens quickly on my Mac Mini, under a second when I launch it from clicking its icon in my task bar or from spotlight (which is my normal way of starting apps). When Chrome is idle with no windows, opening chrome seems even faster, almost instant.

This made me curious so I tried opening some Apple apps, and they appear to open about the same speed as Chrome.

Gui applications like Chrome or Keynote can be opened from a terminal command line using the open command so I tried timing this:

     $ time open /Applications/Google\ Chrome.app

My first college girlfriend made me realize that I wasn't a fast thinker. In person our conversations didn't seem problematic to me, but on the phone she would respond too quickly to what I was saying. I wouldn't be able to get into listening mode in time to pick up on the beginning of her replies.

I suppose that different people just have different strengths and mine isn't quick repartee. Another unusual thing I've noticed is my inability to do my best thinking while music is playing. While working briefly at a company to help out some friends I was forced to hear music throughout my time working on location; it was terrible (for me). In school I always did my work in quiet settings.

I was a math major in college and music interfered with my math work more than other subjects. My theory is that math and music both rely on similar mental resources.

When I went to college, practically every student arrived with a slide rule. I bought mine when I was 14 years old. (I still have it, a Picket model N4-ES https://www.sliderule.ca/pickett.htm) We all learned to use them in High School and were expected to use them in our science and engineering classes.

There were mechanical adding machines (see for example https://www.burroughsinfo.com/portable-adders.html) but these were only practical for adding and subtracting and were heavy, bulky machines.

In engineering and the sciences, multiplication, division, trigonometric, and exponential functions were necessary. In the late 1960s, there were four alternatives for computing these operations: books containing printed tables of values (good for 5 or 6 decimal positions of precision at best), desktop scientific calculators like the Wang 360--expensive and not very common. I remember using one only once at MIT, "real" computers (running FORTRAN programs on punched cards or perhaps APL), or the lowly slide rule.

Slide rules were everywhere that scientists and engineers roamed in the late 1960's. They had only three parts: a pair of fixed rulers, a sliding ruler that slid between the two fixed rulers, and a cursor, which is a thin precise line in a window that could be used to line up the positions on the rulers. The rulers were inscribed not with evenly spaced marks (as measuring rulers are) but with marks starting at 1 (not zero) and going up to 10 spaced logarithmically.

Just as two yard sticks can be lined up to measure 5 feet, a rulers of a slide rule can be lined up to calculate the sum of two logarithms and adding logarithms can be used to perform multiplication.

A typical slide rule had dozens of scales, with spacing corresponding to the trig functions, exponentials, hyperbolic trig functions, logs of logs, etc. A slide rule could perform almost any function needed for basic science and engineering. There were two limitations; slide rules couldn't calculate sums or differences, and they were only accurate for perhaps 3 digits of precision.

The limitations on precision was due to the difficulty in reading the scale accurately; the scales were only around a foot long. To get another digit of precision you'd need a slide rule with fine marking ten times as long as our portable slide rules. The MIT museum had examples of just such devices. Typically, the scale would be marked on the outside of a cylinder in a helical fashion. Such devices could then get more than four digits of precision. See https://en.wikipedia.org/wiki/Fuller_calculator for an example of a cylindrical slide rule.

In 1971, some of my wealthier fellow students bought the Bomar Brain. It was the first portable electronic calculator that I ever saw and cost $240. In today's dollars that would be roughly $1900. All the device could do was add, subtract, multiply and divide. One would still need a slide rule for trig, square roots, logs, etc. A few years later, HP and others came out with hand held scientific calculators and I retired my slide rule, which now adorns my home office in its original leather case (with the belt loop to carry the slide rule at your fingertips).

Coincidently, I'm vacationing right now, and in the lobby there is a case containing an original Thatcher Calculator on display (https://commons.wikimedia.org/wiki/File:The_Thacher_Calculat...), another variation of the cylindrical slide rule and invented around 120 years ago.

Time for hexadecimal.

Rhino horns are not made of ivory.

Humans too can be committed to beliefs that are not true. I have friend that believes in and regularly consults her "clairvoyant". I wonder if our AI assistants in the future will be vulnerable to suspicions or popular fantasies about the world, people, or even other AIs they interact with.

There have been decades of work on file name completion put into Emacs, nothing I’ve seen comes close. Currently I’m using add on packages vertigo, orderless, marginalia, consult, embark, and corfu to handle completion. These packages all work together to produce a crazy good setup, but in the past I’ve used helm, ivy, icicle, and vanilla Emacs. Every one of these open source completion frameworks works great.

Of course, I’ll never get back the time spent fiddling with my 1600 line Emacs configuration file.

This isn’t obvious to me. It doesn’t have to simulate itself in real time. It may not be able to simulate itself simulating itself. There may be proof of this using a diagonalization proof.

Consider programs that are quines, programs are able to output the exact source code of the program. See [1].

And there are abstract computers that can produce any computable output. These are called Universal Turing Machines, see [2]. UTMs can be specified with a remarkably small number of internal states, see [3].

I’m not saying you are wrong, but computability is full of unintuitive results, and the answer may be more subtle than what is revealed by “just thinking about it”.

[1] https://en.m.wikipedia.org/wiki/Quine_(computing)

[2] https://en.m.wikipedia.org/wiki/Universal_Turing_machine

[3] https://en.m.wikipedia.org/wiki/Wolfram%27s_2-state_3-symbol...

Is there a reason for me to pick up Fleet if I already use JetBrains other IDEs?

I've taught hundreds of people programming. For one year, at my first real job, I was tasked with teaching the programmers within a big company Pascal. All of them were already professional programmers using Fortran, COBOL, or assembly language. The company had a commitment to modernize their software development practices and one facet of this was to introduce a more modern language--Pascal at that time (circa 1976).

I enjoyed that year and, for the most part, my "students" were easy to teach, and Pascal held up well. They were all programmers already, so I didn't have to go slow through the basics and introducing ideas like recursion (absent in Fortran, COBOL, and assembly language of the period) kept the classes new and interesting to the students.

Unfortunately, standard Pascal isn't really a good choice for a first programming language today, even though modern Pascals have removed many of early Pascal's limitations (packages, batteries included libraries, etc.)

So, how can we decide if a language is a viable first language? Employing the wisdom of crowds, here are the top 30 languages in the 2023 IEEE Spectrum rankings:

1-10: Python, Java, C++, C, Javascript, C#, SQL, Go, TypeScript, HTML.

11-20: R, Shell, PHP, Ruby, SAS, Swift, Dart, Rust, Kotlin, Matlab.

21-30: Scala, Assembly, Perl, Visual Basic, Objective-C, Lua, Fortran, Verilog, Groovy, Julia.

I contend that we should limit our choice of first-languages to some language in the top 30. This rules out many languages that I consider important, but we should stick with a language that is likely to benefit the student more than others as a first-language. That means not teaching Lisp or Racket or Ada or Ocaml or Prolog or even D for that matter as a first language.

To narrow our top 30 down to a handful of alternatives, I'm going to use my own subjective difficulty rating and remove C++ and Rust and Scala from the list because they will be too hard for beginners.

Furthermore, let's remove languages that aren't general purpose; this knocks out SQL, HTML, R, Shell, PHP, SAS, Matlab, Assembly, Visual Basic, and Verilog.

Some languages require more complex build or execution environments; I would remove Java, Dart, Kotlin, and Groovy from our list for this reason.

Finally, there are some languages that are not as easy to use outside of specific hardware or operating systems; I consider these languages C#, Swift and Objective-C to be ruled out.

For good measure, I'm removing Perl from the list (a bit too irregular) and Fortran (not widely used outside of some important areas).

Our condensed list now look like this:

Possible first languages: Python, JavaScript, Go, TypeScript, Ruby, and Julia.

To narrow it down even a bit further we can observe that one should learn JavaScript before learning Typescript. (Is this opinion shared by HN?)

Ruby and Python seem like close cousins with Ruby being a bit prettier and Python being much much more popular.

Julia is a bit specialized and a bit harder than the others so now we are left with just three: Python, JavaScript, and Go.

These must be the masses of the Mars rovers, the weights would be measured in newtons (or pounds in the USA) and would differ between mars and earth.

In grad school, many years ago, I would plug the drain and let the tub fill while I showered. I would pull the plug and let the tub drain once the water had cooled. This way my bathroom would warm up a bit. I suppose this might have saved a few cents.

BASIC was almost my first programming language. Ten years before anybody had a home computer (1967), I decided that I would write a program. I was just a kid and I came across a keypunch machine in a small room at my high school. After reading a book on FORTRAN I keypunched a program that was supposed to solve optimization problems over sets of linear equations in a number of unknowns constrained by a set of inequalities. The algorithm for doing this is known as the Simplex Method.

I gave the deck of cards to a friend and a couple of days later I got the fan-fold paper output that listed a bunch of syntax errors and nothing else. I just didn't understand programming very well.

BASIC is what got me on track. I found a book in my local public library on the relatively new language BASIC. It was easy to understand and I practiced writing out the solutions to simple problems with paper and pencil. I didn't have access to a BASIC system, but I learned enough that I could try FORTRAN again (this time on simpler problems). After a few attempts (with the two day turnaround) I was successful and programming became a hobby that eventually led to a career as a real computer scientist.

BASIC was just right. It was concrete enough for a novice to understand while being much more expressive than assembly language. I've never actually run any program that I wrote in BASIC, but I have written programs in scores of languages since and BASIC got me started.

Today, there are better choices for a first language: Python provides students with a lot of power right away, and my daughter learned Scheme as her first language and never had difficulties in later classes with recursion or functions as values.

I'm sure it was possible to punch the compiled executable as an option, but I was a student during most of my keypunching days so the cards would be read by a card reader the computer would compile the FORTRAN and then execute the program, reading input data from cards that were stacked behind the source code.

One summer, I worked at an engineering firm and had to run a program frequently on a set of input; it's possible that the executable I was loading into the card reader was already compiled and not the original FORTRAN source, but I don't remember for sure.

I lugged around my favorite boxes of programs on cards for years, I even had big, full sized tapes, see [1], containing more programs I had written.

[1] http://www.columbia.edu/cu/computinghistory/tapes.html

I still have fond memories of working on the 029 keypunch machines, the keys made such a satisfying sound. I also remember the rooms where thousands of chads from punching the cards collected and had a certain smell and the bright overhead lighting, the ample air conditioning, the raised floors, the background noise of the machines, the whirling tape drives; it was an experience I'll never forget.

I started programming around 1967-1968. In my high school, there was an old keypunch machine used for school administration purposes. I had a friend that was able to submit any program I keypunched to the school district's IBM computer; I never saw the computer but it's likely that it was something like an IBM 1130. My my friend would bring the output back a couple of days later; so fixing even one typo required a few days.

This old keypunch machine was a model 026, not the much nicer model 029 that was ubiquitous while I was in college. The 026 had a very basic keyboard, see [1], one could punch the columnar code for the upper case letters and numerals along with a handful of symbols: #@,%$./ and space. This isn't enough to even program in early FORTRAN, the language I was trying to use.

To type say an equals sign one had to use the multi-punch key that allowed punching a combination of the basic symbols that would properly encode the equals sign. It was slow going. One mistake and the card (corresponding to a line of code) was ruined and had to be redone.

I had just finished reading a book on solving linear programming problems, which come up often in operations research, using the simplex algorithm (I still have this book too). Naturally, I decided that that would be the first program I ever wrote. That definitely wasn't the best "hello world" program to try first. I wish I still had a listing of that program; it would be good for a few laughs.

The first working program I wrote printed out a table of sine and cosine values for angles from 0 to 90 degrees. The rest of my programs in high school were not much more sophisticated. I was just trying to learn it on my own as a hobby. I still own my book on Fortran that I bought with my newspaper route income back then, McCracken's book on Fortran IV [2].

A couple of years later I got to write more serious programs and used the IBM 029 keypunch machines that were a lot better. Programs got long enough (hundreds of lines!!) that card management became important. Sturdy cardboard boxes or even long metal drawers designed for holding the stacks of cards were the main tool for source code management.

In college, I was able to use IBM's data processing equipment for punching line numbers in columns 73-80 on each card (these columns are ignored by FORTRAN IV); this allowed dropped cards to be sorted back into order through a series of passes (one for each digit of line number) on IBM card sorting machines. This was my introduction to radix sorting, [3].

One complication when numbering cards was inserted new code between existing cards. Because of this, my initial punching of line numbers in columns 73-80 had to be done with gaps, usually I'd leave one or two zeros at the end of each card number. However, to get the auto numbering machine to do this required pulling out a large (1 foot square) plug board from the equipment and physically connecting jacks with switchboard like cables to make the equipment count by hundreds and punch in columns 73 through 80.

It was all quite primitive. But one did learn to review code carefully before submitting it for being run.

Grad school was better, I still frequently used FORTRAN punched on cards, but I was also able to use the mainframe in a timesharing environment where I used TECO as my text editor at a terminal, there must have been around twenty of these terminals connected to the CDC 6400, [4].

[1] http://www.columbia.edu/cu/computinghistory/026-keyboard.jpg

[2] https://archive.org/details/guidetofortraniv00mccr

[3] https://ibm-1401.info/KensSorter/type83-a.jpg

[4] http://www.bitsavers.org/pdf/cdc/cyber/cyber_70/kronos/60407...

I've wondered about this, but I don't trust myself to figure out the answer. Even though I have a background in math and I've done some cryptography related work, I know enough about the crypto space to know that I don't know enough to make my own decisions. The featured article by Filippo Valsorda makes a lot of sense.

On the other hand, if the NSA really could find backdoors into elliptic curves (perhaps with a great deal of work) they would be motivated to gaslight the rest of us about elliptic curves by creating article like TFA.

Thank you, the paper you cite makes clear claims: that the environmental (climate change, air pollution, etc.) impact should be priced into the cost of petroleum based fuels. The paper states that 92% of the subsidies to the oil & gas industry are because of the price of fuel doesn't reflect the societal costs related to pollution.

The interesting finding presented in the paper are:

[p. 9] "Underpricing of fossil fuels is still pervasive across countries and is often substantial, especially for coal."

[p. 9] 18% of these subsidies go to gasoline

[p. 9] "The power generation sector is the largest recipient of subsidies"

[p. 10] "By region East Asia and the Pacific accounts for 48 percent of total energy subsidies"

[p. 7] China and India together had 3.4 Million premature deaths due to air pollution in 2020 (The USA had 0.1 Million)

From an economic efficiency point of view, I can understand that prices are important, but wouldn't we have to take account of the benefits of using petroleum fuels too? Like allowing developing countries to feed their populations? They clearly can't do this with solar powered agriculture and solar powered shipping.

One of the interesting things that I discovered while working on some legal papers with a lawyer were that legal documents don't have copyright protection. Lawyers regularly copy and paste from other lawyers work. I suppose, that since legislators most often have backgrounds as lawyers, they legislated rules for themselves that are not the same as the rule the rest of us have to follow.

I am not a lawyer so I don't know that anything in the previous paragraph is true; it's just based on a recollection of something I was told once a long time ago.

How precisely? The taxes on profits from oil & gas related businesses are complex, but I honestly (as a computer scientist unrelated to oil & gas businesses) don't understand the claims that we subsidize oil & gas production. I know that the oil & gas industry is heavily taxed and there are numerous exemptions and complications to the tax regulations for that industry just as there are for other industries, but on balance it appears that oil & gas production pays billions to the US and state governments. See [1], for example.

[1] https://www.forbes.com/sites/drillinginfo/2016/02/22/debunki...

I understand that modern type systems can do anything (that can be computed) since they are Turing complete. So are Java generics and C++ templates and Lisp’s macro systems, but I don’t want these things.

I’ve written a number of Turing machine programs; yeah it’s impressive that an imaginary machine that is so simple can run any program that runs on any other computer, but it’s no fun writing code for a Turing machine. For the Theory of Computing studying Turing machines is important.

If I don’t want Turing complete type systems, what do I want? Well, first off, the bugs I find in my programs that are more troubling don’t seem to be stopped by strong type systems. What I want is to be able to declare assertions in my code. For example, I’d like to tell the compiler that the variable year must always satisfy (2000 < year < 3000) and that in a certain block of code that x and y are always within 0.5 of each other. I want the compiler to ensure that these invariants are satisfied by a combination of compile time and run time checks generated by the compiler.

The problem is that we can’t expect programmers to use Turing machine like type declarations, because the programmer must now program the type system without bugs to ensure that the types in the program carry enough information that higher level assertions can be made about the original program’s correctness.

TLDR, I want to work with higher level assertions about the code than that provided by complex types.

I personally don't know how best to interpret lots of research from the medical community. However, I do believe that the meta-analysis based Cochrane reviews[1] are the most reliable reviews of medical intervention for non-experts (and I consider even the vast majority of doctors as non-experts outside of their particular specialization). The Cochrane Collaboration isn't all knowing, but I don't know of a better alternative source of such information.

In a large meta-analysis[2] the Cochrane Collaboration did not find convincing evidence that masks work. Here is a single sentence taken from the author's conclusions:

"The pooled results of RCTs [Randomly Controlled Trials] did not show a clear reduction in respiratory viral infection with the use of medical/surgical masks."

This gives me pause; I was one of the dedicated mask wearers during the pandemic, but now I realize that we don't know that they did any good. Please note that I am saying we don't know if the masks worked; I'm not saying that the masks didn't work, just that we don't know that they did.

I've included above just a single sentence from the the Cochrane review titled Do physical measures such as hand-washing or wearing masks stop or slow down the spread of respiratory viruses?, the review is available online and is easy to read. I encourage those that think they know that masks either work or don't work to read the entire review for themselves.

[1] https://www.cochrane.org

[2] https://www.cochrane.org/CD006207/ARI_do-physical-measures-s...

Core War is a game played in a memory arena of a virtual machine supporting a simple simulated assembly language. I first saw it described in a 1984 issue of Scientific American[1]. I had already been programming for 15 years by then and recognized Core War as being inspired by Darwin, an even earlier game developed at Bell Labs.

Darwin was created in 1961 and ran on an IBM 7090. In Darwin, programs competed for resources and the winner was the program that reproduced and took over all of the allocated space. It didn't last long because an unbeatable program was developed by Robert Morris Sr. See [2].

Software Practice and Experience was one of my favorite CS journals in the mid-70s and it had a frequent column call Computer Recreations written under the pseudonym Aleph-Null. I enjoyed implementing a number of the games described in that column while in grad school. Unfortunately, Software Practice and Experience is an expensive journal, but university students can likely find it like I did in the university libraries. The issues in the 1970s were easy to read and fun, having articles on subjects like pascal compilers, Algol 68, and concurrent programming. That is where I learned about Module[3,4] and later Oberon[5] in articles by N. Wirth.

[1] https://en.wikipedia.org/wiki/Core_War

[2] https://en.wikipedia.org/wiki/Darwin_(programming_game)

[3] https://onlinelibrary.wiley.com/doi/abs/10.1002/spe.43800701...

[4] https://onlinelibrary.wiley.com/doi/abs/10.1002/spe.43800701...

[5] https://onlinelibrary.wiley.com/doi/abs/10.1002/spe.43801909...

Here are a few observations.

From the CDC [1], 2020 total covid deaths by state: West Virginia 1318, Florida 21546, Maine 344, Vermont 134.

The corresponding April 2020 census populations [2] for these four states are: West Virginia 1793716, Florida 21538187, Maine 1362359, Vermont 643077.

Thus, before the vaccines for covid were available the deaths per 100,000 persons for these four states are: West Virginia 73, Florida 100, Vermont 21, Maine 25.

Someone should probably check my math, but it looks like voting for Trump causes over three times as many deaths even before vaccinations were available. In other words, the analysis in the original article may be affected by unaccounted for confounding factors. For example, COPD is a significant medical risk factor for serious covid complications according to the CDC. COPD affects over 13.6% of the population of West Virginia (the worst rate in the country) but affects only 5.9% of the population of Vermont [3].

Personally, I chose to get vaccinated and boosted at the earliest possible dates. I also caught covid during the initial big wave of omicron cases in my state.

[1] https://stacks.cdc.gov/view/cdc/99750

[2] https://en.wikipedia.org/wiki/List_of_U.S._states_and_territ...

[3] https://www.lung.org/research/trends-in-lung-disease/copd-tr...

I don't understand the curved keyboard wells as present on the Glove80 and Kinesis Advantage keyboards. For most keys on a flat keyboard I type not by bending the finger joints and then punching the keys with the tips of my fingers by straightening my fingers. Instead, I press the keys by largely swinging the whole finger up and down and typing with the pads on the distal phalanx of the fingers.

This is hard to explain but my experience with my Kinesis Advantage is that the keys above the home row and especially the function keys (really just function buttons) are too high and are oriented with the faces of these keys too angled towards my hands (i.e. the normal vector from the top of the keycaps are angled at perhaps 45 degrees from vertical). So on an "ordinary" keyboard, like a laptop keyboard, the surface of the keycaps are roughly parallel to the surface of the laptop keyboard. On such an ordinary keyboard it is quite easy to press the number keys and function keys without a lot of finger flexing, while on the Kinesis Advantage I feel like I am curling my fingers then lifting my whole hand and then straightening my fingers to kind of punch the keys like one would press a button mounted on a wall. (Does this elaborate explanation even make sense or am I just being picky?)

I greatly prefer typing on the Kinesis Gaming Keyboard. These feel better than using welled keyboards to me.

I was working on Distributed Services for AIX in 1986 and 1987, a distributed filesystem to compete with NFS. As this was being developed by a dev team, my colleague and I pondered how to test the system that we had architected.

There were so many possible states that a system's file system can be in. Were the conventional tests going to catch subtle bugs? Here's an example of an unusual but not unheard of issue: in a Unix system a file can be unlinked and hence deleted from all directories while remaining open by one or more processes. Such a file could still be written to and read by multiple processes at least until it was finally closed by all processes having open file descriptors at which point it would disappear from the system. Does the distributed file system model this correctly? Many other strange combinations of system calls might be applied to the file system. Will the tests exercise these.

It occurred to me that the "correct" behavior for any sequence of system calls could be defined by just running the sequence on a local file system and comparing the results with running an identical sequence of system calls against the distributed file system.

I built a system to generate random sequences of file related system calls that would run these on a local file system and a remote distributed file system that I wanted to test. As soon as a difference in outcome resulted the test would halt and save a log of the sequence of operations.

My experience with this test rig was interesting. At first discrepancies happened right away. As each bug was fixed by the dev team, we would start the stochastic testing again, and then a new bug would be found. Over time the test would run for a few minutes before failure and then a few minute longer and finally for hours and hours. It was a really ingesting and effective way to find some of the more subtle bugs in the code. I don't recall if I published this information internally or not.

While I am certified for Nitrox diving, I'm not sure I would actually use it very much. After over 100 open water dives and many dive classes (I was one class away from being a certified instructor back in the 1970s) I realized that I didn't want to do extreme diving. Night dives in the Caribbean are exciting enough. Wreck diving, ice diving, cave diving, commercial diving, hard hat diving all seem too dangerous. Diving in the warm, clear Caribbean was great, and 75% of that experience can be obtained with just a snorkel, mask and flippers.

One of my friends was a commercial diver working on Oil platforms in the North Sea. Out of the eight divers he worked with, he is the only one that lived through it without serious injury.

My first, brief, dive to 135 feet (41m) was in 1976 off the coast of Cozumel. I was in a group led by a dive master and we quickly descended, swam through a large ring shaped coral structure at around 135ft, and started our ascent. More accurately, all but one of use started our ascent.

Back then, of course, we had to rely on the Navy dive tables for maximum safe bottom time (just 10 min from entry at the surface to start of final assent), and we still added about 5 minutes at 15 feet as a safety stop before exiting the water. These limits, determined by the Navy for Navy divers are intended to prevent decompression sickness (the "bends").

Unrelated to the bends is another hazard, nitrogen narcosis that can interfere with clear thinking. It usually starts to affect people at around 150 feet and I barely noticed it at 135ft. However one diver in the group was affected and after passing through the coral archway continued to swim down the wall of coral toward the bottom at least 100ft deeper. The dive leader had to chase this diver, catch him, and then go though a real decompression stop or two with him on the way up.

Now days, sport divers can explore these depths more safely by using a mix of nitrogen and oxygen called Nitrox which is a 65/35 percent mix of Nitrogen/Oxygen vs the atmospheric proportions of 78/21 percent. This lowers the partial pressure of Nitrogen while diving and thus allows safe diving at greater depths and duration for sport divers.

If the research described by the featured article is true, this suggest a simple performance enhancer. Perhaps in the future, SAT exams will have to outlaw the use of Nitrox SCUBA tanks in the exam room.