The SitePoint PHP blog has a recent post looking at time complexity in the algorithms you develop in your PHP applications and how that relates to "Big O notation". Big O notation is simply a way of expressing complexity and performance of a method in a less subjective way than "it's faster than.."

If you are a web developer or a programmer in general, you have most likely written algorithms for various tasks. [...] One specification of an algorithm is its correctness. You will probably assume that your algorithm works after testing it out a few times. However, if you can mathematically prove that your algorithm will work as expected for every input value possible, this is a huge bonus. I will not go further in to that subject in this writing. Another specification is its efficiency: how does the computing time relate to the amount of input? Is it a linear relation? Does computing time rise exponentially for the doubling of input? That’s what this article will be about.

He starts by talking about the concept of "time complexity" and how it relates to the overall efficiency of the algorithm. He then gets into the definition and examples of Big O notation, including code showing O(n) and O(n²) methods. He talks some about inefficient and efficient algorithms and follows with a refactoring example of moving from one to the other.

Timothy Boronczyk has a recent post to his site with an interesting thing to use PHP for - composing music.

I'm not an expert on probability theory, artificial intelligence and machine learning, and even my Music 201 class from years ago has been long forgotten. But if you'll indulge me for the next 10 minutes, I think you'll find that even just a little knowledge can yield impressive results if creatively woven together into an application. I'd like to share with you how PHP can be taught to compose music.

He shows examples of some basic melodies generated by PHP (not the prettiest) and talks about how he "taught" PHP to get better at it. He transcribed other music into Scientific Pitch Notation and used a Markov process to create a "next note selection" method based on the notes around it. He includes the code for his "robot composer" class with its "train" and "compose" methods and and example of its usage.

Freek Lijten has put together a new post to his blog looking at a method for showing how complex an algorithm is without having to get too deep into how it works - the big O notation (with examples written in PHP).

I'd like to share a topic today which was re-introduced to me by a lightningtalk of a colleague of mine. His talk was on the "big O notation". The big O notation is a tool you can use to express the order of complexity of an algorithm. It is useful because it lets you express the order of complexity of an algorithm without taking a lot of time profiling or researching the underlying algorithm. In other words: it gives you a quick way to gain an understanding of what might be wrong (or right) with a specific algorithm.

He introduces the notation as the result of a series of steps needed to solve a problem (ex. 2+2 is less complex than 2+2+2). He illustrates with PHP examples that show adding complexity to a class, adding sets of numbers, looping to find needles in haystacks and finding duplicates in an array of strings. Each of these expand on the theory and show more complexity as the article progresses.

In a new post to his blog Justin Carmony talks about a few "itches" he's wanted to scratched when it comes to features of the PHP language - in this post it's the notation that's used surrounding the use of objects.

At the end [of Marco's post to his blog], he states it ultimately boils down to find a better way to bring features build downstream back upstream. So I thought I would do my part by first my blogging about a few "itches" I'd love to see scratched. My first itch would be some form of Object Notation for PHP.

He talks about the notation method that Javascript has always had and how it can help to make objects more flexible by not forcing their creation through a method/argument interface. He offers one potential solution - using arrays for settings values - but notes that it could be more trouble than it's worth in the implementation. He proposes a new sort of notation instead, one that allows the passing of something similar to the Javascript JSON-ish definition of values and callbacks as anonymous functions.

David Otton has a handy little tip if you're looking for a cleaner way to deal with array data - casting it to an object.

Array notation is fine, but it can look a bit clunky when you're working with complex structures. [...] Casting the array to an object allows us to use object notation (->) and makes the code more readable.

He includes examples of the casting, showing the difference between the array and object notations including a method for creating an object based on a simple array that has basic properties built in. This sort of transformation can be useful if you want consistency through out the application - just passing objects with their properties rather than arrays.

As a follow up to a previous post where he discussed reverse polish notation, Nick Halstead has decided to split off the code he created for that previous post into a new, sleeker post without much of the explanation and heavy on the code.

My last post about back to basics covered reverse polish notation including a link to a RPN parser which I wrote to allow people to learn by example (best way in my opinion and in yours). The post got quite long and the PHP code was not really relevant to the subject so I have decided to include in this separate post instead.

There's two parts to the post - a pseudo-code explanation that an overview of how things work and the actual code, a block of code (in the 30 line area) that runs through each item and, based on a token, pushes the value into the array differently.

As a follow up to a previous post where he discussed reverse polish notation, Nick Halstead has decided to split off the code he created for that previous post into a new, sleeker post without much of the explanation and heavy on the code.

My last post about back to basics covered reverse polish notation including a link to a RPN parser which I wrote to allow people to learn by example (best way in my opinion and in yours). The post got quite long and the PHP code was not really relevant to the subject so I have decided to include in this separate post instead.

There's two parts to the post - a pseudo-code explanation that an overview of how things work and the actual code, a block of code (in the 30 line area) that runs through each item and, based on a token, pushes the value into the array differently.

According to this post on the Utah PHP User Group's website today, there's been talk of adding JSON support to the Core portion of the PHP distributions.

There has been some recent activity on the PHP Developer mailing list about the addition of JSON into the PHP Core. After reading the thread, I did a little research on JavaScript Object Notation (JSON). Here is a great website to read more about it.

You can check out the discussion over on the archived copy of the php-dev mailing list...

According to this post on the Utah PHP User Group's website today, there's been talk of adding JSON support to the Core portion of the PHP distributions.

There has been some recent activity on the PHP Developer mailing list about the addition of JSON into the PHP Core. After reading the thread, I did a little research on JavaScript Object Notation (JSON). Here is a great website to read more about it.

You can check out the discussion over on the archived copy of the php-dev mailing list...