Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #108589 > unrolled thread
| Started by | joel.rees@gmail.com |
|---|---|
| First post | 2017-04-27 03:13 -0700 |
| Last post | 2017-04-30 22:05 -0700 |
| Articles | 20 on this page of 127 — 21 participants |
Back to article view | Back to comp.lang.c
Is this code considered to transgress the signed overflow purism? joel.rees@gmail.com - 2017-04-27 03:13 -0700
Re: Is this code considered to transgress the signed overflow purism? joel.rees@gmail.com - 2017-04-27 03:41 -0700
Re: Is this code considered to transgress the signed overflow purism? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-27 11:59 +0100
Re: Is this code considered to transgress the signed overflow purism? joel.rees@gmail.com - 2017-04-27 14:35 -0700
Re: Is this code considered to transgress the signed overflow purism? Keith Thompson <kst-u@mib.org> - 2017-04-27 15:13 -0700
Re: Is this code considered to transgress the signed overflow purism? David Brown <david.brown@hesbynett.no> - 2017-04-28 00:58 +0200
Re: Is this code considered to transgress the signed overflow purism? Keith Thompson <kst-u@mib.org> - 2017-04-27 16:44 -0700
Re: Is this code considered to transgress the signed overflow purism? joel.rees@gmail.com - 2017-04-27 20:04 -0700
Re: Is this code considered to transgress the signed overflow purism? David Brown <david.brown@hesbynett.no> - 2017-04-28 08:53 +0200
Re: Is this code considered to transgress the signed overflow purism? supercat@casperkitty.com - 2017-04-28 08:23 -0700
Re: Is this code considered to transgress the signed overflow purism? Manfred <noname@invalid.add> - 2017-04-28 18:05 +0200
Re: Is this code considered to transgress the signed overflow purism? Keith Thompson <kst-u@mib.org> - 2017-04-28 09:22 -0700
Re: Is this code considered to transgress the signed overflow purism? Keith Thompson <kst-u@mib.org> - 2017-04-28 12:24 -0700
Re: Is this code considered to transgress the signed overflow purism? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-29 00:03 +0100
Re: Is this code considered to transgress the signed overflow purism? supercat@casperkitty.com - 2017-04-28 16:37 -0700
Re: Is this code considered to transgress the signed overflow purism? David Kleinecke <dkleinecke@gmail.com> - 2017-04-28 17:09 -0700
Re: Is this code considered to transgress the signed overflow purism? supercat@casperkitty.com - 2017-04-28 17:34 -0700
Re: Is this code considered to transgress the signed overflow purism? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-29 01:43 +0100
Re: Is this code considered to transgress the signed overflow purism? David Kleinecke <dkleinecke@gmail.com> - 2017-04-28 21:21 -0700
Re: Is this code considered to transgress the signed overflow purism? joel.rees@gmail.com - 2017-04-29 02:04 -0700
Re: Is this code considered to transgress the signed overflow purism? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-29 11:46 +0100
Re: Is this code considered to transgress the signed overflow purism? Robert Wessel <robertwessel2@yahoo.com> - 2017-04-30 12:05 -0500
Re: Is this code considered to transgress the signed overflow purism? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-29 11:33 +0100
Re: Is this code considered to transgress the signed overflow purism? David Kleinecke <dkleinecke@gmail.com> - 2017-04-29 08:26 -0700
Re: Is this code considered to transgress the signed overflow purism? David Brown <david.brown@hesbynett.no> - 2017-04-29 17:58 +0200
Re: Is this code considered to transgress the signed overflow purism? David Kleinecke <dkleinecke@gmail.com> - 2017-04-29 09:13 -0700
Re: Is this code considered to transgress the signed overflow purism? David Brown <david.brown@hesbynett.no> - 2017-04-30 12:55 +0200
Re: Is this code considered to transgress the signed overflow purism? David Kleinecke <dkleinecke@gmail.com> - 2017-04-30 09:17 -0700
Re: Is this code considered to transgress the signed overflow purism? David Brown <david.brown@hesbynett.no> - 2017-04-30 20:35 +0200
Re: Is this code considered to transgress the signed overflow purism? David Kleinecke <dkleinecke@gmail.com> - 2017-04-30 15:39 -0700
Re: Is this code considered to transgress the signed overflow purism? David Brown <david.brown@hesbynett.no> - 2017-05-01 16:21 +0200
Re: Is this code considered to transgress the signed overflow purism? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-02 06:35 -0700
Re: Is this code considered to transgress the signed overflow purism? David Brown <david.brown@hesbynett.no> - 2017-05-02 16:29 +0200
Re: Is this code considered to transgress the signed overflow purism? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-29 20:58 +0100
Re: Is this code considered to transgress the signed overflow purism? David Brown <david.brown@hesbynett.no> - 2017-04-28 18:43 +0200
Re: Is this code considered to transgress the signed overflow purism? bartc <bc@freeuk.com> - 2017-04-28 14:09 +0100
Re: Is this code considered to transgress the signed overflow purism? scott@slp53.sl.home (Scott Lurndal) - 2017-04-28 14:23 +0000
Re: Is this code considered to transgress the signed overflow purism? bartc <bc@freeuk.com> - 2017-04-28 16:17 +0100
Re: Is this code considered to transgress the signed overflow purism? scott@slp53.sl.home (Scott Lurndal) - 2017-04-28 15:55 +0000
Re: Is this code considered to transgress the signed overflow purism? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-04-28 19:11 -0700
Re: Is this code considered to transgress the signed overflow purism? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-29 11:23 +0100
Re: Is this code considered to transgress the signed overflow purism? bartc <bc@freeuk.com> - 2017-04-29 11:31 +0100
Re: Is this code considered to transgress the signed overflow purism? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-29 12:01 +0100
Re: Is this code considered to transgress the signed overflow purism? bartc <bc@freeuk.com> - 2017-04-29 12:47 +0100
Re: Is this code considered to transgress the signed overflow purism? David Brown <david.brown@hesbynett.no> - 2017-04-29 15:20 +0200
Re: Is this code considered to transgress the signed overflow purism? bartc <bc@freeuk.com> - 2017-04-29 15:22 +0100
Re: Is this code considered to transgress the signed overflow purism? David Brown <david.brown@hesbynett.no> - 2017-04-29 16:52 +0200
Re: Is this code considered to transgress the signed overflow purism? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-29 15:18 +0100
Re: Is this code considered to transgress the signed overflow purism? Jean-Marc Bourguet <jm@bourguet.org> - 2017-04-29 14:25 +0200
Re: Is this code considered to transgress the signed overflow purism? Jerry Stuckle <jstucklex@attglobal.net> - 2017-04-29 08:05 -0400
Re: Is this code considered to transgress the signed overflow purism? Gareth Owen <gwowen@gmail.com> - 2017-04-29 13:34 +0100
Re: Is this code considered to transgress the signed overflow purism? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-04-29 05:55 -0700
Re: Is this code considered to transgress the signed overflow purism? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-04-29 15:11 +0200
Re: Is this code considered to transgress the signed overflow purism? David Brown <david.brown@hesbynett.no> - 2017-04-29 15:24 +0200
Re: Is this code considered to transgress the signed overflow purism? Gareth Owen <gwowen@gmail.com> - 2017-04-29 14:57 +0100
Re: Is this code considered to transgress the signed overflow purism? asetofsymbols@gmail.com - 2017-05-03 12:17 -0700
Re: Is this code considered to transgress the signed overflow purism? supercat@casperkitty.com - 2017-05-03 16:36 -0700
Re: Is this code considered to transgress the signed overflow purism? asetofsymbols@gmail.com - 2017-05-03 11:26 -0700
Re: Is this code considered to transgress the signed overflow purism? David Brown <david.brown@hesbynett.no> - 2017-05-03 21:40 +0200
Re: Is this code considered to transgress the signed overflow purism? asetofsymbols@gmail.com - 2017-05-03 23:46 -0700
Re: Is this code considered to transgress the signed overflow purism? Keith Thompson <kst-u@mib.org> - 2017-04-28 08:55 -0700
Re: Is this code considered to transgress the signed overflow purism? joel.rees@gmail.com - 2017-04-27 20:20 -0700
Re: Is this code considered to transgress the signed overflow purism? joel.rees@gmail.com - 2017-04-27 20:26 -0700
Re: Is this code considered to transgress the signed overflow purism? David Brown <david.brown@hesbynett.no> - 2017-04-28 10:19 +0200
Re: Is this code considered to transgress the signed overflow purism? James Kuyper <jameskuyper@verizon.net> - 2017-04-28 09:57 -0400
Re: Is this code considered to transgress the signed overflow purism? David Brown <david.brown@hesbynett.no> - 2017-04-28 17:06 +0200
Re: Is this code considered to transgress the signed overflow purism? supercat@casperkitty.com - 2017-04-28 08:38 -0700
Re: Is this code considered to transgress the signed overflow purism? David Brown <david.brown@hesbynett.no> - 2017-04-28 18:51 +0200
Re: Is this code considered to transgress the signed overflow purism? supercat@casperkitty.com - 2017-04-29 12:43 -0700
Re: Is this code considered to transgress the signed overflow purism? Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-30 14:02 -0700
Re: Is this code considered to transgress the signed overflow purism? Keith Thompson <kst-u@mib.org> - 2017-04-30 14:25 -0700
Re: Is this code considered to transgress the signed overflow purism? Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-30 15:01 -0700
Re: Is this code considered to transgress the signed overflow purism? James Kuyper <jameskuyper@verizon.net> - 2017-04-28 09:48 -0400
Re: Is this code considered to transgress the signed overflow purism? supercat@casperkitty.com - 2017-04-28 08:07 -0700
Re: Is this code considered to transgress the signed overflow purism? David Brown <david.brown@hesbynett.no> - 2017-04-28 18:56 +0200
Re: Is this code considered to transgress the signed overflow purism? supercat@casperkitty.com - 2017-04-28 11:30 -0700
Re: Is this code considered to transgress the signed overflow purism? Keith Thompson <kst-u@mib.org> - 2017-04-28 08:35 -0700
Re: Is this code considered to transgress the signed overflow purism? David Brown <david.brown@hesbynett.no> - 2017-04-28 00:54 +0200
Re: Is this code considered to transgress the signed overflow purism? joel.rees@gmail.com - 2017-04-27 21:05 -0700
Re: Is this code considered to transgress the signed overflow purism? David Brown <david.brown@hesbynett.no> - 2017-04-28 10:58 +0200
Re: Is this code considered to transgress the signed overflow purism? bartc <bc@freeuk.com> - 2017-04-28 10:50 +0100
Re: Is this code considered to transgress the signed overflow purism? James Kuyper <jameskuyper@verizon.net> - 2017-04-28 10:01 -0400
Re: Is this code considered to transgress the signed overflow purism? Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-02 05:06 -0700
Re: Is this code considered to transgress the signed overflow purism? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-28 23:57 +0100
Re: Is this code considered to transgress the signed overflow purism? Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-30 12:28 -0700
Re: Is this code considered to transgress the signed overflow purism? Keith Thompson <kst-u@mib.org> - 2017-04-30 12:41 -0700
Re: Is this code considered to transgress the signed overflow purism? bartc <bc@freeuk.com> - 2017-04-30 21:46 +0100
Re: Is this code considered to transgress the signed overflow purism? Thiago Adams <thiago.adams@gmail.com> - 2017-05-01 05:41 -0700
Re: Is this code considered to transgress the signed overflow purism? bartc <bc@freeuk.com> - 2017-05-01 13:57 +0100
Re: Is this code considered to transgress the signed overflow purism? Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-02 05:30 -0700
Re: Is this code considered to transgress the signed overflow purism? bartc <bc@freeuk.com> - 2017-05-02 16:13 +0100
Re: Is this code considered to transgress the signed overflow purism? Keith Thompson <kst-u@mib.org> - 2017-05-02 09:12 -0700
Re: Is this code considered to transgress the signed overflow purism? bartc <bc@freeuk.com> - 2017-05-02 18:15 +0100
Re: Is this code considered to transgress the signed overflow purism? Keith Thompson <kst-u@mib.org> - 2017-05-02 11:26 -0700
Re: Is this code considered to transgress the signed overflow purism? bartc <bc@freeuk.com> - 2017-05-02 21:39 +0100
Re: Is this code considered to transgress the signed overflow purism? supercat@casperkitty.com - 2017-05-02 13:53 -0700
Re: Is this code considered to transgress the signed overflow purism? Keith Thompson <kst-u@mib.org> - 2017-05-02 14:10 -0700
Re: Is this code considered to transgress the signed overflow purism? bartc <bc@freeuk.com> - 2017-05-02 22:36 +0100
Re: Is this code considered to transgress the signed overflow purism? Keith Thompson <kst-u@mib.org> - 2017-05-02 15:27 -0700
Re: Is this code considered to transgress the signed overflow purism? Robert Wessel <robertwessel2@yahoo.com> - 2017-05-03 00:45 -0500
Re: Is this code considered to transgress the signed overflow purism? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-03 11:57 +0100
Re: Is this code considered to transgress the signed overflow purism? Robert Wessel <robertwessel2@yahoo.com> - 2017-05-03 13:34 -0500
Re: Is this code considered to transgress the signed overflow purism? Keith Thompson <kst-u@mib.org> - 2017-05-03 12:05 -0700
Re: Is this code considered to transgress the signed overflow purism? Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-05 02:58 -0700
Re: Is this code considered to transgress the signed overflow purism? Thiago Adams <thiago.adams@gmail.com> - 2017-05-03 05:26 -0700
Re: Is this code considered to transgress the signed overflow purism? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-03 05:54 -0700
Re: Is this code considered to transgress the signed overflow purism? Thiago Adams <thiago.adams@gmail.com> - 2017-05-03 06:49 -0700
Re: Is this code considered to transgress the signed overflow purism? Thiago Adams <thiago.adams@gmail.com> - 2017-05-03 06:51 -0700
Re: Is this code considered to transgress the signed overflow purism? jadill33@gmail.com - 2017-05-03 09:03 -0700
Re: Is this code considered to transgress the signed overflow purism? supercat@casperkitty.com - 2017-05-02 14:47 -0700
Re: Is this code considered to transgress the signed overflow purism? joel.rees@gmail.com - 2017-05-03 17:45 -0700
Re: Is this code considered to transgress the signed overflow purism? Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-30 14:42 -0700
Re: Is this code considered to transgress the signed overflow purism? joel.rees@gmail.com - 2017-04-30 23:57 -0700
Re: Is this code considered to transgress the signed overflow purism? Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-02 04:32 -0700
Re: Is this code considered to transgress the signed overflow purism? joel.rees@gmail.com - 2017-05-03 18:20 -0700
Re: Is this code considered to transgress the signed overflow purism? luser droog <luser.droog@gmail.com> - 2017-05-08 23:12 -0700
Re: Is this code considered to transgress the signed overflow purism? joel.rees@gmail.com - 2017-05-09 19:54 -0700
Re: Is this code considered to transgress the signed overflow purism? luser droog <luser.droog@gmail.com> - 2017-05-09 21:21 -0700
Re: Is this code considered to transgress the signed overflow purism? James Kuyper <jameskuyper@verizon.net> - 2017-04-27 10:46 -0400
Re: Is this code considered to transgress the signed overflow purism? supercat@casperkitty.com - 2017-04-27 08:37 -0700
Re: Is this code considered to transgress the signed overflow purism? Keith Thompson <kst-u@mib.org> - 2017-04-27 09:38 -0700
Re: Is this code considered to transgress the signed overflow purism? supercat@casperkitty.com - 2017-04-27 10:17 -0700
Re: Is this code considered to transgress the signed overflow purism? Keith Thompson <kst-u@mib.org> - 2017-04-27 12:10 -0700
Re: Is this code considered to transgress the signed overflow purism? Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-30 13:50 -0700
Re: Is this code considered to transgress the signed overflow purism? Keith Thompson <kst-u@mib.org> - 2017-04-30 14:11 -0700
Re: Is this code considered to transgress the signed overflow purism? Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-30 14:44 -0700
Re: Is this code considered to transgress the signed overflow purism? joel.rees@gmail.com - 2017-04-30 22:05 -0700
Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-04-29 11:46 +0100 |
| Message-ID | <87fugr4hla.fsf@bsb.me.uk> |
| In reply to | #108713 |
joel.rees@gmail.com writes: <snip> > Unless something has changed since the last time I read the > standard (more than two back, apparently), ternary and base > four were intended to be covered. A C implementation must behave as if its integer types are binary. Provided that's done correctly, almost any base could be used by the hardware so there's no need to single out ternary and base 4. In fact, I don't recall any version of the C standard giving special permission for bases 3 and 4. What parts of the language are you referring to? <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-04-30 12:05 -0500 |
| Message-ID | <536cgc93vpk1v20mngitr9spgvt70g3qe7@4ax.com> |
| In reply to | #108713 |
On Sat, 29 Apr 2017 02:04:19 -0700 (PDT), joel.rees@gmail.com wrote: >On Saturday, April 29, 2017 at 1:21:47 PM UTC+9, David Kleinecke wrote: >> On Friday, April 28, 2017 at 5:43:18 PM UTC-7, Ben Bacarisse wrote: >> > David Kleinecke <> writes: >> > <snip> >> > > One could define x<<n as x*(2^n) and x>>n as x/(2^n) and any >> > > problems go away. >> > >> > For the cases that are well-defined, that is exactly how they are >> > defined. But that would *cause* problem were that extended to the other >> > cases. The committee wanted to avoid imposing a burden on >> > implementations for hardware that did not match C's definition of a >> > shift. >> > >> > > But that must have been too easy when the standard was developed. >> > >> > That's implausible. The core meaning is defined exactly as you say, but >> > the extra bits are not there because the committee never thought to >> > remove them. >> > >> > > PS: And even x<<(-n) as x/(2^n) and so on. >> > >> > It is not in the spirit of C to impose that sort of cost on a primitive >> > operation like a bit shift. >> >> I admit I was thinking about computers which work on atoms >> of information other than 2 -like quantum computers seem to >> be headed for. If information is not expressed in bits it is >> hard to say what all those edge cases "should" do. >> >> Or I suppose you could claim that C was never intended for >> such hardware. If so - why not? > >Unless something has changed since the last time I read the >standard (more than two back, apparently), ternary and base >four were intended to be covered. > >It seems like there was at least a draft that even took up C >for a native decimal CPU. > >That's probably where the conflating shift and multiplying >by a power of two came from. As of C99, the implementation must act as if integer types were binary, with signed integers being ones' complement, two's complement or sign-magnitude. Padding bits and such are still allowed.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-04-29 11:33 +0100 |
| Message-ID | <87mvaz4i6s.fsf@bsb.me.uk> |
| In reply to | #108711 |
David Kleinecke <dkleinecke@gmail.com> writes: > On Friday, April 28, 2017 at 5:43:18 PM UTC-7, Ben Bacarisse wrote: >> David Kleinecke <dkleinecke@gmail.com> writes: >> <snip> >> > One could define x<<n as x*(2^n) and x>>n as x/(2^n) and any >> > problems go away. >> >> For the cases that are well-defined, that is exactly how they are >> defined. But that would *cause* problem were that extended to the other >> cases. The committee wanted to avoid imposing a burden on >> implementations for hardware that did not match C's definition of a >> shift. >> >> > But that must have been too easy when the standard was developed. >> >> That's implausible. The core meaning is defined exactly as you say, but >> the extra bits are not there because the committee never thought to >> remove them. >> >> > PS: And even x<<(-n) as x/(2^n) and so on. >> >> It is not in the spirit of C to impose that sort of cost on a primitive >> operation like a bit shift. > > I admit I was thinking about computers which work on atoms > of information other than 2 -like quantum computers seem to > be headed for. If information is not expressed in bits it is > hard to say what all those edge cases "should" do. Your 2017 criticism of the C standard from the late 1980s was based on what *might* be the future of quantum computers? > Or I suppose you could claim that C was never intended for > such hardware. If so - why not? Obviously it was never intended for such machines and I can't believe you really need me to say why! -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2017-04-29 08:26 -0700 |
| Message-ID | <8421ef4c-616f-4854-b084-6c355dfeaa96@googlegroups.com> |
| In reply to | #108718 |
On Saturday, April 29, 2017 at 3:33:22 AM UTC-7, Ben Bacarisse wrote: > David Kleinecke <dkleinecke@gmail.com> writes: > > > On Friday, April 28, 2017 at 5:43:18 PM UTC-7, Ben Bacarisse wrote: > >> David Kleinecke <dkleinecke@gmail.com> writes: > >> <snip> > >> > One could define x<<n as x*(2^n) and x>>n as x/(2^n) and any > >> > problems go away. > >> > >> For the cases that are well-defined, that is exactly how they are > >> defined. But that would *cause* problem were that extended to the other > >> cases. The committee wanted to avoid imposing a burden on > >> implementations for hardware that did not match C's definition of a > >> shift. > >> > >> > But that must have been too easy when the standard was developed. > >> > >> That's implausible. The core meaning is defined exactly as you say, but > >> the extra bits are not there because the committee never thought to > >> remove them. > >> > >> > PS: And even x<<(-n) as x/(2^n) and so on. > >> > >> It is not in the spirit of C to impose that sort of cost on a primitive > >> operation like a bit shift. > > > > I admit I was thinking about computers which work on atoms > > of information other than 2 -like quantum computers seem to > > be headed for. If information is not expressed in bits it is > > hard to say what all those edge cases "should" do. > > Your 2017 criticism of the C standard from the late 1980s was based on > what *might* be the future of quantum computers? > > > Or I suppose you could claim that C was never intended for > > such hardware. If so - why not? > > Obviously it was never intended for such machines and I can't believe > you really need me to say why! It wasn't 2017 - that's this year. I am interested in the long range future of computing. I see no reason why C (as I understand it - not necessarily the standard) couldn't be used to program quantum computers. Regardless of what it was intended for back then.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-04-29 17:58 +0200 |
| Message-ID | <oe2d0d$aa4$1@dont-email.me> |
| In reply to | #108739 |
On 29/04/17 17:26, David Kleinecke wrote: > > It wasn't 2017 - that's this year. I am interested in the long > range future of computing. I see no reason why C (as I understand > it - not necessarily the standard) couldn't be used to program > quantum computers. Regardless of what it was intended for back > then. > Do you know anything about quantum computers, how they work, what they can be used for, and how they are different from "classical" computers? I can't say I am an expert on quantum computing, but all that I have read about them suggests that C would be a totally inappropriate way to program them. If you have any reason for supposing that C /would/ be appropriate from programming them, I'd like to hear about it. I am also highly sceptical that true quantum computers will ever make economic sense. That does not mean that some people will not make a great deal of money from making them and selling them - merely that I do not foresee a time when it is cheaper to do a given calculation on quantum computers rather than classical ones. Still, it's good that time, effort and money is used on these - it's all good physics research. (The current commercial so-called "quantum computers" from D-Wave are not true quantum computers as such, and while D-Wave makes good money from selling them, they don't offer any speed advantages to customers.)
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2017-04-29 09:13 -0700 |
| Message-ID | <cc93f048-5d9a-4159-a926-722032c90241@googlegroups.com> |
| In reply to | #108740 |
On Saturday, April 29, 2017 at 8:58:12 AM UTC-7, David Brown wrote: > On 29/04/17 17:26, David Kleinecke wrote: > > > > It wasn't 2017 - that's this year. I am interested in the long > > range future of computing. I see no reason why C (as I understand > > it - not necessarily the standard) couldn't be used to program > > quantum computers. Regardless of what it was intended for back > > then. > > > > Do you know anything about quantum computers, how they work, what they > can be used for, and how they are different from "classical" computers? > I can't say I am an expert on quantum computing, but all that I have > read about them suggests that C would be a totally inappropriate way to > program them. > > If you have any reason for supposing that C /would/ be appropriate from > programming them, I'd like to hear about it. > > > I am also highly sceptical that true quantum computers will ever make > economic sense. That does not mean that some people will not make a > great deal of money from making them and selling them - merely that I do > not foresee a time when it is cheaper to do a given calculation on > quantum computers rather than classical ones. > > Still, it's good that time, effort and money is used on these - it's all > good physics research. > > (The current commercial so-called "quantum computers" from D-Wave are > not true quantum computers as such, and while D-Wave makes good money > from selling them, they don't offer any speed advantages to customers.) I haven't seen any reason to doubt that C would be appropriate - in the sense I use C (see my other post). Could you describe a scenario where it fails?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-04-30 12:55 +0200 |
| Message-ID | <oe4flf$6jn$1@dont-email.me> |
| In reply to | #108742 |
On 29/04/17 18:13, David Kleinecke wrote: > On Saturday, April 29, 2017 at 8:58:12 AM UTC-7, David Brown wrote: >> On 29/04/17 17:26, David Kleinecke wrote: >>> >>> It wasn't 2017 - that's this year. I am interested in the long >>> range future of computing. I see no reason why C (as I understand >>> it - not necessarily the standard) couldn't be used to program >>> quantum computers. Regardless of what it was intended for back >>> then. >>> >> >> Do you know anything about quantum computers, how they work, what they >> can be used for, and how they are different from "classical" computers? >> I can't say I am an expert on quantum computing, but all that I have >> read about them suggests that C would be a totally inappropriate way to >> program them. >> >> If you have any reason for supposing that C /would/ be appropriate from >> programming them, I'd like to hear about it. >> >> >> I am also highly sceptical that true quantum computers will ever make >> economic sense. That does not mean that some people will not make a >> great deal of money from making them and selling them - merely that I do >> not foresee a time when it is cheaper to do a given calculation on >> quantum computers rather than classical ones. >> >> Still, it's good that time, effort and money is used on these - it's all >> good physics research. >> >> (The current commercial so-called "quantum computers" from D-Wave are >> not true quantum computers as such, and while D-Wave makes good money >> from selling them, they don't offer any speed advantages to customers.) > > I haven't seen any reason to doubt that C would be appropriate - > in the sense I use C (see my other post). Could you describe a > scenario where it fails? > Quantum computing uses a completely different computation model than classical computing. There are many different computation models - neural networks, quantum computing, genetic computing, cellular automation, etc. They are all able to compute the same functions, but there can be wide variations in their efficiency for different types of algorithm (but as far as I know, the P/NP split is the same for all). Quantum computers are not, at the moment, "programmed" as such - they are /built/ to execute a particular algorithm. They are more akin to the analogue computers of the 1950's - except they are of far less use. Based on your post, you seem to be under the impression that the difference between a quantum computer and a classical one is that the quantum computer has "qubits" that hold several normal bits of information in one lump - and that otherwise, it is much like a normal computer. You think that a quantum computer might hold 4 bits of binary information per qubit - that it's "bits" hold values between 0 and 15 rather than between 0 and 1. And that other than that, you can perform arithmetic, logic, data movement, program jumps, and everything else on them, just that the smallest lump of data you handle is 4 bits at a time? This is totally and completely wrong. In a quantum computer, a qubit holds a superposition of an unlimited number of states - it is only the resolution and accuracy of the system feeding data into and getting data out of the qubit that limits the useful number of states, combined with the stability of the qubit over time. You can't load and store qubit values, but you can pass them through fixed operations. The result is the "sum" of all possible combinations of all states of the qubits going into the operation. When you take two qubits that are "holding" 4 bits of state, and you add them, the resulting qubit contains the 256 different results of adding all combinations of two 4 bit values. /That/ is the key to being able to scale difficult algorithms like prime factorisation. But if your IO hardware can only distinguish 16 different discrete logic states, then of those 256 theoretical output states you can only read out 16 of them - and figuring out /which/ 16 you get is extremely difficult. And /that/ is key to why quantum computers are of very little practical use, and will continue to be so for the foreseeable future (IMHO).
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2017-04-30 09:17 -0700 |
| Message-ID | <addba823-8489-453f-92a7-093e558d88b4@googlegroups.com> |
| In reply to | #108765 |
On Sunday, April 30, 2017 at 3:55:51 AM UTC-7, David Brown wrote: > On 29/04/17 18:13, David Kleinecke wrote: > > On Saturday, April 29, 2017 at 8:58:12 AM UTC-7, David Brown wrote: > >> On 29/04/17 17:26, David Kleinecke wrote: > >>> > >>> It wasn't 2017 - that's this year. I am interested in the long > >>> range future of computing. I see no reason why C (as I understand > >>> it - not necessarily the standard) couldn't be used to program > >>> quantum computers. Regardless of what it was intended for back > >>> then. > >>> > >> > >> Do you know anything about quantum computers, how they work, what they > >> can be used for, and how they are different from "classical" computers? > >> I can't say I am an expert on quantum computing, but all that I have > >> read about them suggests that C would be a totally inappropriate way to > >> program them. > >> > >> If you have any reason for supposing that C /would/ be appropriate from > >> programming them, I'd like to hear about it. > >> > >> > >> I am also highly sceptical that true quantum computers will ever make > >> economic sense. That does not mean that some people will not make a > >> great deal of money from making them and selling them - merely that I do > >> not foresee a time when it is cheaper to do a given calculation on > >> quantum computers rather than classical ones. > >> > >> Still, it's good that time, effort and money is used on these - it's all > >> good physics research. > >> > >> (The current commercial so-called "quantum computers" from D-Wave are > >> not true quantum computers as such, and while D-Wave makes good money > >> from selling them, they don't offer any speed advantages to customers.) > > > > I haven't seen any reason to doubt that C would be appropriate - > > in the sense I use C (see my other post). Could you describe a > > scenario where it fails? > > > > Quantum computing uses a completely different computation model than > classical computing. There are many different computation models - > neural networks, quantum computing, genetic computing, cellular > automation, etc. They are all able to compute the same functions, but > there can be wide variations in their efficiency for different types of > algorithm (but as far as I know, the P/NP split is the same for all). > > Quantum computers are not, at the moment, "programmed" as such - they > are /built/ to execute a particular algorithm. They are more akin to > the analogue computers of the 1950's - except they are of far less use. > > Based on your post, you seem to be under the impression that the > difference between a quantum computer and a classical one is that the > quantum computer has "qubits" that hold several normal bits of > information in one lump - and that otherwise, it is much like a normal > computer. You think that a quantum computer might hold 4 bits of binary > information per qubit - that it's "bits" hold values between 0 and 15 > rather than between 0 and 1. And that other than that, you can perform > arithmetic, logic, data movement, program jumps, and everything else on > them, just that the smallest lump of data you handle is 4 bits at a time? > > This is totally and completely wrong. In a quantum computer, a qubit > holds a superposition of an unlimited number of states - it is only the > resolution and accuracy of the system feeding data into and getting data > out of the qubit that limits the useful number of states, combined with > the stability of the qubit over time. You can't load and store qubit > values, but you can pass them through fixed operations. The result is > the "sum" of all possible combinations of all states of the qubits going > into the operation. When you take two qubits that are "holding" 4 bits > of state, and you add them, the resulting qubit contains the 256 > different results of adding all combinations of two 4 bit values. > /That/ is the key to being able to scale difficult algorithms like prime > factorisation. But if your IO hardware can only distinguish 16 > different discrete logic states, then of those 256 theoretical output > states you can only read out 16 of them - and figuring out /which/ 16 > you get is extremely difficult. And /that/ is key to why quantum > computers are of very little practical use, and will continue to be so > for the foreseeable future (IMHO). I don't consider current quantum computers serious implementations of quantum possibilities. I remain looking into the rather distant future and trying to guess where quantum computing will end up. As I see it there is still a non-trivial probability that quantum computing will never be useful but enough likelihood that it will that we should plan for it.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-04-30 20:35 +0200 |
| Message-ID | <oe5aji$tln$1@dont-email.me> |
| In reply to | #108775 |
On 30/04/17 18:17, David Kleinecke wrote: > On Sunday, April 30, 2017 at 3:55:51 AM UTC-7, David Brown wrote: >> On 29/04/17 18:13, David Kleinecke wrote: >>> On Saturday, April 29, 2017 at 8:58:12 AM UTC-7, David Brown wrote: >>>> On 29/04/17 17:26, David Kleinecke wrote: >>>>> >>>>> It wasn't 2017 - that's this year. I am interested in the long >>>>> range future of computing. I see no reason why C (as I understand >>>>> it - not necessarily the standard) couldn't be used to program >>>>> quantum computers. Regardless of what it was intended for back >>>>> then. >>>>> >>>> >>>> Do you know anything about quantum computers, how they work, what they >>>> can be used for, and how they are different from "classical" computers? >>>> I can't say I am an expert on quantum computing, but all that I have >>>> read about them suggests that C would be a totally inappropriate way to >>>> program them. >>>> >>>> If you have any reason for supposing that C /would/ be appropriate from >>>> programming them, I'd like to hear about it. >>>> >>>> >>>> I am also highly sceptical that true quantum computers will ever make >>>> economic sense. That does not mean that some people will not make a >>>> great deal of money from making them and selling them - merely that I do >>>> not foresee a time when it is cheaper to do a given calculation on >>>> quantum computers rather than classical ones. >>>> >>>> Still, it's good that time, effort and money is used on these - it's all >>>> good physics research. >>>> >>>> (The current commercial so-called "quantum computers" from D-Wave are >>>> not true quantum computers as such, and while D-Wave makes good money >>>> from selling them, they don't offer any speed advantages to customers.) >>> >>> I haven't seen any reason to doubt that C would be appropriate - >>> in the sense I use C (see my other post). Could you describe a >>> scenario where it fails? >>> >> >> Quantum computing uses a completely different computation model than >> classical computing. There are many different computation models - >> neural networks, quantum computing, genetic computing, cellular >> automation, etc. They are all able to compute the same functions, but >> there can be wide variations in their efficiency for different types of >> algorithm (but as far as I know, the P/NP split is the same for all). >> >> Quantum computers are not, at the moment, "programmed" as such - they >> are /built/ to execute a particular algorithm. They are more akin to >> the analogue computers of the 1950's - except they are of far less use. >> >> Based on your post, you seem to be under the impression that the >> difference between a quantum computer and a classical one is that the >> quantum computer has "qubits" that hold several normal bits of >> information in one lump - and that otherwise, it is much like a normal >> computer. You think that a quantum computer might hold 4 bits of binary >> information per qubit - that it's "bits" hold values between 0 and 15 >> rather than between 0 and 1. And that other than that, you can perform >> arithmetic, logic, data movement, program jumps, and everything else on >> them, just that the smallest lump of data you handle is 4 bits at a time? >> >> This is totally and completely wrong. In a quantum computer, a qubit >> holds a superposition of an unlimited number of states - it is only the >> resolution and accuracy of the system feeding data into and getting data >> out of the qubit that limits the useful number of states, combined with >> the stability of the qubit over time. You can't load and store qubit >> values, but you can pass them through fixed operations. The result is >> the "sum" of all possible combinations of all states of the qubits going >> into the operation. When you take two qubits that are "holding" 4 bits >> of state, and you add them, the resulting qubit contains the 256 >> different results of adding all combinations of two 4 bit values. >> /That/ is the key to being able to scale difficult algorithms like prime >> factorisation. But if your IO hardware can only distinguish 16 >> different discrete logic states, then of those 256 theoretical output >> states you can only read out 16 of them - and figuring out /which/ 16 >> you get is extremely difficult. And /that/ is key to why quantum >> computers are of very little practical use, and will continue to be so >> for the foreseeable future (IMHO). > > I don't consider current quantum computers serious > implementations of quantum possibilities. I remain > looking into the rather distant future and trying to > guess where quantum computing will end up. Do you know what the current state of quantum computing is? Did I provide a fair summary of what you think it is? Did my last paragraph help you understand it? Can you give any kind of description about what you imagine quantum computing will look like in the future (near or distant)? You have said a number of times that you see no reason why C should not be a suitable language for programming quantum computers - to make that statement, you must have a solid basis for how you think they will work. > As I see > it there is still a non-trivial probability that > quantum computing will never be useful but enough > likelihood that it will that we should plan for it. > In what way should we plan for it? (If you feel you have dug yourself into a hole here, by speculating about things that are beyond your knowledge and making claims based on "gut feelings" rather than justifiable and informed opinion, then feel free to back out. I know from personal experience that it can be easier to keep going with more speculation - but it is better to stop digging before things get silly.)
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2017-04-30 15:39 -0700 |
| Message-ID | <2651cc7b-3ffa-4140-a766-1863ee157ded@googlegroups.com> |
| In reply to | #108790 |
On Sunday, April 30, 2017 at 11:35:38 AM UTC-7, David Brown wrote: > On 30/04/17 18:17, David Kleinecke wrote: > > On Sunday, April 30, 2017 at 3:55:51 AM UTC-7, David Brown wrote: > >> On 29/04/17 18:13, David Kleinecke wrote: > >>> On Saturday, April 29, 2017 at 8:58:12 AM UTC-7, David Brown wrote: > >>>> On 29/04/17 17:26, David Kleinecke wrote: > >>>>> > >>>>> It wasn't 2017 - that's this year. I am interested in the long > >>>>> range future of computing. I see no reason why C (as I understand > >>>>> it - not necessarily the standard) couldn't be used to program > >>>>> quantum computers. Regardless of what it was intended for back > >>>>> then. > >>>>> > >>>> > >>>> Do you know anything about quantum computers, how they work, what they > >>>> can be used for, and how they are different from "classical" computers? > >>>> I can't say I am an expert on quantum computing, but all that I have > >>>> read about them suggests that C would be a totally inappropriate way to > >>>> program them. > >>>> > >>>> If you have any reason for supposing that C /would/ be appropriate from > >>>> programming them, I'd like to hear about it. > >>>> > >>>> > >>>> I am also highly sceptical that true quantum computers will ever make > >>>> economic sense. That does not mean that some people will not make a > >>>> great deal of money from making them and selling them - merely that I do > >>>> not foresee a time when it is cheaper to do a given calculation on > >>>> quantum computers rather than classical ones. > >>>> > >>>> Still, it's good that time, effort and money is used on these - it's all > >>>> good physics research. > >>>> > >>>> (The current commercial so-called "quantum computers" from D-Wave are > >>>> not true quantum computers as such, and while D-Wave makes good money > >>>> from selling them, they don't offer any speed advantages to customers.) > >>> > >>> I haven't seen any reason to doubt that C would be appropriate - > >>> in the sense I use C (see my other post). Could you describe a > >>> scenario where it fails? > >>> > >> > >> Quantum computing uses a completely different computation model than > >> classical computing. There are many different computation models - > >> neural networks, quantum computing, genetic computing, cellular > >> automation, etc. They are all able to compute the same functions, but > >> there can be wide variations in their efficiency for different types of > >> algorithm (but as far as I know, the P/NP split is the same for all). > >> > >> Quantum computers are not, at the moment, "programmed" as such - they > >> are /built/ to execute a particular algorithm. They are more akin to > >> the analogue computers of the 1950's - except they are of far less use. > >> > >> Based on your post, you seem to be under the impression that the > >> difference between a quantum computer and a classical one is that the > >> quantum computer has "qubits" that hold several normal bits of > >> information in one lump - and that otherwise, it is much like a normal > >> computer. You think that a quantum computer might hold 4 bits of binary > >> information per qubit - that it's "bits" hold values between 0 and 15 > >> rather than between 0 and 1. And that other than that, you can perform > >> arithmetic, logic, data movement, program jumps, and everything else on > >> them, just that the smallest lump of data you handle is 4 bits at a time? > >> > >> This is totally and completely wrong. In a quantum computer, a qubit > >> holds a superposition of an unlimited number of states - it is only the > >> resolution and accuracy of the system feeding data into and getting data > >> out of the qubit that limits the useful number of states, combined with > >> the stability of the qubit over time. You can't load and store qubit > >> values, but you can pass them through fixed operations. The result is > >> the "sum" of all possible combinations of all states of the qubits going > >> into the operation. When you take two qubits that are "holding" 4 bits > >> of state, and you add them, the resulting qubit contains the 256 > >> different results of adding all combinations of two 4 bit values. > >> /That/ is the key to being able to scale difficult algorithms like prime > >> factorisation. But if your IO hardware can only distinguish 16 > >> different discrete logic states, then of those 256 theoretical output > >> states you can only read out 16 of them - and figuring out /which/ 16 > >> you get is extremely difficult. And /that/ is key to why quantum > >> computers are of very little practical use, and will continue to be so > >> for the foreseeable future (IMHO). > > > > I don't consider current quantum computers serious > > implementations of quantum possibilities. I remain > > looking into the rather distant future and trying to > > guess where quantum computing will end up. > > Do you know what the current state of quantum computing is? Did I > provide a fair summary of what you think it is? Did my last paragraph > help you understand it? Can you give any kind of description about what > you imagine quantum computing will look like in the future (near or > distant)? You have said a number of times that you see no reason why C > should not be a suitable language for programming quantum computers - to > make that statement, you must have a solid basis for how you think they > will work. > > > As I see > > it there is still a non-trivial probability that > > quantum computing will never be useful but enough > > likelihood that it will that we should plan for it. > > > > In what way should we plan for it? > > (If you feel you have dug yourself into a hole here, by speculating > about things that are beyond your knowledge and making claims based on > "gut feelings" rather than justifiable and informed opinion, then feel > free to back out. I know from personal experience that it can be easier > to keep going with more speculation - but it is better to stop digging > before things get silly.) I haven't spent much time on this speculation - and I don't plan to. I am sort of going to back out because I have nothing more to say. By planning for it I mean we should avoid locking in things that might cripple it. Like assuming information atoms must be binary.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-05-01 16:21 +0200 |
| Message-ID | <oe7g2t$o5b$1@dont-email.me> |
| In reply to | #108821 |
On 01/05/17 00:39, David Kleinecke wrote: > > I haven't spent much time on this speculation - and I > don't plan to. I am sort of going to back out because > I have nothing more to say. Fair enough - I will just make a brief comment on the last part. > > By planning for it I mean we should avoid locking in things > that might cripple it. Like assuming information atoms must be > binary. > Some programming languages make assumptions that the underlying hardware operates in binary - but for most, it is sufficient that you can work with some form of integers with particular ranges. C, for example, does /not/ require that the basic data format be in binary - but it /does/ require that you can read and write all data in blocks that support a fixed power of two different values. It does not matter if an "unsigned char" is 8 binary bits, 27 binary bits, 6 base-4 bitpairs, 3 base 16 nibbles, or whatever - as long as it can represent a set of values from 0 to 2^n - 1 for a fixed n >= 8, with no padding or missing codes. There are some programming languages that work well with packed decimal coding of some sort. However, very early in the days of programmable digital computers it became obvious that binary was far and away the most practical choice of base, and we have stuck to that. However, the ability to work directly with integer-based numbers in a deterministic manner is key to the way most programming languages work. To deal with different computing models - neural nets, cellular automata, quantum computers, etc., - you need very, very different types of programming languages. It does not "cripple" a programming language for classical computers if it is limited to classical computers - anything that works well on classical computers cannot possibly work well on quantum computers. Your suggestion is akin to saying that car designers should not cripple their designs by locking them to driving on roads and the ground, when in the future we might want to travel underwater more often.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2017-05-02 06:35 -0700 |
| Message-ID | <d35e97da-dfd1-42c9-b5ac-c79ea5a16080@googlegroups.com> |
| In reply to | #108765 |
On Sunday, April 30, 2017 at 11:55:51 AM UTC+1, David Brown wrote: > > Based on your post, you seem to be under the impression that the > difference between a quantum computer and a classical one is that the > quantum computer has "qubits" that hold several normal bits of > information in one lump - and that otherwise, it is much like a normal > computer. You think that a quantum computer might hold 4 bits of binary > information per qubit - that it's "bits" hold values between 0 and 15 > rather than between 0 and 1. And that other than that, you can perform > arithmetic, logic, data movement, program jumps, and everything else on > them, just that the smallest lump of data you handle is 4 bits at a time? > > This is totally and completely wrong. In a quantum computer, a qubit > holds a superposition of an unlimited number of states - it is only the > resolution and accuracy of the system feeding data into and getting data > out of the qubit that limits the useful number of states, combined with > the stability of the qubit over time. > I had a look at quantum mechanics as part of my PhD, though we decided in pretty short order not to go there. My understanding is that the whole point is that it is quantised - the number of allowed states is finite, though very large, and the system is in all of the state simultaneously. So a qbit would have two states, on and off and a one qbit quantum computer is exactly the same as a 1 bit conventional computer. A 2 qbit quantum computer, however, evaluates 0 0, 0 1, 1 0, and 1 1 simultaneously, so it's four times as powerful as the equivalent binary computer.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-05-02 16:29 +0200 |
| Message-ID | <oea4u6$l47$1@dont-email.me> |
| In reply to | #109025 |
On 02/05/17 15:35, Malcolm McLean wrote: > On Sunday, April 30, 2017 at 11:55:51 AM UTC+1, David Brown wrote: >> >> Based on your post, you seem to be under the impression that the >> difference between a quantum computer and a classical one is that the >> quantum computer has "qubits" that hold several normal bits of >> information in one lump - and that otherwise, it is much like a normal >> computer. You think that a quantum computer might hold 4 bits of binary >> information per qubit - that it's "bits" hold values between 0 and 15 >> rather than between 0 and 1. And that other than that, you can perform >> arithmetic, logic, data movement, program jumps, and everything else on >> them, just that the smallest lump of data you handle is 4 bits at a time? >> >> This is totally and completely wrong. In a quantum computer, a qubit >> holds a superposition of an unlimited number of states - it is only the >> resolution and accuracy of the system feeding data into and getting data >> out of the qubit that limits the useful number of states, combined with >> the stability of the qubit over time. >> > I had a look at quantum mechanics as part of my PhD, though we decided in > pretty short order not to go there. > > My understanding is that the whole point is that it is quantised - the number > of allowed states is finite, though very large, and the system is in all of the > state simultaneously. So a qbit would have two states, on and off and a one > qbit quantum computer is exactly the same as a 1 bit conventional computer. > A 2 qbit quantum computer, however, evaluates 0 0, 0 1, 1 0, and 1 1 simultaneously, > so it's four times as powerful as the equivalent binary computer. > It is not that simple. (For any explanation in quantum "stuff", no matter how complex the explanation, reality is /never/ as simple as the explanation.) In some aspects of the quantum world, you are correct - things happen in discrete steps. Energy levels come in lumps, charge is always an integer (except for quarks, where it is always an integer multiple of 1/3), and so on. In other aspects, things that would be fixed or have a single defining value in the non-quantum world now have waves, probability functions, and other types of "value". You no longer have known positions or speeds for particles - you have probability density functions. A qubit does not have a finite number of states - it has an infinite number. It's "pure qubit state" is a linear combination of a "0" and a "1", where the two scaling factors are complex numbers with the sum of the squares of their amplitudes being 1 (since it is a probability). This is already very, very far away from a single digital bit. And then the qubit can be in a mixed state of different "pure" states - and things really start to get complicated (and far beyond /my/ meagre understanding).
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-04-29 20:58 +0100 |
| Message-ID | <87lgqjhtot.fsf@bsb.me.uk> |
| In reply to | #108739 |
David Kleinecke <dkleinecke@gmail.com> writes: > On Saturday, April 29, 2017 at 3:33:22 AM UTC-7, Ben Bacarisse wrote: >> David Kleinecke <dkleinecke@gmail.com> writes: >> >> > On Friday, April 28, 2017 at 5:43:18 PM UTC-7, Ben Bacarisse wrote: >> >> David Kleinecke <dkleinecke@gmail.com> writes: >> >> <snip> >> >> > One could define x<<n as x*(2^n) and x>>n as x/(2^n) and any >> >> > problems go away. >> >> >> >> For the cases that are well-defined, that is exactly how they are >> >> defined. But that would *cause* problem were that extended to the other >> >> cases. The committee wanted to avoid imposing a burden on >> >> implementations for hardware that did not match C's definition of a >> >> shift. >> >> >> >> > But that must have been too easy when the standard was developed. >> >> >> >> That's implausible. The core meaning is defined exactly as you say, but >> >> the extra bits are not there because the committee never thought to >> >> remove them. >> >> >> >> > PS: And even x<<(-n) as x/(2^n) and so on. >> >> >> >> It is not in the spirit of C to impose that sort of cost on a primitive >> >> operation like a bit shift. >> > >> > I admit I was thinking about computers which work on atoms >> > of information other than 2 -like quantum computers seem to >> > be headed for. If information is not expressed in bits it is >> > hard to say what all those edge cases "should" do. >> >> Your 2017 criticism of the C standard from the late 1980s was based on >> what *might* be the future of quantum computers? >> >> > Or I suppose you could claim that C was never intended for >> > such hardware. If so - why not? >> >> Obviously it was never intended for such machines and I can't believe >> you really need me to say why! > > It wasn't 2017 - that's this year. "It" -- your criticism of the C standardisation process -- *was* this year. > I am interested in the long > range future of computing. I see no reason why C (as I understand > it - not necessarily the standard) couldn't be used to program > quantum computers. Regardless of what it was intended for back > then. I was interested in what you said in the message I replied to. If you have nothing more to say about that, I'm happy to leave it at that. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-04-28 18:43 +0200 |
| Message-ID | <odvr8t$ff5$1@dont-email.me> |
| In reply to | #108664 |
On 28/04/17 17:23, supercat@casperkitty.com wrote: > On Friday, April 28, 2017 at 1:53:53 AM UTC-5, David Brown wrote: >> I used to work with compilers that did little in the way of >> optimisation, and would do this kind of "hand optimisation". Such tools >> were usually for small microcontrollers which may not have things like a >> multiply instruction - "(x << 2) + x" could be significantly faster than >> "x * 5". Almost certainly, "x" would have been an unsigned type in such >> cases - usually uint8_t (even if I had to define that type myself >> because the compiler had no <stdint.h>). > > For multiplication by a constant, I generally prefer to use multiplication > operator since compilers can pretty consistently figure that out. So do I - with decent compilers. But I was talking here about compilers that did little in the way of optimisation, including converting multiplication by a constant into shifts and/or adds. > If the > scale factor will always be a power of two, but *which* power of two may > vary, and if there's no need to even think about running the code on any > machine that doesn't use two's-complement math, I would regard x<<y as > being clearer than x*(1<<y). Note that the former has a define case where > the latter doesn't, and on implementations which don't go out of their way > not to expose useful platform behavior it doesn't require knowing the type > of y. For which case(s) is (x << y) defined but (x * (1u << y)) is not? Do you mean when x is long long (or unsigned long long) ? > > Incidentally, if a platform with 32-bit "int" defines 1<<31 as -1 (likely > on platforms that also handle C++, as C++ would require such behavior), That would be a very odd choice of definition for 1 << 31. In hex, it is 0x8000'0000, which is -2147483648 in two's complement 32-bit signed arithmetic. And as far as I can tell, C++ has exactly the same behaviour for shifts as C, including exactly the same undefined and implementation dependent behaviour. > then if "x" is "long long", then a compiler would likely have to generate > code for x*(1<<y) that was equivalent to (y!=31) ? x<<y : -(x<<y), which > would almost certainly be less efficient than x<<y. >
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-04-28 14:09 +0100 |
| Message-ID | <A9HMA.539544$8b6.445860@fx19.am4> |
| In reply to | #108634 |
On 28/04/2017 00:44, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 28/04/17 00:13, Keith Thompson wrote: >>> joel.rees@gmail.com writes: >>> [...] >>>> We have this coddling of brain-damaged CPUs when a left-shift on a >>>> negative operand is specified on sign-magnitude architectures or >>>> something, but we have this assurance that casting a -1 to an unsigned >>>> fills the thing with ones. >>>> >>>> (I know calling it brain-damaged is too extreme, but ...) >>> >>> I suggest you might benefit from describing these things in less >>> inflammatory terms. >>> >>> The behavor of left-shifting a negative value is undefined. >>> This is specified in N1570 6.5.7p4. >>> >>> (I don't recall that I've ever felt the need to left-shift a negative >>> integer.) >> >> I don't remember ever wanting to shift a signed integer, left or right, >> except perhaps an integer constant (such as "1 << 12") without bothering >> to add the "u" suffix. Bit manipulation, such as shifts and logical bit >> operations, are usually most natural on unsigned types in my experience. > > It can be tempting to use "<<" as a replacement for multiplying by > a power of 2. For example, one might write `n << 3` rather than > `n * 8`. But it's UB if n is negative -- and it's usually better > to write `n * 8` and let the compiler figure out whether it makes > sense to use a shift instruction. With gcc (on my x86 machine), it uses left shift to multiply a signed int by 8, one that it doesn't know whether it's negative or not. It knows that left-shifting a negative int will work. I think it will always work on two's complement (ie. give the same result as multiply), and many will spend their entire working lives working with such machines. Yet they are not allowed to assume that. Ever. As for UB on left-shifting 3 places, isn't this the same UB you get when multiplying by 8 and the result might overflow? In that case it doesn't seem to matter which is used. (BTW why didn't the language just prohibit shifts on signed values if it frowns upon them so much?) -- bartc
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-04-28 14:23 +0000 |
| Message-ID | <tfIMA.84623$KO2.48643@fx36.iad> |
| In reply to | #108651 |
bartc <bc@freeuk.com> writes:
>With gcc (on my x86 machine), it uses left shift to multiply a signed
>int by 8, one that it doesn't know whether it's negative or not.
>
>It knows that left-shifting a negative int will work.
No, it knows that the result is undefined (because of signed
underflow, in this case).
$ cat /tmp/a.c
int main(int argc, char **argv)
{
int fred = -2031524053;
int b = fred * 8;
printf ("%d\n", b);
return b;
}
0000000000400530 <main>:
400530: 55 push %rbp
400531: 48 89 e5 mov %rsp,%rbp
400534: 48 83 ec 20 sub $0x20,%rsp
400538: 89 7d ec mov %edi,-0x14(%rbp)
40053b: 48 89 75 e0 mov %rsi,-0x20(%rbp)
40053f: c7 45 fc 2b 67 e9 86 movl $0x86e9672b,-0x4(%rbp)
400546: 8b 45 fc mov -0x4(%rbp),%eax
==> 400549: c1 e0 03 shl $0x3,%eax
40054c: 89 45 f8 mov %eax,-0x8(%rbp)
40054f: 8b 45 f8 mov -0x8(%rbp),%eax
400552: 89 c6 mov %eax,%esi
400554: bf 00 06 40 00 mov $0x400600,%edi
400559: b8 00 00 00 00 mov $0x0,%eax
40055e: e8 ad fe ff ff callq 400410 <printf@plt>
400563: 8b 45 f8 mov -0x8(%rbp),%eax
400566: c9 leaveq
400567: c3 retq
400568: 0f 1f 84 00 00 00 00 nopl 0x0(%rax,%rax,1)
40056f: 00
$ /tmp/a
927676760
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-04-28 16:17 +0100 |
| Message-ID | <w1JMA.24039$MR.21855@fx35.am4> |
| In reply to | #108658 |
On 28/04/2017 15:23, Scott Lurndal wrote:
> bartc <bc@freeuk.com> writes:
>
>> With gcc (on my x86 machine), it uses left shift to multiply a signed
>> int by 8, one that it doesn't know whether it's negative or not.
>>
>> It knows that left-shifting a negative int will work.
>
> No, it knows that the result is undefined (because of signed
> underflow, in this case).
>
> $ cat /tmp/a.c
> int main(int argc, char **argv)
> {
> int fred = -2031524053;
> int b = fred * 8;
What are you saying, that ANY multiply of signed int is undefined?
With my test, the equivalent of your 'fred' was initialised from an
external function, and gcc still used a left-shift.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-04-28 15:55 +0000 |
| Message-ID | <YBJMA.77218$PI.71442@fx41.iad> |
| In reply to | #108663 |
bartc <bc@freeuk.com> writes:
>On 28/04/2017 15:23, Scott Lurndal wrote:
>> bartc <bc@freeuk.com> writes:
>>
>>> With gcc (on my x86 machine), it uses left shift to multiply a signed
>>> int by 8, one that it doesn't know whether it's negative or not.
>>>
>>> It knows that left-shifting a negative int will work.
>>
>> No, it knows that the result is undefined (because of signed
>> underflow, in this case).
>>
>> $ cat /tmp/a.c
>> int main(int argc, char **argv)
>> {
>> int fred = -2031524053;
>> int b = fred * 8;
>
>What are you saying, that ANY multiply of signed int is undefined?
I think I was pretty clear in the part of the article that
you snipped out. Any signed operations that can result in a signed underflow
or overflow result in undefined behavior. This allows the compiler to
use a left shift as a peephole optimization for multiplication
by powers of two without needing to worry about the fact that
the result may be not be mathematically correct.
The _application programmer_ is responsible for ensuring that the
multiplicand and the multiplier don't result in
overflow/underflow when using signed integer arithmetic.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2017-04-28 19:11 -0700 |
| Message-ID | <10c71913-2871-4474-b05c-804bfdb7074d@googlegroups.com> |
| In reply to | #108663 |
On Friday, April 28, 2017 at 4:16:51 PM UTC+1, Bart wrote: > > What are you saying, that ANY multiply of signed int is undefined? > Let's say we're load an image. width and height are 32 bit quantities. We multiply them together and call malloc to create pixel buffer, then loop over height and width to populate it from the file. If int is 32 bits, some malicious person can contrive a file such that the multiplication overflows, our buffer is too small, and we have a security leak. Unless we have an environment where an overflow leads to termination of the program with an error message.
[toc] | [prev] | [next] | [standalone]
Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web