antonyme
It's astonishing how many web designers have no idea about the difference between inclusive and mutually exclusive options.
I see checkboxes used all the time when they should be radio buttons. It's not rocket surgery. https://www.nngroup.com/articles/checkboxes-vs-radio-buttons...
Now there are certainly times when it is very valuable to do collaborate, such as rubber duck debugging https://en.wikipedia.org/wiki/Rubber_duck_debugging or mentoring or simply doing a 'desk check'. But these are the exceptions, not the rule. Having someone breathing down your neck or be a back seat driver all day is at best a waste of productivity, forcing the driver to think at the pace of the observer, and at worst, a complete waste of time and effort.
- https://dzone.com/articles/never-use-float-and-double-for-mo... - https://husobee.github.io/money/float/2016/09/23/never-use-f... - https://husobee.github.io/money/float/2016/09/23/never-use-f...
Also, I wonder what the overhead of rounding every operation is? Comparable to the cost of using a proper Decimal class?
"if you are doing some financial math that does not need to be accurate to the penny, just use floating point numbers."
I would argue that financial math by definition needs to be accurate to the penny. Where is "pretty close" financial calculations considered acceptable? Having worked at a bank, I know how seriously this sort of thing is taken.
From experience, working in scientific applications and numerical computing, summing large numbers of floats is fraught with accuracy problems too.
It's the instruction set that has been retained, not the silicon design. The variants these days are more power-efficient and powerful in terms of MIPS and peripherals, and have indeed benefited from years of R&D.
FYI the actual paper is https://ieeexplore.ieee.org/document/8425212 and you can get the PDF here: http://pdinda.org/Papers/ipdps18.pdf
I'm not suggesting we replace all our current HW with chips that implement posits (let's fix branch prediction first!!). More that FP should be opt-in for most HLLs.
LOL, sure ok. Worked on banking systems for 2 years and been doing scientific computing for many more. Pretty comfortable with fixed and floating point.
> [error bounds] Likely irrelevant for most e-commerce.
Those bounds are theoretical, and there are plenty of occasions I have come across in the past when rounding errors were observed. It was forbidden in the bank to use floating point! We went to enormous lengths to ensure numerical accuracy and stability across systems.
I think this article has a pretty good explanation:
https://dzone.com/articles/never-use-float-and-double-for-mo...
> Nonsense. If you do any scientific computation you have likely have Boost, GMP, MPFR installed in your system. They support arbitrary precision arithmetic with integer (aka fixed point), rational and floating point.
Yes, absolutely right; I have used several of those 3rd party libs myself, as well as hand-rolling fixed point code (esp for embedded systems). I didn't write what I intended. I meant to say that very few languages have first-class fixed point in their standard library. So long as the simple `float` is available as a POD, people will (mis-)use it.
I think in a general purpose HLL, a fixed decimal type should be the default, and you should have to opt in to IEEE-754 floating point.
So as far as I'm concerned, whatever performance cost these alternate methods may have, it would be well worth it to avoid the pitfalls of IEEE floats. Intel chips have had BCD support in machine code; I'm surprised nobody has made a decent fixed point lib that is widely used already.
I think a declarative DSL with scripting hooks behind it is a better model. Having used many, many build systems over the years, I've never found one I thought truly got things right (though several came close).
I actually think the ideas behind bjam ought to be revisited. It had a declarative style, with scripting to support it. The implementation was awful sadly; the tiniest mistake or typo would send the parser into a tailspin and the documentation was truly confusing. Any errors were presented to the user at the scripting level, which was even more confusing. But the idea of having toolchains defined separately, and having traits and features was brilliant. There's a lot to learn from there.
Fixed that for you.
There are many, many examples of similar (mis)features. Not sure why this particular one is getting so much attention. But yeah, if you know the history, it's not really surprising.
For anyone interested in this sort of software archeology, have a look at Raymond Chen's blog https://blogs.msdn.microsoft.com/oldnewthing/ which is full of this stuff. Very interesting reading.
How much would it cost for developers to do all this themselves? Every single individual developer? People seem to forget what things were like before the App Store.
Now one could question the percentage itself, and ask if it is a reasonable number, but when you consider the time and effort and investment that would otherwise be required,
A while back, I implemented VU meters for some professional AV software. I started with the available references, but quickly discovered that it was well-intentioned but incorrect/inaccurate. I ended up sourcing the original specification for the analog meters, and then devising digital filters to replicate the same ballistics. This matched perfectly with the reference, (pro hardware).
TL;DR don't believe what you read on the web. Go to primary sources!
We would have a different spin on Batterygate where Apple is greedily telling people to replace their batteries when they allegedly still work just fine, because all they care about is selling more batteries and making more profit.
It's surprising to see its return after a long hiatus, as Aibo has had several ups and downs in the market. And despite such a long period when it could have been enhanced, it looks like it is not significantly changed from the last generation.
https://www.youtube.com/watch?v=ZaVo-OffZD8There are many more, but these are more viable alternatives to auto tools.
https://en.wikipedia.org/wiki/List_of_build_automation_softw...
As for CPython extensions, I can relate also. Though the cffi makes some of it redundant, and Boost::Python is brilliant for wrapping C++ projects.
It is easier now than ever before to port code between the major platforms, and especially with frameworks such as Qt.
It's not perfect, but it most closely matches the workflow I need. It's flexible without being overly generic (Trello) yet doesn't impose or constrain your workflow too much as some other tools do.
There certainly are some quirks though, and my biggest peeve is the 'empty task' problem described in the original article. If I could vote for one fix, it would be that!
I encourage everyone to support high quality indy projects like this.
Take a document written in the word processor du jour 20 years ago. It is highly unlikely you could mount the physical media, let alone import the data with high fidelity. But plain text can be read by just about any tool, whereas binary/proprietary formats are limited by the longevity of the hardware/software that created them.