- rational numbers - 9 Updates
| David Brown <david.brown@hesbynett.no>: Sep 18 11:39AM +0200 On 17/09/2021 19:19, alessandro volturno wrote: > This is my personal opinion: C's and C++'s search for efficiency is > probably one of the cause that made other computer scientists develop > newer or more complete and easy to use computer languages. Yes - and that's a good thing. There are all kinds of programming tasks, and all kinds of programmers - there needs to be a variety of programming languages. C++ should not become Python or Lisp any more than Python should become Lua or Lisp should become Fortran. >>>> programming the input data often comes from a physical measurement, >>>> meaning that it already contains measurement inaccuracies. > Physics is not the only Science out there You were the one that brought up physics ("I am not a mathematician or a physicist"). /All/ sciences - to be worthy of the name "science" - involve measurements of real things. Almost always, these are inexact measurements, with the exceptions being relatively small whole number counts. Rational numbers turn up very rarely in science of any kind. Probably the only science in which they /do/ turn up is quantum mechanics in physics, and even there we are talking about small and specific values (half-integer spin, third or two-third charges on quarks, that kind of thing). Rational arithmetic does not really turn up anywhere outside pure mathematics and certain direct applications (such as in cryptography). |
| alessandro volturno <alessandro.volturno@libero.it>: Sep 18 11:56AM +0200 Il 18/09/2021 11:39, David Brown ha scritto: > quarks, that kind of thing). > Rational arithmetic does not really turn up anywhere outside pure > mathematics and certain direct applications (such as in cryptography). But as you say, can have some advantage from them. Anyway I now have a clear picture of the scenario about rational numbers and C++ standard. I can consider the question closed. Thank you to all who took part in this thread. alessandro |
| David Brown <david.brown@hesbynett.no>: Sep 18 12:00PM +0200 On 17/09/2021 23:34, Ian Collins wrote: >> } >> (and that's _with_ -O3). > Maybe a better compiler would help? With clang++ and -O2: Or pretty much any version of gcc with -O2, at least according to my tests on <https://godbolt.org> Maybe Scott has unusual options, or an unusual library, or other surrounding code that affects the results. There are plenty of reasons to dislike C++ output streams (for me, it is the moronic design decision of stateful formatting flags that are the big problem). The quality of code generated for a weird mixture of C-style and C++-style, for an operation that is always big and slow, is not such a concern. |
| Bart <bc@freeuk.com>: Sep 18 11:01AM +0100 On 18/09/2021 10:39, David Brown wrote: > quarks, that kind of thing). > Rational arithmetic does not really turn up anywhere outside pure > mathematics and certain direct applications (such as in cryptography). So where does big integer arithemetic turn up? With big integers, I can see that sometimes you want (A/B)*B to result in A. With integer divide, that might not be the case. Using floating point divide with finite precision, you can lose information (and perversely end up with too much useless precision; if I do (1/3)*3, with 100M digits, I get 100M digits of 0.9999....). Letting A/B (perhaps with a special divide op) yield a rational type would work. In that case, I can see this being of value with i64 and i128 types too, for the two parts of a rational number. |
| scott@slp53.sl.home (Scott Lurndal): Sep 18 02:54PM >tests on <https://godbolt.org> >Maybe Scott has unusual options, or an unusual library, or other >surrounding code that affects the results. $ gcc --version gcc (GCC) 4.8.3 20140911 (Red Hat 4.8.3-7) Copyright (C) 2013 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. It's what I had on the system I was posting from, and the code was an illustrative example, not from our proprietary production code. >There are plenty of reasons to dislike C++ output streams (for me, it is >the moronic design decision of stateful formatting flags that are the >big problem). Indeed, and they're completely unreadable. > The quality of code generated for a weird mixture of >C-style and C++-style, for an operation that is always big and slow, is >not such a concern. snprintf makes a single pass over the formatting string. It's a single function call. output string streams (the "C++" way) has multiple function calls and generates a shitload of code. And is much less readable and not as maintainable. The arguments about mismatched format types is obviated by all modern compilers warning for the *printf family arguments. Custom classes can use 'to_string' functions rather than overloading the << operator. Performance _does_ matter in some applications - ours can eat a 24-core system for lunch, so every cycle matters; especially when the customer complains about performance (but then our application simulates a full SoC - sufficient to boot multicore linux and run packet processing application stacks (e.g DPDK) on the simulator prior to hardware availability). |
| Bart <bc@freeuk.com>: Sep 18 05:36PM +0100 On 18/09/2021 15:54, Scott Lurndal wrote: > not as maintainable. The arguments about mismatched format > types is obviated by all modern compilers warning for the *printf > family arguments. Both approaches are terrible in my opinion: C++: std::cout << "A=" << a << " B=" << b << " C=" << c << std::endl; C: printf("A=%d B=%f C=%s\n", a, b, c); Compared with the equivalent in any of my languages: M: println =a, =b, =c The C++ just looks dreadful (and I keep forgetting the << or writing commas instead). The C has the big problem of needing to tell the compiler the types of the expressions you're printing, something it already knows perfectly well, since it can warn you when they're wrong! You might not even know yourself, with a complex expression, or one involving opaque types. And they need maintenance as code changes. My approach is to have print directly supported by the language. It can map your code to a series of function calls or, at one time when I transpiled to C, into a single synthesised printf call. Or, possibly you can use a feature such as this in my C compiler: C (bcc): printf("%=? %=? %=?\n", a, b, c); where it fills in the format codes. Note the the C example above is ONLY valid when a has an int type, b is double or float, and c is char*, otherwise those need adjusting. If I reverse the order in my C version: printf("%=? %=? %=?\n", c, b, a); It still works fine. If I try the same in the standard C version, without fixing the formats, it crashes. gcc might warn, /if/ you specify -Wformat. And then you still need to fix it. > simulates a full SoC - sufficient to boot multicore linux and run packet > processing application stacks (e.g DPDK) on the simulator prior > to hardware availability). You don't want to make the emulation too good or people won't buy the hardware... |
| Christian Gollwitzer <auriocus@gmx.de>: Sep 18 11:29PM +0200 Am 18.09.21 um 18:36 schrieb Bart: > M: println =a, =b, =c > The C++ just looks dreadful (and I keep forgetting the << or writing > commas instead). There is widespread support for this in other languages; e.g. Python3: Python 3.8.8 (default, Apr 13 2021, 12:59:45) [Clang 10.0.0 ] :: Anaconda, Inc. on darwin Type "help", "copyright", "credits" or "license" for more information. >>> a=3;b=4;c='Hallo' >>> print(f'a={a} b={b} c={c}') a=3 b=4 c=Hallo Tcl: (base) Apfelkiste:Sources chris$ wish86 % set a 3; set b 4; set c Hallo Hallo % puts "a=$a b=$b c=$c" a=3 b=4 c=Hallo % > My approach is to have print directly supported by the language. It can > map your code to a series of function calls or, at one time when I > transpiled to C, into a single synthesised printf call. In the other languages as demonstrated above, it is not a special "print" function but rather a way to build strings; you can feed it to any function or assign it to a variable, not just print it. And so it is much more useful; consider e.g. constructing file names >>> f'input_{a:03}.png' 'input_003.png' ...and, surprise: Christian |
| scott@slp53.sl.home (Scott Lurndal): Sep 18 10:48PM >> snprintf makes a single pass over the formatting string. It's a single >> function call. >C: printf("A=%d B=%f C=%s\n", a, b, c); A trivially useless format string. Try adding field widths and re-ordering the arguments within the format string for i18n/l10n purposes. |
| Ian Collins <ian-news@hotmail.com>: Sep 19 11:03AM +1200 On 19/09/2021 02:54, Scott Lurndal wrote: > It's what I had on the system I was posting from, and the code > was an illustrative example, not from our proprietary production > code. But you still used it to back up an exaggerated claim regarding the performance of std::string! If you are using such an old compiler for production code, you have made a rod for your own back. >> the moronic design decision of stateful formatting flags that are the >> big problem). > Indeed, and they're completely unreadable. Until you need to stream non-trivial objects, or anything in a template... > function call. > output string streams (the "C++" way) has multiple function calls and > generates a shitload of code. This is certainly true. -- Ian |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment