Inspired by an amazingly concise implementation of John Conway’s game of Life that I saw written in APL, I decided to see if I could write Life in a single Linq expression.
This (rather long and rambling) post documents my attempts, my eventual success and the result that it made me want to learn APL!
I’ve been trying to write functional code for some time now, and still have the feeling that I’m not doing it correctly, especially when seemingly simple things don’t work. Having bumped into one specific issue over and over again, I decided to try and sort it out once and for all. Imagine a stupidly simple API endpoint that take a float, and returns the square root doubled. I have helper functions as follows… My API endpoint returns a string of the form “Result: 23.3” if successful, or an error if not. I wire these together as follows… This works as expected. Obviously, my real code would have more from clauses than this, but I’m trying to keep this simple. Now, suppose (which is more realistic) the helper functions were async, then I would need to modify my endpoint to look like this… Again, all works. However, now in the case…
As a (somewhat lapsed but still interested) mathematician, I like to play around with interesting numbers. Well, I guess we all have our little foibles eh?
I decided to have a go at generating pairs of amicable numbers using Linq. This post explains what they are, and how I went about it.
I was browsing the latest C# questions on StackOverflow, and came across one that caught my eye. Sadly, it was quickly closed by people who, in my opinion, didn’t read it properly. The question was…
I am trying to write a program to find the factor of a number with minimum difference. For Ex: for 20 it should be 4×5 or vice versa. How can this be achieved for a really BIG number. lets say 989287498274928743928174192847219347123984723498. Please guide
Ignoring the usual SO rules about showing some effort or research, the question is not simply “How do I find the factors of n?”, which is what all the linked answers were about. This question was how to find the two closest factors. Sure you can do that by finding them all, then sorting them by their difference, but for a big number, that’s hugely inefficient. There are ways of solving this specific question much more efficiently, which is what I decided to do.
The latest in my vague series of posts about using LinqPad to query the schema of a database, and extract information about the database as a whole. In this case, it was finding the number of rows in each table, and whether any were empty.
Inspired by a long-defunct billboard advert, I coded up a Linq expression to find the first 10-digit prime found in consecutive digits of e. This turned out to be disappointingly easy
Ever wondered what the prime factors of your telephone number are? No, nor had I until I read Humble Pi. A throwaway comment there led me to contemplate how to do this in a single Linq statement.
Why? Why not?
Faced with the task of modifying every varchar(n) column of every table in a database to be varchar(max), whilst avoiding default constraint errors, I came up with a script to generate the SQL for me.
Our tables (well, most of them, see below) have a primary key named ID, and we make the (foolish it seems, see below part II) assumption that if an entity has a zero ID, then it is new. I was trying to work out the cause of a bug today, whereby a new entity was being treated as if it already existed, and discovered that the problem was caused by there being a row in the database that had a zero ID. Hmm, bleah and other such words of exasperation. As it happened, the particular row in question was marked as (soft) deleted, so I just altered the code to exclude such entities (which it probably should have done in the first place) and all was well. Well, not quite. You see this got me wondering. How many other tables have a row with a zero ID. Obviously, any table…
I’m not under any illusions that anyone actually reads this blog, I mainly use it as a place to keep my discoveries, as I have a lousy memory, and would never be able to find them otherwise! A case in point was a data query I was asked to do this afternoon. A project’s database includes a table of users, and a table of countries, with a joining table to specify which users are responsible for which countries (this is a many-to-many relationship for reasons that are not relevant to this post). The client wanted a spreadsheet where each row contained one country. This sounded similar in structure to a query I did some time ago, where I discovered an overload of the Linq SelectMany method that I had never used before. Sadly, I had not blogged about it, so couldn’t find the notes. Not making that mistake again, so…
Leave a Comment