This thread reminds me why I visit this site at least daily.
My next visit probably <= 1 day

john

In posts #37 and #41 I concentrated my attention on the gap in your chart. Now I concentrate on the filler. The most filled range is 100–299. That’s the next probable prediction.

As I mentioned that in the post #30 the more algorithms one tries closer to the actual value one of the results locates. Then is enough to publish the link to that one, amazing “prediction” to become the marvelous clairvoyant.

The best forecasters so far (according to their own claims):

1. Didier Spaier – 100% (“sometimes between now and never” post #39).

2. w1k0 – 99.99% (“no less than 7 days and no more than 2 years after the previous release” post #37).

3. allend – 99.7% (“between April 17 2013 and February 11 2014” post #32).

(The other forecasters didn’t try to forecast the percentage of their own accuracy.)

A Julian year, used in astronomy, is exactly 365.25 days.

734,942 days / 365.25 = 2012.161533196 years elapsed (the function calculates Julian Day Numbers, those used in astronomy); 0.16533196 x 365.25 = 59 days (rounded); there are 72 days elapsed from 01/01/2013 through 03/14/2013 -- where's the missing days? Well, keep in mind that you're talking about days -- there have been 5 leap centuries, 400, 800, 1200, 1600 and 2000 (the century year must be equally divisible by 400), none of them actually accounted for in the 10 days removed from the calendar in 1582 (the entire effort was to get the spring equinox to fall on 21 March instead of where it had slipped to, 11 March, by 1582; the whole thing had to do with the calculation of Easter dates).

This all gets real complicated after a while. a year is about 11 minutes shorter than 365.25 days, so we have leap years every 4 years (or 400 years for the century years (1900 was equally divisible by 4 but not by 400 and so on).

So, why the difference? It's a Pfudge Pfactor to correct the Gregorian calendar dates to Julian Day Number (remember Julian Day Numbers are astronomical, not political or religious). Conversion from a Julian Day Number to a Gregorian calendar date involves a pfudge: here's the code to do the conversion:
You invoke this function with the Julian Day Number, it returns month, day and year to the caller.

Your value is correct, it is the number of days; 01/01/01 was Saturday, by the way. You can double check that at http://www.nr.com/julian.html if you'r like.

If you're really interested, see the calculation method at http://en.wikipedia.org/wiki/Julian_day#Calculation. Another good source is the US Naval Observatory web site which explains, in detail, what's what.

Hope this helps some.

1 members found this post helpful.

release date: no less than 7 days and no more than 2 years after the previous release date

release version: no less than +0.1 and no more than +6.0 added to the previous release version

accuracy: 99.99% (the same as before but that’s the parlay).

Thanks tronayne, very enlightening.

That's why I didn't do one. However, the scatter plot shows that if you were to do regression analysis, a linear regression would be the most suitable and give the result you predicted.

It is rather difficult to estimate the confidence interval for the time between 14.0 and 14.1 because we can't assume independence between the release dates and it will be heavily influenced by developments in the Linux community. In cases like these, it is probably best to just draw a picture and let everybody make their own guess.

The secret is in finding the appropriate conditions to derive a conditional probability. In this case I observe a flurry of activity in the changelog, and assuming a minor release step, I'd expect a new release rather soon. Maybe 200 days after the last, maximum 300 (looking at 13.1, 12.1, 10.1, 9.1).

I hope that no one is taking this seriously because it is just fluff and nonsense

For making my prediction, I used a linear regression and then calculated the bounds from the slopes of lines with the regression slope +/- 3 standard errors. These are the red lines in the attached graphic.
If the bounds are calculated by also including the constant term +/- 3 standard errors, the green lines in the attached graphic, then the prediction becomes a release between January 21 2013 and May 8 2015.
In a normal distribution, 99.7% of values are expected to fall between +/- 3 standard deviations of the mean. Interesting to note that the only release that falls outside the green lines was the release that came 7 days after the last.

Attached Images

releases.png (15.8 KB, 26 views)

Thing is, in spite of calling it Coordinated Universal Time (UTC is the French abbreviation), there's nothing universal about it; the standard we use is the spinning of our particular ball of rock (the guys at JPL that work with the Mars rovers live and work on the spin of that rock -- makes you wonder about human hubris, eh?).

The calendar month names are Roman: gods (January, March, May, June), rulers (July, August), sacrifice and purification (February), trees opening (April), plants growing (May) and numbers (September, 7th month; October, 8th month); November (9th month); December, 10th month) -- the year used to begin in March, not January. When Caesar reorganized the calendar (and added leap years) he made the year start in January but kept the old names. They had names for days in the month: 1st, Kalends; 7th, Nones; 15th, Ides. The Romans did not have weeks, life just went on, day by day.

The Julian calendar is still used by Eastern Orthodox national churches and has slipped further and further (so Christmas is celebrated in January -- the 7th, 8th or 19th Gregorian). No leap centuries, you see.

Julian Day Number ignore all that stuff, just counting days. Conversion to (whatever) calendar date has to account for all the extra days (Roman rulers added holidays willy-nilly that were not counted, they just sort of... vanished) and Middle Ages calculation errors.

It's all so confusing. But, if you're doing something that requires day and dates over years, decades or centuries, Julian Day Numbers are really handy for calculating things and converting back and forth between calendar dates.

And all is well that ends.

The explanation is in ANNONCE.TXT for Slackware 4.0:and in README39.TXT:So I consider 3.9 and 4.0 more like two variants or branches than two consecutive releases. Or to use Pat's own words Slackware 3.9 is a special edition of Slackware 4.0.

Anyway, thanks to the friends @ slackware.no to mirror all Slackware releases since slackware-1.1.2, this is very nice of them.

@tronayne: In French we would say "Temps Universel Coordonné". According to this article from Wikipedia UTC is a compromise abbreviation between CUT and TUC and can be read either in unofficial English: "Universal Time Coordinated" or in unofficial French: "Universel Temps Coordonné". I'm not sure that this clarification deserved a post, but here it is.

And, thank you, I stand informed (my knowledge of French is roughly equivalent to my knowledge of Latin or which I have forgotten everything I never quite knew).

I wonder though, tongue firmly in cheek, is that old French, new French, borrowed or blue French?

I think the French are still pissed off about the Prime Meridian going to Greenwich: In 1884, at the International Meridian Conference held in Washington, D.C., 22 countries voted to adopt the Greenwich meridian as the prime meridian of the world. The French argued for a neutral line, mentioning the Azores and the Bering Strait but eventually abstained and continued to use the Paris meridian until 1911.

And so it goes.

Voodoo

Here’s the file including the data:

slack
Here’s the file including the commands:

gnuplot
Here’s the command:

gnuplot -p gnuplot

Here’s the result:

slack.png

(I don’t like too much the graphs with voodoo axis so I used the meaningful data for both X and Y.)

I don't think "release" can be put on a real line without taking serious liberties with interpretation, which is why I called it voodoo. My X axis is not a mystery: it's just 13.0 for ver. 13.0, 13.1 for ver. 13.1, etc. But assigning it this way is just as arbitrary as mapping each release to an integer, or whatever is that you did... After all, the version assignment is a random experiment from hell; it is dependent on everything, including this thread. What is your first column anyway?

And using trend here is also questionable: the correlation coefficient is pretty low, the spread is huge, and so it is far from certain that the mean went up. But for purely gambling purposes I would bet on the trend, probably because I always found pictures very convincing