If a battle at sea happened today, then yesterday the statement was true "there will be a sea battle tomorrow." Likewise, if no battle occurred - yesterday, it was true that "there will be no sea battle tomorrow."
Will there be a sea battle tomorrow?
Aristotle and Hegel both point out that this is predicated on knowledge of the future, so the answer is that we don't know. As Hegel points out, "wisdom comes at dusk".
Suppose that nobody actually wants a battle, but the ultimate universal (divine) plan calls for one. If the divine plan requires it, then surely the will of the combatants is irrelevant and they will go out and (sadly) sink one another. If the will of the combatants overrules the plan, then there will be no battle - but the divine plan will be unfulfilled. If the divine plan involves insuring that enough participants want to fight, then is the will of the combatants truly free?
The simple logical approach is to simply say that the status of a battle tomorrow is undefined until the end of tomorrow. There is no answer, and the question of free will vs. predestination is irrelevant.
An absolute predestination view is that the answer is firmly defined, unchangeable - even if we don't actually know what it is (so we can pretend it was our idea).
A weak predestination view ("foreknowledge does not mean causality") would say that since the divine knows our hearts, it knows what we will choose - but we still make the decision. In that case, if God doesn't want a battle tomorrow, but knows that we are going to have one anyway, can he do more than sigh sadly from the heavenly grandstand?
A selective predestination view (God picks the important events only) requires that the answer be important to a divine plan. If it isn't important, then we have free will. If it is important, we don't. (What counts as important? Who knows!)
Tuesday, November 17, 2009
Thursday, April 23, 2009
Sunday, March 8, 2009
Mobile!

I picked up a cheap moped! Given that bus prices have doubled in a year (and are likely to rise again), and gas/petrol prices are rising once more... I decided that a cheap form of transportation was needed. It's Chinese, so it probably won't last - but as long as it lasts a year, it's a saving over the bus!
So far, I've ridden it twice. Once as a test drive, and once back from the dealership (about 2 miles). Very nice smooth ride, comfortable, and I didn't feel like death was imminent. ;-)
Monday, January 5, 2009
MySQL Wierdness
I don't use MySQL very often (happy PostgreSQL user), but I had occasion to use it for a client recently. A proxy server spits out log entries into a very large database table, which is then queried through a web interface. The table has an index for the date/time, and an index for a text field explaining what the proxy did. It won't permit the generation of an index for both, since that exceeds the key-size limit.
The following query runs great, and properly uses the datetime index (the limit is because it's used for a dashboard display):
SELECT * FROM log ORDER BY datetime DESC LIMIT 50;
This query runs great, too:
SELECT * FROM log WHERE what LIKE '*DENIED*%' LIMIT 50;
In both cases, the optimizer correctly picks the index - and the query runs really fast. However, when one attempts to combine the two, life is not so great:
SELECT * FROM log WHERE what LIKE '*DENIED*%' ORDER BY datetime DESC LIMIT 50;
The query takes a really, really long time to run! EXPLAINing the query shows that it uses the index correctly for "what", but then performs a filesort for the date sort! Since adding a large amount of very-high-performance temporary file storage isn't an option here, there's a problem. Digging into the MySQL documentation, it turns out that MySQL can't perform an ORDER BY using an index if a WHERE clause uses a different index! It was actually several thousand times faster to read the results into PHP sorted and perform the string comparison there. Gahh!
The following query runs great, and properly uses the datetime index (the limit is because it's used for a dashboard display):
SELECT * FROM log ORDER BY datetime DESC LIMIT 50;
This query runs great, too:
SELECT * FROM log WHERE what LIKE '*DENIED*%' LIMIT 50;
In both cases, the optimizer correctly picks the index - and the query runs really fast. However, when one attempts to combine the two, life is not so great:
SELECT * FROM log WHERE what LIKE '*DENIED*%' ORDER BY datetime DESC LIMIT 50;
The query takes a really, really long time to run! EXPLAINing the query shows that it uses the index correctly for "what", but then performs a filesort for the date sort! Since adding a large amount of very-high-performance temporary file storage isn't an option here, there's a problem. Digging into the MySQL documentation, it turns out that MySQL can't perform an ORDER BY using an index if a WHERE clause uses a different index! It was actually several thousand times faster to read the results into PHP sorted and perform the string comparison there. Gahh!
Subscribe to:
Posts (Atom)
