On 06/01/16 18:18, Roland Scheidegger wrote:
Am 06.01.2016 um 17:31 schrieb Jose Fonseca:
On 06/01/16 16:26, Jose Fonseca wrote:
On 06/01/16 00:06, srol...@vmware.com wrote:
From: Roland Scheidegger
The trick here is to recognize that in the c + n * dcdx calculations,
not only can the lower
Am 06.01.2016 um 17:31 schrieb Jose Fonseca:
> On 06/01/16 16:26, Jose Fonseca wrote:
>> On 06/01/16 00:06, srol...@vmware.com wrote:
>>> From: Roland Scheidegger
>>>
>>> The trick here is to recognize that in the c + n * dcdx calculations,
>>> not only can the lower FIXED_ORDER bits not change (a
On 06/01/16 16:26, Jose Fonseca wrote:
On 06/01/16 00:06, srol...@vmware.com wrote:
From: Roland Scheidegger
The trick here is to recognize that in the c + n * dcdx calculations,
not only can the lower FIXED_ORDER bits not change (as the dcdx values
have those all zero) but that this means the
On 06/01/16 00:06, srol...@vmware.com wrote:
From: Roland Scheidegger
The trick here is to recognize that in the c + n * dcdx calculations,
not only can the lower FIXED_ORDER bits not change (as the dcdx values
have those all zero) but that this means the sign bit of the calculations
cannot be
From: Roland Scheidegger
The trick here is to recognize that in the c + n * dcdx calculations,
not only can the lower FIXED_ORDER bits not change (as the dcdx values
have those all zero) but that this means the sign bit of the calculations
cannot be different as well, that is
sign(c + n*dcdx) ==
