Long ago, I used BCD datatypes for adding up nickels and computing
sales tax. Using floats to add nickels doesn't really work out, maybe
working in rationals might however. Working in pennies via integers
might also be done. But is there a simple and convenient method of
working with dollars and cents?
--
TIA
TRT is to implement a Decimal Number datatype, e.g. following the specs at
http://www2.hursley.ibm.com/decimal/
Of course we'll have a #D reader macro to denote decimal numbers.
Cheers
--
Marco
GP lisper wrote:
> Long ago, I used BCD datatypes for adding up nickels and computing
> sales tax. Using floats to add nickels doesn't really work out, maybe
> working in rationals might however. Working in pennies via integers
> might also be done. But is there a simple and convenient method of
> working with dollars and cents?
>
>
> GP lisper wrote:
>> Long ago, I used BCD datatypes for adding up nickels and computing
>> sales tax. Using floats to add nickels doesn't really work out, maybe
>> working in rationals might however. Working in pennies via integers
>> might also be done. But is there a simple and convenient method of
>> working with dollars and cents?
>>
On Mon, 15 Aug 2005 11:57:04 -0400, <·······@cs.nyu.edu> wrote:
>
> TRT is to implement a Decimal Number datatype, e.g. following the specs at
> http://www2.hursley.ibm.com/decimal/
>
> Of course we'll have a #D reader macro to denote decimal numbers.
TRT? What kind of schedule is there?
Is the IBM "reference implementation" usable in your opinon? Maybe I
can throw a FFI wrapper around it (immediate need here)? ...or ECL...
--
On a cloudy day,
You hear the cons cells whisper:
"We are lost and gone." -- Oliver
+ GP lisper <········@CloudDancer.com>:
| On Mon, 15 Aug 2005 11:57:04 -0400, <·······@cs.nyu.edu> wrote:
| >
| > TRT is to implement a Decimal Number datatype [...]
|
| TRT? What kind of schedule is there?
The Right Thing, presumably.
There is only one schedule for The Right Thing:
WIR (When It's Ready).
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Debating gives most of us much more psychological satisfaction
than thinking does: but it deprives us of whatever chance there is
of getting closer to the truth. -- C.P. Snow
On 16 Aug 2005 00:55:14 +0200, <······@math.ntnu.no> wrote:
>
>
> + GP lisper <········@CloudDancer.com>:
>
>| On Mon, 15 Aug 2005 11:57:04 -0400, <·······@cs.nyu.edu> wrote:
>| >
>| > TRT is to implement a Decimal Number datatype [...]
>|
>| TRT? What kind of schedule is there?
>
> The Right Thing, presumably.
> There is only one schedule for The Right Thing:
> WIR (When It's Ready).
>
True, but you left out:
"Of course we'll have a #D reader macro to denote decimal numbers."
--
On a cloudy day,
You hear the cons cells whisper:
"We are lost and gone." -- Oliver
GP lisper wrote:
>>GP lisper wrote:
>>
>>>Long ago, I used BCD datatypes for adding up nickels and computing
>>>sales tax. Using floats to add nickels doesn't really work out, maybe
>>>working in rationals might however. Working in pennies via integers
>>>might also be done. But is there a simple and convenient method of
>>>working with dollars and cents?
>>>
>
>
> On Mon, 15 Aug 2005 11:57:04 -0400, <·······@cs.nyu.edu> wrote:
>
>>TRT is to implement a Decimal Number datatype, e.g. following the specs at
>>http://www2.hursley.ibm.com/decimal/
>>
>>Of course we'll have a #D reader macro to denote decimal numbers.
>
>
> TRT? What kind of schedule is there?
??? TRT is "The Right Thing". Common Lisp is all about TRT :)
>
> Is the IBM "reference implementation" usable in your opinon? Maybe I
> can throw a FFI wrapper around it (immediate need here)? ...or ECL...
>
It seems to works from C. Wrapping it up may be feasable, I have not
thought about it. But I really like the idea of having #D3.14 denote
decimal numbers.
Apart from that, the IBM pages are instructive. Essentially the library
is provided as a "push" to have decimal arithmetic in HW (which, if I am
not mistaken, IBM mainframes already have)
Cheers
--
Marco
On Tue, 16 Aug 2005 10:27:57 -0400, <·······@cs.nyu.edu> wrote:
> GP lisper wrote:
>> On Mon, 15 Aug 2005 11:57:04 -0400, <·······@cs.nyu.edu> wrote:
>>>GP lisper wrote:
>>>
>>>>Long ago, I used BCD datatypes for adding up nickels and computing
>>>>sales tax. Using floats to add nickels doesn't really work
>>
>>>TRT is to implement a Decimal Number datatype, e.g. following the specs at
>>>http://www2.hursley.ibm.com/decimal/
>>>
> ??? TRT is "The Right Thing". Common Lisp is all about TRT :)
Sometimes. ROUND utilizes bankers rounding, so there was some
awareness of decimal needs in the past. I wonder what Kent Pitman has
to say about 'decimal numbers' during the standardization efforts.
Maybe the ivory tower snobbishness about money left this hole in CL.
>>>Of course we'll have a #D reader macro to denote decimal numbers.
>>
>> Is the IBM "reference implementation" usable in your opinon? Maybe I
>> can throw a FFI wrapper around it (immediate need here)? ...or ECL...
>>
> It seems to works from C. Wrapping it up may be feasable, I have not
> thought about it. But I really like the idea of having #D3.14 denote
> decimal numbers.
Sounds great to me, more important than unicode in fact. But unicode
is an easier problem. Adding a new numeric type into Common Lisp
doesn't seem easy, libraries (etc) just look like an ugly hack. Seems
like something a commerical lisp will need to offer, or maybe one of
the new CL efforts will pick it up to attract users.
> Apart from that, the IBM pages are instructive. Essentially the library
> is provided as a "push" to have decimal arithmetic in HW (which, if I am
> not mistaken, IBM mainframes already have)
BCD math was in the 8080/Z80 microprocessors (see DAA opcode), I
remember it in a few CP/M compilers. So it might still be around in
x86, and maybe it works (always a risk with INTEL).
--
On a cloudy day,
You hear the cons cells whisper:
"We are lost and gone." -- Oliver
On Tue, 16 Aug 2005 14:00:29 -0700, GP lisper
<········@CloudDancer.com> wrote:
>BCD math was in the 8080/Z80 microprocessors (see DAA opcode), I
>remember it in a few CP/M compilers. So it might still be around in
>x86, and maybe it works (always a risk with INTEL).
IA-32 processors have ALU support for arithmetic on unpacked (byte per
digit) BCD, and add/subtract on packed BCD. it also has FPU support
for converting floating point from/to an 80-bit, 18-digit packed BCD
format.
IA-64 dropped ALU support for BCD. AFAICT, the FPU support remains.
George
--
for email reply remove "/" from address
On Tue, 16 Aug 2005 14:00:29 -0700, <········@CloudDancer.com> wrote:
>
>
> On Tue, 16 Aug 2005 10:27:57 -0400, <·······@cs.nyu.edu> wrote:
>> GP lisper wrote:
>>> On Mon, 15 Aug 2005 11:57:04 -0400, <·······@cs.nyu.edu> wrote:
>>>>GP lisper wrote:
>>>>
>>>>>Long ago, I used BCD datatypes for adding up nickels and computing
>>>>>sales tax. Using floats to add nickels doesn't really work
>>>
>>>>TRT is to implement a Decimal Number datatype, e.g. following the specs at
>>>>http://www2.hursley.ibm.com/decimal/
>>>>
>> ??? TRT is "The Right Thing". Common Lisp is all about TRT :)
>
> Sometimes. ROUND utilizes bankers rounding, so there was some
> awareness of decimal needs in the past. I wonder what Kent Pitman has
> to say about 'decimal numbers' during the standardization efforts.
> Maybe the ivory tower snobbishness about money left this hole in CL.
>
>
>>>>Of course we'll have a #D reader macro to denote decimal numbers.
>>>
>>> Is the IBM "reference implementation" usable in your opinon? Maybe I
>>> can throw a FFI wrapper around it (immediate need here)? ...or ECL...
>>>
>> It seems to works from C. Wrapping it up may be feasable, I have not
>> thought about it. But I really like the idea of having #D3.14 denote
>> decimal numbers.
>
> Sounds great to me, more important than unicode in fact. But unicode
> is an easier problem. Adding a new numeric type into Common Lisp
> doesn't seem easy, libraries (etc) just look like an ugly hack. Seems
> like something a commerical lisp will need to offer, or maybe one of
> the new CL efforts will pick it up to attract users.
>
>
>> Apart from that, the IBM pages are instructive. Essentially the library
>> is provided as a "push" to have decimal arithmetic in HW (which, if I am
>> not mistaken, IBM mainframes already have)
>
> BCD math was in the 8080/Z80 microprocessors (see DAA opcode), I
> remember it in a few CP/M compilers. So it might still be around in
> x86, and maybe it works (always a risk with INTEL).
>
>
--
Program A uses CLOS, Program B is implemented with structs, leading
to a fourfold increase in execution speed. --J. B. Heimatseiten
I like idea of #D too. I've made a cliki page for this topic ...
http://www.cliki.net/DECIMAL-NUMBER
in case anyone wants to pick this one up and run with it.
+ GP lisper <········@CloudDancer.com>:
| Long ago, I used BCD datatypes for adding up nickels and computing
| sales tax. Using floats to add nickels doesn't really work out, maybe
| working in rationals might however. Working in pennies via integers
| might also be done. But is there a simple and convenient method of
| working with dollars and cents?
One simple (simple minded?) method would be to convert dollars and
cents to cents on reading, then printing with a suitable format.
CL-USER> (round 1234.56 0.01)
123456
8.6188316e-5
CL-USER> (format t "~10,2,-2F" *)
1234.56
You may wish to (setf *read-default-float-format* 'double-float) in
order to avoid trouble on reading big amounts.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Debating gives most of us much more psychological satisfaction
than thinking does: but it deprives us of whatever chance there is
of getting closer to the truth. -- C.P. Snow