- rational numbers - 23 Updates
| Juha Nieminen <nospam@thanks.invalid>: Sep 17 05:36AM > printDescription() // prints a description of the number and its > // numerical value This is not really something that belongs to a class that behaves like an arithmetic numerical value. At most what you could have is a separate std::ostream& operator<<(std::ostream&, YourRationalClass); function for outputting the value to a std::ostream. |
| Christian Gollwitzer <auriocus@gmx.de>: Sep 17 09:21AM +0200 Am 16.09.21 um 19:05 schrieb Scott Lurndal: > for numerical software nowadays. It's really hard to get it > right when using binary floating point, hence standard numerical > libraries (LINPACK, et alia). I am a scientist, and Matlab and R are popular, but slowly they give way to Python. With the "numpy" package wrapping LAPACK and "scipy", which is based on it, Python code almost looks like Matlab, but it's completely open source. To my understanding, that and the machine learning libs are the reasons why Python gained so much in the last years. The language on its own is not that much better than other modern scripting languages, it's the libraries with a large user base. Christian |
| alessandro volturno <alessandro.volturno@libero.it>: Sep 17 09:50AM +0200 Il 16/09/2021 22:12, Paavo Helde ha scritto: > have to admit I also wrote a C++ class for rational numbers ca 20 years > ago, but so far I have not found any usage for it in my work (which also > involves a lot of heavy numeric computations). I am not a mathematician nor a physicist but probably solving systems of linear equations with Gauss or Gauss-Jordan methods can be an application of rational numbers. Many years ago trying to use the Common lisp programming language, I was impressed by its natural handling of rational numbers and by its use of integers or floating point numbers of arbitrary precision. Common Lisp is an ANSI standard dated 1990 but it inherits properties and behaviours from ancient LISP dialects. So it seemed to me a bit strange that a programming language as widespread as C++ doesn't offer that same facilities. > already contains measurement inaccuracies. Thus the end result will not > be absolutely accurate anyway, so there is no need to use absolutely > precise computations. there are not only physical measures, you could develop examples with integer numbers just for didactic goals. C++ must be learned like any other discipline. And having wide numerical facilities can be very useful permitting to develop new strategies by tackling numerical problems in a different way. I'm sorry for my general argumentation and lack of practical examples, but as I had already written, I do program just for fun. > [...] And talking about features offered by a programming language, there is just another addition that could help developing large applications or bigger projects, and that is 2d and GUI facilities. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0267r10.pdf Thank you again for the opportunity of this discussion. alessandro |
| alessandro volturno <alessandro.volturno@libero.it>: Sep 17 09:55AM +0200 Il 17/09/2021 07:36, Juha Nieminen ha scritto: > At most what you could have is a separate > std::ostream& operator<<(std::ostream&, YourRationalClass); > function for outputting the value to a std::ostream. if you read the two lines right before the one here reported you can see I did that. I wrote that function to give an extensive description of a rational number in a way like this: "4/16 reduces to 1/4 and evaluates to 0.25" thank you, alessandro |
| David Brown <david.brown@hesbynett.no>: Sep 17 10:34AM +0200 On 17/09/2021 09:21, Christian Gollwitzer wrote: > learning libs are the reasons why Python gained so much in the last > years. The language on its own is not that much better than other modern > scripting languages, it's the libraries with a large user base. Python might not be much better than Matlab as a language for the numerical bits (I haven't done Matlab programming to compare), but as a general purpose language it is vastly more powerful for everything else than highly specialised and consequently limited tools like Matlab. All the extra capabilities from Python, such sending emails when your calculations are done, interacting with databases, generating pdf reports from the results, etc., are going to make it a lot more attractive if it can handle the maths you need. |
| David Brown <david.brown@hesbynett.no>: Sep 17 11:15AM +0200 On 17/09/2021 09:50, alessandro volturno wrote: > I am not a mathematician nor a physicist but probably solving systems of > linear equations with Gauss or Gauss-Jordan methods can be an > application of rational numbers. You will quickly get meaninglessly big numbers if you use rationals for that kind of thing. Calculations with rationals usually only makes sense for pure mathematics and number theory, not applied mathematics or physics. > from ancient LISP dialects. So it seemed to me a bit strange that a > programming language as widespread as C++ doesn't offer that same > facilities. C++ arithmetic aims for efficiency, predictability, and fixed sizes. Fixed size rationals are of quite limited use - you can't do much arithmetic on them before the sizes overflow. As I mentioned earlier, there is a lot of fun and learning from making classes to support these, but little practical use - therefore no point in having them in the standard library. (The C++ standard library has support for compile-time rational arithmetic, mainly as a convenient way to handle magnitudes of SI units.) So for useful rationals, you need arbitrary precision integers. And that is a whole different ballgame from fixed sizes - you are now talking about memory management, big complicated algorithms, and all sorts of trade-offs in the implementation. For some languages, it's okay to pick one "reasonable" implementation. It might be big and incorporate a range of algorithms for different sizes - that's fine for a language like Python that already has huge libraries. It might be small and simple, and do a reasonable job for smaller sizes but be less optimal for huge values - that made sense for Bart in his language. For C++, it's a /lot/ harder to decide what to do for the standard library, as C++ programmers have such different needs. Someone who just wants to do arithmetic up to 4K bits for cryptography will not want the cost to support megabit sizes. Someone who needs a lot of decimal I/O might want a base-10 model rather than a base-2 model. People with particular processors might want a model optimised for the SIMD instructions they have, though it might be much less efficient on other processors. C++ does not try to put /everything/ a programmer might need into its standard library - it aims to have the tools and basics there, so that others can make libraries as needed. That's the case here. > other discipline. And having wide numerical facilities can be very > useful permitting to develop new strategies by tackling numerical > problems in a different way. I agree with those aims. And a C++ standard library for rational numbers would be completely against that aim - how could you learn about making good classes and abstractions using rational numbers if the library already supported them? Make it yourself - that's how you will learn. > just another addition that could help developing large applications or > bigger projects, and that is 2d and GUI facilities. > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0267r10.pdf The proposal for adding gui facilities to the C++ standard is /highly/ controversial. Some people think it would be nice to have in the standard because "everyone" needs graphics and a gui. Others think it is a terrible idea because there are several dozen popular gui libraries, with wildly varying pros and cons, and making a "standard C++ gui library" would be as bad an idea as a country's roads department picking a standard car. |
| Ian Collins <ian-news@hotmail.com>: Sep 17 10:07PM +1200 On 17/09/2021 19:21, Christian Gollwitzer wrote: > learning libs are the reasons why Python gained so much in the last > years. The language on its own is not that much better than other modern > scripting languages, it's the libraries with a large user base. Matlab does have one advantage (at least in our environment); it can convert models into C++ code! -- Ian. |
| Juha Nieminen <nospam@thanks.invalid>: Sep 17 11:16AM > I wrote that function to give an extensive description of a rational > number in a way like this: > "4/16 reduces to 1/4 and evaluates to 0.25" I still think that designwise such a function does not belong in that class. Sure, nobody is stopping you from adding such functions to your class, if and when you want to use just in your own small projects, but generally, when designing such classes for general use for a wider audience and a wider set of applications, that's just not something that logically belongs to such a class. A class that behaves like a numerical value shouldn't itself print anything, because that doesn't make much logical sense. You could have separate functions that do that, but they don't belong as members of the class. Even when you do implement something like an operator<<(std::ostream&) for the class, its output should just be an ascii representation of the number itself, and nothing else. If you want to provide such printing functions for convenience, you could implement them as separate functions (maybe even declared in their own separate header file). Note, however, that you will be fixing the format (and language) of such messages, which is one of the reasons why it's not something you usually want to do. Let the user of the class decide how such things are printed, rather than the library forcing a particular format (and language). (After all, it's not such a huge amount of work to write a simple printing line which uses values from the instance of the class.) |
| David Brown <david.brown@hesbynett.no>: Sep 17 01:32PM +0200 On 17/09/2021 12:07, Ian Collins wrote: >> scripting languages, it's the libraries with a large user base. > Matlab does have one advantage (at least in our environment); it can > convert models into C++ code! A few times in the past, I've seen C code generated by Matlab, produced by researchers who then wanted the whole think running in a little microcontroller. The generated code was utterly hideous - vastly over-complex, and ridiculous inefficiencies (malloc allocation for things that should be local stack variables, multiplying integers by 0.5 instead of dividing by 2, using strings and strcmp() instead of enums, etc.). But perhaps it was the user rather than the software that was at fault - it's not a tool I use myself. I just know that for use on a small microcontroller, I'd rather hand-translate some well-written Python than clear up the vomit that Matlab produced. |
| Christian Gollwitzer <auriocus@gmx.de>: Sep 17 03:55PM +0200 Am 17.09.21 um 10:34 schrieb David Brown: > numerical bits (I haven't done Matlab programming to compare), but as a > general purpose language it is vastly more powerful for everything else > than highly specialised and consequently limited tools like Matlab. I agree, and maybe I wasn't clearly expressing myself. Matlab has a little edge if one does linear algebra stuff. There are some weird extra parentheses in numpy sometimes (e.g. numpy.zeros((3,4)) vs zeros(3,4) in Matlab), numpy does not distinguish row and column vectors and therefore leads to more cumbersome code for matrix multiplications, and literals also look cleaner in Matlab. In addition, the documentation of Matlab and the toolboxes is really high standard, commercial quality and well maintained whereas in Scipy you can often see that it is more of a "hobbyist" thing. But these are minor disadvantages of Python that are a bit annoying in interactive use like Jupyter notebooks and not real show-stoppers. > calculations are done, interacting with databases, generating pdf > reports from the results, etc., are going to make it a lot more > attractive if it can handle the maths you need. OTOH, Matlab is a terrible general purpose language. They have bolted on to that matrix language everything, you *can* use object orientation, general I/O, GUIs and also send emails https://www.mathworks.com/help/matlab/import_export/sending-email.html connect databases https://www.mathworks.com/help/database/ug/odbc.html and create PDFs https://www.mathworks.com/help/rptgen/ug/create-an-html-or-pdf-template.html but it often looks quirky and not like a language I would want to write a larger program in. Python was constructed as a sane language to begin with, but so have been Lua, Julia, Ruby, Kotlin, and surely dozens of others. Why Python has become the Nr#1? I suspect that as soon as scientists picked it up with numpy it grew as an alternative to the de-facto standard Matlab simply because it was free. And then the machine learning guys really boosted it to a point where it couldn't be ignored any longer. The same happened years ago with Tcl. Python and Tcl are almost the same age. Due to Tk, which allowed non-guru-level programmers to make simple GUIs and the adoption of the circuit CAD industry, Tcl became the de-facto scripting standard for many years. The decline came with the stall of development (Sun pulled the money out) and the main focus has shifted away from desktop GUI and circuit board designers. Now it's Python that everyone uses and recommends. Christian |
| scott@slp53.sl.home (Scott Lurndal): Sep 17 02:03PM >At most what you could have is a separate > std::ostream& operator<<(std::ostream&, YourRationalClass); >function for outputting the value to a std::ostream. I could rant for hours on the unsuitability of the silly C++ output stream crap in real applications. But I've got too much on my plate right now. Much of which is making performance improvements to a large CPU-bound C++ application; primarily by getting rid of all outputstringstream crap (replacing with snprintf) and eliminating most trivial run-time (vs. startup time) uses of std::string. void a(void) { std::string fred = "this is a test"; printf("%s", fred.c_str()); } 0000000000400970 <a()>: 400970: 53 push %rbx 400971: be 50 0b 40 00 mov $0x400b50,%esi 400976: 48 83 ec 20 sub $0x20,%rsp 40097a: 48 8d 7c 24 10 lea 0x10(%rsp),%rdi 40097f: 48 8d 54 24 0f lea 0xf(%rsp),%rdx 400984: e8 97 fe ff ff callq 400820 <std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&)@plt> 400989: 48 8b 74 24 10 mov 0x10(%rsp),%rsi 40098e: bf 5f 0b 40 00 mov $0x400b5f,%edi 400993: 31 c0 xor %eax,%eax 400995: e8 36 fe ff ff callq 4007d0 <printf@plt> 40099a: 48 8b 44 24 10 mov 0x10(%rsp),%rax 40099f: 48 8d 78 e8 lea -0x18(%rax),%rdi 4009a3: 48 81 ff 80 10 60 00 cmp $0x601080,%rdi 4009aa: 75 06 jne 4009b2 <a()+0x42> 4009ac: 48 83 c4 20 add $0x20,%rsp 4009b0: 5b pop %rbx 4009b1: c3 retq 4009b2: b9 00 00 00 00 mov $0x0,%ecx 4009b7: 48 8d 57 10 lea 0x10(%rdi),%rdx 4009bb: 48 85 c9 test %rcx,%rcx 4009be: 74 35 je 4009f5 <a()+0x85> 4009c0: 83 c8 ff or $0xffffffff,%eax 4009c3: f0 0f c1 02 lock xadd %eax,(%rdx) 4009c7: 85 c0 test %eax,%eax 4009c9: 7f e1 jg 4009ac <a()+0x3c> 4009cb: 48 8d 74 24 0f lea 0xf(%rsp),%rsi 4009d0: e8 3b fe ff ff callq 400810 <std::string::_Rep::_M_destroy(std::allocator<char> const&)@plt> 4009d5: eb d5 jmp 4009ac <a()+0x3c> 4009d7: 48 89 c3 mov %rax,%rbx 4009da: 48 8b 44 24 10 mov 0x10(%rsp),%rax 4009df: 48 8d 74 24 0f lea 0xf(%rsp),%rsi 4009e4: 48 8d 78 e8 lea -0x18(%rax),%rdi 4009e8: e8 03 fe ff ff callq 4007f0 <std::string::_Rep::_M_dispose(std::allocator<char> const&)@plt> 4009ed: 48 89 df mov %rbx,%rdi 4009f0: e8 5b fe ff ff callq 400850 <_Unwind_Resume@plt> 4009f5: 8b 50 f8 mov -0x8(%rax),%edx 4009f8: 8d 4a ff lea -0x1(%rdx),%ecx 4009fb: 89 48 f8 mov %ecx,-0x8(%rax) 4009fe: 89 d0 mov %edx,%eax 400a00: eb c5 jmp 4009c7 <a()+0x57> 400a02: 66 66 66 66 66 2e 0f data32 data32 data32 data32 nopw %cs:0x0(%rax,%rax,1) 400a09: 1f 84 00 00 00 00 00 (and that's _with_ -O3). |
| scott@slp53.sl.home (Scott Lurndal): Sep 17 02:06PM >> scripting languages, it's the libraries with a large user base. >Matlab does have one advantage (at least in our environment); it can >convert models into C++ code! One of my colleagues wrote a tool (verilator) to convert Verilog into C++ code. Quite useful. https://en.wikipedia.org/wiki/Verilator |
| Christian Gollwitzer <auriocus@gmx.de>: Sep 17 05:12PM +0200 Am 17.09.21 um 16:03 schrieb Scott Lurndal: > printf("%s", fred.c_str()); > } > [...long assembly...] Wow, thats an awful lot of code. Does it improve if you do const std::string or constexpr or the like? Christian |
| Christian Gollwitzer <auriocus@gmx.de>: Sep 17 05:16PM +0200 Am 17.09.21 um 17:12 schrieb Christian Gollwitzer: > Wow, thats an awful lot of code. Does it improve if you do const > std::string or constexpr or the like? > Christian Quick test on compiler explorer shows a much more reasonable code: https://godbolt.org/z/5MzscK95W with gcc 11. Christian |
| David Brown <david.brown@hesbynett.no>: Sep 17 05:49PM +0200 On 17/09/2021 15:55, Christian Gollwitzer wrote: > with numpy it grew as an alternative to the de-facto standard Matlab > simply because it was free. And then the machine learning guys really > boosted it to a point where it couldn't be ignored any longer. Lua, Julia, Ruby, etc., are also free. But Python was there first, and I think momentum has a lot to do with it. It's also a higher level language than, say, Lua, and while there are some mixed opinions on some aspects of Python's syntax, it is generally regarded as a easier to read, write and learn than Ruby and many alternatives. > stall of development (Sun pulled the money out) and the main focus has > shifted away from desktop GUI and circuit board designers. Now it's > Python that everyone uses and recommends. Tcl is okay as a "tool control language", but it is far too weak for more advanced work. Python was considered too "heavy" for simple scripting in many areas - but as everything else (disks, memory, cpus, etc.) has got bigger, the relative cost of Python has dropped. |
| Christian Gollwitzer <auriocus@gmx.de>: Sep 17 06:22PM +0200 Am 17.09.21 um 17:49 schrieb David Brown: > On 17/09/2021 15:55, Christian Gollwitzer wrote: > Tcl is okay as a "tool control language", but it is far too weak for > more advanced work. To be fair, one must say "has been". Tcl has improved since the days back then and acquired many modern things like coroutines, built-in object orientation etc. but the development went on a very slow path after the support from Sun was dropped. I'm one of the inhabitants of a small Gallic village ;) this is one of my projects realized in modern Tcl: https://github.com/BessyHDFViewer/BessyHDFViewer But the world has moved on, and now I'm recommending Pyton to everyone who needs a programming language as the first pick. C++ comes second, if speed is required or special hardware control etc. Of course, as a scientist my environment is data analysis and lab hardware control. On embedded devices the ranking would be different. Christian |
| alessandro volturno <alessandro.volturno@libero.it>: Sep 17 06:33PM +0200 Il 17/09/2021 13:16, Juha Nieminen ha scritto: > I still think that designwise such a function does not belong in that class. You are right, but the project started as a game and it is not intentended to leave my PC :-) > anything, because that doesn't make much logical sense. You could have > separate functions that do that, but they don't belong as members of > the class. you were perfectly clear, thank you for that. alessandro |
| Manfred <noname@add.invalid>: Sep 17 06:59PM +0200 On 9/17/2021 5:16 PM, Christian Gollwitzer wrote: > https://godbolt.org/z/5MzscK95W > with gcc 11. > Christian Still, Feeding a C string to a std::string to be fed to printf() /is/ masochism (or sadism, depending on which side you are on). |
| scott@slp53.sl.home (Scott Lurndal): Sep 17 05:13PM >Still, >Feeding a C string to a std::string to be fed to printf() /is/ masochism >(or sadism, depending on which side you are on). One quite often runs across C++ purists (or new grads) who falsly eschew C constructs as "not C++". Unfortunately, we need to support GCC4 through GCC11 efficiently. |
| alessandro volturno <alessandro.volturno@libero.it>: Sep 17 07:19PM +0200 Il 17/09/2021 11:15, David Brown ha scritto: > that kind of thing. Calculations with rationals usually only makes > sense for pure mathematics and number theory, not applied mathematics or > physics. A tool is crafted for a certain scope, you could but don't want to peel an apple with a cutter. If a tool is present in a computer language's library that doesn't mean every one has ever to use it. > C++ arithmetic aims for efficiency, predictability, and fixed sizes. > Fixed size rationals are of quite limited use - you can't do much > arithmetic on them before the sizes overflow. 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. > particular processors might want a model optimised for the SIMD > instructions they have, though it might be much less efficient on other > processors. If something is in the standard library that doesn't mean everyone has to use it. Your argument is valid if it were made a built in facility, but in Common Lisp you have the usual fixed sized numerical types as well as the wider and heavier ratios or numbers of arbitrary precision. it's at your discretion use those things or not. > C++ does not try to put /everything/ a programmer might need into its > standard library - it aims to have the tools and basics there, so that > others can make libraries as needed. That's the case here. Libraries are a bless, but there are so many of them all around you get confused, and one has to spend many weeks studying one of them to obtain something you could do inside your favourite programming language. I have written, some years ago, a silly game in C++, quite similar to Amiga's Colors. The platform used to develop it was linux. and well, to paint on the screen I had to use an external library (Allegro 4). Another toy program that I wrote uses FLTK's GUI facility. If I had the opportunity of a graphics library inside C++, my program could just be recompiled on Windows to work, without having to compile the library using tools like cygwin to make it working in Windows. >>> the calculation results are always exact. However, in numeric >>> 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 >> problems in a different way. > I agree with those aims. And a C++ standard library for rational > numbers would be completely against that aim Why? - how could you learn about > making good classes and abstractions using rational numbers if the > library already supported them? Make it yourself - that's how you will > learn. You could just try to reinvent the wheel, thinking about how it could be implemented. But that doesn't mean having rationals in the language hinder you to mimic its functionality. Thank you, alessandro |
| Ian Collins <ian-news@hotmail.com>: Sep 18 09:15AM +1200 On 17/09/2021 23:32, David Brown wrote: > fault - it's not a tool I use myself. I just know that for use on a > small microcontroller, I'd rather hand-translate some well-written > Python than clear up the vomit that Matlab produced. The generated code isn't great, but with a little care in the model, it isn't too bad either. I liken the process to the hand optimisations we used to do in C to get the best from 80's vintage compilers! -- Ian. |
| Ian Collins <ian-news@hotmail.com>: Sep 18 09:34AM +1200 On 18/09/2021 02:03, Scott Lurndal wrote: > 400a02: 66 66 66 66 66 2e 0f data32 data32 data32 data32 nopw %cs:0x0(%rax,%rax,1) > 400a09: 1f 84 00 00 00 00 00 > (and that's _with_ -O3). Maybe a better compiler would help? With clang++ and -O2: _Z1av: # @_Z1av .cfi_startproc # %bb.0: pushq %rbx .cfi_def_cfa_offset 16 subq $32, %rsp .cfi_def_cfa_offset 48 .cfi_offset %rbx, -16 leaq 16(%rsp), %rbx movq %rbx, (%rsp) movabsq $2338328219631577204, %rax # imm = 0x2073692073696874 movq %rax, 16(%rsp) movabsq $8391162080155213939, %rax # imm = 0x7473657420612073 movq %rax, 22(%rsp) movq $14, 8(%rsp) movb $0, 30(%rsp) movl $.L.str.1, %edi movq %rbx, %rsi xorl %eax, %eax callq printf movq (%rsp), %rdi cmpq %rbx, %rdi je .LBB0_2 # %bb.1: callq _ZdlPv .LBB0_2: addq $32, %rsp .cfi_def_cfa_offset 16 popq %rbx .cfi_def_cfa_offset 8 retq -- Ian. |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Sep 17 07:00PM -0400 On 9/17/21 1:19 PM, alessandro volturno wrote: > Il 17/09/2021 11:15, David Brown ha scritto: ... >>>> 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 Yes, but exactly rational numbers that are an accurate reflection of something in reality remain rare in all of the sciences. |
| 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