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

[Benjamin B. <ben...@si...>]

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.

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!

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.

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.

Benjamin

[1] I am actually very surprised that calculations with /intbv/s have an
integer result and not an intbv result with the min/max values kept up
to date.