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

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

On Do, 2013-09-12 at 06:07 -0500, Christopher Felton wrote:
> On 9/10/13 5:20 PM, Benjamin Berg wrote:
> > 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/.

Yeah, returning a /fixbv/ is the best solution.

> > 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

Yup, that solves the issue.

>     >>> 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.

Hm, yes. So the x which originally was (8,3,4) now becomes (9,4,4)
because of the addition. This does make a lot of sense.

> > 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.

I agree that this is the sanest solution :-)

> > 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.

Ah. It seems to me like this could be interesting when adding a
constant; but it needs careful thought on what the effect on the min/max
values of a returned fixedbv is (assuming a fixedbv is returned).
Throwing an error would not block adding such a feature later on.

Thanks for looking into this,
Benjamin