Path: csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Ian Collins Newsgroups: comp.lang.c++ Subject: Re: rational numbers Date: Sat, 18 Sep 2021 09:15:22 +1200 Lines: 40 Message-ID: References: <3PK0J.78848$g81.78219@fx33.iad> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: individual.net Lg1XNvwE9qT5IckbWJhcQAKw6/Rtg1UtI+A7Cik5+ezmy/xRoN Cancel-Lock: sha1:vaKFkjHecwRt1aiYUXGDZ8Z4ZyY= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 In-Reply-To: Content-Language: en-US Xref: csiph.com comp.lang.c++:81303 On 17/09/2021 23:32, David Brown wrote: > On 17/09/2021 12:07, Ian Collins wrote: >> On 17/09/2021 19:21, Christian Gollwitzer wrote: >>> >>> Am 16.09.21 um 19:05 schrieb Scott Lurndal: >>>> I suspect that the vast majority of people use existing >>>> software packages like Matlab or R (for statistics) than write C++ code >>>> 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. >> >> 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. 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.