"anderson" <anderson@firestar.com.au> wrote in message news:afsfd9$273s$1@digitaldaemon.com...
> Wellcome back.

Thanks!

> > I've done "fixed point" arithmetic many times by simply using longs. All that needed to be done was some special code for input/output
formatting.
> > How do you see a fixed point type as being different?
> That is true, so have I. But when doing somthing like multiplication I
takes
> a bit more effort to get correct answers.

That's true, but it's not usually a problem if the size of the long is twice as large as the intended precision. Integer arithmetic doesn't handle overflows, nans, etc.

> It'd be nice to have a standard
> way of doing fixed point.

Adding a new native type tends to be a long and error prone process, since it affects the entire compiler source. Usually when I do add one, it takes months of finding all the corners that need to take it into account. Sigh.

"Walter" <walter@digitalmars.com> wrote in message news:afshh1$2976$3@digitaldaemon.com...
>
> "anderson" <anderson@firestar.com.au> wrote in message news:afsfd9$273s$1@digitaldaemon.com...
> > Wellcome back.
>
> Thanks!
>
> > > I've done "fixed point" arithmetic many times by simply using longs.
All
> > > that needed to be done was some special code for input/output
> formatting.
> > > How do you see a fixed point type as being different?
> > That is true, so have I. But when doing somthing like multiplication I
> takes
> > a bit more effort to get correct answers.
>
> That's true, but it's not usually a problem if the size of the long is
twice
> as large as the intended precision. Integer arithmetic doesn't handle overflows, nans, etc.
>
> > It'd be nice to have a standard
> > way of doing fixed point.
>
> Adding a new native type tends to be a long and error prone process, since it affects the entire compiler source. Usually when I do add one, it takes months of finding all the corners that need to take it into account. Sigh.

Good point. Well if it can't be done, it can't be done. I'd rather have a dozen useful features then just one.

PS
Are you and pavel taking vacations in >> , because just as you arrive back,
he leaves ;)

"anderson" <anderson@firestar.com.au> wrote in message news:afsi2k$29ue$1@digitaldaemon.com...
> PS
> Are you and pavel taking vacations in >> , because just as you arrive
back,
> he leaves ;)

No, it's just the season for vacations!

Multiplication and division need extra shifting for fixed point, and something should be done about overflow in the intermediate calculation. This could be automated easily.

alias long fixed20_12;
fixed20_12 a = 26 << 12, b = (47 << 12) | ((1<<12)/2), c;
c = cast(long)((cast(huge)(a) * b)>>12); // if a * b intermediate
calculation won't overflow
c = (a>>6) * (b>>6); // if there's not a larger intermediate buffer to use,
just lose accuracy on inputs

Addition and subtraction are the same as for long.

You're right, I/O formatting needs addressed.  It could be formatted similarly to floats.

Glad you're back!  Did you enjoy your vacation?

Sean

"Walter" <walter@digitalmars.com> wrote in message news:afsdhc$2523$1@digitaldaemon.com...
>
> "Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:afi8n5$2chb$1@digitaldaemon.com...
> > PLEASE PLEASE make fixed point and vector math basic operations.
There's
> > already a good start on the vector math (by being able to add/subtract/multiply arrays componentwise) but there is more to be
done.
>
> I've done "fixed point" arithmetic many times by simply using longs. All that needed to be done was some special code for input/output formatting. How do you see a fixed point type as being different?

It's not true, you can't "just multiply" two fixed point numbers... you have to shift the result back into place.  It's tedious and error prone, and a compiler would be much better at doing it.

We'll help you find all the corners.  ;)

Sean


"Walter" <walter@digitalmars.com> wrote in message news:afshh1$2976$3@digitaldaemon.com...
>
> "anderson" <anderson@firestar.com.au> wrote in message news:afsfd9$273s$1@digitaldaemon.com...
> > Wellcome back.
>
> Thanks!
>
> > > I've done "fixed point" arithmetic many times by simply using longs.
All
> > > that needed to be done was some special code for input/output
> formatting.
> > > How do you see a fixed point type as being different?
> > That is true, so have I. But when doing somthing like multiplication I
> takes
> > a bit more effort to get correct answers.
>
> That's true, but it's not usually a problem if the size of the long is
twice
> as large as the intended precision. Integer arithmetic doesn't handle overflows, nans, etc.
>
> > It'd be nice to have a standard
> > way of doing fixed point.
>
> Adding a new native type tends to be a long and error prone process, since it affects the entire compiler source. Usually when I do add one, it takes months of finding all the corners that need to take it into account. Sigh.

"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:afsphb$2hnc$1@digitaldaemon.com...
> Multiplication and division need extra shifting for fixed point, and something should be done about overflow in the intermediate calculation.

Right, but I rarely needed that because I was scaling the fixed point by an int, which didn't need the result shifted.

> Glad you're back!  Did you enjoy your vacation?

Sure. But it's good to be back.