Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: Table 4 proposal version 0.1...

On 02/29/2012 06:04 PM, Dan Zuras Intervals wrote:

I made a proposal which is mathematically sound and uniform (and is
the only mathematically sound choice), but conflicts with your
definition on unbounded intervals, which _is_ in the proposal.

Taking infinity as the midpoint of [0,Inf] is against all common sense
as it is as far from any point of the interval as is conceivable.
No midpoint in any conceivable interpretation. There is no midpoint,
and the result should reflect that. Labeling Inf as 'the' midpoint is
misleading,


	Ah, so this is something OTHER than midpoint(Empty).

	Very well.

	If you read the proposal very carefully, you will find
	that the level 2 midpoint returned for any semi-infinite
	interval is finite.  Thus the split of [0,inf] becomes
	[0,Fmax] \union [Fmax,inf].

	However, I agree that calling Fmax the midpoint is nearly
	as misleading as calling infinity the midpoint would be.

	I originally had something like (0+Fmax)/2 as the midpoint
	but Michel made an argument that Fmax was better.  I must
	admit I resisted that argument for a time but I believe
	his reasoning leads to a better (that is, simpler&  more
	useful) split than I had in mind.

	It is a compromise.  Many choices are possible.  All of
	them have something arbitrary to their nature.  It is our
	job to pick one&  stick with it.

	Do you have a better choice?
NaN is the only consistent choice. An unbounded interval has no midpoint; so the standard shoudn't invent one just to return a finite answer. 



Many problems have bounds [0,1], and your proposal would split this
interval somewhere close to the sqrt of the smallest normalizable
number. This produces a tiny interval (containing half the floats)
and an interval essentially as wide as before (containing the other
half). For most functions people would apply b&b to, this is a totally
unproductive split.


	You are quite correct.  And such a split should not be used
	in this case.
But the whole point of a split routine is to say where to split. So it should 't be in the standard, becaus good splitting depends on many things. It is not an elementary operation with a fixed semantics. 



	But there are many scale free problems where even the
	exponent of the answer is not known.  Various astronomical
	questions come to mind.  The Drake equation is a simple
	example.

	Non-astronomical applications include monte-carlo
	calculations which involve computing probablities that
	are logrithmically distributed with [0,1].  Answers tend
	to be small&  a logrithmic split would take substantially
	fewer steps than an arithmetic one.
But this has nothing to do with split. None of these instances need a split operation!