Agreed that Berkeley hashtag activists and white male professional victims can both suck it, but you should consider that what you have written above is a classic example of 'the subtle racism of lowered expectations'. The idea that rhetoric should be translated to be more 'street' or something to resonate / show solidarity with minorities is patronizing, actually doing it is doubly so. It is not for the 'educated' group to translate rhetoric for the 'minority' group - that is what the 'educated minority' group is for. In the meantime, it does not tarnish the messages of the 'educated white' group that they sound like a bunch of poindexters - it just means that they cannot lay any claim to the righteousness of the oppressed.

It's funny to me that none of us lefty 'cucks' knew what the hell you guys were talking about when you first started slinging this word around. Something that's apparently been on the collective mind of the alt-right so much that they managed to coin a term and start hurling it about without ever giving thought to the hilarious projection of insecurities it exposes. Don't worry, I'm sure all of your wife's bruises will keep her under the radar of those super scary mandingos checking out her backpages ad.

He said that real professionals will buy what is right for them, not what brand that is.

You shilled a brand then insulted everybody not using it because you think they are insulting you not the brand. Critical thinking fail.

I don't know, man. I am completely on-board with improving the quality of discourse, but the comment to which you refer is a classic shit sandwich (two compliments book-ending a steaming turd of patronizing criticism). It's a particularly condescending and pedantic shit sandwich at that, coming from a guy who seems to fancy himself the Strunk and/or White of the internet. Personally, I find this kind of patronizing attitude even more offensive than an aggressive or insulting one.

The context in this case is that you used the word explicitly because you knew it would be interpreted in that way, so the filter and/or reviewer would in fact be correct. You are not British, and it is not a part of your standard lexicon. 'Context' involves the presence of subtlety, and there is none to be had here.

Sailing right past the slur, really the most offensive part of this is just the fact that you thought it was somehow clever or funny. Oh no I get it, you were doing 'research'. I look forward to your thesis on the blatantly obvious effects of being an infantile twat online.

No, they don't. They purchase my framework for the express purpose of not doing what you just said. Values are handled end-to-end by the framework with no floating point operations - this is why they buy it. You don't seem to understand that what I'm telling you is based off the real world, delivering real software to real customers for real money. But that's all just smug lies apparently, because you have some opinions on 'accountants'.

Oh shit, I guess we've got a couple million dollars in refunds to issue then. I better tell the CFO.

Sure, one incorrect approach in many cases does better than another incorrect approach. Or, you could do it correctly using the standards which are required in any reasonably serious financial application.

BigDecimal is not a data type, it is an API (containing 'numerical algorithms'), and it is no more superior to machine floating point numbers than a hammer is to an oxygen atom. If the use case is financial however, then yes BigDecimal is unquestionably superior unless you are comparing it to another arbitrary precision API like JScience (which I do like better).

As I explained above, I think you have these concepts muddled up so I'm not even sure what you think 'the latter' is, But if it was somebody trying to tell you that BigDecimal retains accuracy better than floating point, then that was 'correctness' not 'smugness'. Well, maybe it was both.

There, I fixed his poorly worded statement. Now you are definitely wrong.

a) We are talking about decimals so nice try with your integer example

b) If something is potentially inaccurate, it is functionally inaccurate

c) Are you seriously not aware of what binary approximation is, and the fact that numbers as 'simple' as .1 have no exact binary representation?

Your ignorance is a time bomb waiting to go off.

Nope. The last 5 or so years I've been delivering a math processing framework for various use cases that supports everything ranging from machine-precision floating point operations to rational/exponent representation numbers and intra-operational accuracy specifications. Scientists and EE guys always go for floating point, max 4 decimals precision. Accountants always go for arbitrary precision with accuracy settings twice as far out as precision and decimals only ever actually evaluated when they are to be presented to a human.

Wrong on both counts. The only 'correct' representation of 10/3 is 10/3. Need 10/3+1? Well, then that's 13/3, and so on. The moment you evaluate this rational you have an error, so you don't. This is what arbitrary precision libraries do, and they are de rigueur in finance for a reason.

Precision and accuracy are far from the same thing. It is perfectly possible to have a number with 10 digits precision where the last 5 are garbage because you weren't educated enough about how hardware arithmetic works. Parent is correct - if you are serious about retaining accuracy, machine precision floating point decimals are out of the question.

You have it backwards. Most programmers will never know how to properly use an arbitrary precision math library until a financial application forces them to do so. I have not met many programmers who even know what machine precision/epsilon even is, much less how to avoid subjecting yourself to it.

Quoting myself from above, since you made exactly the same blunder as the other guy:

There is more to decimal errors than the number of bits allocated for the number. Inaccuracies can be easily encountered in any size of floating point number (usually by aggregating them or multiplying them by larger numbers). If you're really serious about accuracy (i.e. you are working in finance), you treat all your values as rationals/exponents. An evaluated decimal before presentation time is just a little error waiting to be aggregated/multiplied into a bigger one. Arbitrary precision libraries are the only safe way to handle this, and even with those you have to use great care with how you manage precision vs. accuracy.

Way to use an example that completely ignores why you would need BigDecimal in the first place (the ability to supply a MathContext as the 2nd argument to each operation). You can't just say 'A * B' if you are even remotely serious about controlling the accuracy of the result. You have not told it how many accurate digits to retain or how to resolve rounding when the resulting decimal is longer than the accuracy allocation. Just using BigDecimal by itself doesn't mean shit - its purpose is the ability to ensure with every single operation that no inaccuracies are produced. I don't know of any arbitrary precision math API that doesn't work like this. Many of them allow you to set global contexts, but if you are really serious about performance and accuracy then each operation needs to be considered.

As someone who works solely on HA systems, I can assure you that this is not a standard practice. It is in fact the opposite of what 'HA' means and would be considered an unacceptable showstopper in any project. Our server platform consists of Java, C++, Fortran and AIMMS, and out of all these the only components which require a separate daemon to monitor their status / restart on failure are the C++ ones. This is not a negative commentary on C++, merely a byproduct of the higher bar of code quality required to achieve graceful fault handling in that language. The Java components running out of containers never need to come down unless they have an actual memory/resource leak induced by the code, something so ridiculously easy to spot and and address it would never have made it past round 1 of QA. Perhaps you meant 'It is standard practice to kill and restart poorly written processes of any language in high availability systems', but you would still be wrong because if you have such components you do not have an HA system.

Complete nonsense. Aside from the fact that I can use a debugger, profiler, JMX console and heap/thread dumps to diagnose literally any problem on a live Java process, if a developer ever said the above to me they would be immediately reassigned to intern-level shitwork and fired at the nearest opportunity. 'bounce it once in a while' is an utterly unacceptable solution in HA regardless of language.

I don't think you do either. You seem to think that there is something about the JVM that inherently leads to long uptime issues. This is a function of bad code, not the language in which it was poorly written or the container under which it is executing. Profiling Java applications for deviations in resource usage / behavior is so easy that we had an intern set it up as an automated post-build step using only tools that come standard with the JDK, It took her about a week. There are some valid criticisms of the mis-use of Java (or any language for that matter), but your whole stability argument here is just completely bogus.