www.digitalmars.com         C & C++   DMDScript  

D - Currency

reply "Andrew" <crxace13 comcast.net> writes:
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” - Anonymous
Jun 11 2002
next sibling parent "Matthew Wilson" <dm synesis-group.com> writes:
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” - Anonymous
Jun 11 2002
prev sibling parent reply Burton Radons <loth users.sourceforge.net> writes:
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.
Jun 11 2002
parent reply "OddesE" <OddesE_XYZ hotmail.com> writes:
"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
Jun 26 2002
next sibling parent reply "Matthew Wilson" <matthew thedjournal.com> writes:
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
Jun 26 2002
parent reply Pavel Minayev <evilone omen.ru> writes:
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
Jun 27 2002
next sibling parent reply "Matthew Wilson" <matthew thedjournal.com> writes:
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
Jun 27 2002
parent reply "anderson" <anderson firestar.com.au> writes:
"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
Jun 27 2002
next sibling parent Pavel Minayev <evilone omen.ru> writes:
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


Well, anyhow, whatever it is, it should be there...
Jun 27 2002
prev sibling parent reply "Matthew Wilson" <matthew thedjournal.com> writes:
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
Jun 27 2002
next sibling parent Pavel Minayev <evilone omen.ru> writes:
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?
Jun 27 2002
prev sibling next sibling parent "anderson" <anderson firestar.com.au> writes:
 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.
Jun 27 2002
prev sibling parent reply "Roberto Mariottini" <rmariottini lycosmail.com> writes:
I also vote for a built-in 64bit (32+32) fixed point type.

Ciao
Jun 28 2002
parent reply C.R.Chafer <blackmarlin nospam.asean-mail.com> writes:
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
Jun 28 2002
parent reply Pavel Minayev <evilone omen.ru> writes:
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. =)
Jun 28 2002
parent reply "Sean L. Palmer" <seanpalmer earthlink.net> writes:
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. =)
Jun 28 2002
parent reply "Walter" <walter digitalmars.com> writes:
"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?
Jul 01 2002
next sibling parent reply "anderson" <anderson firestar.com.au> writes:
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.
Jul 02 2002
parent reply "Walter" <walter digitalmars.com> writes:
"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.
Jul 02 2002
next sibling parent reply "anderson" <anderson firestar.com.au> writes:
"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 ;)
Jul 02 2002
parent "Walter" <walter digitalmars.com> writes:
"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!
Jul 02 2002
prev sibling parent "Sean L. Palmer" <seanpalmer earthlink.net> writes:
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.
Jul 02 2002
prev sibling parent reply "Sean L. Palmer" <seanpalmer earthlink.net> writes:
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?
Jul 02 2002
parent "Walter" <walter digitalmars.com> writes:
"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.
Jul 02 2002
prev sibling parent "Sean L. Palmer" <seanpalmer earthlink.net> writes:
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
Jun 27 2002
prev sibling parent Burton Radons <loth users.sourceforge.net> writes:
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.  ;-)
Jun 27 2002