On Thu, 27 Jun 2002 17:23:48 +0800 "anderson" <anderson@firestar.com.au> wrote:

> Which means that every program that needs fixed point will need to come up with it's own standard. Fixed point seems to be a pretty comman data type. Why not simply include it in the language in the first place? Parhaps It could be included in a standard libary using templates, but that is unlikely to be as effecient as an inbuilt complier version.

It is not even necessary a fixed point type. It could be as well an FP-type, but with decimal point, and rounding rules to prevent precision loss to maximum degree possible. Something like 128-bit C# decimal type.

Well, anyhow, whatever it is, it should be there...

Entirely wrong. I was merely suggesting that it be a library feature rather than a language one. You could just use the library

"anderson" <anderson@firestar.com.au> wrote in message news:afel67$qkl$1@digitaldaemon.com...
>
> "Matthew Wilson" <matthew@thedjournal.com> wrote in message news:afef6j$kkd$1@digitaldaemon.com...
> > Mix in templates and adding/subtracting is ridiculously simple. Without,
> and
> > we just need another member to indicate the subUnit factor
>
> Which means that every program that needs fixed point will need to come up with it's own standard. Fixed point seems to be a pretty comman data type. Why not simply include it in the language in the first place? Parhaps It could be included in a standard libary using templates, but that is
unlikely
> to be as effecient as an inbuilt complier version.
>
> --I hate redundancy
>
>

On Fri, 28 Jun 2002 08:40:28 +1000 "Matthew Wilson" <matthew@thedjournal.com> wrote:

> Entirely wrong. I was merely suggesting that it be a library feature rather than a language one. You could just use the library

I don't understand, why should it be in the library, if complex is built in?

> Entirely wrong. I was merely suggesting that it be a library feature
rather
> than a language one. You could just use the library

Didn't you read my full comment?

> > Parhaps It
> > could be included in a standard libary, but that is
> > unlikely to be as effecient as a inbuilt complier version.
> >

I also vote for a built-in 64bit (32+32) fixed point type.

Ciao

Roberto Mariottini wrote:

> I also vote for a built-in 64bit (32+32) fixed point type.
> 
> Ciao

I would be useful - though not necessarily for currency, however then I think that a 16.16 fixed point would also be useful (ie. for fixed point graphics).

That is the trouble with having inbuilt types in a language,
there are never enough to do what we want in every
circumstance - however if the optimiser is good enough then
using a library (provided inlineing can be done from said library)
should prove sufficient.

C 2002/6/28

On Sat, 29 Jun 2002 05:38:07 +0100 C.R.Chafer <blackmarlin@nospam.asean-mail.com> wrote:

> That is the trouble with having inbuilt types in a language, there are never enough to do what we want in every circumstance

Well, D already has things like complex numbers, dynamic arrays,
and hash tables built-in, rather than residing in standard
library - so it seems to be the ideology. And currency type is used
just as frequent in financial applications as complex in math ones. =)

The decision to not provide generics or operator overloading is almost *requiring* that this kind of thing be provided as a basic builtin type.  Or not provided at all.

I am looking forward to D 2.0.  ;)

However for fixed point I think the compiler can do a *way* better job of generating code if it's a native type than if it's a user-defined type. I've experienced this over and over, and no matter how nice you write your vector or fixed point class, you can never get the performance that the compiler *could* get if it were a native type (because the compiler is never quite sure that your little functions are small enough to inline, for one thing)

I've never seen a compiler generate good code for that kind of thing anyway. That's not saying one couldn't, but in the real world, they don't.  And that makes a builtin type all the more attractive, especially since vector math and fixed point math are WIDELY USED and COMMON applications.  Almost as common and fundamental as floating point math and integer math.  Just because one *can*  be used to derive the other doesn't mean that's the best way.  In practice it turns out to be inefficient, not only at runtime but also for the programmer, who must often resort to inline assembly and other bullshit.  And using inline assembly often thwarts the optimizer which ends up making code worse.

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.

Sean

"Pavel Minayev" <evilone@omen.ru> wrote in message news:CFN374358881695833@news.digitalmars.com...
> On Sat, 29 Jun 2002 05:38:07 +0100 C.R.Chafer <blackmarlin@nospam.asean-mail.com> wrote:
>
> > That is the trouble with having inbuilt types in a language, there are never enough to do what we want in every circumstance
>
> Well, D already has things like complex numbers, dynamic arrays,
> and hash tables built-in, rather than residing in standard
> library - so it seems to be the ideology. And currency type is used
> just as frequent in financial applications as complex in math ones. =)

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

Wellcome back.


> 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. It'd be nice to have a standard way of doing fixed point. Or as pavel pointed out it doesn't even need to be fixed point, just some way to limit the amount of places FP can distort.