Today we review the codejam question to determine the number of intersection point between lines connecting floors of two buildings.
In this case the connectors could connect floors at the same level or those above or those below on the opposite side. There is only one connector on each of the floors. The connectors intersect only when there is a  span across other connectors.
To determine the number of intersection points, we only need to look at the connectors that span others. This happens only in two cases - when the connectors connect floors above or when the connectors connect floors below. In each of those cases, if there are other connectors in their way, their endpoints would be within the range from the start to the end of the current connector. We can choose either the starting endpoints or the finishing endpoints and they could be different for the two cases. In both cases we will have to exclude one of the endpoints to determine the number of intersections. Intuitively, we are articulating that the intersections arise from connectors that lie within the start and the end of the chosen connector. If there are no intersections, the lines are parallel even if they are not horizontal and their start and end will not have the beginning or end of any other connectors within their start and end.

Now back to AWS Billing:
we were discussing how to archive the metrics

CREATE TABLE [dbo].[Metric]
(
[ID] INT NOT NULL PRIMARY KEY IDENTITY,
    [Label] NVARCHAR(50) NOT NULL DEFAULT 'UNKNOWN',
    [Created] DATETIME NOT NULL DEFAULT getdate(),
    [Value] REAL NOT NULL DEFAULT 0.00,
    [Type] NVARCHAR(50) NOT NULL DEFAULT 'Gauge',
    [Units] NVARCHAR(50) NOT NULL DEFAULT 'NA',
    [Service] NVARCHAR(50) NULL,
    [Region] NVARCHAR(50) NULL,
    [InstanceID] INT NULL,
    [ClusterID] INT NULL,
    [ProjectID] INT NULL,
    [Created By] NVARCHAR(50) NULL
)

GO

CREATE INDEX [IX_Metric_Created] ON [dbo].[Metric] ([Created])

GO

DECLARE @ID INT;
while EXISTS(SELECT * FROM Metric WHERE Created < '2014-01-01')
BEGIN
SELECT @ID=ID FROM Metric WHERE Created < '2014-01-01'
INSERT INTO Archive (Label, Created, Value, Type, Units, Service, Region, InstanceID, ClusterID, ProjectID, [Created By])
SELECT Label, Created, Value, Type, Units, Service, Region, InstanceID, ClusterID, ProjectID, [Created By] from Metric WHERE ID = @ID;
DELETE FROM Metric WHERE ID=@ID;
SELECT @ID=ID FROM Metric WHERE Created < '2014-01-01';
END

How do we calculate the CPU instance hours from AWS metrics?
Its true that AWS Metrics use the term CPUCredit which does not immediately tell us how many vcpu we are talking about. But this jargon is much more informational, true and accurate as we will see. In fact, they have a concept of CPUCreditUsage and CPUCreditBalance. So what is a CPU credit ? One CPU Credit is equal to one vCPU running at 100% utilization for one minute. Other combinations of vCPUs, utilization and time are also equal to one CPU credit for example one vCPU running at 50% utilization for two minutes etc. We can translate minutes to hours as well. In this case we can have 1/30 CPU credits for an hour which is equivalent to 1 CPU Credit
We say it is informational because it is not merely based on the static allocation of the number of cpus and instead based on the usage and balance of the utilization. This leads to the question how are CPU Credits earned ? Each instance for example a T2 instance  starts with a healthy initial CPU credit balance and then continuously receives a set rate of CPU credits per hour. This accounting is done at a millisecond level resolution and it ensures a maximum earned CPU credit balance for example 144 CPU credits  for a t2.micro. Thus these metrics are much more true and accurate. There are two metrics associated with CPU Credits - one is CPUCreditUsage and another is CPUCreditBalance. The CPUCreditUsage metric indicates the number of CPU credits used during the measurement period The CPUCreditBalance metric indicates the number of unused CPU Credits a T2 instance has earned. The CPUCreditUsage identifies the amount of time during which the physical CPUs were used for processing instructions by virtual CPUs allocated to the instance. Therefore this metric can directly be used to generate the bill. Moreover the CPU Utilization metric is aggregated for the number of cpus that instance may have. A t2.medium instance has two vCPUs and if one of them is at 100% and the other is rarely used, the CPU Utilization metric will show 50%.