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 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-08-24 09:46 +0200 |
| Message-ID | <npjjbv$n24$1@dont-email.me> |
| In reply to | #92666 |
On 24/08/16 02:53, Jerry Stuckle wrote: > 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. > Seriously? That's your objection? You asked a simple question that you claimed to be hard, a got a simple answer. You can't then declare that Ben (or I) had failed to answer everything you can imagine /around/ that question. If I ask you to write a "Hello, world!" program in C, and you replied with a simple "printf", you would think it a touch unreasonable if I complained that you'd forgotten to write the source code for the compiler, and thus barely started the answer.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-24 14:53 +0100 |
| Message-ID | <87r39ep92m.fsf@bsb.me.uk> |
| In reply to | #92672 |
David Brown <david.brown@hesbynett.no> writes: > On 24/08/16 02:53, Jerry Stuckle wrote: >> 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. >> > > Seriously? That's your objection? You asked a simple question that you > claimed to be hard, a got a simple answer. You can't then declare that > Ben (or I) had failed to answer everything you can imagine /around/ that > question. He just likes to argue, all the more when he's wrong. He has no interest in how this scheme works -- in fact it it very likely he knows perfectly well how to do these things. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-08-24 11:35 -0400 |
| Message-ID | <npkess$gqu$4@jstuckle.eternal-september.org> |
| In reply to | #92679 |
On 8/24/2016 9:53 AM, Ben Bacarisse wrote: > David Brown <david.brown@hesbynett.no> writes: > >> On 24/08/16 02:53, Jerry Stuckle wrote: >>> 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. >>> >> >> Seriously? That's your objection? You asked a simple question that you >> claimed to be hard, a got a simple answer. You can't then declare that >> Ben (or I) had failed to answer everything you can imagine /around/ that >> question. > > He just likes to argue, all the more when he's wrong. He has no > interest in how this scheme works -- in fact it it very likely he knows > perfectly well how to do these things. > Ok, if your scheme is so good, how do you do 25.3 / 14.7? Or 1.414 / 3.14159? And BTW - your code fails in the case of 1.4 - 2.2. So much for it being "simple". You claim to have done it many times - yet you can't even get that right. Yes, I know how to do it. But I know how to do it so that it works. -- ================== 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-24 08:57 -0700 |
| Message-ID | <714f8368-e090-4be0-8061-183388e89e92@googlegroups.com> |
| In reply to | #92683 |
On Wednesday, August 24, 2016 at 4:36:03 PM UTC+1, Jerry Stuckle wrote: > > And BTW - your code fails in the case of 1.4 - 2.2. > No, the answer is outside of the domain. just as pow(sqrt(-1), sqrt(-1)); will "fail" in C, but not in Maple.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-24 17:36 +0100 |
| Message-ID | <87eg5ep1i5.fsf@bsb.me.uk> |
| In reply to | #92684 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Wednesday, August 24, 2016 at 4:36:03 PM UTC+1, Jerry Stuckle wrote: >> >> And BTW - your code fails in the case of 1.4 - 2.2. >> > No, the answer is outside of the domain. Unless I missed it, the domain has not yet been specified, and the representation I suggested has only been illustrated rather defined. I'd say the result would be (1, [1, 400000000]) - (1, [2, 200000000]) = (1, [-800000000]) but there are many other representations that could be used. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-08-24 12:50 -0400 |
| Message-ID | <npkj8a$1gj$1@jstuckle.eternal-september.org> |
| In reply to | #92684 |
On 8/24/2016 11:57 AM, Malcolm McLean wrote: > On Wednesday, August 24, 2016 at 4:36:03 PM UTC+1, Jerry Stuckle wrote: >> >> And BTW - your code fails in the case of 1.4 - 2.2. >> > No, the answer is outside of the domain. > > just as pow(sqrt(-1), sqrt(-1)); will "fail" in C, but not in Maple. > Nope, it is in the domain. But the calculation fails. -- ================== 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 17:26 +0100 |
| Message-ID | <87k2f6p1ym.fsf@bsb.me.uk> |
| In reply to | #92683 |
Jerry Stuckle <jstucklex@attglobal.net> writes: <snip> > Yes, I know how to do it. And yet you said: | ... how easy would it be to subtract 123.456 from 789012.345678? Not | that hard with BCD, but very difficult with supercat's idea. Do you still claim that subtraction is very difficult, now you know what's being discussed? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-08-24 12:51 -0400 |
| Message-ID | <npkj9o$1gj$2@jstuckle.eternal-september.org> |
| In reply to | #92685 |
On 8/24/2016 12:26 PM, Ben Bacarisse wrote: > Jerry Stuckle <jstucklex@attglobal.net> writes: > <snip> >> Yes, I know how to do it. > > And yet you said: > > | ... how easy would it be to subtract 123.456 from 789012.345678? Not > | that hard with BCD, but very difficult with supercat's idea. > > Do you still claim that subtraction is very difficult, now you know > what's being discussed? > Oh, I know what's being discussed. And I know you have no idea how to do it *correctly*. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-08-24 11:33 -0400 |
| Message-ID | <npkeoo$gqu$3@jstuckle.eternal-september.org> |
| In reply to | #92672 |
On 8/24/2016 3:46 AM, David Brown wrote: > On 24/08/16 02:53, Jerry Stuckle wrote: >> 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. >> > > Seriously? That's your objection? You asked a simple question that you > claimed to be hard, a got a simple answer. You can't then declare that > Ben (or I) had failed to answer everything you can imagine /around/ that > question. > > If I ask you to write a "Hello, world!" program in C, and you replied > with a simple "printf", you would think it a touch unreasonable if I > complained that you'd forgotten to write the source code for the > compiler, and thus barely started the answer. > > Yes, stoopid trolls like you would think that. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2016-08-28 02:33 -0500 |
| Message-ID | <eg45sb1rmj0i7oslb8sqkia9mg7fq7c7fn@4ax.com> |
| In reply to | #92611 |
On Tue, 23 Aug 2016 01:01:31 +0100, Ben Bacarisse <ben.usenet@bsb.me.uk> 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. The common usage is to call such things "limbs" rather than digits. IOW, "limb" refers to the internal format, "digit" remains free to mean something to the user. And FWIW, I implemented my first "binary-coded-base-one-billion" bignum functions in the early eighties. It's not at all uncommon if you have reason for avoiding the pure binary forms. Conversion of external decimal formats and decimal scaling are much easier with such a format, although the actual arithmetic is slower.
[toc] | [prev] | [next] | [standalone]
| From | antispam@math.uni.wroc.pl |
|---|---|
| Date | 2016-08-31 22:36 +0000 |
| Message-ID | <nq7m4r$qi1$1@z-news.wcss.wroc.pl> |
| In reply to | #92584 |
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").
Maple used to do this (my impression is that they switched to binary
in newer versions, but I am not sure). The experience is that it
is much slower than binary. In most applications easy convertion
to decimal does not compensate other drawbacks.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-31 15:51 -0700 |
| Message-ID | <8a43daa1-f70c-43c2-87e8-9de80345c784@googlegroups.com> |
| In reply to | #93031 |
On Wednesday, August 31, 2016 at 5:36:21 PM UTC-5, anti...@math.uni.wroc.pl wrote: > Maple used to do this (my impression is that they switched to binary > in newer versions, but I am not sure). The experience is that it > is much slower than binary. In most applications easy convertion > to decimal does not compensate other drawbacks. For whole numbers, I would think straight binary would generally be the way to go. For decimal fractions, however, using a combination of a binary significand but base-ten exponent would add considerably to the cost of addition and subtraction (if e.g. one had a 30-bit significand, and wanted to add 900000000/100 to 12345678/10000, one would first have to divide the latter quantity by 100 before one could add it to the former.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-08-31 22:42 -0400 |
| Message-ID | <nq84is$1sl$1@jstuckle.eternal-september.org> |
| In reply to | #93032 |
On 8/31/2016 6:51 PM, supercat@casperkitty.com wrote: > On Wednesday, August 31, 2016 at 5:36:21 PM UTC-5, anti...@math.uni.wroc.pl wrote: >> Maple used to do this (my impression is that they switched to binary >> in newer versions, but I am not sure). The experience is that it >> is much slower than binary. In most applications easy convertion >> to decimal does not compensate other drawbacks. > > For whole numbers, I would think straight binary would generally be the way > to go. For decimal fractions, however, using a combination of a binary > significand but base-ten exponent would add considerably to the cost of > addition and subtraction (if e.g. one had a 30-bit significand, and wanted > to add 900000000/100 to 12345678/10000, one would first have to divide > the latter quantity by 100 before one could add it to the former. > And how do you divide 1234.5678 by 9.012345? -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-09-01 08:32 -0700 |
| Message-ID | <600cf3e2-70a0-4246-a52f-a89f8a3e00d5@googlegroups.com> |
| In reply to | #93035 |
On Wednesday, August 31, 2016 at 9:42:47 PM UTC-5, Jerry Stuckle wrote: > On 8/31/2016 6:51 PM, supercat wrote: > > On Wednesday, August 31, 2016 at 5:36:21 PM UTC-5, anti...@math.uni.wroc.pl wrote: > >> Maple used to do this (my impression is that they switched to binary > >> in newer versions, but I am not sure). The experience is that it > >> is much slower than binary. In most applications easy convertion > >> to decimal does not compensate other drawbacks. > > > > For whole numbers, I would think straight binary would generally be the way > > to go. For decimal fractions, however, using a combination of a binary > > significand but base-ten exponent would add considerably to the cost of > > addition and subtraction (if e.g. one had a 30-bit significand, and wanted > > to add 900000000/100 to 12345678/10000, one would first have to divide > > the latter quantity by 100 before one could add it to the former. > > > > And how do you divide 1234.5678 by 9.012345? Normalize both values, yielding 000001234,567800000 / 000000009,012345000 (constants decimal, not octal). Then add as many groups of 9 digits to the divisor as one will want after the decimal point (let's say one will want 12 digits, so two groups). So divide the whole number 000000009,012345000 into 000001234,567800000,000000000,000000000 which will yield 136,986300457,871952305 and less than half. Round the last part to three figures, yielding 136,986300457,872000000.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-09-01 15:00 -0400 |
| Message-ID | <nq9tsr$imi$2@jstuckle.eternal-september.org> |
| In reply to | #93059 |
On 9/1/2016 11:32 AM, supercat@casperkitty.com wrote: > On Wednesday, August 31, 2016 at 9:42:47 PM UTC-5, Jerry Stuckle wrote: >> On 8/31/2016 6:51 PM, supercat wrote: >>> On Wednesday, August 31, 2016 at 5:36:21 PM UTC-5, anti...@math.uni.wroc.pl wrote: >>>> Maple used to do this (my impression is that they switched to binary >>>> in newer versions, but I am not sure). The experience is that it >>>> is much slower than binary. In most applications easy convertion >>>> to decimal does not compensate other drawbacks. >>> >>> For whole numbers, I would think straight binary would generally be the way >>> to go. For decimal fractions, however, using a combination of a binary >>> significand but base-ten exponent would add considerably to the cost of >>> addition and subtraction (if e.g. one had a 30-bit significand, and wanted >>> to add 900000000/100 to 12345678/10000, one would first have to divide >>> the latter quantity by 100 before one could add it to the former. >>> >> >> And how do you divide 1234.5678 by 9.012345? > > Normalize both values, yielding 000001234,567800000 / 000000009,012345000 > (constants decimal, not octal). Then add as many groups of 9 digits to the > divisor as one will want after the decimal point (let's say one will want > 12 digits, so two groups). So divide the whole number 000000009,012345000 > into 000001234,567800000,000000000,000000000 which will yield > 136,986300457,871952305 and less than half. Round the last part to three > figures, yielding 136,986300457,872000000. > > > Let's see you write the actual code which divides two numbers using the method you are proposing. It's not as trivial as you claim it is. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-09-01 13:45 -0700 |
| Message-ID | <deaa84ef-6789-4c79-8f8b-cd7398bc8fc1@googlegroups.com> |
| In reply to | #93071 |
On Thursday, September 1, 2016 at 2:00:52 PM UTC-5, Jerry Stuckle wrote: > Let's see you write the actual code which divides two numbers using the > method you are proposing. It's not as trivial as you claim it is. Long division is a pain no matter what format the numbers are in. Using base 1,000,000,000 may not be as nice as optimal approaches using base 2, but is would probably be more than 10x as fast as using packed binary.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-09-01 20:50 -0400 |
| Message-ID | <nqaid9$kb5$1@jstuckle.eternal-september.org> |
| In reply to | #93078 |
On 9/1/2016 4:45 PM, supercat@casperkitty.com wrote: > On Thursday, September 1, 2016 at 2:00:52 PM UTC-5, Jerry Stuckle wrote: >> Let's see you write the actual code which divides two numbers using the >> method you are proposing. It's not as trivial as you claim it is. > > Long division is a pain no matter what format the numbers are in. Using > base 1,000,000,000 may not be as nice as optimal approaches using base 2, > but is would probably be more than 10x as fast as using packed binary. > No, it's actually quite simple with bcd arithmetic. Especially with chips like the Intel series which have native support for it - although there is some work to get longer values. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-09-02 08:11 -0700 |
| Message-ID | <83ff68b7-ebbf-4ed2-bff4-e4351275513b@googlegroups.com> |
| In reply to | #93088 |
On Thursday, September 1, 2016 at 7:51:00 PM UTC-5, Jerry Stuckle wrote: > No, it's actually quite simple with bcd arithmetic. Especially with > chips like the Intel series which have native support for it - although > there is some work to get longer values. Multiplying two ten-digit numbers which are stored on base 1,000,000,000 will require computing four partial products. Doing it in BCD would require either computing 100 partial products or computing 40 ten-digit sums; if a processor had instructions to compute BCD sums eight digits (32 bits) at a time, the latter approach might be almost workable, but I don't think I've seen a processor which could handle BCD math more than two digits at a time.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-09-02 12:25 -0400 |
| Message-ID | <nqc95p$jqj$1@jstuckle.eternal-september.org> |
| In reply to | #93111 |
On 9/2/2016 11:11 AM, supercat@casperkitty.com wrote: > On Thursday, September 1, 2016 at 7:51:00 PM UTC-5, Jerry Stuckle wrote: >> No, it's actually quite simple with bcd arithmetic. Especially with >> chips like the Intel series which have native support for it - although >> there is some work to get longer values. > > Multiplying two ten-digit numbers which are stored on base 1,000,000,000 > will require computing four partial products. Doing it in BCD would require > either computing 100 partial products or computing 40 ten-digit sums; if a > processor had instructions to compute BCD sums eight digits (32 bits) at a > time, the latter approach might be almost workable, but I don't think I've > seen a processor which could handle BCD math more than two digits at a time. > You obviously do not understand Intel chip assembler languages. And IBM Mainframes handle 31 digits at a time - and have for over 40 years. You still haven't shown the code to divide two numbers using your method. -- ================== 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-09-02 20:42 +0200 |
| Message-ID | <nqch61$ioc$1@dont-email.me> |
| In reply to | #93121 |
On 02/09/16 18:25, Jerry Stuckle wrote: > On 9/2/2016 11:11 AM, supercat@casperkitty.com wrote: >> On Thursday, September 1, 2016 at 7:51:00 PM UTC-5, Jerry Stuckle wrote: >>> No, it's actually quite simple with bcd arithmetic. Especially with >>> chips like the Intel series which have native support for it - although >>> there is some work to get longer values. >> >> Multiplying two ten-digit numbers which are stored on base 1,000,000,000 >> will require computing four partial products. Doing it in BCD would require >> either computing 100 partial products or computing 40 ten-digit sums; if a >> processor had instructions to compute BCD sums eight digits (32 bits) at a >> time, the latter approach might be almost workable, but I don't think I've >> seen a processor which could handle BCD math more than two digits at a time. >> > > You obviously do not understand Intel chip assembler languages. Have you a reference for the Intel assembly instructions that work with more than two BCD digits (packed or unpacked) at a time? Instructions that deal with strings of BCD data are common in mainframe processors, but not in microprocessors. > > And IBM Mainframes handle 31 digits at a time - and have for over 40 years. > > You still haven't shown the code to divide two numbers using your method. >
[toc] | [prev] | [next] | [standalone]
Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web