On Wed, 15 May 2013 23:46:07 +0200, Christian Froeschlin <chr### [at] chrfrde>  
wrote:

> Nekar Xenos wrote:
>
>> ObjectCenter =  
>> min_extent(Object)+.5*(max_extent(Object)-minExtent(Object))
>
> Or 0.5*(min + max) if you're a fan of distributive law ;)
>
> Also note that min/max_extend is actually the bounding
> box and may not yield the expected position for all objects.
>

It seems it's too long since I've done proper algebra. Your solution makes  
perfect sense, yet can't seem to get from my solution to yours  
algebraically.

-- 
-Nekar Xenos-

Post a reply to this message

>>> min_extent(Object)+.5*(max_extent(Object)-minExtent(Object))
>>
>> Or 0.5*(min + max) if you're a fan of distributive law ;)
> 
> It seems it's too long since I've done proper algebra. Your solution 
> makes perfect sense, yet can't seem to get from my solution to yours 
> algebraically.

an algebraic mystification that is easily resolved ;)

   1.0 * min + 0.5 * (max - min)
= 1.0 * min + 0.5 * max - 0.5 * min
= 0.5 * min + 0.5 * max
= 0.5 * (min + max)

Post a reply to this message

On 16/05/2013 9:55 PM, Christian Froeschlin wrote:
> an algebraic mystification that is easily resolved ;)
>
>    1.0 * min + 0.5 * (max - min)
> = 1.0 * min + 0.5 * max - 0.5 * min
> = 0.5 * min + 0.5 * max
> = 0.5 * (min + max)

You are right of course.
But why put that "1.0 + " on the first line?

I think of it (the first line), from my mid 20th Cent schooling, as:
Half of the difference between max and min plus the "offset" of min.


-- 
Regards
     Stephen

Post a reply to this message

On Thu, 16 May 2013 22:55:38 +0200, Christian Froeschlin <chr### [at] chrfrde>  
wrote:

>>>> min_extent(Object)+.5*(max_extent(Object)-minExtent(Object))
>>>
>>> Or 0.5*(min + max) if you're a fan of distributive law ;)
>>  It seems it's too long since I've done proper algebra. Your solution  
>> makes perfect sense, yet can't seem to get from my solution to yours  
>> algebraically.
>
> an algebraic mystification that is easily resolved ;)
>
>    1.0 * min + 0.5 * (max - min)
> = 1.0 * min + 0.5 * max - 0.5 * min
> = 0.5 * min + 0.5 * max
> = 0.5 * (min + max)

Of course. It helps to write it down and not just try and solve it in my  
mind ;)

-- 
-Nekar Xenos-

Post a reply to this message

On Thu, 16 May 2013 23:17:42 +0200, Stephen <mca### [at] aolcom> wrote:

> On 16/05/2013 9:55 PM, Christian Froeschlin wrote:
>> an algebraic mystification that is easily resolved ;)
>>
>>    1.0 * min + 0.5 * (max - min)
>> = 1.0 * min + 0.5 * max - 0.5 * min
>> = 0.5 * min + 0.5 * max
>> = 0.5 * (min + max)
>
> You are right of course.
> But why put that "1.0 + " on the first line?
>
> I think of it (the first line), from my mid 20th Cent schooling, as:
> Half of the difference between max and min plus the "offset" of min.
>
It did help to clarify the issue though.

-- 
-Nekar Xenos-

Post a reply to this message

On 17/05/2013 4:24 AM, Nekar Xenos wrote:
> On Thu, 16 May 2013 23:17:42 +0200, Stephen <mca### [at] aolcom> wrote:
>
>> On 16/05/2013 9:55 PM, Christian Froeschlin wrote:
>>> an algebraic mystification that is easily resolved ;)
>>>
>>>    1.0 * min + 0.5 * (max - min)
>>> = 1.0 * min + 0.5 * max - 0.5 * min
>>> = 0.5 * min + 0.5 * max
>>> = 0.5 * (min + max)
>>
>> You are right of course.
>> But why put that "1.0 + " on the first line?
>>
>> I think of it (the first line), from my mid 20th Cent schooling, as:
>> Half of the difference between max and min plus the "offset" of min.
>>
> It did help to clarify the issue though.
>

I am not criticizing, it is interesting and educational to know how 
others see and do things. Is that a mathematicians view?

And why multiply by a half instead of dividing by two? Is that more 
computer/CPU friendly?

-- 
Regards
     Stephen

Post a reply to this message

Le 17/05/2013 12:31, Stephen a écrit :
> And why multiply by a half instead of dividing by two? Is that more
> computer/CPU friendly?

It might.

If the compiler/interpreter does not catch that the operation is easy to
perform with a single decrement of exponent (in case of IEEE-754 float)
or a single bit shift (in case of integer), the used assembly code is to
use the multiply opcode, instead of the divide opcode.

Division at opcode-level is far more cycles-hungry than a
multiplication. (especially with float format, but prediction on current
CPUs is dependent on too many variables to assert that without actual
benchmark)

Now, beware of premature optimisation.


It might also be just a style of programming (*0.5) to keep the equation
on a single text line. (whereas the /2 would need a 2 lines on
graphically accurate display)

Post a reply to this message

Stephen wrote:

> You are right of course.
> But why put that "1.0 + " on the first line?

purely educational ... it help to see how a rule like

a * c - b * c = (a - b) * c

applies here.

Post a reply to this message

Christian Froeschlin wrote:

> purely educational ... it help to see how a rule like
> 
> a * c - b * c = (a - b) * c
> 
> applies here.

and dito for writing 0.5 * c instead of c/2.

Definitely not intended as compiler optimization ;)

Post a reply to this message

"Nekar Xenos" <nek### [at] gmailcom> wrote:
> Of course. It helps to write it down and not just try and solve it in my
> mind ;)

Whoa!  I don't even try.  (I sometimes have to use pencil and paper just to
compute microwave cooking time!)

People who know that I'm good at math are surprised to learn that I cannot do
math in my head.  But remember, the human brain did not evolve to do math.

Post a reply to this message