all things Love

Why do my poems be like water rushing in a rapid I seem to love four four letters in a row four lines in a tow Why do my poems be like joyful bursts of sporadic laughter short sweet fragrant after as if they need reader till writer greets Why do my poems be like dreamy sunrise on mountain summit I seem to have taken the road hither nobody seldom goes thither Why do my poems be like hazy reflections upon silent sea roaring rolling beneath before perhaps the one sought perhaps the one aft

Hey there, How you holding up? So, this is the end of astropy@GSoC  time period. There was a time growing up when I used to wonder about Astropy people. About those science wizards who worked on writing computer programs for an esoteric software thing that made calculations of the universe, with a bizarre portmanteau of a name, astro-pie . Haha, and now, as the project finishes up, I am one of those fabled wizards. Well, it has been quite a ride, hasn't it? Let's first take a step back to recap what the context of my Google Summer of Code project was and then have a detailed look at what has been done. Below is part of the short project synopsis I had submitted during the application process back in April. One important feature of Astropy is reading and writing tabular data in a wide variety of useful formats. One such astronomical data storage format is the CDS-ASCII format employed by Centre de Données astronomiques de Strasbourg (CD

Heads-up about the Progress of #11897 In summary the situation of the concerned PR a few days back was 4 types of CI test errors, one bug and possibly a need for modification of part of the code copied from pycdsreadme. All these have been taken care of as detailed below, but for the numpy depreciation warnings that keep coming up. I don't think we can do anything about the latter's persistence as of now. I shall comment more about it on GitHub as well. File not found error : Moritz's HW, i.e. using get_pkg_data_filename import, directly took care of this. Error in coord col decimal places : The precision of the coordinate component columns was getting set arbitrarily, which created difference in the output for 32-bit and 62-bit machines, and possibly between different operating systems. This has been corrected by having a fixed number of 12 digits after decimal for RAs,   DEs and the

The Dead of Jericho by Colin Dexter My rating: 5 of 5 stars This was the first Colin Dexter book I took up, indeed only after we had obtained a paperback of it. This is per se the sixth book in the Inspector Morse series, but I am glad I started off with this first. Because, this is a mighty likeable book. Also, the first episode of the Inspector Morse TV series is based on the Dead of Jericho, so another plus point. In the book, Morse cunningly, albeit with hick-ups here and there, solves the Murder of Miss Anne Scott, previous employee at Richards Publishing shifted now to giving private Greek lessons owning to her previous exposer to it, and that of her nosy sixty-something neighbour Mr. George Jackson, who pries over others affairs and wanted to make a buck or two out of it. Events take place mostly in the Oxford sub-urb of Jericho, which is a real place on the map. I liked the complexity of the plot and the level of familiarity the author shows about the vocabulary of the E

Hi, How are you? My dear mentors and I have decided to have the MRT (Machine Readable Table) format writing first. The same CDS code as been used now will be used, just the template of the written table will be in the MRT format. Points to be noted regarding this and the immediate things that have been and will done are as follows: Leave out writing all the optional CDS ReadMe fields as of now. These can be dealt with individual PRs later. Some tests fail because start_line = None doesn't work. It has been introduced once again within CdsData.write function in addition to been defined in the main Cds class. The test failure occurs because CdsData now inherits from FixedWidthData which itself inherits basic.BasicReader instead of BaseReader. I should make sure that all tests pass properly. Have a template for MRT tables and write them first. Title , Authors , Date , Caption and Notes sections, i.e. all sections except the Byte-By-Byte and the Data itself, will be left blank i

Damn yaar!  I didn't know this. Astropy can be a dangerous place. There are codestyle ninjas present. Hidden in plain sight. It's not just the PEP8 speaks  from GitHub actions. There are real people in it too. And worse of all they don't allow merging the Pull Request (PR) until we do what they say. All in the name of adhering to modern standards that improve readability. What has open source come to! Really? This and the past week, below listed is what the codestyle ninjas have made me do to my otherwise perfectly working code: (copied without permission from GitHub) TABLE should not be used as a variable name No camelCase anywhere . For example, tableDescription should be table_description . Module level variables as SCREAMING_SNAKE_CASE . E.g. BYTE_BY_BYTE_TEMPLATE not ByteByByteTemplate . Regular variables, functions, methods are lower_case_underscore_separated , never camelCase or CapsCase . Private methods start with one underscore not two, e.g. def _split_float_

So, it's the start of the 3rd week now. I will be virtually meeting Aarya and Moritz again Tom. For the past few weeks now, I have been pushing commits to a Draft PR  https://github.com/astropy/astropy/pull/11835  on GitHub. I wanted to have something working quite early in the project, in order to be able to pinpoint accurately when something doesn't work. This is why I started with directly adding the cdspyreadme code within Astropy. Afterwards, I am also writing the code from scratch. As more of the required features from cdspyreadme get integrated into cds.py , those files and codes added earlier will be removed. About the reading/writing to Machine Readable Table format, in fact I wrote about it briefly in my GSoC Proposal that I could attempt it as an extension. I don't have an opinion on whether or not it should have it's own format classes etc. However, since the title of my GSoC project is to Add a CDS format writer to Astropy , I would prefer to work on the

Hi, How are you? So, it's been two weeks of astropy@GSoC work already. Of course I have been damn busy! With the last commit made to the draft PR https://github.com/astropy/astropy/pull/11835 , a few hours back, I have successfully written a basic CDS writer. And voilà it works, albeit without the ReadMe at present! 😁 Note that I am quite unlikely to go into technical details here in these posts. There are two reasons for this. Hhm..., Na I guess there's just one single reason. It would be too repetitive a task to write them. I already write aplenty about those in the GitHub comments and other communications. And of course, the whole codes I am writing during the project are available publicly on GitHub, for the overly curious kind. Moreover, the final report is gonna have more than ample discussion too, because I like to explain myself a lot. 😐 What then is the need to write all that here again? So consider these posts my plain uncouth thoughts, which in any case, I suppose,

Hey there, How are you? Chances are that you are coming across me for the first time. Nice meeting you too! 😄 Since this is an introductory astropy@GSoC Blog Post, I would keep things brief.                        As you probably already know, my name is Suyog and I am a participant for Google Summer of Code (GSoC) 2021. Over the course of the next 10 weeks or so, I will be working on the Astropy project under the umbrella organisation OpenAstronomy. During this while, I aim to add a CDS format writer to the Astropy library with the help of my affable mentors Aarya and Moritz.    I had actually also applied for GSoC last summer, however I had failed to pass one of the eligibility criteria, and so wasn't selected. This astropy@GSoC project, therefore, is quite an awesome opportunity for me. I am looking forward to making the most of it and enjoying the time all the same. There are two preliminary observations:     1. The associated stipend, albeit so

Homo Deus: A Brief History of Tomorrow by Yuval Noah Harari My rating: 5 of 5 stars It took me a long time to finish reading Homo Deus . And I think the long duration was well worth it. Homo Deus is not the ordinary everyday stale non-fiction that one comes across. It is a masterpiece in its own right. But for the Sapiens , I don't recall having read any other book that stimulated thinking to the degree Homo Deus does. The book starts off almost right away from where its predecessor, Sapiens , ended. A New Human Agenda , that of seeking eternal youth , bliss and divinity , is put forward for the 21st Century. Since the dawn of Humankind, the persistent goal of any population has been to have sufficient food to quench hunger, to have health measures to fight infections and diseases and to be at peace with neighbouring kingdoms. With the advent of the modern technology and the unprecedented progress it has made over the last few decades, the goals have changed now. Rest of the

The Honjin Murders by Seishi Yokomizo My rating: 5 of 5 stars Well, this is my first of both translated Japanese mysteries and in particular, Seishi Yokomizo-san. I was vaguely familiar with the author's name from it being mentioned in some Detective Conan episodes. What I didn't know was how famous this author is in Japan, which googling the book afterwards amply told me. The Honjin Murders is the first book in a series of 77 novels featuring the scruffy looking young detective Kosuke Kindaichi that Seishi-san wrote in his lifetime. Only two of the series have been translated to English till date. The story of The Honjin Murders starts with a cheery narrator, fascinated by a crime committed ten years ago in the remote village of Yamanaza, visiting the location in order to get the material for his book on the same. Soon the reader learns about the Ichiyanagi family, their honjin lineage, the events before the fateful night and the greasome crime. The bride and the groom