Re: [boost] Some follow-up on my fixed point code, and safe integers

From: Maurizio Vitale (mav_at_[hidden])
Date: 2007-04-28 14:04:29

"John Femiani" <JOHN.FEMIANI_at_[hidden]> writes:

> I have seen Phil's code, but I wonder if Maurizio is willing to offer a
> peak at the proto-fied library he is working on as well? 

I've no problems in making my code available as I go, but I'm still
working on porting to proto some of the code I did write before proto
was widely announced. If I can finish that port I'll post the result
as 'work in progress' around the end of next week.

That part was using my horrible homegrown expression templates, but
had the nice property of working, something you cannot underestimate
in software development. And I was getting nice vibes from looking at
the assembly code produced.

In the meantime I might write up something on the features I'm trying
to implement, both for discussion and as a starting point for
documenting my code.

But I'd like to stress an important point: I'm not in the immediate
working on a boost library, rather I want to replace the SystemC datatype
implementation with something:

     - much shorter (right now the OSCI SystemC implementation weights
       at about 15K lines of code, I want to get as near to zero as possible)

     - more efficient (by using expression templates there more domain
       specific optimizations that can be done)

This means that I've to do a few things that are probably of no
interest to a wider community. For instance in SystemC you have a
class sc_int<N> that behaves like you'd think, but it is defined to
inherit from a class sc_int_base that takes the width as a constructor
parameters. This width cannot be changed after construction, so you'd
question why to have it at run time at all. Still I need to allow
bounds to be optionally specifiable at run-time.  For now I'm doing
good and you pay for bounds only when you actually want to specify
them at run-time, otherwise (with decent EBO) they just disappear.

Similary, there're things that might be interesting for some people
and I'm not implementing immediately (but leave hooks in the
framework). For instance I'm allowing multiple logical representations
for integers, but at the beginning I'll implement only magnitude (for
unsigned) and two_complement (for signed). Later, I'll support
sign-magnitude and one-complement.  I've ruled out for instance
polarized numbers (e.g. numbers w/ offset as used often in exponents
of floating point values) because it would be a place where the
logical representation needs to be parametrized.

Also, for now I'll support access to bitfields inside numbers only to
the extent required by SystemC.  The right thing to do would be to
allow for the specification of a phyisical layout (simple application
is the definition of different endianesses than the host machine. I
did it with a previous employer and I know how to design the framework
to allow for the plugin of this part later, but is a big project on
its own.

> I am curious to
> see the different approaches and also I wonder if either of you are
> willing to consider non power-of-two scaled values. 

Not in the first implementation. Later I'd like to let people specify
bounds as a MIN and MAX value, rather than bitwidths, but this wouldn't
be what I think you mean here.

If you allow for arbitrary scales, you get into what Ada called 'the small'.
This is basically the weight of the lsb in your significand. And even them,
they required compilers to implement only power of two.
There're nasty things that happen with arithmetic when numbers with
arbitrary (and different) smalls are mixed.
Just to give an idea, when you add two values with a different binary scaling
factor you need to align the decimal point, and you do this by shifting one of
the two (you chose which so that you do not loose bits, when you're allowed to
grow the significand).
If the 'small' is arbitrary, this alignment becomes messier and people have
fought many papers on the resulting error in arithmetic operations.

So, no I do not think I want to go there.

> For instance images
> are commonly stored using 8bit integers, but with the assumption that
> 255 is actually 'one'.  

As I said before, this seems easy untill all numbers in the expression
shares the same 'small', but in general is very difficult.

There might be ways to get what you need in this case by allowing
the user to specify optional functors that are used to convert to/from
builtin types. But it requires further thought.

Which is why probably I should post a list of features open for discussion,
regardeless from what I'll be able to implement right now.

> Also dollars can be apparently by treated as
> scaled<int64_t, 100> in order to prevent some floating point errors.
> If the library included something like scaled<uint8_t, 255>, along with
> operators and their return types as discussed for fixed points, then I
> would personally be extremely interested. 

Well, next C++ and C standard will have numbers with decimal representation
exactly for that. I haven't followed recent developments, but that was
the impression I got.