Does D support a currency type? If not, is there any intention to include support for such a type in the future? Or is this something that anyone with little programming experience can easily accommodate and does not warrant further thought?

-----------------------------------------------------------------
Andrew C. Edwards
crxace13@comcast.net

"The heights that great men reached and kept, were not attained by sudden
flight.  But they, whilst their companion slept, kept toiling upwards
through the
night$B!I(B - Anonymous

My instincts would be to assume that this is a library issue, rather than a language one.


"Andrew" <crxace13@comcast.net> wrote in message news:ae64he$mhf$1@digitaldaemon.com...
> Does D support a currency type? If not, is there any intention to include support for such a type in the future? Or is this something that anyone with little programming experience can easily accommodate and does not warrant further thought?
>
> -----------------------------------------------------------------
> Andrew C. Edwards
> crxace13@comcast.net
>
> "The heights that great men reached and kept, were not attained by sudden
> flight.  But they, whilst their companion slept, kept toiling upwards
> through the
> night$B!I(B - Anonymous
>

Andrew wrote:

> Does D support a currency type? If not, is there any intention to include support for such a type in the future? Or is this something that anyone with little programming experience can easily accommodate and does not warrant further thought?


It's a crazily complex problem.  It's far easier to support full dates with leap seconds and various year numbering systems.  I don't know if the needs could be sated within Phobos... but if they could be, it would be written by someone who works on this kind of software.  For example, the value of money varies not only with time and locality, but upon the indices used to gauge inflation (which are fairly arbitrary) and whether you want this variability.  But that this hair-tearing issue exists doesn't mean it needs to be addressed for the library to be useful - see the problem?

For mere humans and tax purposes, a typedef'd extended is far more than
enough.  When this issue came up on Python dev awhile back the
suggestion was mostly as a kind of clamped blackbox to prevent
accidentally mixing currencies, which is about the best anything can do.
 It failed as it didn't really having a purpose - the user class for
doing same was just a couple lines.

"Burton Radons" <loth@users.sourceforge.net> wrote in message news:3D06C45C.6000207@users.sourceforge.net...
> Andrew wrote:
>
> > Does D support a currency type? If not, is there any intention to
include
> > support for such a type in the future? Or is this something that anyone with little programming experience can easily accommodate and does not warrant further thought?
>
>
> It's a crazily complex problem.  It's far easier to support full dates with leap seconds and various year numbering systems.  I don't know if the needs could be sated within Phobos... but if they could be, it would be written by someone who works on this kind of software.  For example, the value of money varies not only with time and locality, but upon the indices used to gauge inflation (which are fairly arbitrary) and whether you want this variability.  But that this hair-tearing issue exists doesn't mean it needs to be addressed for the library to be useful - see the problem?
>
> For mere humans and tax purposes, a typedef'd extended is far more than
> enough.  When this issue came up on Python dev awhile back the
> suggestion was mostly as a kind of clamped blackbox to prevent
> accidentally mixing currencies, which is about the best anything can do.
>  It failed as it didn't really having a purpose - the user class for
> doing same was just a couple lines.
>


An extended?
I always learned that floating point numbers should
not be used to represent money, because it can
cause all kinds of roundoff errors? I thought a fixed
point number was better suited? I admit I have very
little experience with this though...


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail

Absolutely.

Simple struct/class containing

{
    integral-type    unit;
    integral-type    subUnit;
}

"OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:afd3vb$27m9$1@digitaldaemon.com...
> "Burton Radons" <loth@users.sourceforge.net> wrote in message news:3D06C45C.6000207@users.sourceforge.net...
> > Andrew wrote:
> >
> > > Does D support a currency type? If not, is there any intention to
> include
> > > support for such a type in the future? Or is this something that
anyone
> > > with little programming experience can easily accommodate and does not warrant further thought?
> >
> >
> > It's a crazily complex problem.  It's far easier to support full dates with leap seconds and various year numbering systems.  I don't know if the needs could be sated within Phobos... but if they could be, it would be written by someone who works on this kind of software.  For example, the value of money varies not only with time and locality, but upon the indices used to gauge inflation (which are fairly arbitrary) and whether you want this variability.  But that this hair-tearing issue exists doesn't mean it needs to be addressed for the library to be useful - see the problem?
> >
> > For mere humans and tax purposes, a typedef'd extended is far more than
> > enough.  When this issue came up on Python dev awhile back the
> > suggestion was mostly as a kind of clamped blackbox to prevent
> > accidentally mixing currencies, which is about the best anything can do.
> >  It failed as it didn't really having a purpose - the user class for
> > doing same was just a couple lines.
> >
>
>
> An extended?
> I always learned that floating point numbers should
> not be used to represent money, because it can
> cause all kinds of roundoff errors? I thought a fixed
> point number was better suited? I admit I have very
> little experience with this though...
>
>
> --
> Stijn
> OddesE_XYZ@hotmail.com
> http://OddesE.cjb.net
> _________________________________________________
> Remove _XYZ from my address when replying by mail
>
>
>
>

On Thu, 27 Jun 2002 11:33:35 +1000 "Matthew Wilson" <matthew@thedjournal.com> wrote:

> Absolutely.
> 
> Simple struct/class containing
> 
> {
>     integral-type    unit;
>     integral-type    subUnit;
> }

Yep, and how are you going to add or subtract these?

I think that built-in type is better. After all, there are "complex" and "imaginary" types, why not "currency" (or "decimal", whichever you prefer) fixed-point number? Delphi has it, C# does...

Mix in templates and adding/subtracting is ridiculously simple. Without, and we just need another member to indicate the subUnit factor

"Pavel Minayev" <evilone@omen.ru> wrote in message news:CFN374344640871643@news.digitalmars.com...
> On Thu, 27 Jun 2002 11:33:35 +1000 "Matthew Wilson"
<matthew@thedjournal.com>
> wrote:
>
> > Absolutely.
> >
> > Simple struct/class containing
> >
> > {
> >     integral-type    unit;
> >     integral-type    subUnit;
> > }
>
> Yep, and how are you going to add or subtract these?
>
> I think that built-in type is better. After all, there are "complex" and "imaginary" types, why not "currency" (or "decimal", whichever you prefer) fixed-point number? Delphi has it, C# does...

OddesE wrote:

>>For mere humans and tax purposes, a typedef'd extended is far more than
>>enough.  When this issue came up on Python dev awhile back the
>>suggestion was mostly as a kind of clamped blackbox to prevent
>>accidentally mixing currencies, which is about the best anything can do.
>> It failed as it didn't really having a purpose - the user class for
>>doing same was just a couple lines.
> 
> An extended?
> I always learned that floating point numbers should
> not be used to represent money, because it can
> cause all kinds of roundoff errors? I thought a fixed
> point number was better suited? I admit I have very
> little experience with this though...


You're not going to go to jail because your tax return is a nickel off.  Considering recent news, though, an error within $3.8 billion will perform better than reality.  ;-)

I wanted a user-configurable fixed point type.  Any compiler that can do double-precision integer multiply and divide can support fixed point with very little trouble.  And fixed point is still very useful even today... most CPU's do integer math faster than float math.  At least for adds and subtracts anyway.

Sean

"Pavel Minayev" <evilone@omen.ru> wrote in message news:CFN374344640871643@news.digitalmars.com...
> On Thu, 27 Jun 2002 11:33:35 +1000 "Matthew Wilson"
<matthew@thedjournal.com>
> wrote:
>
> > Absolutely.
> >
> > Simple struct/class containing
> >
> > {
> >     integral-type    unit;
> >     integral-type    subUnit;
> > }
>
> Yep, and how are you going to add or subtract these?
>
> I think that built-in type is better. After all, there are "complex" and "imaginary" types, why not "currency" (or "decimal", whichever you prefer) fixed-point number? Delphi has it, C# does...

"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