Re: [myhdl-list] fixed-point thoughts : part two

[Christopher F. <chr...@gm...>]

On 9/10/13 5:20 PM, Benjamin Berg wrote:
> Hello,
>
> I think there are some serious issues with the behaviour that you are
> suggest. The fact that two fixedbv added together should return an
> integer (instead of a floating point value) alone opens a *huge* can of
> worms.

I agree, an oversights on my part. I disagree that a
floating-point value can be used.  The operations need
to return a /fixbv/.

>
> Lets take your example:
>
> On Mi, 2013-09-04 at 22:28 -0500, Christopher Felton wrote:
>>       >>> x = fixbv(0,min=-8,max=8,res=1/16.)
>>       >>> y = fixbv(0,min=-1,max=1,res=1/128.)
>>       >>> x + y
>>       AssertionError: Add: points not aligned
>>              fixbv(0.00, format=(8,3,4), ) and fixbv(0.00, format=(8,0,7), )
>
> A nice assertion error, but now, if I did:
>        >>> x + x + y
> Then the result:
>   1. is not quite defined (either it is wrong, or results in really
> surprising behaviour, see below)
>   2. doesn't throw any error!

Concur, for the operations a /fixbv/ object should
be returned.  The "book-keeping" needs to occur through-out
a complex operation.  As you note, if /x+x/ returns an /int/
the trailing /int + y/ will encounter incorrect behavior.

Updating the operation to return a /fixbv/, an error will be
thrown for the example provided

    >>> x = fixbv(0,min=-8,max=8,res=1/16.)
    >>> y = fixbv(0,min=-1,max=1,res=1/128.)
    >>> x + x + y
    AssertionError: Add: points not aligned
       fixbv(0.00, format=(9,4,4), ) and fixbv(0.00, format=(8,0,7), )

Note the intermediate format changed, it has to accommodate
the intermediate range.

>
> The same issue occurs when assigning the result of an operation to a new
> fixedbv type. You do not get *any* error checking whether the point is
> still at the same spot. The only way around this would be to either
> return a fixedbv for any operation that happens[1], or a floating point
> number.
>
> Note that as a direct consequence the following code:
>   >>> int(fixedbv(1.25,min=-8,max=8,res=1/16.)
> would need to return 20. I personally would expect 1 to be returned.

This example, 1 is returned and not 20.

>
> The same turned, what about:
>   >>> fixedbv(1.25,min=-8,max=8,res=1/16.) + 1
> To be consistent with the suggestion, this would result in 1.3125. Not
> something I would expect.

Currently, it would throw an error.


Thanks for the comments, I will update part II with this
correction.

Regards,
Chris Felton