Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #153691 > unrolled thread
| Started by | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| First post | 2020-08-17 22:11 +0200 |
| Last post | 2020-08-23 08:03 -0700 |
| Articles | 20 on this page of 154 — 23 participants |
Back to article view | Back to comp.lang.c
widening multiplication jacobnavia <jacob@jacob.remcomp.fr> - 2020-08-17 22:11 +0200
Re: widening multiplication Eric Sosman <esosman@comcast-dot-net.invalid> - 2020-08-17 16:30 -0400
Re: widening multiplication jacobnavia <jacob@jacob.remcomp.fr> - 2020-08-18 09:27 +0200
Re: widening multiplication Andrey Tarasevich <andreytarasevich@hotmail.com> - 2020-08-17 13:33 -0700
Re: widening multiplication jacobnavia <jacob@jacob.remcomp.fr> - 2020-08-18 09:24 +0200
Re: widening multiplication Andrey Tarasevich <andreytarasevich@hotmail.com> - 2020-08-21 14:47 -0700
Re: widening multiplication Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-17 21:52 +0100
Re: widening multiplication jacobnavia <jacob@jacob.remcomp.fr> - 2020-08-18 09:22 +0200
Re: widening multiplication Siri Cruise <chine.bleu@yahoo.com> - 2020-08-17 14:10 -0700
Re: widening multiplication Bart <bc@freeuk.com> - 2020-08-17 22:33 +0100
Re: widening multiplication Siri Cruise <chine.bleu@yahoo.com> - 2020-08-17 15:13 -0700
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-18 11:33 +0200
Re: widening multiplication jacobnavia <jacob@jacob.remcomp.fr> - 2020-08-18 09:20 +0200
Re: widening multiplication scott@slp53.sl.home (Scott Lurndal) - 2020-08-17 21:38 +0000
Re: widening multiplication jacobnavia <jacob@jacob.remcomp.fr> - 2020-08-18 09:19 +0200
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-18 11:31 +0200
Re: widening multiplication Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-08-18 05:00 -0700
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-18 15:10 +0200
Re: widening multiplication Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-08-18 12:31 +0000
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-18 15:15 +0200
Re: widening multiplication Siri Cruise <chine.bleu@yahoo.com> - 2020-08-18 06:53 -0700
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-18 16:14 +0200
Re: widening multiplication Siri Cruise <chine.bleu@yahoo.com> - 2020-08-18 07:24 -0700
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-18 22:41 +0200
Re: widening multiplication Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-08-18 14:24 -0700
Re: widening multiplication Bart <bc@freeuk.com> - 2020-08-18 22:54 +0100
Re: widening multiplication Siri Cruise <chine.bleu@yahoo.com> - 2020-08-18 15:18 -0700
Re: widening multiplication Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-18 15:54 -0700
Re: widening multiplication Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-18 15:38 -0700
Re: widening multiplication Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-08-19 07:03 +0000
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-19 09:24 +0200
Re: widening multiplication Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-08-19 02:13 -0700
Re: widening multiplication Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-08-19 10:43 +0000
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-19 12:50 +0200
Re: widening multiplication Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-08-19 07:30 -0700
Re: widening multiplication Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-08-19 07:44 -0700
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-19 17:35 +0200
Re: widening multiplication Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-19 10:13 -0700
Re: widening multiplication Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-08-19 14:30 -0700
Re: widening multiplication Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-19 15:07 -0700
Re: widening multiplication Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-08-19 22:13 +0000
Re: widening multiplication Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-08-19 15:49 -0700
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-20 11:31 +0200
Re: widening multiplication Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-08-20 03:47 -0700
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-20 13:21 +0200
Re: widening multiplication Richard Damon <Richard@Damon-Family.org> - 2020-08-20 08:20 -0400
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-21 09:51 +0200
Re: widening multiplication Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-08-21 02:51 -0700
Re: widening multiplication Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-21 11:44 +0100
Re: widening multiplication Bart <bc@freeuk.com> - 2020-08-21 12:17 +0100
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-21 13:36 +0200
Re: widening multiplication Bart <bc@freeuk.com> - 2020-08-21 13:15 +0100
Re: widening multiplication Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-21 11:04 -0700
Re: widening multiplication Richard Damon <Richard@Damon-Family.org> - 2020-08-21 08:30 -0400
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-21 13:32 +0200
Re: widening multiplication Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-21 12:46 +0100
Re: widening multiplication Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-08-21 07:43 -0700
Re: widening multiplication Bart <bc@freeuk.com> - 2020-08-21 16:13 +0100
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-21 20:15 +0200
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-21 20:14 +0200
Re: widening multiplication Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-08-21 16:37 -0700
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-22 15:38 +0200
Re: widening multiplication Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-22 01:02 +0100
Re: widening multiplication Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-08-22 04:57 -0700
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-22 16:11 +0200
Re: widening multiplication Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-08-22 08:46 -0700
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-22 18:33 +0200
Re: widening multiplication Richard Damon <Richard@Damon-Family.org> - 2020-08-22 13:44 -0400
Re: widening multiplication Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-22 12:48 -0700
Re: widening multiplication Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-22 21:45 +0100
Re: widening multiplication Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-08-22 05:20 -0700
Re: widening multiplication Richard Damon <Richard@Damon-Family.org> - 2020-08-22 10:16 -0400
Re: widening multiplication Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-08-22 08:59 -0700
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-22 19:04 +0200
Re: widening multiplication Richard Damon <Richard@Damon-Family.org> - 2020-08-22 13:59 -0400
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-22 23:01 +0200
Re: widening multiplication Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-08-23 07:42 -0700
Re: widening multiplication Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-22 22:12 +0100
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-23 13:31 +0200
Re: widening multiplication Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-08-23 04:53 -0700
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-23 14:22 +0200
Re: widening multiplication Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-08-23 06:47 -0700
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-23 16:25 +0200
Re: widening multiplication Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-08-23 07:42 -0700
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-24 09:10 +0200
Re: widening multiplication Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-08-24 02:06 -0700
Re: widening multiplication Richard Damon <Richard@Damon-Family.org> - 2020-08-23 13:10 -0400
Re: widening multiplication Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-23 16:16 +0100
Re: widening multiplication Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-22 22:02 +0100
Re: widening multiplication Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-08-22 18:14 -0700
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-23 14:27 +0200
Re: widening multiplication James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-08-21 05:58 -0700
Re: widening multiplication Richard Damon <Richard@Damon-Family.org> - 2020-08-19 19:15 -0400
Re: widening multiplication Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-08-19 16:48 -0700
Re: widening multiplication Bart <bc@freeuk.com> - 2020-08-19 23:39 +0100
Re: widening multiplication Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-08-19 15:51 -0700
Re: widening multiplication Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-19 15:56 -0700
Re: widening multiplication Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-08-19 16:04 -0700
Re: widening multiplication Siri Cruise <chine.bleu@yahoo.com> - 2020-08-19 18:04 -0700
Re: widening multiplication antispam@math.uni.wroc.pl - 2020-08-20 00:13 +0000
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-20 10:06 +0200
Re: widening multiplication Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> - 2020-08-20 11:26 +0200
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-20 13:25 +0200
Re: widening multiplication Richard Damon <Richard@Damon-Family.org> - 2020-08-19 07:41 -0400
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-19 15:08 +0200
Re: widening multiplication Richard Damon <Richard@Damon-Family.org> - 2020-08-19 10:29 -0400
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-19 17:41 +0200
Re: widening multiplication Richard Damon <Richard@Damon-Family.org> - 2020-08-19 13:34 -0400
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-19 20:21 +0200
Re: widening multiplication Siri Cruise <chine.bleu@yahoo.com> - 2020-08-18 15:16 -0700
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-19 09:32 +0200
Re: widening multiplication James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-08-18 11:11 -0400
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-18 22:45 +0200
Re: widening multiplication Daniel Hyde <Daniel.Hyde71@gmail.com> - 2020-08-19 20:17 +0200
Re: widening multiplication James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-08-19 15:20 -0400
Re: widening multiplication Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-08-19 20:59 +0000
Re: widening multiplication James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-08-19 17:28 -0400
Re: widening multiplication Bart <bc@freeuk.com> - 2020-08-19 22:43 +0100
Re: widening multiplication Sjouke Burry <burrynulnulfour@ppllaanneett.nnll> - 2020-08-19 21:38 +0200
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-19 21:47 +0200
Re: widening multiplication Daniel Hyde <Daniel.Hyde71@gmail.com> - 2020-08-20 12:24 +0200
Re: widening multiplication James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-08-20 08:14 -0400
Re: widening multiplication Daniel Hyde <Daniel.Hyde71@gmail.com> - 2020-08-20 14:20 +0200
Re: widening multiplication Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-20 10:39 -0700
Re: widening multiplication Richard Damon <Richard@Damon-Family.org> - 2020-08-19 15:55 -0400
Re: widening multiplication Daniel Hyde <Daniel.Hyde71@gmail.com> - 2020-08-22 12:30 +0200
Re: widening multiplication James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-08-22 05:09 -0700
Re: widening multiplication Daniel Hyde <Daniel.Hyde71@gmail.com> - 2020-08-22 17:15 +0200
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-22 19:06 +0200
Re: widening multiplication Richard Harnden <richard.nospam@gmail.com> - 2020-08-22 19:06 +0100
Re: widening multiplication Bonita Montero <Bonita.Montero@gmail.com> - 2020-08-22 20:28 +0200
Re: widening multiplication Bonita Montero <Bonita.Montero@gmail.com> - 2020-08-23 01:36 +0200
Re: widening multiplication "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-08-22 18:15 -0700
Re: widening multiplication Bonita Montero <Bonita.Montero@gmail.com> - 2020-08-23 11:16 +0200
Re: widening multiplication "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-08-23 21:05 -0700
Re: widening multiplication Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-22 12:45 -0700
Re: widening multiplication James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-08-22 11:47 -0700
Re: widening multiplication Richard Damon <Richard@Damon-Family.org> - 2020-08-22 10:21 -0400
Re: widening multiplication Bart <bc@freeuk.com> - 2020-08-22 16:18 +0100
Re: widening multiplication David Brown <david.brown@hesbynett.no> - 2020-08-22 19:16 +0200
Re: widening multiplication Kaz Kylheku <793-849-0957@kylheku.com> - 2020-08-23 04:38 +0000
Re: widening multiplication James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-08-23 08:22 -0400
Re: widening multiplication Kaz Kylheku <793-849-0957@kylheku.com> - 2020-08-24 03:00 +0000
Re: widening multiplication James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-08-23 23:54 -0400
Re: widening multiplication Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-08-24 06:19 +0000
Re: widening multiplication James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-08-24 09:45 -0400
Re: widening multiplication Kaz Kylheku <793-849-0957@kylheku.com> - 2020-08-24 14:47 +0000
Re: widening multiplication "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-08-24 12:14 -0700
Re: widening multiplication Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-24 08:40 -0700
Re: widening multiplication Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-08-26 18:06 +0000
Re: widening multiplication Daniel Hyde <Daniel.Hyde71@gmail.com> - 2020-08-23 17:55 +0200
Re: widening multiplication Bart <bc@freeuk.com> - 2020-08-23 17:38 +0100
Re: widening multiplication Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-19 13:15 -0700
Re: widening multiplication rick.c.hodgin@gmail.com - 2020-08-23 08:03 -0700
Page 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8 Next page →
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-08-21 16:37 -0700 |
| Message-ID | <5a31930a-8f1f-4ca8-aa8d-6011c1155a62n@googlegroups.com> |
| In reply to | #153820 |
On Friday, 21 August 2020 at 19:14:17 UTC+1, David Brown wrote: > On 21/08/2020 16:43, Malcolm McLean wrote: > > I fail to see how C has a particular "gotcha" here. > > > Now most languages don't have this gotcha. > I beg to differ. But maybe you can provide a list of languages to back > up your "most languages" claim. Only low-level languages usually have fixed width integer types. In high level languages you have just "integers", or often just "scalars". The number of programming problems that require "scalars" is much larger than the number that require integers with fixed numbers of bits. However it is quite common to do most of your work in a high level language, but need to code a few routines in a low level language for efficiency. The "gotcha" is worse than I mentioned at first. int r; short x, y; r = x * y; /* almost certainly safe, but not actually guaranteed */ long long r; int x, y; r = x * y; /* unsafe, but not actually guaranteed to produce an overflow*/ Don't you see this as a "gotcha?" > > Whoever suggested that C was "intuitive" ? A few people describe their > own favourite language as "intuitive", but generally they are wrong. C > has its rules - they are fairly straight-forward and consistent here > (though like most C programmers, I don't find them perfect - different C > programmers will of course disagree about what they'd have preferred). > If you want to program in C, learn those rules. If you don't learn > them, don't be surprised if you make mistakes. > People don't have time. They just want to write Fortran in another dialect, they're not interested in the idiosyncracies of C or any other language. And yes, that leads to mistakes. Mistakes that can be minimised by good language design.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-08-22 15:38 +0200 |
| Message-ID | <rhr74l$jku$1@dont-email.me> |
| In reply to | #153840 |
On 22/08/2020 01:37, Malcolm McLean wrote: > On Friday, 21 August 2020 at 19:14:17 UTC+1, David Brown wrote: >> On 21/08/2020 16:43, Malcolm McLean wrote: >> >> I fail to see how C has a particular "gotcha" here. >> >>> Now most languages don't have this gotcha. >> I beg to differ. But maybe you can provide a list of languages to back >> up your "most languages" claim. > > Only low-level languages usually have fixed width integer types. In high > level languages you have just "integers", or often just "scalars". The > number of programming problems that require "scalars" is much larger > than the number that require integers with fixed numbers of bits. > There are, of course, a /huge/ number of programming languages that are in use today of have been used over the last 50 years or so. But there are not that many /major/ languages - languages that have been used for many purposes by many people over a substantial period of time. (Yes, I am aware that is a very vague and unquantified description.) Fixed width integers are much more efficient than expanding integers - so they are the norm for compiled languages. For interpreted (or byte-coded) higher-level languages, the balance between programming convenience and run-time efficiency is different, and it's not uncommon with larger numerical types or types that grow as needed. Languages such as C, C++, Ada, D, Modula 2, Java, Go, and many others are normally classified as high-level languages as they are defined in terms of abstract machines and language specifications, rather than in terms of the underlying hardware. Of course some are "lower level" and some are "higher level" within that classification. > However it is quite common to do most of your work in a high level > language, but need to code a few routines in a low level language for > efficiency. Sure. Are you still trying to claim that people who program mainly in a high-level language (Matlab, Python, etc.), sometimes do some work in C despite not being familiar with the language, and when they get the C code wrong it is somehow the fault of the C language for not being more like Matlab and Python? Or that the C language and/or tools should be changed to suit these programmers? That was your argument before, and it is obviously absurd. > > The "gotcha" is worse than I mentioned at first. > > int r; > short x, y; > r = x * y; /* almost certainly safe, but not actually guaranteed */ > Signed arithmetic in C is perfectly safe when you use values that don't overflow. (The same applies to any other language with fixed size types - neither wrapping nor errors are "safe" as they don't give correct mathematically results.) This is not more "unsafe" than any other signed arithmetic expression. There is an oddity of the way C handles int promotion if x and y are /unsigned/ short, and "short" is half the size of "int". IMHO it is unfortunate, and I'd prefer that int promotion did not exist, but that's the way C works. It is rarely a relevant gotcha or difficult to avoid, for people who have bothered to learn the rules of the language. > long long r; > int x, y; > r = x * y; /* unsafe, but not actually guaranteed to produce an overflow*/ > Overflows are undefined behaviour in C - there are no guarantees at all. Surely you understand that? > Don't you see this as a "gotcha?" I don't see it as anything special. For any programming language, you need to know how things work - you need to know the rules before you can use them. The rules for C in regard to arithmetic expressions are not particularly difficult, or especially different from many other languages, at least as long as you are using types and values that give meaningful results. (And all languages give garbage out when you put garbage in.) But if the way "x * y" were calculated depended on what you did with it afterwards, such as the type of "r" above, then that /would/ be a "gotcha". >> >> Whoever suggested that C was "intuitive" ? A few people describe their >> own favourite language as "intuitive", but generally they are wrong. C >> has its rules - they are fairly straight-forward and consistent here >> (though like most C programmers, I don't find them perfect - different C >> programmers will of course disagree about what they'd have preferred). >> If you want to program in C, learn those rules. If you don't learn >> them, don't be surprised if you make mistakes. >> > People don't have time. Do you think people should bother to learn about traffic rules before starting to drive? Or should they just get the basics of the pedals, steering, gears, and which side of the road to stick to, and off they go? After all, who has time to learn how to use indicators, or what different road signs mean? Really, your arguments here are ridiculous. You want to redefine a language that vast numbers of professionals use daily for decades, to aid a few lazy sods who can't be bothered to spend a couple of hours learning a few details of the language? This is not rocket science. For people who already understand programming, and have enough of a familiarity with C to be able to write the code snippets you have given, these rules are simple and quickly learned. > They just want to write Fortran in another dialect, > they're not interested in the idiosyncracies of C or any other language. And > yes, that leads to mistakes. People moving from /Fortran/ to C are going to be surprised by the idiosyncrasies of C? Now I /know/ you are joking. > Mistakes that can be minimised by good > language design. > No one has suggested that C is perfect. Many of its details are the result of historical baggage - it's easy to find scope for improvement with hindsight. Nonetheless, these particular details are not difficult.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-08-22 01:02 +0100 |
| Message-ID | <87zh6n5yzj.fsf@bsb.me.uk> |
| In reply to | #153815 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > On Friday, 21 August 2020 at 11:45:31 UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.ar...@gmail.com> writes: >> >> > On Friday, 21 August 2020 at 08:52:05 UTC+1, David Brown wrote: >> >> >> >> (I have nothing against this concept in itself - I merely disagree that >> >> it would be a good idea to squeeze it into C, and I want Malcolm to >> >> justify claiming it applies to "most programming languages".) >> I've restored the quote because the various edits have not done any >> favours to the discussion. >> > Restore the snip and you'll see that that's not quite what I was >> > saying. >> What you said was this: >> "Most programming languages work in more or less the same way, and if >> you know one you can follow along another. And you often have to do >> that. [...] Ideally, you keep these gotchas to a bare minimum, only >> the things so deeply rooted [that] you can't eliminate them from the >> language." >> >> And (barring the usual trouble of about talking about "most" of anything >> as diverse as programming languages) you are essentially correct. But >> your words argue against the point you made about the code -- namely >> that not using a wide multiplication will be a "gotcha", tripping up >> programmers who know other languages but not C. A totally unscientific >> survey of the inside of my head suggests that most languages determine >> the result of arithmetic expressions from the types for their operands >> and not from any wider context. >> >> So, despite some snipping, David Brown still has a point. What is the >> evidence (specifically in terms of other programming languages) that an >> experienced programmer would not immediately suspect a problem in the >> code being discussed? Presumably you where surprised by what C does >> because your experience differs from mine. What are the languages that >> formed your expectations of that code? >> > The line > > index = y * width + x > > could appear in almost any procedural programming language with > essentially the same meaning. But you then go on to list lots of different meanings. You may be using "essentially the same" in such an abstract way that it's not helpful anymore. > C has a "gotcha" that, if y and width are ints, > and "y * width" overflows the value of an int, the result has undefined behaviour, > even if index is wide enough to hold the result. > > Now most languages don't have this gotcha. y * width might overflow the > maximum size of an integer, but likely there is only one integer type, so > the problem is insoluble (and it's probably impossible to create an array > that can't be indexed by an integer). Other languages just have "scalar" types > where integers are represented by what in C are "doubles", And these have a different gotcha for large integer arithmetic. > and others > have dynamic typing so it's impossible to overflow an integer without > exceeding the capacity of the computer's memory. Dynamic typing does not imply that it's impossible to overflow an integer, and having unbounded integers does not imply dynamic typing. > A few might have a rule > that a whole expression is always evaluated according to its widest > component type. Does the "might" mean you don't know of any, because I don't either? Since you seemed to suggest this for C, I was hoping you knew some examples. But to get back to the big picture, you don't give examples of any of these. You seem to be cherry-picking without giving details for anyone to check. For example, some of the "only one sized integer type" languages might have undefined overflow -- something that you call a gotcha. Other suggested semantics have other pitfalls. I don't think you have made your case. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-08-22 04:57 -0700 |
| Message-ID | <337b817e-fc23-430b-9ba2-cb107dcf934cn@googlegroups.com> |
| In reply to | #153841 |
On Saturday, 22 August 2020 at 01:02:54 UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.ar...@gmail.com> writes: > > > The line > > > > index = y * width + x > > > > could appear in almost any procedural programming language with > > essentially the same meaning. > But you then go on to list lots of different meanings. You may be using > "essentially the same" in such an abstract way that it's not helpful > anymore. > It means convert a 2d space to a 1d space, using y as the major axis. Any programmer will be in his comfort zone here. He knows that "*" means "multiply". He will also be familar with the conventional names. In some languages, x and y might not be scalars and "*" might be overloaded to mean a matrix multiply, but that's ruled out (assuming everything has been set up correctly) by context. What you are saying is that in C it has a different "meaning" than in Python when the variables overflow. In C it "means" "take (y * width + x) and assign to index, unless the result is greater than INT_MAX, it which case do anything you want". You can quibble about how to use the word "mean". I'd say it "behaves" like that, not that it "means" that. "Meaning" is to with intention, "behaviour" is how a physical construct responds to a stimulus. > > But to get back to the big picture, you don't give examples of any of > these. You seem to be cherry-picking without giving details for anyone > to check. For example, some of the "only one sized integer type" > languages might have undefined overflow -- something that you call a > gotcha. Other suggested semantics have other pitfalls. I don't think > you have made your case. > If you have only one integer type, you can't deal with integers bigger than the type will hold, other than by writing your own bignum routines. But most people understand that. And, likely, you can't create an array larger than an integer can index. In C, if x, y, width and index are all size_t's the problem largely goes away. It's when index is a size_t, and matrix dimensions can't go above 2 billion, so we use ints for them, that you get the danger, if matrices can get very large. The programmer sees "the index might go above 2 billion" and makes "index" a size_t, and doesn't realise that he hasn't solved the problem. Worse, he's got similar code as a pattern where matrix dimensions can't go above 30,000, and are stored as 16 bit shorts. In that code "index" is an "int", and it all works as expected. Or maybe he thinks "the fix is to make x, y and width size_t's". Then he goes all through the code, potentially breaking lots of stuff, because fundamental variables which are used everywhere have changed their type, when in fact the fix is little and local. .
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-08-22 16:11 +0200 |
| Message-ID | <rhr935$ur4$1@dont-email.me> |
| In reply to | #153857 |
On 22/08/2020 13:57, Malcolm McLean wrote: > On Saturday, 22 August 2020 at 01:02:54 UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.ar...@gmail.com> writes: >> >>> The line >>> >>> index = y * width + x >>> >>> could appear in almost any procedural programming language with >>> essentially the same meaning. >> But you then go on to list lots of different meanings. You may be using >> "essentially the same" in such an abstract way that it's not helpful >> anymore. >> > It means convert a 2d space to a 1d space, using y as the major axis. > Any programmer will be in his comfort zone here. He knows that "*" > means "multiply". He will also be familar with the conventional names. > > In some languages, x and y might not be scalars and "*" might be overloaded > to mean a matrix multiply, but that's ruled out (assuming everything has been > set up correctly) by context. > > What you are saying is that in C it has a different "meaning" than in Python > when the variables overflow. In C it "means" "take (y * width + x) and assign > to index, unless the result is greater than INT_MAX, it which case do anything > you want". You can quibble about how to use the word "mean". I'd say it > "behaves" like that, not that it "means" that. "Meaning" is to with intention, > "behaviour" is how a physical construct responds to a stimulus. Ignoring the lack of precision in your description here, are you suggesting that compilers should read programmers' minds to figure out their intentions, rather than expecting programmers to learn how the language works? Is the compiler supposed to interpret the identifiers "x", "width" and "y" to figure out that you are talking about 2D calculations and not some other kind of calculation? The "meaning" of code is what the language specification (plus any other documented specifications, like compiler manuals) say it means - no more and no less. That applies to all programming languages.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-08-22 08:46 -0700 |
| Message-ID | <ba21581f-9f9a-4b57-8e47-71adb24f537bn@googlegroups.com> |
| In reply to | #153864 |
On Saturday, 22 August 2020 at 15:11:58 UTC+1, David Brown wrote: > > Ignoring the lack of precision in your description here, are you > suggesting that compilers should read programmers' minds to figure out > their intentions, rather than expecting programmers to learn how the > language works? Is the compiler supposed to interpret the identifiers > "x", "width" and "y" to figure out that you are talking about 2D > calculations and not some other kind of calculation? > If you assign to a wide type, then you normally expect that the right hand side of the expression will be representable in the wide type, but not necessarily in a narrower type. The exceptions are rare. > > The "meaning" of code is what the language specification (plus any other > documented specifications, like compiler manuals) say it means - no more > and no less. That applies to all programming languages. > You can use the word "meaning" in many ways. But I was using it in the sense of "the programmer's intentions".
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-08-22 18:33 +0200 |
| Message-ID | <rhrhdc$h1j$1@dont-email.me> |
| In reply to | #153871 |
On 22/08/2020 17:46, Malcolm McLean wrote: > On Saturday, 22 August 2020 at 15:11:58 UTC+1, David Brown wrote: >> >> Ignoring the lack of precision in your description here, are you >> suggesting that compilers should read programmers' minds to figure out >> their intentions, rather than expecting programmers to learn how the >> language works? Is the compiler supposed to interpret the identifiers >> "x", "width" and "y" to figure out that you are talking about 2D >> calculations and not some other kind of calculation? >> > If you assign to a wide type, then you normally expect that the right > hand side of the expression will be representable in the wide type, but > not necessarily in a narrower type. The exceptions are rare. I don't have such expectations - because I know what the language means! When I write an expression or sub-expression, /my/ expectations are that it will be evaluated according to the rules of the language - which in almost every case (Verilog is the /only/ exception so far mentioned), is completely independent of what is done with the expression or sub-expression afterwards. And no, I don't think it would be a good idea if C were suddenly changed to be different from every other language. >> >> The "meaning" of code is what the language specification (plus any other >> documented specifications, like compiler manuals) say it means - no more >> and no less. That applies to all programming languages. >> > You can use the word "meaning" in many ways. But I was using it in the sense > of "the programmer's intentions". > Regulars in this group are well aware of your Humpty-Dumpty attitude to words. I guess we can add "Malcolm-mean" to "Malcolm-function", "Malcolm-array", and all the other "Malcolm-speak" words collected over the years.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2020-08-22 13:44 -0400 |
| Message-ID | <XPc0H.143349$d95.125335@fx06.iad> |
| In reply to | #153871 |
On 8/22/20 11:46 AM, Malcolm McLean wrote:
> On Saturday, 22 August 2020 at 15:11:58 UTC+1, David Brown wrote:
>>
>> Ignoring the lack of precision in your description here, are you
>> suggesting that compilers should read programmers' minds to figure out
>> their intentions, rather than expecting programmers to learn how the
>> language works? Is the compiler supposed to interpret the identifiers
>> "x", "width" and "y" to figure out that you are talking about 2D
>> calculations and not some other kind of calculation?
>>
> If you assign to a wide type, then you normally expect that the right
> hand side of the expression will be representable in the wide type, but
> not necessarily in a narrower type. The exceptions are rare.
>
Perhaps you need to think about what the compiler needs to deal with.
What should this code do:
#include <stdio.h>
void fun(char const* fmt, int a, int b) {
printf(fmt, a*b)
}
What type SHOULD the compiler assume is requested?
How about the snippet
int a, b, c;
long long d;
d = a * b * c;
Where does the desired long long type apply?
a * b (both ints) will be multiplied by another int, so maybe that is
the type requested?
The concept of the requested type is ill defined in too many corners of
the computer language, which is one reason languages that scale by the
requested size are rare. Verilog can do it because it doesn't have the
equivalent to 'varargs' functions, and the fact that 'real'
multiplication like shown is rare, and some compilers might not actually
allow the synthesis of such code. (You might do multiplication by a
constant, but not two 'variables')
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-08-22 12:48 -0700 |
| Message-ID | <87a6ym7979.fsf@nosuchdomain.example.com> |
| In reply to | #153871 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Saturday, 22 August 2020 at 15:11:58 UTC+1, David Brown wrote:
>> Ignoring the lack of precision in your description here, are you
>> suggesting that compilers should read programmers' minds to figure out
>> their intentions, rather than expecting programmers to learn how the
>> language works? Is the compiler supposed to interpret the identifiers
>> "x", "width" and "y" to figure out that you are talking about 2D
>> calculations and not some other kind of calculation?
>>
> If you assign to a wide type, then you normally expect that the right
> hand side of the expression will be representable in the wide type, but
> not necessarily in a narrower type. The exceptions are rare.
>>
>> The "meaning" of code is what the language specification (plus any other
>> documented specifications, like compiler manuals) say it means - no more
>> and no less. That applies to all programming languages.
>>
> You can use the word "meaning" in many ways. But I was using it in the sense
> of "the programmer's intentions".
Fortunately we have a phrase that means exactly that: "the programmer's
intentions". Please use that phrase, or something similar, when talking
about the programmer's intentions. Thank you.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-08-22 21:45 +0100 |
| Message-ID | <87k0xq4dfu.fsf@bsb.me.uk> |
| In reply to | #153857 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > On Saturday, 22 August 2020 at 01:02:54 UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.ar...@gmail.com> writes: >> >> > The line >> > >> > index = y * width + x >> > >> > could appear in almost any procedural programming language with >> > essentially the same meaning. >> But you then go on to list lots of different meanings. You may be using >> "essentially the same" in such an abstract way that it's not helpful >> anymore. >> > It means convert a 2d space to a 1d space, using y as the major axis. > Any programmer will be in his comfort zone here. He knows that "*" > means "multiply". He will also be familar with the conventional names. > > In some languages, x and y might not be scalars and "*" might be overloaded > to mean a matrix multiply, but that's ruled out (assuming everything has been > set up correctly) by context. > > What you are saying is that in C it has a different "meaning" than in Python > when the variables overflow. In C it "means" "take (y * width + x) and assign > to index, unless the result is greater than INT_MAX, it which case do anything > you want". You can quibble about how to use the word "mean". I'd say it > "behaves" like that, not that it "means" that. "Meaning" is to with intention, > "behaviour" is how a physical construct responds to a stimulus. That screeching sound is your dragging the goalposts onto the tennis court. Now, you want "meaning" to be no more than "intent" not behaviour, but the point you are defending is a clear claim about the mechanics: "Most programming languages work in more or less the same way..." Work. Not the intention they suggest or hint at, but how they work. I don't think it is possible, at least for me, to have an orderly technical discussion with you. (But thank you for writing "his", "he" and "he". It's always good to know where people stand.) -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-08-22 05:20 -0700 |
| Message-ID | <04119787-016c-4db7-ad38-0542c2d510f6n@googlegroups.com> |
| In reply to | #153841 |
On Saturday, 22 August 2020 at 01:02:54 UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.ar...@gmail.com> writes: > > > A few might have a rule > > that a whole expression is always evaluated according to its widest > > component type. > Does the "might" mean you don't know of any, because I don't either? > Since you seemed to suggest this for C, I was hoping you knew some > examples. > I didn't know of any. It has since emerged that there is at least one example of a language, Verilog, which has the same rule as I was proposing for C. Also Rust forbids mixed expressions, which is another way of achieving the same goal. The point I was making was that I was not saying "most languages have the rule that an assignment statement is evaluated according to the width of it's left hand side". I was saying that most languages don't have the same problem, on the basis that most languages are higher level, and others don't provide as many types as C. Or in Fortran we have this rule Do not use INTEGER*8 variables or 8-byte constants or expressions when indexing arrays, otherwise, only 4 low-order bytes are taken into account. This action can cause unpredictable results in your program if the index value exceeds the range for 4-byte integers. This is also awful, but it does solve C's athlete's foot by cutting off the programmer's legs.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2020-08-22 10:16 -0400 |
| Message-ID | <mN90H.95223$355.48870@fx27.iad> |
| In reply to | #153860 |
On 8/22/20 8:20 AM, Malcolm McLean wrote: > On Saturday, 22 August 2020 at 01:02:54 UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.ar...@gmail.com> writes: >> >>> A few might have a rule >>> that a whole expression is always evaluated according to its widest >>> component type. >> Does the "might" mean you don't know of any, because I don't either? >> Since you seemed to suggest this for C, I was hoping you knew some >> examples. >> > I didn't know of any. It has since emerged that there is at least one example > of a language, Verilog, which has the same rule as I was proposing for C. > Also Rust forbids mixed expressions, which is another way of achieving > the same goal. > The point I was making was that I was not saying "most languages have > the rule that an assignment statement is evaluated according to the width > of it's left hand side". I was saying that most languages don't have the > same problem, on the basis that most languages are higher level, and others > don't provide as many types as C. Or in Fortran we have this rule > > Do not use INTEGER*8 variables or 8-byte constants or expressions when indexing > arrays, otherwise, only 4 low-order bytes are taken into account. This action can cause > unpredictable results in your program if the index value exceeds the range for 4-byte integers. > > This is also awful, but it does solve C's athlete's foot by cutting off the programmer's legs. > I would say your 'most' is a bit inaccurate or misleading, unless you really do mean that most languages do worst. The ones that do 'better' than C in this would be: 1) Languages with dynamic typing, where integer math automatically converts to higher/arbitrary precision types. These get around the problem by defining it away, there is no type like int32_t 2) Maybe languages with fixed typing, but integers default to a arbitrary precision type. So again, you don't have the specified width type. 3) Languages that will 'fault' on the overflow, maybe better in that knowing you have the problem is better than not knowing but still having the problem. 4) The very rare languages (know any besides my Verilog example) that do the operation in a type that includes looking at the destination, or automatically widens products. C, with its multitude of types gives us the ability to get around the overflow, at least when we think about it, and also allows us to be efficient when we know it won't be. The other options all seem to be a lot more computationally expensive. Yes, the programmer has to THINK, and some of the alternatives might be better by trading the programmer not needing to think by making the code slower.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-08-22 08:59 -0700 |
| Message-ID | <4a7454b6-784a-4e67-acf9-f3c37163c93en@googlegroups.com> |
| In reply to | #153865 |
On Saturday, 22 August 2020 at 15:17:01 UTC+1, Richard Damon wrote: > > I would say your 'most' is a bit inaccurate or misleading, unless you > really do mean that most languages do worst. > > The ones that do 'better' than C in this would be: > > 1) Languages with dynamic typing, where integer math automatically > converts to higher/arbitrary precision types. These get around the > problem by defining it away, there is no type like int32_t > So that's pretty much every high level language, scripting language, mathematical language. > > 2) Maybe languages with fixed typing, but integers default to a > arbitrary precision type. So again, you don't have the specified width type. > That's quite a few of the rest. Plus you can include, for practical purposes, languages where you have an "integer" type which is used in all but special circumstances. C is unusual in that it had a default integer type, "int", which was replaced by "size_t" for most places where you would use an integer. So in C, mixed mode expressions are common. > > 3) Languages that will 'fault' on the overflow, maybe better in that > knowing you have the problem is better than not knowing but still having > the problem. > That's Ada. Obviously it's not as good as handling the expression as the programmer intended, but it's better than a silent error. > > 4) The very rare languages (know any besides my Verilog example) that do > the operation in a type that includes looking at the destination, or > automatically widens products. > Rust also forbids mixed mode arithmetic. The XC applied the "widening" rule. But only in the width of "int". Which isn't guaranteed to be wide enough to index any array. > > C, with its multitude of types gives us the ability to get around the > overflow, at least when we think about it, and also allows us to be > efficient when we know it won't be. The other options all seem to be a > lot more computationally expensive. Yes, the programmer has to THINK, > and some of the alternatives might be better by trading the programmer > not needing to think by making the code slower. > If you said that an assignment statement is evaulated according to the width of its widest component, you'd make some assignment statements less efficent. But only if the width wasn't needed, or if the programmer had decided to use the free unsigned modulus rule.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-08-22 19:04 +0200 |
| Message-ID | <rhrj6r$s5d$1@dont-email.me> |
| In reply to | #153872 |
On 22/08/2020 17:59, Malcolm McLean wrote:
> On Saturday, 22 August 2020 at 15:17:01 UTC+1, Richard Damon wrote:
>>
>> I would say your 'most' is a bit inaccurate or misleading, unless you
>> really do mean that most languages do worst.
>>
>> The ones that do 'better' than C in this would be:
>>
>> 1) Languages with dynamic typing, where integer math automatically
>> converts to higher/arbitrary precision types. These get around the
>> problem by defining it away, there is no type like int32_t
>>
> So that's pretty much every high level language, scripting language,
> mathematical language.
<https://en.wikipedia.org/wiki/Comparison_of_programming_languages_(basic_instructions)#Integers>
Of course that is not a complete list of languages by any means. But it
gives a rough idea. And while there is clearly a correlation between
higher level languages having support for "big numbers", it is not
remotely as clear-cut as you seem to think. Many of the "high-level"
and "scripting" languages there have big numbers as a standard library
type in addition to fixed-size integer types that are used more generally.
>>
>> 2) Maybe languages with fixed typing, but integers default to a
>> arbitrary precision type. So again, you don't have the specified width type.
>>
> That's quite a few of the rest.
The only language I can think of that works this way is Verilog (perhaps
also MyHDL, another hardware description language), where you have fixed
sizes for vectors of bits representing hardware, and arbitrary integer
sizes for abstract numbers. Can you give other examples?
> Plus you can include, for practical purposes,
> languages where you have an "integer" type which is used in all but special
> circumstances. C is unusual in that it had a default integer type, "int", which
> was replaced by "size_t" for most places where you would use an integer.
> So in C, mixed mode expressions are common.
In general C programming, I think "int" is by far the most commonly used
type - and it has certainly not been replaced by "size_t" in "most
places". (I know you have rather peculiar ideas about what types and
integers are used for in C - let's not go through that again.)
>>
>> 3) Languages that will 'fault' on the overflow, maybe better in that
>> knowing you have the problem is better than not knowing but still having
>> the problem.
>>
> That's Ada. Obviously it's not as good as handling the expression as the
> programmer intended, but it's better than a silent error.
There are many languages that support error-detection on integer
overflow. And if you are using a language with that support, it /is/
what the programmer intended as far as the language and tools are
concerned - because that's the meaning of the code they wrote. As for
being "better" than a silent error, that depends on the needs of the
code - if the programmer never runs the code with values that overflow,
all you have done with the overflow detection is made the object code
less efficient and introduced untestable code paths.
>>
>> 4) The very rare languages (know any besides my Verilog example) that do
>> the operation in a type that includes looking at the destination, or
>> automatically widens products.
>>
> Rust also forbids mixed mode arithmetic. The XC applied the "widening" rule.
What is "the XC" ?
> But only in the width of "int". Which isn't guaranteed to be wide enough to
> index any array.
Contrary to your unique believes, integers are not used primarily to
index arrays. And "int" in C /is/ wide enough to index virtually any
array in practical programming.
>>
>> C, with its multitude of types gives us the ability to get around the
>> overflow, at least when we think about it, and also allows us to be
>> efficient when we know it won't be. The other options all seem to be a
>> lot more computationally expensive. Yes, the programmer has to THINK,
>> and some of the alternatives might be better by trading the programmer
>> not needing to think by making the code slower.
>>
> If you said that an assignment statement is evaulated according to the
> width of its widest component, you'd make some assignment statements
> less efficent. But only if the width wasn't needed, or if the programmer had
> decided to use the free unsigned modulus rule.
>
C does not have an "assignment statement".
I expect that, with a good enough optimising compiler, you would not get
significant inefficiencies with your idea in the simple examples
discussed so far. But you /would/ get them in other cases that are more
complex. And it is also not hard to construct examples where your new
ideas would result in changed behaviour in code with well defined
behaviour (assuming it is possible to generalise and implement your
ideas in a consistent way in the C language - of which I remain sceptical).
Try this in godbolt.org with -O2, so that the "test" functions give a
single result. "foo2" is the same as "foo1", but with your new "promote
values in an expression according to the usual arithmetic conversions by
considering the expression as a whole, rather than recursively by
sub-expression" rule.
float foo1(int a, int b) {
float f = a - b;
return f;
}
int foo1test(void) {
// returns 1
return foo1(1000000002, 1000000001);
}
float foo2(int a, int b) {
float f = (float) a - (float) b;
return f;
}
int foo2test(void) {
// returns 0
return foo2(1000000002, 1000000001);
}
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2020-08-22 13:59 -0400 |
| Message-ID | <y2d0H.168817$5_4.31207@fx40.iad> |
| In reply to | #153877 |
On 8/22/20 1:04 PM, David Brown wrote: > On 22/08/2020 17:59, Malcolm McLean wrote: >> On Saturday, 22 August 2020 at 15:17:01 UTC+1, Richard Damon wrote: >>> >>> I would say your 'most' is a bit inaccurate or misleading, unless you >>> really do mean that most languages do worst. >>> >>> The ones that do 'better' than C in this would be: >>> >>> 1) Languages with dynamic typing, where integer math automatically >>> converts to higher/arbitrary precision types. These get around the >>> problem by defining it away, there is no type like int32_t >>> >> So that's pretty much every high level language, scripting language, >> mathematical language. > > <https://en.wikipedia.org/wiki/Comparison_of_programming_languages_(basic_instructions)#Integers> > > Of course that is not a complete list of languages by any means. But it > gives a rough idea. And while there is clearly a correlation between > higher level languages having support for "big numbers", it is not > remotely as clear-cut as you seem to think. Many of the "high-level" > and "scripting" languages there have big numbers as a standard library > type in addition to fixed-size integer types that are used more generally. Looking at that list, only Python 3. Erlang, Mathmatica, and Wolfram meet that requirement. Many other have the 'BigNum' type, but don't go to it automatically. You have a very small idea of 'pretty much every' > >>> >>> 2) Maybe languages with fixed typing, but integers default to a >>> arbitrary precision type. So again, you don't have the specified width type. >>> >> That's quite a few of the rest. Just Haskell? (It looks like the fixed width types are the special case for it) Malcom, you seem to have a fairly skewed concept of what 'most languages' do. All these case are languages well different from C, so a competent programmer shouldn't be that surprised that C is different.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-08-22 23:01 +0200 |
| Message-ID | <rhs13j$go5$1@dont-email.me> |
| In reply to | #153881 |
On 22/08/2020 19:59, Richard Damon wrote: > On 8/22/20 1:04 PM, David Brown wrote: >> On 22/08/2020 17:59, Malcolm McLean wrote: >>> On Saturday, 22 August 2020 at 15:17:01 UTC+1, Richard Damon wrote: >>>> >>>> I would say your 'most' is a bit inaccurate or misleading, unless you >>>> really do mean that most languages do worst. >>>> >>>> The ones that do 'better' than C in this would be: >>>> >>>> 1) Languages with dynamic typing, where integer math automatically >>>> converts to higher/arbitrary precision types. These get around the >>>> problem by defining it away, there is no type like int32_t >>>> >>> So that's pretty much every high level language, scripting language, >>> mathematical language. >> >> <https://en.wikipedia.org/wiki/Comparison_of_programming_languages_(basic_instructions)#Integers> >> >> Of course that is not a complete list of languages by any means. But it >> gives a rough idea. And while there is clearly a correlation between >> higher level languages having support for "big numbers", it is not >> remotely as clear-cut as you seem to think. Many of the "high-level" >> and "scripting" languages there have big numbers as a standard library >> type in addition to fixed-size integer types that are used more generally. > > Looking at that list, only Python 3. Erlang, Mathmatica, and Wolfram > meet that requirement. Many other have the 'BigNum' type, but don't go > to it automatically. > > You have a very small idea of 'pretty much every' I believe you have mixed up the authors here a little - you replied to /my/ post, but are using "you" to refer to Malcolm. >> >>>> >>>> 2) Maybe languages with fixed typing, but integers default to a >>>> arbitrary precision type. So again, you don't have the specified width type. >>>> >>> That's quite a few of the rest. > > Just Haskell? (It looks like the fixed width types are the special case > for it) > > Malcom, you seem to have a fairly skewed concept of what 'most > languages' do. All these case are languages well different from C, so a > competent programmer shouldn't be that surprised that C is different. >
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-08-23 07:42 -0700 |
| Message-ID | <86y2m5bf0f.fsf@linuxsc.com> |
| In reply to | #153881 |
Richard Damon <Richard@Damon-Family.org> writes: > On 8/22/20 1:04 PM, David Brown wrote: > >> On 22/08/2020 17:59, Malcolm McLean wrote: >> >>> On Saturday, 22 August 2020 at 15:17:01 UTC+1, Richard Damon wrote: >>> >>>> I would say your 'most' is a bit inaccurate or misleading, unless you >>>> really do mean that most languages do worst. >>>> >>>> The ones that do 'better' than C in this would be: >>>> >>>> 1) Languages with dynamic typing, where integer math automatically >>>> converts to higher/arbitrary precision types. These get around the >>>> problem by defining it away, there is no type like int32_t >>> >>> So that's pretty much every high level language, scripting language, >>> mathematical language. >> >> <https://en.wikipedia.org/wiki/ >> Comparison_of_programming_languages_(basic_instructions)#Integers> >> >> Of course that is not a complete list of languages by any means. But it >> gives a rough idea. And while there is clearly a correlation between >> higher level languages having support for "big numbers", it is not >> remotely as clear-cut as you seem to think. Many of the "high-level" >> and "scripting" languages there have big numbers as a standard library >> type in addition to fixed-size integer types that are used more generally. > > Looking at that list, only Python 3. Erlang, Mathmatica, and Wolfram > meet that requirement. [...] You left out Smalltalk, which had automatic conversion to arbitrary precision ten years or so before the others. (The predecessor to Mathematica, SMP, may have been only a few years after Smalltalk.)
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-08-22 22:12 +0100 |
| Message-ID | <878se64c7x.fsf@bsb.me.uk> |
| In reply to | #153877 |
David Brown <david.brown@hesbynett.no> writes: > On 22/08/2020 17:59, Malcolm McLean wrote: >> On Saturday, 22 August 2020 at 15:17:01 UTC+1, Richard Damon wrote: <cut> >>> 2) Maybe languages with fixed typing, but integers default to a >>> arbitrary precision type. So again, you don't have the specified width type. >>> >> That's quite a few of the rest. > > The only language I can think of that works this way is Verilog (perhaps > also MyHDL, another hardware description language), where you have fixed > sizes for vectors of bits representing hardware, and arbitrary integer > sizes for abstract numbers. I am no longer sure what is being claimed about Velilog. The one clear suggestion that has been made about it -- that it does arithmetic in the widest type involved in a whole expression -- is, as far as I can tell, somewhat suspicious. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-08-23 13:31 +0200 |
| Message-ID | <rhtk24$8n9$1@dont-email.me> |
| In reply to | #153900 |
On 22/08/2020 23:12, Ben Bacarisse wrote: > David Brown <david.brown@hesbynett.no> writes: > >> On 22/08/2020 17:59, Malcolm McLean wrote: >>> On Saturday, 22 August 2020 at 15:17:01 UTC+1, Richard Damon wrote: > <cut> >>>> 2) Maybe languages with fixed typing, but integers default to a >>>> arbitrary precision type. So again, you don't have the specified width type. >>>> >>> That's quite a few of the rest. >> >> The only language I can think of that works this way is Verilog (perhaps >> also MyHDL, another hardware description language), where you have fixed >> sizes for vectors of bits representing hardware, and arbitrary integer >> sizes for abstract numbers. > > I am no longer sure what is being claimed about Velilog. The one clear > suggestion that has been made about it -- that it does arithmetic in the > widest type involved in a whole expression -- is, as far as I can tell, > somewhat suspicious. > First some caveats - it's perhaps 15 years since I used Verilog, and when I did it was for fairly simple work and I can't say I learned the language fully. (For the bigger programmable logic parts I did, I used a functional programming language that generated Verilog as an output.) And with the brief searching I did, I did not find any official Verilog standards to check. If Richard (or anyone else) has more experience or knowledge and can correct me, great, as what I write below is based on memory and limited understanding. Verilog is designed for writing simulators for electronic parts - but is mainly used for coding programmable logic devices, ASICs, and chips. Partly because of this, it has a mixture of concrete types that can be synthesized into hardware, and abstract types that are used more descriptively. When working with the concrete types, primarily vectors of bits, it appears that the result types are included when figuring out the types used in the expression evaluation. In effect, these are logically expanded indefinitely in the expression, and then cut off to fit the size of the result type. In comparing this with C code or most other languages, remember that these expressions are not evaluated in the same sense in Verilog programming. When you write "c = a + b", with bit vector variables, you are asking the Verilog tool to generate the hardware logic gates required for adding two vectors of bits. Verilog also supports abstract types, such as an integer type, that represents a "number" and doesn't match hardware directly. I can't remember if these have limited sizes, but the intention is that they don't overflow - since they are not used to generate the hardware, they are only used at compile time when synthesizing. (They are used at run-time for simulation.)
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-08-23 04:53 -0700 |
| Message-ID | <429742f7-9c81-47e9-87b4-85e356dbf109n@googlegroups.com> |
| In reply to | #153946 |
On Sunday, 23 August 2020 at 12:31:26 UTC+1, David Brown wrote: > > Verilog is designed for writing simulators for electronic parts - but is > mainly used for coding programmable logic devices, ASICs, and chips. > Partly because of this, it has a mixture of concrete types that can be > synthesized into hardware, and abstract types that are used more > descriptively. When working with the concrete types, primarily vectors > of bits, it appears that the result types are included when figuring out > the types used in the expression evaluation. In effect, these are > logically expanded indefinitely in the expression, and then cut off to > fit the size of the result type. > > In comparing this with C code or most other languages, remember that > these expressions are not evaluated in the same sense in Verilog > programming. When you write "c = a + b", with bit vector variables, you > are asking the Verilog tool to generate the hardware logic gates > required for adding two vectors of bits. > So if c is a 64 bit vector, and a and b are 32 bit vectors, we'd expect a language like that to produce the logic circuit for setting the high bits of c to zero, and creating the 33 bit output. Certainly if the expression was c = a * b you'd expect it to be capable of creating a widening multiplication. But it's very much a special case, thus a bad example.
[toc] | [prev] | [next] | [standalone]
Page 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web