Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #91879 > unrolled thread
| Started by | Real Troll <real.troll@trolls.com> |
|---|---|
| First post | 2016-08-07 17:59 -0400 |
| Last post | 2016-08-10 15:00 -0500 |
| Articles | 20 on this page of 123 — 23 participants |
Back to article view | Back to comp.lang.c
Float Vs Double Real Troll <real.troll@trolls.com> - 2016-08-07 17:59 -0400
Re: Float Vs Double Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-07 23:38 +0100
Re: Float Vs Double Real Troll <real.troll@trolls.com> - 2016-08-07 18:55 -0400
Re: Float Vs Double jameskuyper@verizon.net - 2016-08-07 16:43 -0700
Re: Float Vs Double Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-07 19:36 -0700
Re: Float Vs Double Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-08 04:05 +0100
Re: Float Vs Double Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-07 20:41 -0700
Re: Float Vs Double Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-08 11:41 +0100
Re: Float Vs Double Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-08 04:23 -0700
Re: Float Vs Double Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-08 23:45 +0100
Re: Float Vs Double Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-10 03:26 -0700
Re: Float Vs Double Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-11 01:00 +0100
Re: Float Vs Double jameskuyper@verizon.net - 2016-08-08 08:52 -0700
Re: Float Vs Double James Kuyper <jameskuyper@verizon.net> - 2016-08-08 11:58 -0400
Re: Float Vs Double Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-08 10:06 -0700
Re: Float Vs Double "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-08 19:46 -0400
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-07 21:29 -0400
Re: Float Vs Double jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-08 14:04 +0200
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-08 09:00 -0400
Re: Float Vs Double jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-08 18:43 +0200
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-08 14:34 -0400
Re: Float Vs Double Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-08 12:00 -0700
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-08 16:42 -0400
Re: Float Vs Double Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-08 14:04 -0700
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-09 08:48 -0400
Re: Float Vs Double Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-10 03:22 -0700
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-21 18:31 -0400
Re: Float Vs Double supercat@casperkitty.com - 2016-08-22 08:39 -0700
Re: Float Vs Double Jean-Marc Bourguet <jm@bourguet.org> - 2016-08-22 19:29 +0200
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-22 19:24 -0400
Re: Float Vs Double Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-23 01:01 +0100
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-22 21:58 -0400
Re: Float Vs Double David Brown <david.brown@hesbynett.no> - 2016-08-23 09:38 +0200
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-23 08:15 -0400
Re: Float Vs Double David Brown <david.brown@hesbynett.no> - 2016-08-23 15:07 +0200
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-23 09:40 -0400
Re: Float Vs Double Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-23 15:14 +0100
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-23 10:38 -0400
Re: Float Vs Double Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-23 17:18 +0100
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-23 15:47 -0400
Re: Float Vs Double David Brown <david.brown@hesbynett.no> - 2016-08-23 16:39 +0200
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-23 11:45 -0400
Re: Float Vs Double David Brown <david.brown@hesbynett.no> - 2016-08-23 21:42 +0200
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-23 15:52 -0400
Re: Float Vs Double Ian Collins <ian-news@hotmail.com> - 2016-08-24 08:36 +1200
Re: Float Vs Double David Brown <david.brown@hesbynett.no> - 2016-08-24 09:39 +0200
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-24 11:31 -0400
Re: Float Vs Double Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-23 10:48 +0100
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-23 08:17 -0400
Re: Float Vs Double Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-23 06:01 -0700
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-23 09:44 -0400
Re: Float Vs Double Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-23 07:19 -0700
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-23 10:39 -0400
Re: Float Vs Double Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-23 08:18 -0700
Re: Float Vs Double Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-23 14:47 +0100
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-23 10:40 -0400
Re: Float Vs Double Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-24 01:31 +0100
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-23 20:53 -0400
Re: Float Vs Double supercat@casperkitty.com - 2016-08-23 23:20 -0700
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-24 11:32 -0400
Re: Float Vs Double David Brown <david.brown@hesbynett.no> - 2016-08-24 09:46 +0200
Re: Float Vs Double Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-24 14:53 +0100
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-24 11:35 -0400
Re: Float Vs Double Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-24 08:57 -0700
Re: Float Vs Double Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-24 17:36 +0100
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-24 12:50 -0400
Re: Float Vs Double Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-24 17:26 +0100
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-24 12:51 -0400
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-24 11:33 -0400
Re: Float Vs Double Robert Wessel <robertwessel2@yahoo.com> - 2016-08-28 02:33 -0500
Re: Float Vs Double antispam@math.uni.wroc.pl - 2016-08-31 22:36 +0000
Re: Float Vs Double supercat@casperkitty.com - 2016-08-31 15:51 -0700
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-31 22:42 -0400
Re: Float Vs Double supercat@casperkitty.com - 2016-09-01 08:32 -0700
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-01 15:00 -0400
Re: Float Vs Double supercat@casperkitty.com - 2016-09-01 13:45 -0700
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-01 20:50 -0400
Re: Float Vs Double supercat@casperkitty.com - 2016-09-02 08:11 -0700
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-02 12:25 -0400
Re: Float Vs Double David Brown <david.brown@hesbynett.no> - 2016-09-02 20:42 +0200
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-02 16:25 -0400
Re: Float Vs Double Jean-Marc Bourguet <jm@bourguet.org> - 2016-09-03 08:43 +0200
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-03 10:48 -0400
Re: Float Vs Double Jean-Marc Bourguet <jm@bourguet.org> - 2016-09-03 19:43 +0200
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-03 18:16 -0400
Re: Float Vs Double asetofsymbols@gmail.com - 2016-09-08 11:18 -0700
Re: Float Vs Double Robert Wessel <robertwessel2@yahoo.com> - 2016-09-07 19:59 -0500
Re: Float Vs Double supercat@casperkitty.com - 2016-09-08 08:13 -0700
Re: Float Vs Double Robert Wessel <robertwessel2@yahoo.com> - 2016-09-08 19:34 -0500
Re: Float Vs Double supercat@casperkitty.com - 2016-09-09 07:50 -0700
Re: Float Vs Double Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-02 23:40 -0700
Re: Float Vs Double Jean-Marc Bourguet <jm@bourguet.org> - 2016-09-03 09:06 +0200
Re: Float Vs Double Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-03 10:52 -0400
Re: Float Vs Double Rosario19 <Ros@invalid.invalid> - 2016-08-24 08:57 +0200
Re: Float Vs Double Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-24 01:04 -0700
Re: Float Vs Double Ike Naar <ike@iceland.freeshell.org> - 2016-08-08 06:44 +0000
Re: Float Vs Double Keith Thompson <kst-u@mib.org> - 2016-08-08 00:16 -0700
Re: Float Vs Double Richard Damon <Richard@Damon-Family.org> - 2016-08-08 23:29 -0400
Re: Float Vs Double jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-08 14:03 +0200
Re: Float Vs Double "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-08 05:14 -0700
Re: Float Vs Double BGB <cr88192@hotmail.com> - 2016-08-09 19:53 -0500
Re: Float Vs Double "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-07 18:47 -0400
Float Vs Double "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-07 17:04 -0700
Re: Float Vs Double "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-08 05:49 -0700
Re: Float Vs Double Nobody <nobody@nowhere.invalid> - 2016-08-10 03:26 +0100
Re: Float Vs Double "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-09 20:15 -0700
Re: Float Vs Double "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-10 06:07 -0700
Re: Float Vs Double "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-10 06:13 -0700
Re: Float Vs Double David Brown <david.brown@hesbynett.no> - 2016-08-10 16:43 +0200
Re: Float Vs Double "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-10 07:56 -0700
Re: Float Vs Double supercat@casperkitty.com - 2016-08-10 08:39 -0700
Re: Float Vs Double Keith Thompson <kst-u@mib.org> - 2016-08-10 09:56 -0700
Re: Float Vs Double Keith Thompson <kst-u@mib.org> - 2016-08-10 10:04 -0700
Re: Float Vs Double Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-11 07:08 -0700
Re: Float Vs Double "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-11 07:15 -0700
Re: Float Vs Double Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-12 08:11 -0700
Re: Float Vs Double jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-10 20:38 +0200
Re: Float Vs Double Keith Thompson <kst-u@mib.org> - 2016-08-10 12:20 -0700
Re: Float Vs Double supercat@casperkitty.com - 2016-08-10 12:17 -0700
Re: Float Vs Double jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-10 21:48 +0200
Re: Float Vs Double Keith Thompson <kst-u@mib.org> - 2016-08-10 13:40 -0700
Re: Float Vs Double Ian Collins <ian-news@hotmail.com> - 2016-08-12 08:01 +1200
Re: Float Vs Double BGB <cr88192@hotmail.com> - 2016-08-10 15:00 -0500
Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-08-23 16:39 +0200 |
| Message-ID | <nphn7v$1dh$1@dont-email.me> |
| In reply to | #92631 |
On 23/08/16 15:40, Jerry Stuckle wrote:
> On 8/23/2016 9:07 AM, David Brown wrote:
>> On 23/08/16 14:15, Jerry Stuckle wrote:
>>> On 8/23/2016 3:38 AM, David Brown wrote:
>>>> On 23/08/16 03:58, Jerry Stuckle wrote:
>>>>> On 8/22/2016 8:01 PM, Ben Bacarisse wrote:
>>>>>> Jerry Stuckle <jstucklex@attglobal.net> writes:
>>>>>>
>>>>>>> On 8/22/2016 11:39 AM, supercat@casperkitty.com wrote:
>>>>>>>> On Sunday, August 21, 2016 at 5:31:13 PM UTC-5, Jerry Stuckle wrote:
>>>>>>>>> For instance - I've seen it implemented as storing the digits in a
>>>>>>>>> string. Quite easy to implement - but performance was terrible, as you
>>>>>>>>> can imagine. OTOH, I implemented one back in the 80's based on two
>>>>>>>>> digits per byte, using 808x assembler. Much faster, but not portable
>>>>>>>>> and not all that easy.
>>>>>>>>
>>>>>>>> I'm surprised I haven't seen more "decimal math" libraries using 9 digits
>>>>>>>> per word; such a thing would seem like a natural fit on a 32-bit processor
>>>>>>>> with a 32x32->64 multiply. Performance would be likely slower than for
>>>>>>>> binary math, but nowhere near as slow as using single-digit or two-digit
>>>>>>>> chunks (on processors which can't use a carry flag for extended-precision
>>>>>>>> math, addition and subtraction could benefit from the fact that the sum
>>>>>>>> or difference of any two 9-digit chunks could fit in a 32-bit signed "int").
>>>>>>>>
>>>>>>>
>>>>>>> 9 digits per word would not be decimal math. The most you could get
>>>>>>> into 32 bits would be 8 decimal digits.
>>>>>>
>>>>>> I think what supercat is talking about might otherwise be called base
>>>>>> 1,000,000,000 arithmetic.
>>>>>>
>>>>>>> And I suspect trying it would
>>>>>>> be even slower than decimal math. It would be much more complicated to
>>>>>>> implement.
>>>>>>
>>>>>> In software, it's faster and simpler than using BCD-type schemes, but
>>>>>> it's a matter of definition if is a decimal scheme or not.
>>>>>>
>>>>>
>>>>> I understand what he's after, and my comments stand. For instance, how
>>>>> easy would it be to subtract 123.456 from 789012.345678? Not that hard
>>>>> with BCD, but very difficult with supercat's idea. Adjusting for the
>>>>> decimal point would not be easy.
>>>>>
>>>>
>>>> That would depend on whether he is considering just integers (in which
>>>> case arithmetic with a decimal point is /really/ hard!), or a
>>>> representation supporting multiple 9-digit chunks (in which case,
>>>> subtracting 000000123.456000000 from 000789012.345678000 would be quite
>>>> simple), or something with a floating decimal point (which would be very
>>>> messy).
>>>>
>>>> Personally, I don't think there would be anything much to be gained from
>>>> base 1G formats, except perhaps in very niche cases.
>>>>
>>>>
>>>>
>>>
>>> The whole thread is about real numbers, not integers, David. And seldom
>>> do the numbers always have the same number of decimal places.
>>>
>>
>> Just because the thread is about real numbers, does not mean that
>> Supercat is still talking about them!
>>
>
> Try again, stoopid.
You think Supercat always sticks to the thread topic? You haven't read
many of his posts.
>
>> But I think that in many situations where you might be interested in
>> tracking your numbers in decimal digit formats rather than floating
>> point, scaled integer, or other binary formats, then you probably /do/
>> have a fixed number of decimal digits. Financial calculations would be
>> an example.
>>
>
> No, financial calculations are not an example. For instance, banks
> generally go at least six decimal places for monetary calculations, but
> may go four to eight for percentage calculations (depending on how often
> interest is calculated). And, of course, account transfers are only two
> decimal places.
>
> The are many different numbers of decimal places used in financial
> calculations.
That sounds like a perfect example. At no point did I say that the
fixed number of decimal places was the same in every use-case.
And a single fixed value of 18 decimal places would do a far job of
covering all the situations you describe.
>
>> The exception would be in mathematical calculations where you want
>> arbitrary precision in your decimal calculations.
>>
>
> More the rule than the exception.
>
>> And in either case, I can't see why storing 9 digits in 32-bit chunks is
>> going to be much more complicated than storing 1 or 2 digits in 8-bit
>> chunks (BCD, packed or unpacked). It will certainly be more efficient
>> for calculations. 18 digits in 64-bit chunks is going to be even better
>> on modern cpus.
>>
>
> Then you show how to subtract 123.456 from 789012.345678 using 18 digits
> in 64 bit chunks. I'd love to see you do it.
>
typedef struct {
int64_t whole;
int64_t part;
} bignum;
bignum subtractBigNum(bignum a, bignum b) {
bignum c;
c.whole = a.whole - b.whole;
c.part = a.part - b.part;
if (c.part < 0) {
c.part += 1000000000000000000;
c.whole -= 1;
}
if (c.part > 1000000000000000000) {
c.part -= 1000000000000000000;
c.whole += 1;
}
return c;
}
bignum test(void) {
bignum a = { 789012, 345678 * 1000000000000ll };
bignum b = { 123, 456 * 1000000000000000ll };
return subtractBigNum(a, b);
}
It's a little off-topic, but this sounds like a marvellous opportunity
for a C++ class and user-defined literals.
> But you've already shown you have no clue, so I won't hold my breath.
>
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-08-23 11:45 -0400 |
| Message-ID | <nphr30$f0k$1@jstuckle.eternal-september.org> |
| In reply to | #92648 |
On 8/23/2016 10:39 AM, David Brown wrote:
> On 23/08/16 15:40, Jerry Stuckle wrote:
>> On 8/23/2016 9:07 AM, David Brown wrote:
>>> On 23/08/16 14:15, Jerry Stuckle wrote:
>>>> On 8/23/2016 3:38 AM, David Brown wrote:
>>>>> On 23/08/16 03:58, Jerry Stuckle wrote:
>>>>>> On 8/22/2016 8:01 PM, Ben Bacarisse wrote:
>>>>>>> Jerry Stuckle <jstucklex@attglobal.net> writes:
>>>>>>>
>>>>>>>> On 8/22/2016 11:39 AM, supercat@casperkitty.com wrote:
>>>>>>>>> On Sunday, August 21, 2016 at 5:31:13 PM UTC-5, Jerry Stuckle wrote:
>>>>>>>>>> For instance - I've seen it implemented as storing the digits in a
>>>>>>>>>> string. Quite easy to implement - but performance was terrible, as you
>>>>>>>>>> can imagine. OTOH, I implemented one back in the 80's based on two
>>>>>>>>>> digits per byte, using 808x assembler. Much faster, but not portable
>>>>>>>>>> and not all that easy.
>>>>>>>>>
>>>>>>>>> I'm surprised I haven't seen more "decimal math" libraries using 9 digits
>>>>>>>>> per word; such a thing would seem like a natural fit on a 32-bit processor
>>>>>>>>> with a 32x32->64 multiply. Performance would be likely slower than for
>>>>>>>>> binary math, but nowhere near as slow as using single-digit or two-digit
>>>>>>>>> chunks (on processors which can't use a carry flag for extended-precision
>>>>>>>>> math, addition and subtraction could benefit from the fact that the sum
>>>>>>>>> or difference of any two 9-digit chunks could fit in a 32-bit signed "int").
>>>>>>>>>
>>>>>>>>
>>>>>>>> 9 digits per word would not be decimal math. The most you could get
>>>>>>>> into 32 bits would be 8 decimal digits.
>>>>>>>
>>>>>>> I think what supercat is talking about might otherwise be called base
>>>>>>> 1,000,000,000 arithmetic.
>>>>>>>
>>>>>>>> And I suspect trying it would
>>>>>>>> be even slower than decimal math. It would be much more complicated to
>>>>>>>> implement.
>>>>>>>
>>>>>>> In software, it's faster and simpler than using BCD-type schemes, but
>>>>>>> it's a matter of definition if is a decimal scheme or not.
>>>>>>>
>>>>>>
>>>>>> I understand what he's after, and my comments stand. For instance, how
>>>>>> easy would it be to subtract 123.456 from 789012.345678? Not that hard
>>>>>> with BCD, but very difficult with supercat's idea. Adjusting for the
>>>>>> decimal point would not be easy.
>>>>>>
>>>>>
>>>>> That would depend on whether he is considering just integers (in which
>>>>> case arithmetic with a decimal point is /really/ hard!), or a
>>>>> representation supporting multiple 9-digit chunks (in which case,
>>>>> subtracting 000000123.456000000 from 000789012.345678000 would be quite
>>>>> simple), or something with a floating decimal point (which would be very
>>>>> messy).
>>>>>
>>>>> Personally, I don't think there would be anything much to be gained from
>>>>> base 1G formats, except perhaps in very niche cases.
>>>>>
>>>>>
>>>>>
>>>>
>>>> The whole thread is about real numbers, not integers, David. And seldom
>>>> do the numbers always have the same number of decimal places.
>>>>
>>>
>>> Just because the thread is about real numbers, does not mean that
>>> Supercat is still talking about them!
>>>
>>
>> Try again, stoopid.
>
> You think Supercat always sticks to the thread topic? You haven't read
> many of his posts.
>
Oh, I have read enough.
>>
>>> But I think that in many situations where you might be interested in
>>> tracking your numbers in decimal digit formats rather than floating
>>> point, scaled integer, or other binary formats, then you probably /do/
>>> have a fixed number of decimal digits. Financial calculations would be
>>> an example.
>>>
>>
>> No, financial calculations are not an example. For instance, banks
>> generally go at least six decimal places for monetary calculations, but
>> may go four to eight for percentage calculations (depending on how often
>> interest is calculated). And, of course, account transfers are only two
>> decimal places.
>>
>> The are many different numbers of decimal places used in financial
>> calculations.
>
> That sounds like a perfect example. At no point did I say that the
> fixed number of decimal places was the same in every use-case.
>
> And a single fixed value of 18 decimal places would do a far job of
> covering all the situations you describe.
>
Which would also waste all kinds of space. For instance - when
transferring money from one account to another, only two decimal places
are required. Now this sounds like a small amount - but when you're
talking millions of transactions a day, it quickly adds up.
This is especially true when you're talking interbank transfers, where
tapes are cut and sent to the Federal Reserve nightly. Adding four
extra decimal places greatly increases the amount of time required to
process those tapes (and yes, tapes are still used for a several very
valid reasons).
>>
>>> The exception would be in mathematical calculations where you want
>>> arbitrary precision in your decimal calculations.
>>>
>>
>> More the rule than the exception.
>>
>>> And in either case, I can't see why storing 9 digits in 32-bit chunks is
>>> going to be much more complicated than storing 1 or 2 digits in 8-bit
>>> chunks (BCD, packed or unpacked). It will certainly be more efficient
>>> for calculations. 18 digits in 64-bit chunks is going to be even better
>>> on modern cpus.
>>>
>>
>> Then you show how to subtract 123.456 from 789012.345678 using 18 digits
>> in 64 bit chunks. I'd love to see you do it.
>>
>
> typedef struct {
> int64_t whole;
> int64_t part;
> } bignum;
>
> bignum subtractBigNum(bignum a, bignum b) {
> bignum c;
> c.whole = a.whole - b.whole;
> c.part = a.part - b.part;
> if (c.part < 0) {
> c.part += 1000000000000000000;
> c.whole -= 1;
> }
> if (c.part > 1000000000000000000) {
> c.part -= 1000000000000000000;
> c.whole += 1;
> }
> return c;
> }
>
> bignum test(void) {
> bignum a = { 789012, 345678 * 1000000000000ll };
> bignum b = { 123, 456 * 1000000000000000ll };
> return subtractBigNum(a, b);
> }
>
> It's a little off-topic, but this sounds like a marvellous opportunity
> for a C++ class and user-defined literals.
>
Which only works if you have 64 bit integers - something relatively new
in computing, and only available on a limited number of platforms. And
while it will work in the specific case, it fails miserably for more
generic code.
But that's what I would expect from you. You solve the specific problem
rather than the general nature of the problem.
>> But you've already shown you have no clue, so I won't hold my breath.
>>
>
I'm still not holding my breath.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-08-23 21:42 +0200 |
| Message-ID | <npi8vt$2f6$1@dont-email.me> |
| In reply to | #92652 |
On 23/08/16 17:45, Jerry Stuckle wrote:
> On 8/23/2016 10:39 AM, David Brown wrote:
>> On 23/08/16 15:40, Jerry Stuckle wrote:
<snip>
>>> No, financial calculations are not an example. For instance, banks
>>> generally go at least six decimal places for monetary calculations, but
>>> may go four to eight for percentage calculations (depending on how often
>>> interest is calculated). And, of course, account transfers are only two
>>> decimal places.
>>>
>>> The are many different numbers of decimal places used in financial
>>> calculations.
>>
>> That sounds like a perfect example. At no point did I say that the
>> fixed number of decimal places was the same in every use-case.
>>
>> And a single fixed value of 18 decimal places would do a far job of
>> covering all the situations you describe.
>>
>
> Which would also waste all kinds of space. For instance - when
> transferring money from one account to another, only two decimal places
> are required. Now this sounds like a small amount - but when you're
> talking millions of transactions a day, it quickly adds up.
>
It quickly adds up to ... a small amount. Wasting 8 bytes per
transaction, multiplied by a few million, gives a few 10's of MB
overhead per day. Let's say 30 MB to be generous to you. If that
breaks the banks computer system, then it deserves to be broken.
> This is especially true when you're talking interbank transfers, where
> tapes are cut and sent to the Federal Reserve nightly. Adding four
> extra decimal places greatly increases the amount of time required to
> process those tapes (and yes, tapes are still used for a several very
> valid reasons).
>
A modern LTO-7 tape is 6 TB and runs at 300 MB/s (raw). Let's assume
the bank is using tried-and-true technology rather than the latest and
greatest. LTO-1 from 2000 is 100 GB at 20 MB/s. So this extra space
costs 1.5 seconds of extra time - hardly a "great increase".
>>>
>>>> The exception would be in mathematical calculations where you want
>>>> arbitrary precision in your decimal calculations.
>>>>
>>>
>>> More the rule than the exception.
>>>
>>>> And in either case, I can't see why storing 9 digits in 32-bit chunks is
>>>> going to be much more complicated than storing 1 or 2 digits in 8-bit
>>>> chunks (BCD, packed or unpacked). It will certainly be more efficient
>>>> for calculations. 18 digits in 64-bit chunks is going to be even better
>>>> on modern cpus.
>>>>
>>>
>>> Then you show how to subtract 123.456 from 789012.345678 using 18 digits
>>> in 64 bit chunks. I'd love to see you do it.
>>>
>>
>> typedef struct {
>> int64_t whole;
>> int64_t part;
>> } bignum;
>>
>> bignum subtractBigNum(bignum a, bignum b) {
>> bignum c;
>> c.whole = a.whole - b.whole;
>> c.part = a.part - b.part;
>> if (c.part < 0) {
>> c.part += 1000000000000000000;
>> c.whole -= 1;
>> }
>> if (c.part > 1000000000000000000) {
>> c.part -= 1000000000000000000;
>> c.whole += 1;
>> }
>> return c;
>> }
>>
>> bignum test(void) {
>> bignum a = { 789012, 345678 * 1000000000000ll };
>> bignum b = { 123, 456 * 1000000000000000ll };
>> return subtractBigNum(a, b);
>> }
>>
>> It's a little off-topic, but this sounds like a marvellous opportunity
>> for a C++ class and user-defined literals.
>>
>
> Which only works if you have 64 bit integers - something relatively new
> in computing, and only available on a limited number of platforms.
Yes, 64-bit cpus have only existing since 1975, and were not popular on
servers or serious computers until about 20 years ago. Quite new,
really. Of course, you don't need a 64-bit cpu in order to have 64-bit
integers - they are fully supported on some 8-bit systems. (Of course,
you only get speed benefits from using 64-bit chunks if you have a
64-bit cpu.)
As Ben noted, multiplication would be awkward if the compiler doesn't
have good support for a 64 x 64 -> 128 bit multiplication, so on older
or more limited systems you might be better with 9 digits in 32-bit
words if you have a lot of multiplication to do.
> And
> while it will work in the specific case, it fails miserably for more
> generic code.
What on earth do you mean? Sometimes I think you just open your mouth
and let your belly rumble, as the saying goes.
>
> But that's what I would expect from you. You solve the specific problem
> rather than the general nature of the problem.
>
>>> But you've already shown you have no clue, so I won't hold my breath.
>>>
>>
>
> I'm still not holding my breath.
>
Oh, go on - I bet you can hold it if you try.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-08-23 15:52 -0400 |
| Message-ID | <npi9hb$4fm$1@jstuckle.eternal-september.org> |
| In reply to | #92659 |
On 8/23/2016 3:42 PM, David Brown wrote:
> On 23/08/16 17:45, Jerry Stuckle wrote:
>> On 8/23/2016 10:39 AM, David Brown wrote:
>>> On 23/08/16 15:40, Jerry Stuckle wrote:
> <snip>
>>>> No, financial calculations are not an example. For instance, banks
>>>> generally go at least six decimal places for monetary calculations, but
>>>> may go four to eight for percentage calculations (depending on how
>>>> often
>>>> interest is calculated). And, of course, account transfers are only
>>>> two
>>>> decimal places.
>>>>
>>>> The are many different numbers of decimal places used in financial
>>>> calculations.
>>>
>>> That sounds like a perfect example. At no point did I say that the
>>> fixed number of decimal places was the same in every use-case.
>>>
>>> And a single fixed value of 18 decimal places would do a far job of
>>> covering all the situations you describe.
>>>
>>
>> Which would also waste all kinds of space. For instance - when
>> transferring money from one account to another, only two decimal places
>> are required. Now this sounds like a small amount - but when you're
>> talking millions of transactions a day, it quickly adds up.
>>
>
> It quickly adds up to ... a small amount. Wasting 8 bytes per
> transaction, multiplied by a few million, gives a few 10's of MB
> overhead per day. Let's say 30 MB to be generous to you. If that
> breaks the banks computer system, then it deserves to be broken.
>
Once again you show you have absolutely no idea what you're talking about.
>> This is especially true when you're talking interbank transfers, where
>> tapes are cut and sent to the Federal Reserve nightly. Adding four
>> extra decimal places greatly increases the amount of time required to
>> process those tapes (and yes, tapes are still used for a several very
>> valid reasons).
>>
>
> A modern LTO-7 tape is 6 TB and runs at 300 MB/s (raw). Let's assume
> the bank is using tried-and-true technology rather than the latest and
> greatest. LTO-1 from 2000 is 100 GB at 20 MB/s. So this extra space
> costs 1.5 seconds of extra time - hardly a "great increase".
>
And you again show you know nothing about which you speak. The real
speed is nothing close to the "raw" speed you specify. But if you had
any experience with such, you would know that.
>
>>>>
>>>>> The exception would be in mathematical calculations where you want
>>>>> arbitrary precision in your decimal calculations.
>>>>>
>>>>
>>>> More the rule than the exception.
>>>>
>>>>> And in either case, I can't see why storing 9 digits in 32-bit
>>>>> chunks is
>>>>> going to be much more complicated than storing 1 or 2 digits in 8-bit
>>>>> chunks (BCD, packed or unpacked). It will certainly be more efficient
>>>>> for calculations. 18 digits in 64-bit chunks is going to be even
>>>>> better
>>>>> on modern cpus.
>>>>>
>>>>
>>>> Then you show how to subtract 123.456 from 789012.345678 using 18
>>>> digits
>>>> in 64 bit chunks. I'd love to see you do it.
>>>>
>>>
>>> typedef struct {
>>> int64_t whole;
>>> int64_t part;
>>> } bignum;
>>>
>>> bignum subtractBigNum(bignum a, bignum b) {
>>> bignum c;
>>> c.whole = a.whole - b.whole;
>>> c.part = a.part - b.part;
>>> if (c.part < 0) {
>>> c.part += 1000000000000000000;
>>> c.whole -= 1;
>>> }
>>> if (c.part > 1000000000000000000) {
>>> c.part -= 1000000000000000000;
>>> c.whole += 1;
>>> }
>>> return c;
>>> }
>>>
>>> bignum test(void) {
>>> bignum a = { 789012, 345678 * 1000000000000ll };
>>> bignum b = { 123, 456 * 1000000000000000ll };
>>> return subtractBigNum(a, b);
>>> }
>>>
>>> It's a little off-topic, but this sounds like a marvellous opportunity
>>> for a C++ class and user-defined literals.
>>>
>>
>> Which only works if you have 64 bit integers - something relatively new
>> in computing, and only available on a limited number of platforms.
>
> Yes, 64-bit cpus have only existing since 1975, and were not popular on
> servers or serious computers until about 20 years ago. Quite new,
> really. Of course, you don't need a 64-bit cpu in order to have 64-bit
> integers - they are fully supported on some 8-bit systems. (Of course,
> you only get speed benefits from using 64-bit chunks if you have a
> 64-bit cpu.)
>
> As Ben noted, multiplication would be awkward if the compiler doesn't
> have good support for a 64 x 64 -> 128 bit multiplication, so on older
> or more limited systems you might be better with 9 digits in 32-bit
> words if you have a lot of multiplication to do.
>
Gee, again you have to show your ignorance. But you do it so often,
that it doesn't surprise me. Your update is as full of crap as you are -
not even worth trying to correct.
>
>> And
>> while it will work in the specific case, it fails miserably for more
>> generic code.
>
> What on earth do you mean? Sometimes I think you just open your mouth
> and let your belly rumble, as the saying goes.
>
Yes, you are very good at that. But if you actually understood the
problem, you would understand the failure.
>>
>> But that's what I would expect from you. You solve the specific problem
>> rather than the general nature of the problem.
>>
>>>> But you've already shown you have no clue, so I won't hold my breath.
>>>>
>>>
>>
>> I'm still not holding my breath.
>>
>
> Oh, go on - I bet you can hold it if you try.
>
>
You're not worth it.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-08-24 08:36 +1200 |
| Message-ID | <e23qfaF35ipU1@mid.individual.net> |
| In reply to | #92659 |
On 08/24/16 07:42 AM, David Brown wrote: > On 23/08/16 17:45, Jerry Stuckle wrote: > >> This is especially true when you're talking interbank transfers, where >> tapes are cut and sent to the Federal Reserve nightly. Adding four >> extra decimal places greatly increases the amount of time required to >> process those tapes (and yes, tapes are still used for a several very >> valid reasons). >> > > A modern LTO-7 tape is 6 TB and runs at 300 MB/s (raw). Let's assume > the bank is using tried-and-true technology rather than the latest and > greatest. LTO-1 from 2000 is 100 GB at 20 MB/s. So this extra space > costs 1.5 seconds of extra time - hardly a "great increase". Less than that - nothingness compresses rather well! >> Which only works if you have 64 bit integers - something relatively new >> in computing, and only available on a limited number of platforms. > > Yes, 64-bit cpus have only existing since 1975, and were not popular on > servers or serious computers until about 20 years ago. Quite new, > really. Don't forget Jerry World is stuck in the 90s, to there they are new. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-08-24 09:39 +0200 |
| Message-ID | <npjiv9$m0g$1@dont-email.me> |
| In reply to | #92662 |
On 23/08/16 22:36, Ian Collins wrote: > On 08/24/16 07:42 AM, David Brown wrote: >> On 23/08/16 17:45, Jerry Stuckle wrote: >> >>> This is especially true when you're talking interbank transfers, where >>> tapes are cut and sent to the Federal Reserve nightly. Adding four >>> extra decimal places greatly increases the amount of time required to >>> process those tapes (and yes, tapes are still used for a several very >>> valid reasons). >>> >> >> A modern LTO-7 tape is 6 TB and runs at 300 MB/s (raw). Let's assume >> the bank is using tried-and-true technology rather than the latest and >> greatest. LTO-1 from 2000 is 100 GB at 20 MB/s. So this extra space >> costs 1.5 seconds of extra time - hardly a "great increase". > > Less than that - nothingness compresses rather well! > >>> Which only works if you have 64 bit integers - something relatively new >>> in computing, and only available on a limited number of platforms. >> >> Yes, 64-bit cpus have only existing since 1975, and were not popular on >> servers or serious computers until about 20 years ago. Quite new, >> really. > > Don't forget Jerry World is stuck in the 90s, to there they are new. > I am not convinced he has made it as far as the 90's. Note that he refers to "where tapes are /cut/" - perhaps he is thinking more of punched tapes and punched cards. Anyway, as Ben already noted he has gone back to "gratuitous personal insult" mode, so that's the end of this thread branch.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-08-24 11:31 -0400 |
| Message-ID | <npkekm$gqu$1@jstuckle.eternal-september.org> |
| In reply to | #92671 |
On 8/24/2016 3:39 AM, David Brown wrote: > On 23/08/16 22:36, Ian Collins wrote: >> On 08/24/16 07:42 AM, David Brown wrote: >>> On 23/08/16 17:45, Jerry Stuckle wrote: >>> >>>> This is especially true when you're talking interbank transfers, where >>>> tapes are cut and sent to the Federal Reserve nightly. Adding four >>>> extra decimal places greatly increases the amount of time required to >>>> process those tapes (and yes, tapes are still used for a several very >>>> valid reasons). >>>> >>> >>> A modern LTO-7 tape is 6 TB and runs at 300 MB/s (raw). Let's assume >>> the bank is using tried-and-true technology rather than the latest and >>> greatest. LTO-1 from 2000 is 100 GB at 20 MB/s. So this extra space >>> costs 1.5 seconds of extra time - hardly a "great increase". >> >> Less than that - nothingness compresses rather well! >> >>>> Which only works if you have 64 bit integers - something relatively new >>>> in computing, and only available on a limited number of platforms. >>> >>> Yes, 64-bit cpus have only existing since 1975, and were not popular on >>> servers or serious computers until about 20 years ago. Quite new, >>> really. >> >> Don't forget Jerry World is stuck in the 90s, to there they are new. >> > > I am not convinced he has made it as far as the 90's. Note that he > refers to "where tapes are /cut/" - perhaps he is thinking more of > punched tapes and punched cards. > > Anyway, as Ben already noted he has gone back to "gratuitous personal > insult" mode, so that's the end of this thread branch. > > No, it is still called "cutting a tape". But you once again are showing your ignorance. I really feel sorry for both you and Ian. So ignorant, yet believing you know everything. But for so long you've been able to bullshit newer programmers in this newsgroup to think you really know something. One of these days hopefully you will figure out just how little you do know. Then maybe you can start to learn. Not until then, though. Until then, you are just trolls. And stoopid ones at that. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-23 10:48 +0100 |
| Message-ID | <87inurstnl.fsf@bsb.me.uk> |
| In reply to | #92612 |
Jerry Stuckle <jstucklex@attglobal.net> writes: > On 8/22/2016 8:01 PM, Ben Bacarisse wrote: >> Jerry Stuckle <jstucklex@attglobal.net> writes: >> >>> On 8/22/2016 11:39 AM, supercat@casperkitty.com wrote: <snip> >>>> I'm surprised I haven't seen more "decimal math" libraries using 9 digits >>>> per word; such a thing would seem like a natural fit on a 32-bit processor >>>> with a 32x32->64 multiply. Performance would be likely slower than for >>>> binary math, but nowhere near as slow as using single-digit or two-digit >>>> chunks (on processors which can't use a carry flag for extended-precision >>>> math, addition and subtraction could benefit from the fact that the sum >>>> or difference of any two 9-digit chunks could fit in a 32-bit signed "int"). >>>> >>> >>> 9 digits per word would not be decimal math. The most you could get >>> into 32 bits would be 8 decimal digits. >> >> I think what supercat is talking about might otherwise be called base >> 1,000,000,000 arithmetic. >> >>> And I suspect trying it would >>> be even slower than decimal math. It would be much more complicated to >>> implement. >> >> In software, it's faster and simpler than using BCD-type schemes, but >> it's a matter of definition if is a decimal scheme or not. >> > > I understand what he's after, and my comments stand. For instance, how > easy would it be to subtract 123.456 from 789012.345678? Not that hard > with BCD, but very difficult with supercat's idea. Adjusting for the > decimal point would not be easy. I think you have missed what he's suggesting. Your example subtraction is very easy in base 1,000,000,000 arithmetic. One simple representation might be (1, [789012, 345678000]) - (1, [123, 456000000]) The 1 showing that both have 1 digit after the point. Even using a naive algorithm, the whole operation will take two subtractions, an add and a decrement. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-08-23 08:17 -0400 |
| Message-ID | <nphes2$1dn$4@jstuckle.eternal-september.org> |
| In reply to | #92616 |
On 8/23/2016 5:48 AM, Ben Bacarisse wrote: > Jerry Stuckle <jstucklex@attglobal.net> writes: > >> On 8/22/2016 8:01 PM, Ben Bacarisse wrote: >>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>> >>>> On 8/22/2016 11:39 AM, supercat@casperkitty.com wrote: > <snip> >>>>> I'm surprised I haven't seen more "decimal math" libraries using 9 digits >>>>> per word; such a thing would seem like a natural fit on a 32-bit processor >>>>> with a 32x32->64 multiply. Performance would be likely slower than for >>>>> binary math, but nowhere near as slow as using single-digit or two-digit >>>>> chunks (on processors which can't use a carry flag for extended-precision >>>>> math, addition and subtraction could benefit from the fact that the sum >>>>> or difference of any two 9-digit chunks could fit in a 32-bit signed "int"). >>>>> >>>> >>>> 9 digits per word would not be decimal math. The most you could get >>>> into 32 bits would be 8 decimal digits. >>> >>> I think what supercat is talking about might otherwise be called base >>> 1,000,000,000 arithmetic. >>> >>>> And I suspect trying it would >>>> be even slower than decimal math. It would be much more complicated to >>>> implement. >>> >>> In software, it's faster and simpler than using BCD-type schemes, but >>> it's a matter of definition if is a decimal scheme or not. >>> >> >> I understand what he's after, and my comments stand. For instance, how >> easy would it be to subtract 123.456 from 789012.345678? Not that hard >> with BCD, but very difficult with supercat's idea. Adjusting for the >> decimal point would not be easy. > > I think you have missed what he's suggesting. Your example subtraction > is very easy in base 1,000,000,000 arithmetic. One simple > representation might be > > (1, [789012, 345678000]) - (1, [123, 456000000]) > > The 1 showing that both have 1 digit after the point. Even using a > naive algorithm, the whole operation will take two subtractions, an add > and a decrement. > No, I did not miss his suggestion. What YOU miss is the fact that in the real world, numbers generally don't all have the same number of decimal places. So your code doesn't work. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-23 06:01 -0700 |
| Message-ID | <2c6f0cd1-2249-4272-a173-b6bff7541a00@googlegroups.com> |
| In reply to | #92618 |
On Tuesday, August 23, 2016 at 1:17:14 PM UTC+1, Jerry Stuckle wrote: > > No, I did not miss his suggestion. What YOU miss is the fact that in > the real world, numbers generally don't all have the same number of > decimal places. So your code doesn't work. > What do you mean? It's very common for all numbers in a list to be restricted to say, 0-1, with tiny numbers very close to zero unlikely or forbidden by an epsilon of, say 0.001. That also implies three decimal places. Of course general purpose functions, like my median code elsethread, cannot assume that all numbers are within a tight range or have a low precision. You can usually make some assumptions, e.g. that range and precision of a double is easily enough to avoid numerical problems.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-08-23 09:44 -0400 |
| Message-ID | <nphk09$kta$1@jstuckle.eternal-september.org> |
| In reply to | #92624 |
On 8/23/2016 9:01 AM, Malcolm McLean wrote: > On Tuesday, August 23, 2016 at 1:17:14 PM UTC+1, Jerry Stuckle wrote: >> >> No, I did not miss his suggestion. What YOU miss is the fact that in >> the real world, numbers generally don't all have the same number of >> decimal places. So your code doesn't work. >> > What do you mean? > > It's very common for all numbers in a list to be restricted to say, 0-1, with > tiny numbers very close to zero unlikely or forbidden by an epsilon of, say > 0.001. That also implies three decimal places. > > Of course general purpose functions, like my median code elsethread, > cannot assume that all numbers are within a tight range or have a low > precision. You can usually make some assumptions, e.g. that range > and precision of a double is easily enough to avoid numerical problems. > I meant exactly what I said. Seldom in the real world does everything have the same number of decimal places. The number of decimal places required can vary widely. Even financial calculations can vary from two to six or more decimal places at financial institutions. And while numbers in a list may be restricted, that isn't the only source of numbers in a program. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-23 07:19 -0700 |
| Message-ID | <f24dbff5-1084-440d-9ec7-899b86cff9a4@googlegroups.com> |
| In reply to | #92633 |
On Tuesday, August 23, 2016 at 2:44:48 PM UTC+1, Jerry Stuckle wrote: > On 8/23/2016 9:01 AM, Malcolm McLean wrote: > > On Tuesday, August 23, 2016 at 1:17:14 PM UTC+1, Jerry Stuckle wrote: > >> > >> No, I did not miss his suggestion. What YOU miss is the fact that in > >> the real world, numbers generally don't all have the same number of > >> decimal places. So your code doesn't work. > >> > > What do you mean? > > > > It's very common for all numbers in a list to be restricted to say, 0-1, with > > tiny numbers very close to zero unlikely or forbidden by an epsilon of, say > > 0.001. That also implies three decimal places. > > > > Of course general purpose functions, like my median code elsethread, > > cannot assume that all numbers are within a tight range or have a low > > precision. You can usually make some assumptions, e.g. that range > > and precision of a double is easily enough to avoid numerical problems. > > > > I meant exactly what I said. Seldom in the real world does everything > have the same number of decimal places. The number of decimal places > required can vary widely. Even financial calculations can vary from two > to six or more decimal places at financial institutions. > > And while numbers in a list may be restricted, that isn't the only > source of numbers in a program. > So we have a video game. We decide that a game unit shall be 1.0 metres in the real world, assuming the characters are roughly human-sized, and the camera's near clipping plane shall be 0.5 m and the far clipping plane 200m (any geometry further than 200m is faked up, or we design the levels with rooms so that distances of > 200m can't arise). So objects less than about 0.01 m are going to be sub-pixel even at closest distance, and there won't be any objects greater than about 100m. Those aren't all the numbers in the program, of course, but they are all the points that represent geometry in Cartesian co-ordinates. And that's a fairly typical situation. Very many programs are essentially like that.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-08-23 10:39 -0400 |
| Message-ID | <nphn6j$de$2@jstuckle.eternal-september.org> |
| In reply to | #92644 |
On 8/23/2016 10:19 AM, Malcolm McLean wrote: > On Tuesday, August 23, 2016 at 2:44:48 PM UTC+1, Jerry Stuckle wrote: >> On 8/23/2016 9:01 AM, Malcolm McLean wrote: >>> On Tuesday, August 23, 2016 at 1:17:14 PM UTC+1, Jerry Stuckle wrote: >>>> >>>> No, I did not miss his suggestion. What YOU miss is the fact that in >>>> the real world, numbers generally don't all have the same number of >>>> decimal places. So your code doesn't work. >>>> >>> What do you mean? >>> >>> It's very common for all numbers in a list to be restricted to say, 0-1, with >>> tiny numbers very close to zero unlikely or forbidden by an epsilon of, say >>> 0.001. That also implies three decimal places. >>> >>> Of course general purpose functions, like my median code elsethread, >>> cannot assume that all numbers are within a tight range or have a low >>> precision. You can usually make some assumptions, e.g. that range >>> and precision of a double is easily enough to avoid numerical problems. >>> >> >> I meant exactly what I said. Seldom in the real world does everything >> have the same number of decimal places. The number of decimal places >> required can vary widely. Even financial calculations can vary from two >> to six or more decimal places at financial institutions. >> >> And while numbers in a list may be restricted, that isn't the only >> source of numbers in a program. >> > So we have a video game. We decide that a game unit shall be 1.0 metres in > the real world, assuming the characters are roughly human-sized, and the > camera's near clipping plane shall be 0.5 m and the far clipping plane 200m > (any geometry further than 200m is faked up, or we design the levels with > rooms so that distances of > 200m can't arise). > So objects less than about 0.01 m are going to be sub-pixel even at closest > distance, and there won't be any objects greater than about 100m. > Those aren't all the numbers in the program, of course, but they are all the > points that represent geometry in Cartesian co-ordinates. And that's a > fairly typical situation. Very many programs are essentially like that. > Who's talking video games? You can do that with straight integers. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-23 08:18 -0700 |
| Message-ID | <73bbecd4-994e-48c6-a95c-3844f8c9805e@googlegroups.com> |
| In reply to | #92647 |
On Tuesday, August 23, 2016 at 3:39:22 PM UTC+1, Jerry Stuckle wrote: > > Who's talking video games? You can do that with straight integers. > Yes, and in the olden days, that was the solution often adopted. But whilst you can do everything in integer units of, say, 1cm, it's easier to use a floating point type. For one thing, you want to square values to obtain distances. Then you want to normalize for directions. Then 1cm isn't a hard limit you can can easily set in modelling tools, just roughly the point at which geometry is going to be largely sub-pixel.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-23 14:47 +0100 |
| Message-ID | <87zio3r400.fsf@bsb.me.uk> |
| In reply to | #92618 |
Jerry Stuckle <jstucklex@attglobal.net> writes: > On 8/23/2016 5:48 AM, Ben Bacarisse wrote: >> Jerry Stuckle <jstucklex@attglobal.net> writes: >> >>> On 8/22/2016 8:01 PM, Ben Bacarisse wrote: >>>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>>> >>>>> On 8/22/2016 11:39 AM, supercat@casperkitty.com wrote: >> <snip> >>>>>> I'm surprised I haven't seen more "decimal math" libraries using 9 digits >>>>>> per word; such a thing would seem like a natural fit on a 32-bit processor >>>>>> with a 32x32->64 multiply. Performance would be likely slower than for >>>>>> binary math, but nowhere near as slow as using single-digit or two-digit >>>>>> chunks (on processors which can't use a carry flag for extended-precision >>>>>> math, addition and subtraction could benefit from the fact that the sum >>>>>> or difference of any two 9-digit chunks could fit in a 32-bit >>>>>> signed "int"). >>>>>> >>>>> >>>>> 9 digits per word would not be decimal math. The most you could get >>>>> into 32 bits would be 8 decimal digits. >>>> >>>> I think what supercat is talking about might otherwise be called base >>>> 1,000,000,000 arithmetic. >>>> >>>>> And I suspect trying it would >>>>> be even slower than decimal math. It would be much more complicated to >>>>> implement. >>>> >>>> In software, it's faster and simpler than using BCD-type schemes, but >>>> it's a matter of definition if is a decimal scheme or not. >>>> >>> >>> I understand what he's after, and my comments stand. For instance, how >>> easy would it be to subtract 123.456 from 789012.345678? Not that hard >>> with BCD, but very difficult with supercat's idea. Adjusting for the >>> decimal point would not be easy. >> >> I think you have missed what he's suggesting. Your example subtraction >> is very easy in base 1,000,000,000 arithmetic. One simple >> representation might be >> >> (1, [789012, 345678000]) - (1, [123, 456000000]) >> >> The 1 showing that both have 1 digit after the point. Even using a >> naive algorithm, the whole operation will take two subtractions, an add >> and a decrement. > > No, I did not miss his suggestion. What YOU miss is the fact that in > the real world, numbers generally don't all have the same number of > decimal places. No, you claimed the subtraction you gave was "very hard". You obviously did not understand what was being suggested or you would have given an example that was, at least, not trivial. If you like, try again to post a "very hard" subtraction, but there are none -- it's a simple scheme. It maybe time for you to start insulting me. > So your code doesn't work. I posted no code, but I *have* implemented this scheme (more than once) and it is very simple. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-08-23 10:40 -0400 |
| Message-ID | <nphn8t$de$3@jstuckle.eternal-september.org> |
| In reply to | #92635 |
On 8/23/2016 9:47 AM, Ben Bacarisse wrote: > Jerry Stuckle <jstucklex@attglobal.net> writes: > >> On 8/23/2016 5:48 AM, Ben Bacarisse wrote: >>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>> >>>> On 8/22/2016 8:01 PM, Ben Bacarisse wrote: >>>>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>>>> >>>>>> On 8/22/2016 11:39 AM, supercat@casperkitty.com wrote: >>> <snip> >>>>>>> I'm surprised I haven't seen more "decimal math" libraries using 9 digits >>>>>>> per word; such a thing would seem like a natural fit on a 32-bit processor >>>>>>> with a 32x32->64 multiply. Performance would be likely slower than for >>>>>>> binary math, but nowhere near as slow as using single-digit or two-digit >>>>>>> chunks (on processors which can't use a carry flag for extended-precision >>>>>>> math, addition and subtraction could benefit from the fact that the sum >>>>>>> or difference of any two 9-digit chunks could fit in a 32-bit >>>>>>> signed "int"). >>>>>>> >>>>>> >>>>>> 9 digits per word would not be decimal math. The most you could get >>>>>> into 32 bits would be 8 decimal digits. >>>>> >>>>> I think what supercat is talking about might otherwise be called base >>>>> 1,000,000,000 arithmetic. >>>>> >>>>>> And I suspect trying it would >>>>>> be even slower than decimal math. It would be much more complicated to >>>>>> implement. >>>>> >>>>> In software, it's faster and simpler than using BCD-type schemes, but >>>>> it's a matter of definition if is a decimal scheme or not. >>>>> >>>> >>>> I understand what he's after, and my comments stand. For instance, how >>>> easy would it be to subtract 123.456 from 789012.345678? Not that hard >>>> with BCD, but very difficult with supercat's idea. Adjusting for the >>>> decimal point would not be easy. >>> >>> I think you have missed what he's suggesting. Your example subtraction >>> is very easy in base 1,000,000,000 arithmetic. One simple >>> representation might be >>> >>> (1, [789012, 345678000]) - (1, [123, 456000000]) >>> >>> The 1 showing that both have 1 digit after the point. Even using a >>> naive algorithm, the whole operation will take two subtractions, an add >>> and a decrement. >> >> No, I did not miss his suggestion. What YOU miss is the fact that in >> the real world, numbers generally don't all have the same number of >> decimal places. > > No, you claimed the subtraction you gave was "very hard". You obviously > did not understand what was being suggested or you would have given an > example that was, at least, not trivial. If you like, try again to post > a "very hard" subtraction, but there are none -- it's a simple scheme. > It maybe time for you to start insulting me. > >> So your code doesn't work. > > I posted no code, but I *have* implemented this scheme (more than once) > and it is very simple. > So, let's see your code. And I gave a trivial example which just *might* be easy enough for you to understand. But I can see even that didn't work. And no insult - just the truth. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-24 01:31 +0100 |
| Message-ID | <8737lvqa7r.fsf@bsb.me.uk> |
| In reply to | #92649 |
Jerry Stuckle <jstucklex@attglobal.net> writes: <snip> >>>>> On 8/22/2016 8:01 PM, Ben Bacarisse wrote: <snip> >>>>>> I think what supercat is talking about might otherwise be called base >>>>>> 1,000,000,000 arithmetic. <snip> >>>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>>> >>>>> I understand what he's after, and my comments stand. For instance, how >>>>> easy would it be to subtract 123.456 from 789012.345678? Not that hard >>>>> with BCD, but very difficult with supercat's idea. Adjusting for the >>>>> decimal point would not be easy. <snip> > ... And I gave a trivial example which just > *might* be easy enough for you to understand. You claimed to understand, but gave an example you said was "very hard" because "adjusting for the decimal point would not be easy". (I've left that part quoted so everyone can see it.) The decimal point is in the same place in both numbers using the scheme in question. No adjustment is needed. Each number is two digits, and the "very hard" subtraction needs two subtractions and a borrow (a decrement and an addition of the base). -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-08-23 20:53 -0400 |
| Message-ID | <npir73$s82$1@jstuckle.eternal-september.org> |
| In reply to | #92665 |
On 8/23/2016 8:31 PM, Ben Bacarisse wrote: > Jerry Stuckle <jstucklex@attglobal.net> writes: > <snip> >>>>>> On 8/22/2016 8:01 PM, Ben Bacarisse wrote: > <snip> >>>>>>> I think what supercat is talking about might otherwise be called base >>>>>>> 1,000,000,000 arithmetic. > <snip> >>>>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>>>> >>>>>> I understand what he's after, and my comments stand. For instance, how >>>>>> easy would it be to subtract 123.456 from 789012.345678? Not that hard >>>>>> with BCD, but very difficult with supercat's idea. Adjusting for the >>>>>> decimal point would not be easy. > <snip> >> ... And I gave a trivial example which just >> *might* be easy enough for you to understand. > > You claimed to understand, but gave an example you said was "very hard" > because "adjusting for the decimal point would not be easy". (I've left > that part quoted so everyone can see it.) The decimal point is in the > same place in both numbers using the scheme in question. No adjustment > is needed. Each number is two digits, and the "very hard" subtraction > needs two subtractions and a borrow (a decrement and an addition of the > base). > Yes, and how do you handle user input, where you don't know how many decimal places there area? How do you use it with columns of type DECIMAL in databases? IOW, how do you make it work in the real world? Your "solution" is so full of holes I don't quite know where to begin. As I said - you solved the specific problem - without understanding the general problem. Something you (and a few others here) do quite regularly. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-23 23:20 -0700 |
| Message-ID | <e9cdc7bd-596d-4003-8d94-941ad00042bf@googlegroups.com> |
| In reply to | #92666 |
On Tuesday, August 23, 2016 at 7:54:04 PM UTC-5, Jerry Stuckle wrote: > Yes, and how do you handle user input, where you don't know how many > decimal places there area? How do you use it with columns of type > DECIMAL in databases? For user input, one typically reads things into a buffer until the input is complete, whereupon one can see how many decimal places were entered. As for a database, the simplest way to store things would be to keep whole groups of 9 digits. If the first or last group has 1-2 digits, however, it can easily be stored as one byte. If 3-4 digits, two bytes. If 5-7 digits, 3 bytes. > IOW, how do you make it work in the real world? Your "solution" is so > full of holes I don't quite know where to begin. As I said - you solved > the specific problem - without understanding the general problem. > Something you (and a few others here) do quite regularly.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-08-24 11:32 -0400 |
| Message-ID | <npkelt$gqu$2@jstuckle.eternal-september.org> |
| In reply to | #92668 |
On 8/24/2016 2:20 AM, supercat@casperkitty.com wrote: > On Tuesday, August 23, 2016 at 7:54:04 PM UTC-5, Jerry Stuckle wrote: >> Yes, and how do you handle user input, where you don't know how many >> decimal places there area? How do you use it with columns of type >> DECIMAL in databases? > > For user input, one typically reads things into a buffer until the input > is complete, whereupon one can see how many decimal places were entered. > > As for a database, the simplest way to store things would be to keep whole > groups of 9 digits. If the first or last group has 1-2 digits, however, > it can easily be stored as one byte. If 3-4 digits, two bytes. If 5-7 > digits, 3 bytes. > >> IOW, how do you make it work in the real world? Your "solution" is so >> full of holes I don't quite know where to begin. As I said - you solved >> the specific problem - without understanding the general problem. >> Something you (and a few others here) do quite regularly. You missed the DECIMAL type - which is what people use in the real world. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web