The keyword false
Negative number 0
0 in BigInt
Primitive null – no value
Not a Number
The two primitives null and undefined are known as nullish. Put simply, it means that they don’t have any value. They get converted to false via Type Coercion in a boolean context.
By above definitions, we see that nullish values are also falsy.
It was a Monday. I was 14, and my math tuition class was in 2 hours. I was hurriedly going through the homework to be done. Yes, we’re all major procrastinators. My tutor had given 12 questions on division by integers. It was always 12 questions, because he could divide that number in many ways. This was useful in formatting the page layout of the questions; 2, 3, or even 4 columns per row.
It was basic arithmetic, and there were two or three questions with 7 as the denominator. I don’t remember exactly what the numbers were, so let’s say they were 1/7, 2/7, and 5/7. Then there were other fractions with 3, 11, 5 and so on. While working out the decimal representations of these numbers, I realized something – the decimal part of fractions with 7 as the denominator had the same set of numbers, recurring every 6 digits.
As you can see above, the numbers 1, 2, 4, 5, 7, and 8 repeat in the decimal part of these rational numbers. Interestingly, they repeat in a manner that shows a cyclic rotation; 142857 is repeated such that n/7 starts from the nth largest number in the sequence 1, 4, 2, 8, 5, and 7, rolling over to the beginning when it reaches the end of the sequence.
This means we can figure out the decimals of a number divided by seven, just by remembering the number 142857. Don’t ask me who would remember a random number like that. Some of us just do.
For example, let’s take 213/7. Looking at the numerator, one could figure out that 210 is the nearest number divisible by 7. (21 = 3 x 7. Multiplication tables, anyone?). That means the decimal representation is 30… something, as the remainder is 3. For the decimal part, we have 30 + 3/7, where 3/7 is 0.428571… by the above pattern. So the answer for 213/7 = 30.428571…
Pretty neat, as long as you remember 142857.
That’s not all. Many rational numbers have recurring patterns in their decimal part. For example, any number divided by 9 gives the same number. So 4/9 = 0.444444… and 7/9 = 0.77777….
Similarly, division by 11 results in multiplying the numerator by 9, and representing it to two decimal points, which then repeats itself. Thus, 5/11 = 0.45 45 45… where 45 = 5 x 9 3/11 = 0.27 27 27 … where 27 = 3 x 9 .
Naturally, I was curious whether other numbers showed the same behaviour as 7. So I checked the decimal part of different rational numbers, intuitively checking with prime numbers as the denominator, since 7 is prime. I didn’t make much progress there, but I remember realizing 17 had such a cyclic rotation in its fractions. I just couldn’t figure out an easy way to derive the starting point of the repetend. Not that it would have been very useful anyway – the length of the repetend of 1/p is either p-1, or a factor of p-1 – not that easy to remember. I’ve only tried a max of 16 digits to remember in order so far. You can probably guess what for.
Looking back now, I had accidentally discovered Cyclic Numbers. It was fun to play around with numbers back then, and we had enough free time to do stuff like that. Some of the best days, those were. And not just because of arithmetics ?
If you’re interested in learning more about Repeating Decimals and Cyclic Numbers, take a look at the following Wikipedia articles. Have fun!
There’s a certain pleasure in seeing people make use of your work. That’s one of the main driving forces behind the open source philosophy. It’s deeply satisfying to know that your lines of code makes someone’s life easier, even if by just a little bit. But what about not just making lives easier, but helping to save entire lives? That’s some next level thing. Enter OpenMRS. This summer I had the opportunity to contribute with code to save lives, and this is my final note about the experience.
It’s a little hard to think 12 weeks have passed already. But as they say, all good things must come to an end. So goes Google Summer of Code 2017 with OpenMRS.
This summer, I worked on the Operation Theater module to bring it up to speed with 2017. The project had 2 main targets.
Migrate the module to work with the current OpenMRS platform.
Add workflow enhancements pertaining to pre, post and in-theater stages.
To remind what the operation theater module does, it basically helps us to schedule surgeries in the operation theaters within a hospital. We can add operation theater locations, save available procedures, schedule surgeries for patients and have a scheduling engine come up with the best schedule for current surgeries.
We can also add a team of surgeons and other people who will be taking part in the surgery. But after making the module, it was somehow left behind and wasn’t updated along with the core of OpenMRS & other modules. It just went beep for 3 years.
So my first task was to get it up and running. For this I had to first check what had changed between those 3 years and update the module codebase. I learned much about how the concept of time is handled in the programming world. I learned about Optaplanner, and constraint satisfaction problems in general (shout out to Charith sir for the Intelligent Systems lectures!). And bloody hell, I replaced an entire time library with two other libraries.
Along with that, there were database changes. OpenMRS had migrated from Hibernate 3.x to 4.x, so the Operation theater module needed some changes on that front. There I learned a bit of Hibernate, the ORM (Object-relational mapping. It’s a database thing). So the first month was spent on updating the module codebase and dependencies.
And we revved up the module.
After adding an operation theater location from settings, we can access the scheduling page and start scheduling. But wait, you need to add some procedures first. Otherwise, what surgery are you going to schedule?
And we’re good. So, first task, done!
Next, we started doing workflow enhancements. The main focus here was on the collection of data throughout the surgery. Before starting a surgery, it’s important to know the history of the patient. What procedures have they done before? Are there any drugs we need to give before the surgery? Is the guy even fit to go into surgery? Curiosity to save a life. Or two, counting the surgeon’s.
I initially planned to collect data as notes – free text. But the community suggested that we do it with concepts and observations, the preferred method of collecting data into OpenMRS. This way, we can use the collected data to generate reports and perform analytics. You can probably guess how hard that would be with free text.
I was halfway through doing it with free text when I got the suggestion. After that, I rewrote the code with appropriate concepts. So now, we’re adhering to standards and working neater overall.
We record past surgery data, allergies, physical condition and drug prescriptions during the pre-theater data collection.
We do the same for in-theater and post-theater data. As for in-theater data, we decided to capture it in the post-operative form as it’s not practical to enter the data during the surgery.
And that’s target number two, down. We’re all good with the primary tasks 😀
After that, I started documenting the code and the module. I’ve written some tests to cover the code and tried to clean it up.
I’ve learned a lot in these past few months, specially how a real project handles collection of data in a flexible manner. This is especially useful for some of my personal projects as well.
As next steps, I’d much rather fully rewrite the scheduling engine myself. Then I know the module inside out from its core, and can help other people to get involved in maintaining it. Another possible extension is generating reports from the data we collect. It’s just a matter of presenting the data in suitable formats.
And that’s it for this time, people. We’ll wrap it up after the final evaluations in one more post.
Over the 11th week, I tried to refactor the code to use as many concepts as possible for data collection. I have added required concepts to be loaded via the module activator at module startup. Then I tested adding data to the system with the saved concepts.
We’re now properly using concepts to store theater workflow data with observation groups where necessary. This is a major milestone as this means we’ve effectively standardized the data collection over the long term, enabling people to make use of the gathered data. My mentors provided feedback on the module and discussed the possibility of shipping the module with the next release of the Reference Application 😀
That’s a big deal, but I feel we’re short of that yet. I’d personally rewrite the scheduling engine completely, as at the moment it’s a mess of one guy’s solution and another guy’s attempt at bringing it to 2017. It works, but with a few quirks here and there – like sometimes it schedules surgeries after the theater open hours. But with the time constraints, this’ll be a task for after the GSoC deadline.
On unit testing side, I wrote test cases for checking availability of initial concepts, adding data with concepts and retrieving them. I plan to document a guide on using the module over the next week. We will also make a video about our work as the final presentation of the project.
We’re nearly done with all development now. This week I went through CIEL and identified existing concepts that I can use for data collection.
It turns out that the whole set of data collected for past surgery history are available in CIEL. Instead of past procedures, they call it procedure history. There’s a set of concepts to record past surgery details as below.
160714 – Procedure history (Grouping concept)
1651 – Procedure performed
160715 – Procedure date/time
160716 – Procedure comment
160721 – Procedure outcome
163049 – Procedure site
During this week I refactored my code to use these concepts for past surgery data collection. I also added them to the module activator to ensure that they are available in any deployment environment.
Apart from that, I spent some time looking into how unit tests are written for OpenMRS modules. We have less than two weeks left of the coding period, so I plan to finish off development with feedback from the community this week.
In-theater workflow enhancements includes collecting various data during the surgery is being performed. My original plan was to have a simple page that would show a timer and allow users to add various data as the surgery continues.
But later I realized that it’s not practical to have someone typing at a computer during a surgery. Silly me. The better approach, I think, is to let the data be recorded after the surgery is performed – add it to the post-operative data.
This is the case with one of the existing implementations that I saw. They have a post-ops form with fields to enter fluids administered during the procedure, specimens collected and such.
Wow, two months gone just like that. This week, my focus was on implementing the pre-theater data collection as per our discussions over the previous weeks. If you followed along, you’d remember that we decided to use concepts and obs groups to record the collected data.
The first thing I did was getting the patient’s allergies and showing them alongside the surgery data. Documentation is scarce on this but I remembered that the new Reference Application contained Allergy module by default. So when I view a patient, his or her allergies are listed on the profile itself. Now I just had to see the corresponding code.
During the 7th week, I got feedback on the mock-ups for pre-theater data collection. Just as I suspected, letting the user simply note data as free text was not the best idea.
Although a simple note might be useful in communicating the patient history, it’s not usable for analytical purposes. I mean, a text paragraph is not granular enough to analyze trends in patient history and can’t be used to generate reports. We need to organize the data collection such that they can be analyzed in the future. This means breaking it down into contextual chunks. Then structuring the DB to store them allowing easy querying.
It’s the end of the 6th week and I’m happy to bring some UI to the mix. Up until now we’ve been working with the stuff that was made before. But now it’s time for new enhancements. The first part of it is enhancing the pre-theater workflow.
Along that line, we discussed what data need to be collected before a procedure, last week. I asked the community what they considered necessary, while making my own suggestions. Just as expected, there are already some implementations of data collection of a surgery.
One example was a post-op form used by a Partners In Health member. She provided screenshots of the form which they used to collect data about the procedure after it took place. It included fields to record the surgical team involved, the location of the procedure, anesthetics, complications etc. They were not collecting any data before the procedure, so they used the same form to record pre-operative diagnoses as well.