1. Fw: BCD-lib

From: "Euman" <euman at bellsouth.net>

> My understanding from Electronics and its been a long time 10+ years since I
> went to school but BCD is a four (4) byte representation of each decimal
> digit.
> If this is the case, then how would it be usefull other than require massive
> amounts
> of Ram to store even the smallest string???

Excuse me, four (4) bit "NOT BYTE" as I said. So yes I could see this as usefull
and my earlier post should be shot down.

Euman

new topic     » topic index » view message » categorize

2. Re: Fw: BCD-lib

Consider this integer Chris,   

7863 = 0111-1000-0110-0011 -- BCD
7863 = 10110111  -- BYTE
7863 = 1111010110111 -- Dword / word

in BCD the largest decimal that can be displayed 
by any four digits is 9 and the four bits are the
binary equivalent of 1 thru 9. 

I'll be happy to see how it will all work out.
Will it be fast and efficient?.
 
Euman
euman at bellsouth.net

----- Original Message ----- 
From: "Chris Bensler" <bensler at mail.com>
To: "EUforum" <EUforum at topica.com>
Sent: Saturday, April 13, 2002 7:40 PM
Subject: RE: Fw: BCD-lib


> 
> How can you represent decimals with only 4 bits? That would be a maximum 
> number of 16, not even considering fractions.
> 
> 4 bytes makes more sense.
> 
> >From what I understand, the purpose of the BCD lib would be for accurate 
> math, not speed or size.
> 
> 
> Chris
> 
> 
> euman at bellsouth.net wrote:
> > From: "Euman" <euman at bellsouth.net>
> > 
> > > My understanding from Electronics and its been a long time 10+ years 
> > > since I
> > > went to school but BCD is a four (4) byte representation of each decimal 
> > > digit.
> > > If this is the case, then how would it be usefull other than require 
> > > massive amounts
> > > of Ram to store even the smallest string???
> > 
> > Excuse me, four (4) bit "NOT BYTE" as I said. So yes I could see this as 
> > usefull
> > and my earlier post should be shot down.
> > 
> > Euman
> > 
> > 
> 
> 
>

new topic     » goto parent     » topic index » view message » categorize

3. Re: Fw: BCD-lib

On Sat, 13 Apr 2002 21:15:59 -0500, Kat <gertie at PELL.NET> wrote:

> The question is how will 
>Eu store the BCD bytes for us?

Off the top of my head, a "short" BCD could be held in an integer,
which is 31 bits. The natural scheme would be sign+ 7 nibbles
(therefore seven significant digits), using 29 bits, leaving space for
a 2-bit mantissa (therefore between 0 and 3 decimal places). That
could accurately hold 0.001 or 9,999,999. The largest money value it
could hold would be 99,999.99. Longer BCD values could be held as a
sequence of n integers, with up to 7*n significant digits and 3*n
decimal places.

Alternatively, you explicitly specify how many decimal places you need
at the start of the program and the routines return the shortest
possible sequence which will hold the calculated result.

Pete

new topic     » goto parent     » topic index » view message » categorize

4. Re: Fw: BCD-lib

On 14 Apr 2002, at 9:36, petelomax at blueyonder.co.uk wrote:

> 
> On Sat, 13 Apr 2002 21:15:59 -0500, Kat <gertie at PELL.NET> wrote:
> 
> > The question is how will 
> >Eu store the BCD bytes for us?
> 
> Off the top of my head, a "short" BCD could be held in an integer,
> which is 31 bits. The natural scheme would be sign+ 7 nibbles
> (therefore seven significant digits), using 29 bits, leaving space for
> a 2-bit mantissa (therefore between 0 and 3 decimal places). That
> could accurately hold 0.001 or 9,999,999. The largest money value it
> could hold would be 99,999.99. Longer BCD values could be held as a
> sequence of n integers, with up to 7*n significant digits and 3*n
> decimal places.
> 
> Alternatively, you explicitly specify how many decimal places you need
> at the start of the program and the routines return the shortest
> possible sequence which will hold the calculated result.

I prefer this, rather than locking the user to a limited number of digits on 
either side of decimal. If someone really needs to measure the distance to 
Alpha Centuri in angstroms, i'd let them.  smile

What i was worried about was that every nibble would take a 32bit integer in 
Eu, making a large data store in memory impossible, like with storing strings 
in sequences now.

Kat

new topic     » goto parent     » topic index » view message » categorize

5. Re: Fw: BCD-lib

Hi Felix Programmatica (Kat=>cat),

would +/- 10^1073471823 * any number of 1048576 * 9 digits do?
thats what would be the limits the system i think of would allow.

antoine

new topic     » goto parent     » topic index » view message » categorize

6. Re: Fw: BCD-lib

On 14 Apr 2002, at 18:46, a.tammer at hetnet.nl wrote:

> 
> Hi Felix Programmatica (Kat=>cat),
> 
> would +/- 10^1073471823 * any number of 1048576 * 9 digits do?
> thats what would be the limits the system i think of would allow.

*significant* digits? Then why use exponents at all?

Kat

new topic     » goto parent     » topic index » view message » categorize

7. Re: Fw: BCD-lib

Simply, Kat for the next reason

why exponent? because 90(rep 9M -1 times) could be written as {9437183,{1}) ISO
{1,0..rep 1048575} thus taking 2 integers(8 bytes) and not 1048576 integers being
4Mb. that's why.

Antoine

new topic     » goto parent     » topic index » view message » categorize

8. Re: Fw: BCD-lib

On 14 Apr 2002, at 21:40, a.tammer at hetnet.nl wrote:

> 
> Simply, Kat for the next reason
> 
> why exponent? because 90(rep 9M -1 times) could be written as {9437183,{1})
> ISO
> {1,0..rep 1048575} thus taking 2 integers(8 bytes) and not 1048576 integers
> being 4Mb. that's why.

I don't understand. Can you explain?

Also, how is an exponent going to help if i have pi written out to 10 pages of 
significant digits, and i want to divide by some number with 50 significant 
digits?

Kat

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu