DEC64: Decimal Floating Point - <AUTHOR> http://dec64.com/ As described by Douglas himself, DEC64 is a decimal floating point format for the next generation of application programming languages. <comment><USER3> > DEC64 is intended to be the only number type in the next generation of > application programming languages.

Please no. There's a very solid case for integers in programming languages: _many_ places in code call for a number which _must_ be an integer: having the type enforce this is nice: you don't need to check and abort (or floor, or whatever) if someone passes you a non-integer. Basically, anything that does an array index, which is any for loop walking through a memory buffer (which might be an array, a string, a file, the list goes on and on. Anything that can be counted) wants an integer. x[i] where i is not an integer just doesn't make sense: ideally, let a type system enforce that.

Granted, of course, that many languages will just truncate a float in an integers context, and so funny stuff does happen (I don't really feel that this is a good thing). (Although interestingly, JS is not one of them.) Personally, I think JS _needs_ an integer type. Especially when you see people start getting into bignum stuff in JS, it gets silly fast, as first you can only store so many bits before floating point loses precision, but even then, even if you have an "integer", JS will find funny ways to shoot you in the foot. For example:

      x | 0 === x

does not hold true for all integers in JS.

<comment><USER4> Nothing is stopping you from building a natural number/integer on top of a dec64 type. You could add whatever logic necessary like truncating fractional values, throwing exceptions, etc.

<comment><USER5> That sounds like a lot of work and a lot of pain (and likely bugs) just to end up not quite back at square one thanks to the resulting performance drop. I feel what you've done here is the rough equivalent of pointing out that "nothing is stopping you" from building a webpage generator in brainfuck. It's turning complete after all! You could add whatever logic is necessary, like UTF8, XML, and Json parsing, etc.

Technically correct, but fails to address the core point that this might be a terrible idea.

</comment></comment></comment><comment><USER6> This would benefit from a better comparison with IEEE 754-2008 decimal64; he dismisses it as being too inefficient but I don't see much other discussion about it, which is too bad since at least it's already implemented in hardware on some platforms.

Also, it's worth mentioning [http://speleotrove.com/decimal/](http://speleotrove.com/decimal/) as a great repository of decimal float info. I hope it will be updated with some discussion of this proposed format.

<comment><USER7> One difference is with non-numbers. IEEE 754 defines several infinities (positive, negative) and several NaN values. DEC64 seems to simplify things to a single NaN value. That seems more practical for the average use case.

<comment><USER8> But it complicates things by having 255 different zeros which are all equal, and by defining

        1 / 0 == 0 / 0 == (-1) / 0 == MAX_DEC64 + X == (-MAX_DEC64) - <USER2>

(X being the some number large enough to cause overflow)

I'd qualify the proposal as a midbrow dismissial of all the real thought that went into the IEEE float standards (I mean, there is no actual substance to his criticism, except _" uh, look, it's so bad nobody uses it,"_ which isn't even true, it is in IBM Power7, IBM zSeries, Fujitsu SPARC64, SAP ABAP and gcc). Floating point on a finite precision computer is hard, you can't gloss over the details and assume you have solved everything by that.

<comment><USER9> Holy crap. I was about to comment that NANs are not equal to each other, as is the case in every other floating-point representation on the planet[0]. I wasn't actually expecting the page to say either way, but I decided to have a quick look in the vague hope of finding a quote to support that, and instead discovered:

      "nan is equal to itself."

That strikes me as being very odd, and will likely catch a lot of programmers out who are expecting the "normal" behaviour there. I predict many bugs, and much wailing and gnashing of teeth, as a result.

[0] Maybe.

Edit: I see Stormbrew made the point before me, lower down the thread.

</comment></comment></comment></comment><comment><USER10> Interesting approach, rather than normalize to 1 it normalizes to the largest whole number. The positives of this are that you don't run into issues with encoding things like .1 that you do in binary (or any repeating binary fraction), the downside is that you lose precision when you have more than 16 digits of precision. And the of course the complaint most folks will throw at it is that it fails differently depending on what 'end' of the number you're losing precision. The largest decimal number you can represent in 56 bits is 72,057,594,927,935 so the largest decimal number you can represent will any digit value is 9,999,999,999,999 (16 digits), and you have "extra" space at the top (0-6).

However, to Doug Crockfords credit, the number space it covers is pretty useful for a lot of different things and in scripted languages and other uses that aren't safety related I can see the advantage of an 'fractional integer' type.

Edit: Mike Cowlishaw, who is also quite interested in decimal arithmetic has a much deeper treatment here: [http://speleotrove.com/decimal/](http://speleotrove.com/decimal/)

<comment><USER11> But it can still bite you. I got hit with an IEEE 754 implementation detail that took me two days to figure out ([http://boston.conman.org/2014/03/05.1](http://boston.conman.org/2014/03/05.1)). The same problem would exist with this proposal as well.

The summary: RLIM_INFINITY on a 32-bit system can be safely stored in a double. RLIM_INFINITY on a 64-bit system can't. I had code in Lua (which uses doubles as the only numeric type) that worked fine on 32-bit systems, but not 64-bit systems. It took me two days to track the root cause down.

(Edit: added summary)

<comment><USER12> Which is why Lua 5.3 will have a 64 bit integer type, and will move away from float types only. You can't interop with external stuff without full 64 bit ints.

</comment></comment></comment><comment><USER13> Instead of being stuck with yet another inaccurate number type for integers, I want to see hardware assisted bigints. Something like:

\- A value is either a 63 bit signed integer or a pointer to external storage, using one bit to tell which.

\- One instruction to take two operands, test if either is a pointer, do arithmetic, and test for overflow. Those cases would jump to a previously configured operation table for software helpers.

\- A bit to distinguish bigint from trap-on-overflow, which would differ only in what the software helper does.

\- Separate branch predictor for this and normal branches?

I don't know much about CPUs, but this doesn't seem unreasonable, and it could eliminate classes of software errors.

<comment><USER14> I see no need to provide a single instruction for this. It can already be implemented in a couple of instructions in standard instruction sets (I am familiar with OCaml's Zarith, which does exactly this: [https://forge.ocamlcore.org/scm/viewvc.php/*checkout*/trunk/...](https://forge.ocamlcore.org/scm/viewvc.php/*checkout*/trunk/caml_z_x86_64.S?revision=78&root=zarith) . Other implementations surely exist). The only inefficient aspect of the current implementation is that most operations contain two or three conditional jumps, two for the arguments and sometimes one for the possibility of overflow.

The way modern, heavily-pipelined processors are designed, any instruction that could possibly need to obtain an address from an address and jump to there would have to be micro-coded. Also, from the instruction dependency point of view, the way modern, heavily-pipelined processors are designed, all instructions dependencies are fetched as early as possible (before the instruction is executing and it is known which may be ignored). This is why cmov is sometimes worse than a conditional branch. The entries of the "previously configured operation table" would need to be fetched all the time. Again, the simplest way not to fetch them all the time would be to micro-code the instruction, meaning that it would take about as much time as a short sequence of instructions that expands to the same micro-instructions.

There used to be a way in IA-32/x86_64 to annotate conditional branch instructions with a static prediction (cs: and ds: prefixes), which could be useful regardless of the approach, but nowadays I believe this annotation is ignored altogether.

<comment><USER13> I agree that static prediction would be nice. I wonder if the new Intel bounds checking extension can be abused for that.

My main problem with writing it out is code size, since ideally you want every single integer operation in your nice fast C-like-language program to expand to that kind of sequence. But maybe it doesn't actually matter that much.

</comment></comment></comment><comment><USER15> "DEC64 is intended to be the only number type in the next generation of application programming languages."

FFS, just because the designers of JS couldn't numerically compute their way out of a paper bag doesn't mean that FUTURE languages should be saddled with that mistake.

</comment><comment><USER16> Where's exp(), log(), sin(), cos()? He did the bare minimum amount of work and left all the interesting functionality out. We have relatively fast ways of dealing with these in IEEE754, but I see no equivalent here.

I really don't want to rehash the arguments that applied 30 years ago, as they do today. Decimal floating point is good for some things, but to be considered the "only number type in the next generation of programming languages" is laughable.

<comment><USER17> Cast to IEEE754 binary floating point number, perform exp()/sin/..., and cast back.

In any case, I don't think DEC64 is intended for those users that need to use cos() et al.

<comment><USER18> > In any case, I don't think DEC64 is intended for those users that need to > use cos() et al

He apparently has other ideas: "DEC64 is intended to be the only number type in the next generation of application programming languages."

</comment></comment></comment><comment><USER19> _It can provide very fast performance on integer values, eliminating the need for a separate int type and avoiding the terrible errors than can result from int truncation._

What! I do not see how making a float fast on integers should ever eliminate the need for an int type. Ints and Real-approximations like Dec64 are simply different things entirely.

It's annoying enough that this happens in Javascript.

<comment><USER20> Why does anybody listen to Crockford? He wrote a human-readable data format but refused to give it comments. He wrote an obnoxious linter that bans _continue;_. Now he's proposing to replace integers with decimal floating point type (what happens if someone wants to store a 64-bit integer?).

As a C programmer, he just seems off his trolley.

<comment> mark-r How often have you _needed_ a 64-bit integer where a 56-bit one wouldn't do? I rather like the idea of having only one numeric type.

<comment><USER20> As a succinct example, 64-bits is 584 years of nanoseconds. 56-bits is only 2 years of nanoseconds.

The problem is that many extant APIs return 64-bit integers, so if your language only has 56-bit integers you are creating a bug/vulnerability every time you want to talk to the outside world.

e.g. sqlite has _sqlite3_column_int64()_ to get a value from a result set. How do you use that safely if your language can only do 56-bit ints? Ugly.

Remember the "Twitter Apocalypse" when Twitter changed their tweet IDs to be bigger than 56-bits and all the JS programmers had to switch to using strings?

Also, bitboards. Bitboards are cool: [https://chessprogramming.wikispaces.com/Bitboards](https://chessprogramming.wikispaces.com/Bitboards).

EDIT: I also reject the premise that just because there's an ugly hack available, we can get rid of useful language features. Am I working for the language or is the language working for me?

<comment> mark-r The question is, why do APIs return 64-bit values? In general it's not because they need all 64 bits, it's because the 64-bit integer type is convenient for them. This might make Crockford's proposal completely impractical but it doesn't invalidate the argument that led to it.

I reject the nanosecond example because it's completely arbitrary. 64 bits of picoseconds would only cover 0.584 years so should we claim 64 bits isn't enough? Wouldn't 2000 years of microseconds in 56 bits be good enough?

I'll give you credit for bitboards though, that's one I hadn't considered.

</comment></comment></comment></comment></comment><comment><USER21> From the blog post

> DEC64 is a number type. It can precisely represent decimal fractions with 16 > decimal places, which makes it well suited to all applications that are > concerned with money.

From the reference code

> Rounding is to the nearest value. Ties are rounded away from zero.

Useful wikipedia entry regarding rounding ([http://en.wikipedia.org/wiki/Rounding#Round_half_to_even](http://en.wikipedia.org/wiki/Rounding#Round_half_to_even))

> This variant of the round-to-nearest method is also called unbiased > rounding, convergent rounding, statistician's rounding, Dutch rounding, > Gaussian rounding, odd-even rounding, bankers' rounding, broken rounding, or > DDR rounding and is widely used in bookkeeping. This is the default rounding > mode used in IEEE 754 computing functions and operators.

Rounding towards zero isn't compatible with financial calculations (unless you're performing office space style bank theft), so this should never be used for numeric calculations involving money. I wonder what he was really trying to solve with this since he missed a fairly important aspect of the big picture. That being said, there's no problem statement on his entire website to address what actual problem he was trying to solve, so all we see is a half baked solution for some unknown problem. On the plus side, at least he didn't use the "for Good, not Evil" clause in the license this time.

edit: formatting

<comment><USER22> The superman penny shaving attack is not related to rounding behavior. You may multiply with fractional values, but when you add or subtract from a ledger, you are doing so in fixed precision (usually cents). If you were calculating something like interest and consistently rounding in one direction, you'd be either over or undercharging people, but the money wouldn't vanish.

In other cases, you need to actually think about rounding mode (e.g. how many shares of AAPL can I buy with $5000).

> there's no problem statement on his entire website to address what actual > problem he was trying to solve

This is very true. I don't understand what problem this is trying to solve, because I don't spend a lot of time confused by the internal detail that a double is binary. The storage format isn't important beyond knowing roughly how many digits of accuracy I can count on.

</comment></comment><comment><USER23> So is this primarily a performance vs. convenience thing?

If both base2 and base10 floating point are implemented in hardware, what makes base10 inherently less efficient?

Also, I don't have a good intuition for the difference in what numbers can be exactly represented. I'd love to see this represented visually somehow.

Double precision can exactly represent integers up to 2^53, then half of integers between 2^53 and 2^54, then a quarter of integers between 2^54 and 2^55, etc.

Dec64 would be able to exactly represent integers up to 2^55, then 1/10th of all integers between 2^55 and 10(2^55), then 1/100th of all integers between 10(2^55) and 100(2^55).

So the "holes" are different, so-to-speak. How would this affect accuracy of complicated expressions?

<comment><USER24> Decimal floating point would hardly affect accuracy compared to binary floating point -- with the exception of domains where the inputs and output are strictly human-readable and human-precise constructs (e.g. banking... is there a better term for this?).

Binary floating point can accurately represent fractions of the form 1/(2^n). Decimal floating point can accurately represent fractions of the form 1/((2^n)*(5^m)). Either can only approximate fractions with other prime factors in the denominator (1/3, 1/7, 1/11, ...).

In terms of a programmer having to be concerned with accumulated errors due to approximations in the representation, I'd assert that decimal floating point in no way changes the scope of concerns or approach to numeric programming compared to binary floating point. I'd guess even in a domain with a very precise need of fractional decimals, a programmer would still need to reason about and account for numeric representation errors in decimal floating point such as overflow and underflow.

<comment><USER25> > Decimal floating point would hardly affect accuracy compared to binary > floating point

The larger the radix, the more of the mantissa is wasted. Given fixed storage, base 2 floats will have higher precision over their range than higher bases, like 10 and 16.

The difference is easy to illustrate with base 16 and base 2, since we can convert between the two easily. Converting a base 16 float to base 2 will result in leading zeroes some of the time, which could have been used for storing data. The same is true with base 10, but you have to do more math to demonstrate it.

<comment><USER26> You could just expand the mantissa to account for the base providing more range, though I do agree using a small base is better in general.

</comment></comment></comment></comment><comment><USER27> IBM also have a library called decNumber which has decent high level functions as well as 32/64/128 bit types.

[http://speleotrove.com/decimal/decnumber.html](http://speleotrove.com/decimal/decnumber.html)

Have used this for a number of years for financial calculations.

</comment><comment><USER28> > A later revision of IEEE 754 attempted to remedy this, but the formats it > recommended were so inefficient that it has not found much acceptance.

The C and C++ standards committees have been drafting decimal support based on IEC 60559:2011 (previously IEEE 754-2008) since its creation.

Original C TR: [http://www.open- std.org/jtc1/sc22/wg14/www/docs/n1312.pdf](http://www.open- std.org/jtc1/sc22/wg14/www/docs/n1312.pdf)

Latest draft specification: [http://www.open- std.org/jtc1/sc22/wg14/www/docs/n1781.pdf](http://www.open- std.org/jtc1/sc22/wg14/www/docs/n1781.pdf)

Original C++ TR: [http://www.open- std.org/JTC1/SC22/WG21/docs/papers/2009/n284...](http://www.open- std.org/JTC1/SC22/WG21/docs/papers/2009/n2849.pdf)

Update proposal for C++11: [http://www.open- std.org/jtc1/sc22/wg21/docs/papers/2012/n340...](http://www.open- std.org/jtc1/sc22/wg21/docs/papers/2012/n3407.html)

GCC, ICC, IBM C, and HP C have adopted the extension. Links to the respective software implementations can be found under "cost of implementation" in the C++11 proposal above, except GCC, which uses IBM's library. Its support is documented here: [http://gcc.gnu.org/onlinedocs/gcc/Decimal- Float.html](http://gcc.gnu.org/onlinedocs/gcc/Decimal-Float.html)

Meanwhile, hardware support so far exists in POWER6 and 7 and SPARC64 X.

This may seem like slow adoption if you aren't accustomed to the glacial pace of standards processes. Especially in the context of a component as critical as floating point numerics. If there is any holdup it would be lack of demand for this format, which the article's proposal doesn't affect.

</comment><comment><USER29> Python has three basic numeric types, unbounded integers, floats (with the precision of C doubles), and complex (for example, 5+0.3j). However, its standard library includes both a decimal type and a fraction type. The decimal type has been in the language for over 9 years. The documentation is quite clear [1].

Python's decimal type conforms to IBM's General Decimal Arithmetic Specification [2] which is based on IEEE 754 and IEEE 854. Python's decimal type is very complete. For example Python supports the complete range of rounding options found in these specifications (ROUND_CEILING, ROUND_DOWN, ROUND_FLOOR, ROUND_HALF_DOWN, ROUND_HALF_EVEN, ROUND_HALF_UP, ROUND_UP, and ROUND_05UP). By comparison Dec64 supports only one.

Despite having used Python on and off for over 10 years, I've never felt a need to use this decimal type. Integers and floats seem to work for me (although it's nice to have a good decimal implementation available if I need it).

[1] [http://docs.python.org/3.4/library/decimal.html](http://docs.python.org/3.4/library/decimal.html) [2] [http://speleotrove.com/decimal/decarith.html](http://speleotrove.com/decimal/decarith.html)

</comment><comment><USER30> For those who didn't notice, this is an initiative of Douglas Crockford, the inventor of JSON (among other things).

<comment><USER31> [http://www.logicalfallacies.info/relevance/appeals/appeal- to...](http://www.logicalfallacies.info/relevance/appeals/appeal-to- authority/)

<comment><USER32> I don't think this is necessarily an appeal to authority, for two reasons.

First, because some people will treat that authorship credit as a _warning label_ rather than authority; that would make it ad hominem, not appeal to authority.

Second, because it actually gives useful context to some parts of this spec: "Oh, it makes sense that the author of a language without integer types would propose a spec that claims you don't need integer types". That's not a logical fallacy at all; that's perfectly reasonable reasoning.

<comment><USER33> I read it as a simple statement of fact. Not an argument for or against anything.

</comment></comment></comment></comment><comment><USER34> A specific thing I haven't seen anyone mention is that NaN is equal to NaN in this, which is quite different from IEEE FP. Although it's a thing that often seems counterintuitive at first glance, doesn't this kind of ruin the error- taint quality of NaN?

<comment><USER18> Also, he defines 0*NaN=0, but 0+NaN=NaN.

<comment><USER35> So that you can divide by 0, get a NaN, then multiply by 0 to make it disappear!

</comment></comment></comment><comment><USER36> How does he explain storing simple integers in a reasonable amount of space? Any decent programmer will avoid using too many bits for a variable that never exceeds a certain value (short, int, etc). It seems rather foolish and arrogant to claim this one half-implemented number type can satisfy everyone's needs in every programming language.

Next week he'll have a number format with 48 mantissa bits, 8 exponent bits and 8 unsigned base bits to define a base value between 0 and 255. Look at all the performance and simplicity involved!

<comment> guard-of-terra "Any decent programmer will avoid using too many bits for a variable that never exceeds a certain value (short, int, etc)."

Why? Why aren't you use half-bytes also?

If all your pointers are 64-bit aligned, all your variables are 64-bit aligned and your processor isn't any faster processing 16-bit numbers - if it even have instructions to process those - than 64-bit numbers?

<comment><USER37> All your variables are not 64-bit aligned. An array of 16-bit integers will generally use 16 bits (2 bytes) per integer. So will two or more subsequent integers in a struct. In general, variables smaller than the alignment of the CPU (but still power of two sizes) only need to be aligned to their own size.

</comment></comment></comment><comment><USER38> This is some serious amateur hour. The most glaring problem is this:

> There are 255 possible representations of zero. They are all considered to > be equal.

There are also 255 representations of _almost all representable numbers_. For example, 10 is 1 x 10^1 or 10 x 10^0 – or any one of 253 other representations. Aside from the fact that you're wasting an entire byte of your representation, this means that you can't check for equality by comparing bits. Take a look at the the assembly implementation of equality checking:

[https://github.com/douglascrockford/DEC64/blob/master/dec64....](https://github.com/douglascrockford/DEC64/blob/master/dec64.asm#L1068-L1105)

The "fast path" (which is ten instruction) applies only if the two numbers have the same exponent. The slow path calls subtraction and returns true if the result is zero. The implementation of subtraction falls back on yet another function, which jumps around even more:

[https://github.com/douglascrockford/DEC64/blob/master/dec64....](https://github.com/douglascrockford/DEC64/blob/master/dec64.asm#L631-L664)

For most comparisons (no, comparing numbers with the same exponent is not the norm) it will take around FIFTY INSTRUCTIONS TO CHECK IF TWO NUMBERS ARE EQUAL OR NOT. Many of these instructions are branches – and inherently unpredictable ones at that, which means that pipeline stalls will be normal. All told, I would expect equality comparison to typically take around 100 cycles. It's not even clear to me that this implementation is correct because at the end of the subtraction, it compares the result to the zero word, which is only one of the 255 possible representations of zero. The lack of a single canonical representation of any number is just as bad for other arithmetic operations and comparisons, if not worse.

Crockfords bugaboo with IEEE 754 floating-point is bizarre, verging on pathological. He devoted a section in his book "JavaScript: The Good Parts" to a rather ill-informed rant against it. When I saw him give a talk, I took the opportunity to ask him what he thought would be a good alternative to using IEEE 754. His answer was – I shit you not – "I don't know". Apparently this proposal is the answer. No thanks, I will stick with the amazingly successful, ubiquitous, thoroughly thought out standard, that was spearheaded by William Kahan – one of the greatest numerical analysts of all time. Anyone who doesn't appreciate how good we have it with IEEE 754 should really read "An Interview with the Old Man of Floating-Point" [1], in which Kahan relates just how messed up this stuff was before the IEEE 754 standardization process. It should also be noted that there already _is_ an IEEE standard for decimal floating-point [2], which is not only infinitely better thought out than this drivel, but also is already implemented in hardware on many systems sold by IBM and others, specifically for financial applications.

[1] [http://www.cs.berkeley.edu/~wkahan/ieee754status/754story.ht...](http://www.cs.berkeley.edu/~wkahan/ieee754status/754story.html)

[2] [http://en.wikipedia.org/wiki/Decimal64_floating- point_format](http://en.wikipedia.org/wiki/Decimal64_floating-point_format)

<comment><USER23> This is some seriously hyperbolic negativity.

> There are also 255 representations of almost all representable numbers. > [...] Aside from the fact that you're wasting an entire byte of your > representation

How is this different than any other floating-point representation? I'm pretty sure IEEE floating-point has the same redundancy, though numbers are normalized so comparisons are cheaper as you note. But IEEE doubles "waste" even more bits due to the 2^52 representations of NaN.

> For most comparisons [...] it will take around FIFTY INSTRUCTIONS TO CHECK > IF TWO NUMBERS ARE EQUAL OR NOT.

Good point, sounds like a notable weakness and barrier to adoption.

> Crockfords bugaboo with IEEE 754 floating-point is bizarre, verging on > pathological.

He calls it "the most frequently reported bug in JavaScript." Wouldn't you be interested in improving on the most common cause of user confusion in a technology you care about?

<comment><USER38> IEEE 754 doesn't waste any bits – there is only a single representation of each value (except for multiple NaNs). In this proposal, there are 255 representations of most values, which means that it has almost an entire byte of redundancy. The waste is bad, but the lack of a canonical representation of each value is worse.

I personally think that the way to handle floating-point confusion is better user education. However, if you really want a decimal standard, then, as I mentioned above, there already is one that is part of the IEEE 754 standard. Not only do there exist hardware implementations, but there are also high- quality software implementations.

A better approach to making things more intuitive in all bases, not just base 10, is using rational numbers. The natural way is to use reduced paris of integers, but this is unfortunately quite prone to overflow. You can improve that by using reduced ratios of – guess what – floating point numbers.

<comment><USER39> > There are also 255 representations of almost all representable numbers. For > example, 10 is 1 x 10^1 or 10 x 10^0 – or any one of 253 other > representations.

You are not correct. The smallest significand possible is 1x10^1, but you can't delve further into positive exponents. Conversely, 56 signed bits allows the largest integer power of 10 as 10 000 000 000 000 000 so the exponent will be -15. So there are exactly 17 representations of 10, and that's the worst it gets. All other numbers except powers of 10 have fewer representations, and most real world data affected by noise has a single representation because they use the full precision of the significand, and you can't shift them to the right or left without overflow or loss of precision.

So the redundancy is much less than you think, one in 10 real values has two representations, one in 100 has three etc. This is common for other decimal formats and not that big of a problem, detecting zero is a simple NOR gate on all significant bits.

The real problem with this format is the very high price in hardware (changing the exponent requires recomputing the significand) and complete unsuitability for any kind of numerical problem or scientific number crunching. Because designing a floating point format takes numerical scientists and hardware designers, not assembly programmers and language designers.

Heck, the only reason he put the exponent in the lower byte and not the upper byte, where it would have ensured a perfect compatibility to most positive integers, is that X64 assembly does not allow direct access to the upper byte.

<comment><USER38> You are right. I forgot about the interaction between the exponent and the significand. The lack of a canonical representation is still quite problematic.

</comment></comment></comment></comment></comment><comment><USER40> While i find the binary incomparability with with decimals somewhat annoying.

In the bigger picture what i fell we are generally missing in most programing languages is an EASY way to store and handle fractions.

<comment><USER18> Just curious, what is your use-case in which you need better support for fractions?

<comment><USER40> A simple example: (i will use decimal instead of binary as it is easier and binary suffers from the same stuff but for other numbers)

(10/3)x(9/4) == 7.5

but due to the fact that computers store the value instead of the fraction it would come out as something like 7.4999999999 cause instead of doing (10x9)/(3x4) it would do 3.3333333333333 x 2.25

<comment><USER41> This looks like a case for decimal floating point, not fractionals. In Python:

>>> from decimal import Decimal as D >>> D("10")/D("3") * D("9")/D("4") Decimal('7.50000000000000000000000000')

</comment></comment></comment></comment><comment><USER42> I see a few flaws that would prevent this from being a decent hardware type:

1) The exponent bits should be the higher order bits. Otherwise, this type breaks compatibility with existing comparator circuitry.

2) This representation uses 10 as the exponent base. That will require quite a bit of extra circuitry, as opposed to what would be required if a base of 2 was used. Citing examples from COBOL and BASIC as reasons for using base 10 is not a very convincing.

3) With both fields being 2's compliment, you're wasting a bit, just to indicate sign. The IEEE single precision floating point standard cleverly avoids this by implicitly subtracting 127 from the exponent value.

4) 255 possible representations of zero? Wat?

5) This type may be suitable for large numbers, but there's no fraction support. In a lot of work that would require doing math on the large numbers that this "standard" affords, those large numbers are involved in division operations, and there's no type for the results of such an operation to cast into.

6) This data type seems to be designed to make efficient by-hand (and perhaps by-software) translation into a human-readable string. But who cares? That's not a reason to choose a data type, especially not a "scientific" one. You choose data types to represent the range of data you have in a format that makes for efficient calculation and conversion with the mathematical or logical operations you want to be able to perform.

</comment><comment><USER43> A real alternative to floating points would be a Logarithmic number system ([http://en.wikipedia.org/wiki/Logarithmic_number_system](http://en.wikipedia.org/wiki/Logarithmic_number_system)) which has been shown to be a "more accurate alternative to floating-point, with improved speed."

</comment><comment><USER44> > DEC64 is intended to be the only number type in the next generation of > application programming languages.

Is he seriously arguing that integer types should be eliminated? What the hell?

I really hope for the author's sake this is a joke.

<comment><USER16> He's the creator of Javascript, so obviously it is.

<comment><USER45> You've got the wrong person or you're being really subtly tongue-in-cheek.

Douglas Crockford is the standardizer of JSON and author of "JavaScript: The Good Parts", in which he popularized non-terrible Javascript. Brendan Eich is the creator of Javascript.

</comment></comment></comment><comment><USER46> Does look interesting.

However, one nit in terms of interesting architecture: _The Burroughs 5000 series had a floating point format in which an exponent of zero allowed the mantissa to be treated as an ordinary integer._ In fact, the whole addressing scheme was decimal. The addresses were stored in one decimal digit per nibble, so it was doing decimal at the hardware level.

While this looks interesting at first blush, good luck with _DEC64 is intended to be the only number type in the next generation of application programming languages._ I think float will be around for a while, what with the blinding speed in today's processors, and the availability of 80 bit intermediate precision.

<comment><USER18> > I think float will be around for a while, what with the blinding speed in > today's processors, and the availability of 80 bit intermediate precision.

...and well-understood numerical behavior...

<comment><USER47> In my experience float is well understood by very few of those who use it. I have had to explain multiple times to people who have been using floats for years that just because floats have guaranteed minimum 6 significant digits doesn't mean that the result of your calculations will be correct to 6 significant digits.

<comment><USER46> Yes.

I have been thinking of running a floating-point school just for this reason. Lots of gotchas.

</comment></comment></comment></comment><comment><USER48> I thought the advantage of 2's complement was that we only had one zero and no additional conversions to do arithmetic on negatives, simplifying operations and ALU implementations. Without normalization, how would that work with DEC64? Set both numbers to the highest exponent?

</comment><comment><USER49> >By giving programmers a choice of number types, programmers are required to waste their time making choices that don't matter

So I guess making sure that you can never do array[0.5] before your program ever runs doesn't matter? At least not to Crockford apparently, who seems to have some kind of irrational hatred for static type systems.

</comment><comment><USER50> "By giving programmers a choice of number types, programmers are required to waste their time making choices that don't matter. Even worse, making a bad choice can lead to a loss of accuracy or destructive bugs. This is a bad practice that is very deeply ingrained."

This is like saying that the sharp blades on scissors (diverse numeric types) make them prone to causing bodily harm to surrounding people(errors due to constraints of types), then concluding that we should replace all scissors (numeric types) with those rounded plastic scissors(dec64 play dough floats) which come with a play dough set.

Every time somebody has the idea that by deluding developers more we can save them trouble and make them feel safer, we pat that person on the back and follow their recipe. Then two years later there's a HN post about why you really shouldn't be doing whatever was prescribed.

</comment><comment><USER51> > There are 255 possible representations of zero. They are all considered to > be equal.

And we're done here folks.

</comment><comment><USER52> The name is a bit confusing. I have seen dec32 and dec64 numbers in some mil std ICDs. I can't find any of the documents online but here [1] is a discussion about dec 32 that links to a pdf which briefly describes the dec32 and dec64 formats.

[1] [http://stackoverflow.com/questions/1797806/parsing-a-hex- for...](http://stackoverflow.com/questions/1797806/parsing-a-hex-formated- dec-32-bit-single-precision-floating-point-value-in-pytho)

</comment><comment><USER53> Q: Why do programmers confuse Christmas and Halloween?

A: Because DEC 25 = OCT 31

</comment><comment><USER54> to view the description html page: [http://htmlpreview.github.io/?https://raw.github.com/douglas...](http://htmlpreview.github.io/?https://raw.github.com/douglascrockford/DEC64/master/dec64.html)

<comment><USER55> "A later revision of IEEE 754 attempted to remedy this, but the formats it recommended were so inefficient that it has not found much acceptance."

IBM put hardware support for the IEEE 754-2008 Decimal Format in their POWER architecture. The POWER7 clocks 5 GHz. Decimal floating point is only considered slow because Intel and ARM do not have any support for decimal floating point in hardware. Lack of acceptance probably comes from lack of support in standard libraries rather than inefficiency inherent in the standard.

Reference: [https://en.wikipedia.org/wiki/POWER7](https://en.wikipedia.org/wiki/POWER7)

<comment><USER16> POWER7 has a max clock of 4.25 GHz according to that reference.

Anyhow, clock rate in this case is irrelevant. Look at the instruction latencies. I don't have these handy, but I'd bet $50 at at the chance of winning $10 that decimal floating point instructions (at least the divide) are slower than the IEEE754 ones.

These chips are also ridiculously expensive, so probably not the best benchmark.

</comment></comment></comment><comment><USER18> As a "specification" this document is laughable. For example, rounding modes and overflow behavior are not addressed. The comment that object pointers can be stuffed into the coefficient field (usually called 'mantissa') is completely non-sequitur. Frankly I am surprised to see such a big name behind it.

I imagine this project is inspired by the sad state of numerical computing in Javascript, but this proposal will surely only make it worse. The world certainly doesn't need a new, incompatible, poorly-thought-out floating point format.

Compare the level of thought and detail in this "specification" to the level of thought and detail in this famous summary overview of floating point issues: [https://ece.uwaterloo.ca/~dwharder/NumericalAnalysis/02Numer...](https://ece.uwaterloo.ca/~dwharder/NumericalAnalysis/02Numerics/Double/paper.pdf) ("What every computer scientist should know...")

> DEC64 is intended to be the only number type in the next generation of > application programming languages.

Jesus, I certainly hope not.

<comment><USER56> > rounding modes and overflow behavior are not addressed

He provides a reference implementation. That means this and many other details are defined by code. Quoting dec64.asm: "Rounding is to the nearest value. Ties are rounded away from zero. Integer division is floored."

> Compare the level of thought and detail in this "specification" to ... > [Goldberg]

I don't think this comparison is fair. David Goldberg's text is an introduction to the topic. Douglas Crockford describes an idea and gives you a reference implementation.

<comment><USER57> > He provides a reference implementation. That means this and many other > details are defined by code.

I dream of a day when we stop thinking of "reference implementations" as proper specifications. The whole concept of a "reference implementation" leads to an entire class of nightmarish problems.

What happens if there is an unintentional bug in the reference implementation that causes valid (but incorrect) output for certain inputs? What if feeding it certain input reliably produces a segfault? Does that mean that other implementations should mimic that behavior? What if a patch is issued to the reference implementation that changes the behavior of certain inputs? Is this the same as issuing an amendment to the specification? Does this mean that other implementations now need to change their behavior as well?

Or, worse, what if there is certain behavior that should be explicitly left undefined in a proper specification? A reference implementation cannot express this concept - by definition, _everything_ is defined based on the output that the reference implementation provides.

Finally, there's the fact that it takes time and effort to produce a proper specification, and this process usually reveals (to the author) complexities about the problem and edge cases that may not become apparent simply by providing a reference implementation.

<comment><USER58> On the other hand, if you don't have a reference specification you shouldn't declare something standard.

(re: all the web standards that had very wide "interpretation" by different browser efforts, leading to chaos and a whole industry based on fear an uncertainty)

<comment><USER59> But nobody did, you're the first person in the thread to mention the word "standard". You might be confusing specification with standard.

</comment></comment></comment></comment></comment><comment><USER4> I think this is pretty interesting and appreciate that it's presented with working code.

I think people freaking out that they're taking our precious integers away are being a little brash. A natural number type could easily be built on top of a dec64 type for those cases where you really need only whole numbers.

</comment><comment><USER60> I seem to remember that "wobble" which is how the relative roundoff error relates to the absolute error, becomes worse as the base becomes larger (the ratio being the base itself). So that may be one disadvantage in using a decimal base.

</comment><comment><USER61> Is this intended to be used in a future version of JavaScript?

<comment><USER18> Worse:

> DEC64 is intended to be the only number type in the next generation of > application programming languages.

<comment><USER62> Was this sweeping pronouncement approved by the Central Committee for the Design of Future Programming Languages (CCDFPL), or is Crockford only speaking for himself?

<comment><USER63> He's just proposing it. It doesn't carry any weight.

</comment></comment></comment></comment><comment><USER64> Can we please make fun of this "specification" very very loudly as a warning to people who might think this is even a _remotely_ good idea?

Decimal floating point is actually a good, underutilized idea. However, there is a _VERY_ good specification here: [http://speleotrove.com/decimal/dbspec.html](http://speleotrove.com/decimal/dbspec.html)

It is written by people who understand the problem, and have thought quite deeply about the solutions.

As opposed to this pile of garbage ...

</comment><comment><USER65> Here is the fixed point decimal implementation for Golang

[https://github.com/oguzbilgic/fpd](https://github.com/oguzbilgic/fpd)

</comment><comment><USER66> The term "mantissa" is related to common logarithms, why is it used in relation to floats?

<comment><USER67> Mantissa is also used as the number being multiplied by a base to a power on calculators. That's basically what it is in floats.

<comment><USER66> I use the term "significand", because the mantissa is logarithmic, the significand isn't.</comment></comment></comment>


Bad News Wrapped in Protein: Inside the Coronavirus Genome - <AUTHOR> https://www.nytimes.com/interactive/2020/04/03/science/coronavirus-genome-bad-news-wrapped-in-protein.html <comment><USER2> Oh wow, this is really a spectacular article. I didn't expect to see science reporting of this quality or depth in a traditional mainstream newspaper, this is pretty awesome</comment>


Ask HN: Best Data Visualisation Resources? - <AUTHOR>

So, I'm needing to do some data visualisation for an analytics program soon, and I want to rapidly get up to speed on the best practises for data visualisation in 2014.
What would you recommend as the best books, videos, ebooks, websites, etc to learn about data visualisation right now, particularly for less-technical users?
I speed-read, so feel free to suggest thick tomes if they're the best option :) <comment><USER2> Edward Tufte's materials are well-regarded:

[http://www.edwardtufte.com/tufte/books_vdqi](http://www.edwardtufte.com/tufte/books_vdqi)

[http://www.edwardtufte.com/tufte/books_ei](http://www.edwardtufte.com/tufte/books_ei)

[http://www.edwardtufte.com/tufte/books_visex](http://www.edwardtufte.com/tufte/books_visex)

<comment><AUTHOR> They look superb - thanks very much.

</comment></comment><comment><USER3> Other than the usual books, I dig the most recent innovations (on Twitter) by subscribing to these lists :

[https://twitter.com/BrianBBrian/lists/data- visualization](https://twitter.com/BrianBBrian/lists/data-visualization) [https://twitter.com/venkasub/lists/viz](https://twitter.com/venkasub/lists/viz)

Also, collated a list of libraries almost 3 years back: [http://theuforce.blogspot.in/2010/12/data-visualization- char...](http://theuforce.blogspot.in/2010/12/data-visualization-charts- and.html)

</comment><comment><USER4> Might want to xpost over at [http://datatau.com](http://datatau.com) if you don't get what you hope to by posting here.

<comment><AUTHOR> Very useful, thanks!

</comment></comment><comment><USER5> I've posted an informal list of visualization resources that I've been tracking. There are references to other visualization lists within the doc.

[https://github.com/dbuonomo/visualization- resources](https://github.com/dbuonomo/visualization-resources)

</comment><comment><USER6> I will suggest checking out following resources:

Books

* Nathan Yau, Data Points Visualization that means something * Stephen Few, Information Dashboard Design The effective communication of data * OReilly, Visualizing Data

Software

* Tableau and example visualizations * D3.js and example visualizations

<comment><AUTHOR> Will do, thanks!</comment></comment>


Stimulus for Startups: Some Thoughts From a Seattle Startup Attorney - <AUTHOR> http://www.startupcompanylawblog.com/2010/09/articles/federal-law-regulation/stimulus-for-startups-some-thoughts-from-a-seattle-startup-attorney/

<comment><USER2> Quoth the article: _I think that investors in companies ought to be able to obtain a full and immediate tax credit for the entire amount of their investment to the extent that the funds are used to employ people. This would cost the Treasury (because, for example, an investor's tax bill would be reduced by the amount of a $100,000 investment by $100,000, and the payroll taxes collected on $100,000 paid in wages would be less than $100,000), but I think it would be a simple and wonderful way to encourage direct investments into companies and create jobs._

Am I misunderstanding this, or is it really as loony as I think it is? He seems to be saying that if I would have a $100k tax bill, I can decide to hire my brother to weave baskets and pay him $100k instead of paying it to the government.

Aside from supporting nepotism, how is this any different from the government hiring people to weave baskets?

<comment><AUTHOR> cperciva--we can disagree, and you can think that what the govt is doing or has done in the past is great...but it is not working. we need to try something different. as long as the money is used to employ people...why should the govt care? it will get its payroll tax dollars from your brother weaving baskets...

<comment><USER2> _as long as the money is used to employ people...why should the govt care?_

Because the government could employ someone to do something useful. Pay them to build bridges. Or to repair hurricane-damaged homes. Or to write open source software. Or heck, pay them to run around in circles and burn off some of the famous American obesity.

I don't know what the _best_ thing to pay people to do is, but I'm sure there's _something_ useful the government could do if it's paying people anyway...

<comment><AUTHOR> yeah...my hunch is that if you are going to invest money in a company, you don't want to waste your investment on a basket weaving business...you would pay someone to code something cool....</comment></comment></comment></comment>


Rick Warren on a life of purpose - <AUTHOR> http://www.ted.com/talks/rick_warren_on_a_life_of_purpose.html <comment><AUTHOR> _I don't personally have enough faith to be an atheist._ </quote></comment>


California's EV charging network gets $800M spark from VW - <AUTHOR> http://www.siliconvalley.com/2017/07/27/ev-charging-network-gets-800-million-spark-from-vw/ <comment><USER2> How is the electricity generated?

<comment><USER3> a) it doesn't matter, because EVs are still an improvement

b) it doesn't matter, because the grid need to be cleaned up anyway

<comment><USER2> Yes, I agree that it is a step forward regardless of the source. However, I would like to see a bigger step forward, with more solar used.

Adding more clean energy to the grid isn't something we are waiting to do at some point in the future.</comment></comment></comment>


Birth order doesn't affect your personality–just your intelligence - <AUTHOR> http://arstechnica.com/science/2015/10/birth-order-doesnt-affect-your-personalityjust-your-intelligence/ <comment><USER2> What kind of dichotomy is that? Doesn't intelligence affect your personality anyway?</comment>


Nipkow disk - <AUTHOR> https://en.wikipedia.org/wiki/Nipkow_disk <comment><USER2> Here is an excellent in-depth explanation of the concept from one of my favorite educational YouTube channels - Technology Connections: [https://youtu.be/v5OANXk-6-w](https://youtu.be/v5OANXk-6-w)

<comment><USER3> I just watched that and have to agree, an excellent in-depth explanation it was indeed, with a lovely demonstration.

</comment></comment><comment><USER4> A descendant of this guy is hard at work in theorem proving: [http://www21.in.tum.de/~nipkow/](http://www21.in.tum.de/~nipkow/)

<comment><USER5> Is this a joke or is Tobias a (great) grandson of Paul Gottlieb's?

<comment><USER4> Not a joke. I asked him about that (quite) a few years ago, and he indeed is :-)

</comment></comment></comment><comment><USER6> William Osman tried to build a mechanical display around these: [https://www.youtube.com/watch?v=R96TtG5FCTU](https://www.youtube.com/watch?v=R96TtG5FCTU)

<comment><USER7> He seems to really be overcomplicating its construction with all those fancy 21st century electronics when in reality you can build it with early 20th century materials.

I wonder if a camera obscura would be enough to create the focused image instead of having to bother with lenses.

<comment><USER8> Probably, but that would require even more light.

</comment></comment></comment><comment><USER9> Thanks for this, I have been trying to remember the term 'confocal microscopy' for a while. [https://en.wikipedia.org/wiki/Confocal_microscopy](https://en.wikipedia.org/wiki/Confocal_microscopy)

</comment><comment><USER7> This is a really good short educational video about the invention of television:

[https://www.youtube.com/watch?v=MyHAev_qJNU](https://www.youtube.com/watch?v=MyHAev_qJNU)

</comment><comment><USER10> This is very similar to the old fax machines, that had a needle over a rotating text on a wax cylinder and reproduced the needle up-down on the other end with a pen. Predated telegraph etc.

</comment><comment><USER11> I don't understand why you have to approximate straight scanlines by using a fraction of a really large disk. What's the disadvantage in using a smaller disk and letting the scanlines be curved?

<comment><USER12> With the large disk, the difference between the (linear) velocities of different holes is smaller.

</comment></comment><comment><USER13> Could it be possible to use this mechanism to create a type of X-ray or gamma ray camera? Perhaps using a lead disc.

</comment><comment><USER14> The spelling of disk, with a K, intrigues me, since I was under the impression that disk-with-a-K was short for "diskette", meaning a circular spinning object protected inside an outer casing.

Circular flat objects are spelled disc, with a C.

Hence floppy disk, hard disk, but compact disc.

(MiniDisc is the only exception to this rule that I can think of, probably because it is a trade mark.)

<comment><USER8> Seems Wikipedia has a dedicated article on the subject!

[https://en.wikipedia.org/wiki/Spelling_of_disc](https://en.wikipedia.org/wiki/Spelling_of_disc)

<comment><USER15> Relevant bit:

> in the case of flat, rotational data storage media the convention is that > the spelling disk is used for magnetic storage (e.g. hard disks) while disc > is used for optical storage (e.g. compact discs, better known as CDs). When > there is no clear convention, the spelling disk is more popular in American > English, while the spelling disc is more popular in British English.</comment></comment></comment>


Massive Cryptocurrency Heist Spurs Call for More Regulation - <AUTHOR> https://www.bloomberg.com/news/articles/2018-01-28/massive-cryptocurrency-heist-puts-spotlight-on-exchange-security?elqTrackId=4f1ede9e0c884211a6923a2383728a94&elq=2badf1e0e5144dd5ab395c0505fbb7fc&elqaid=10473&elqat=1&elqCampaignId=5187 <comment><USER2> Libertarian that originally wanted BTC to never touch the government hands here.

BTC has gotten insanely popular and the world has changed. Old people and finance institutions have gotten involved.

Now I'm okay with regulation on exchanges(I prefer no regulation, but I'm also reasonable).

You cant exactly regulate the blockchain, wallets will do transactions regardless. This would only affect exchanges.</comment>


Ask HN: If Oracle win, why would anyone use Java ever again? - <AUTHOR> <comment><USER2> At this point it's irrelevant what the underlying language is. Apis will either be copyrightable or uncopyrightable.

I hope Google wins but I don't think their lawyers did the best job litigating this. For example, where was the testimony by someone like Jeremy White of Codeweavers explaining he won't even have a business if this interpretation of Copyright Law holds.

</comment><comment><USER3> Never underestimate the "getting squeezed by Oracle[1] will never happen to me" effect.

[1] [https://thestack.com/cloud/2015/07/10/oracle-breach- notice-b...](https://thestack.com/cloud/2015/07/10/oracle-breach-notice- bullies-enterprise-clients-into-cloud-service-consultant-claims/)

</comment><comment><USER4> Java as a language is not a great thing (Elixir for instance is a thousand times better). But the JVM is just an engineering marvel.

</comment><comment><USER5> Because they've already built giant systems in Java and a rewrite would be extremely expensive.

<comment><USER6> Exactly even if Oracle demands some kind of licensing its likly far cheaper than the cost of writing a new system</comment></comment>


All Medium paywalled stories now free, unmetered when you're coming from Twitter - <AUTHOR> https://twitter.com/ev/status/1100899021621583872 <comment><USER2> Medium always confuses me on how hundreds of millions are spent on making such a poor product. It's a very basic blog, something that's an "intro to programming" youtube video at this point, yet it's slow and annoying to use and has never made any serious money for anyone.

It's starting to get to Juicero levels of absurdity.

<comment><USER3> If your only consumers are developers, then yes, it's really straightforward.

I made a small CMS at work that started to gain steam. 2 years of me using it and no issues, but then I turned it over to the marketing team and they crashed the VM it ran on in 2 days. I have no idea how, it's just a bunch of text boxes and a SQL DB.

That's what medium is trying to build. A text box that marketing people can't fuck up. It's just sad that technical skills are so low in society that it takes $130mil to do that.

<comment><USER2> Considering that there are hundreds of blog engines from Wordpress to Squarespace that work fine with even more control and advanced layouts, I think this is a solved problem.

<comment><USER4> Do you have any idea what it takes to run a Wordpress service at scale in a way that doesn't get the host rooted every ten seconds?

You have little idea what you are talking about for somebody so dismissive.

<comment><USER2> Honestly, yes I do. I've single-handedly built global applications serving billions of requests daily for several startups. I understand hidden complexities but a blogging site like Medium is as simple as it gets. It's $132M to build a blog that's not even as advanced as 15 year old software like Wordpress.

If you need another example, look at [https://dev.to/](https://dev.to/) for a fantastic blog UX, and it's open-source so Medium can just copy it for free and end up with a better product.

<comment> stone-monkey Isn't comparing the scale of the two like comparing apples to oranges? I think most wordpress sites are self hosted. There's wordpress.com hosting, but I'd guess that most of their sites are self hosted for the explicit purpose of customization.

While WordPress still dominates large areas of the web, they have a decentralized model vs medium. It's like comparing scaling web forums to reddit ("why do they have so many outages? All they do is store text!"), but reddit obviously has a way higher load than any single forum. I'd wager the same is true for medium.

To continue on with the metaphor, medium, like reddit, is solving a different problem than the wordpress/squarespace model: you don't have to roll your own. You get a built in audience due to centralization and the cache of the site (For some reason I associate a medium link as being more legit than seeing a WordPress hosting site. Strange, but better branding I guess.)

<comment><USER2> The discussion has gotten muddy. The point was that this custom-built expensive site is just a blog and still offers less than Wordpress in terms of features.

Scale is differently, but again there are plenty of sites with far more complex usage and data that took much less to create and run. Stackoverflow being that example.

</comment></comment></comment></comment></comment></comment></comment><comment><USER5> Are there Medium publications that are consistently of a high quality? I recall Backchannel being one (written and edited by tech journalists) but the issue is it's hard to know which publications are contributor-driven and which aren't.

Contributor-driven content is why Forbes.com, Inc.com, etc are unreadable. It's all puff pieces for some startup, unoriginal life-hacking advice and entreporn.

<comment><USER6> As was once said of a computer magazine, but is really an evergreen observation about all business media:

"The publication is packed full of advertisements, some of which are clearly labeled as such."

<comment><USER7> What a great insight. Thank you for sharing.

</comment></comment></comment><comment><USER8> I used to like Medium as a discovery tool for interesting articles & ideas for authors to follow (on Medium or Twitter). But since the introduction of the premium model it is completely broken for this purpose. Now all you see (at least 80% of their recommendations) is premium articles on the Medium website.

For the topics that I am interested in (Data science, ML, Cloud, Programming etc) very close to 0% of the quality authors write to make a few pennies of the articles. They do it to enhance their own personal brand or as content marketing for the companies they work for. For this reason the premium article star marker works as a filter for things I am not willing click and invest time in reading since they are rarely written by experts with actual experience in the topics that I am interested in.

So when they skew their recommendation algorithm so hard towards the premium content it is just not worth it anymore and I never click around on the Medium.com website anymore. 90%+ of my clicks to articles comes from Twitter. I wish they built their business model to charge for features and not content since the path they are on is not going to work out. It is reducing the incentive for quality authors to publish on Medium since the exposure they will get through the recommendation algorithm is being smaller and smaller. Most people don't publish on Medium because it is difficult or expensive to run a wordpress blog. They do it because of it is a good way to find new readers of your content.

</comment><comment><USER9> I don't get it, who looks at Twitter and thinks "Yes, I want more of that type of audience."

<comment><USER10> Who looks at Medium and says "Sure, I'd love it if you own my content forever?"

<comment><USER11> I wonder what happens if a Medium user copies someone else's original content onto Medium and the post is uncontested by a DMCA request. If Medium or a subsidiary profit from reproducing that content, could the original creator sue, and for how much?

Copyright is something I haven't taken the time to fully understand.

<comment><USER12> This is an important legal question that's currently being debated by many legislators around the world. In the U.S. there's a law frequently called "Section 230"[1] that protects online content publishers from being held legally responsible for user-created content published on their platform. It's the reason why Tinder isn't on the hook for fraud every time someone uses their service to catfish and why Backpage & Craigslist (until recently at least) weren't accessories to prostitution every time someone sold sexual services on their sites.

Likewise, Section 230 acts as a "shield" to protect the platforms from copyright liability for content posted by their users.

This is _good_. It allows platforms like Facebook, Reddit, Medium, and even Hacker News to exist without needing to constantly police everything being said on their platform. It allows users of those platforms to have free and open discussion.

You've probably heard about "Article 13" and the "upload filter" in the European Union. Article 13 takes away the European equivalent of Section 230's "shield" that protects online platforms from copyright liability.

And the United States has been slowly chipping away at Section 230's protections as well. Last year Trump signed "FOSTA" (sometimes called "SESTA") which "creates liability for third-party content on websites "that unlawfully promote or facilitate prostitution." I would encourage you to read why this legislation is a problem for anyone who enjoys the open internet as we currently know it.[2][3]

[1] [https://www.law.cornell.edu/uscode/text/47/230](https://www.law.cornell.edu/uscode/text/47/230) [2] [https://www.eff.org/cases/woodhull-freedom-foundation-et- al-...](https://www.eff.org/cases/woodhull-freedom-foundation-et-al-v-united- states) [3] [https://stopsesta.org/](https://stopsesta.org/)

</comment></comment></comment></comment><comment><USER13> From farther down in the thread[1]:

> It doesn't affect compensation—assuming you mean for Partner Program. That's > determined by readership from paying members, which will still be counted > (assuming they're logged in).

Ev also said that they'll watch to see if this change negatively impacts paid subscriptions.

[1]: [https://twitter.com/ev/status/1100905414089031680](https://twitter.com/ev/status/1100905414089031680)

</comment><comment><USER14> One of the tweets suggests Twitter is going to buy Medium. That's ... interesting.

<comment><USER15> It's not too farfetched given that Evan Williams founded the company.

<comment><USER16> Serious question: does he also own the Bourbon company in the same name?

<comment><USER17> No.

</comment></comment></comment></comment><comment><USER18> Or, more accurately, if you go to the Medium article via a t.co redirect (Twitter's outgoing link redirector). So if you want to share a paywalled article outside of Twitter (on HN, say) then submit the t.co link and there you go.

Example (this is usually paywalled): [https://t.co/EkfcBtSUdo](https://t.co/EkfcBtSUdo)

<comment><USER19> I don't get a paywall when opening the destination URL of that directly in Chrome's incognito mode.

<comment><USER18> Yeah, I _think_ you get up to 5 paywalled articles a month anyway if you're not logged in and incognito basically resets that over and over. But if I'm linking people to stuff, they're not usually going to go through that process and it'd be easier for me to make the t.co link for them.

</comment></comment></comment><comment><USER20> It looks like it's time for an "Un-paywall Medium" Chrome extension. [https://twitter.com/sephr/status/1101176562274037760](https://twitter.com/sephr/status/1101176562274037760)

I imagine that most causal desktop users would rather install an extension in seconds than take the time to enter their payment information for an easily- bypassed paywall.

</comment><comment><USER21> unfortunately, it's still Medium. If they improved their accessibility it wouldn't be as bad, but they're more pro design than pro accessible design.

</comment><comment><USER22> Does this mean they're tightening the paywall in general? I have run into annoying meaaafws but never been blocked from reading an article, and I'm always logged in.

My understanding is that if you do hit the paywall you can just open the article in an incognito window. Is this not the case, such that a twitter workaround would now be necessary?

<comment><USER22> Too late to edit, but that gibberish word was a crazy autocorrect from "messages"</comment></comment>


Uber Is Hiring Like Mad for Its Driverless-Cars Business - <AUTHOR> https://qz.com/962670/uber-is-hiring-more-engineers-for-its-pittsburgh-self-driving-car-research-center-despite-a-lawsuit-from-alphabets-waymo/ <comment><USER2> I wondering if they are having trouble hiring because of their reputation issues?</comment>


Kill Math - <AUTHOR> http://worrydream.com/#!/KillMath

<comment><USER2> Or to discuss the post without the #!, <http://news.ycombinator.com/item?id=2532271></comment>


VMware Moves to Defuse Software Threats, Plans Hardware - <AUTHOR> http://online.wsj.com/articles/vmware-moves-to-defuse-openstack-software-threats-plans-new-hardware-1408968002

<comment><AUTHOR> Warning: The usual WSJ paywall.</comment>


Bill Gates lives in all our SharePoint installations - <AUTHOR> http://sharepintblog.com/2011/12/21/bill-gates-lives-in-all-our-sharepoint-installations/

<comment><USER2> that pic is also the default pic in Outlook 2010 if you have no pic set in Exchange.

<comment><USER3> [http://arstechnica.com/microsoft/news/2010/09/bill-gates- sta...](http://arstechnica.com/microsoft/news/2010/09/bill-gates-staring-back- at-you-from-outlook-2010.ars)

</comment></comment><comment><USER4> There's no way this will get picked up in HN, but that is awesome.</comment>


The Second Screen Community Group Is Reborn - <AUTHOR> https://www.w3.org/community/webscreens/2016/09/06/the-second-screen-community-group-is-reborn/ <comment><USER2> This was a new term to me. A "second screen" is when you have a device with its own display, and which also controls another screen. I imagine it's for cases like if your phone were also to display content on a 40" screen in your living room, or you wanted a web-based presentation system where the operator/presenter gets a different screen than the presentation proper.

(When I saw the title, I thought it was about the GNU "screen" terminal multiplexer. The term "secondary screen" made me think of the TSA. I write this now should others be equally as confused as I was.)</comment>


Ask HN: Does RAM speed matter for programming? - <AUTHOR> It is a well accepted fact that lots of RAM does improve performance.  But does RAM speed matter in computation intensive operations?  Is there a difference between 1600MHz RAM and a 2400MHz RAM in performance, everything else being equal? If so, how much?<p>I have googled around and came across a few links and this excellent review http://www.anandtech.com/show/6372/memory-performance-16gb-ddr31333-to-ddr32400-on-ivy-bridge-igp-with-gskill .  But all of these seem to be in the context of gaming? Does it apply to programming too? <comment><USER2> I can tell you for Mechanical CAD models, both metrics matter. Same is true for CAM, which can generate absolutely huge data sets.

Additionally, Mechanical CAD (Solid Modeling) isn't multi-threaded in the vast majority of cases right now. There are some niches where it can help, but really we are still identifying how this might work.

For CAD, you want a very fast CPU and fast being single thread performance maximized, and then fast and a lot of RAM.

The order depends. Small, but complicated data sets favor speed over size.

Larger ones demand both.

On the software I work with, that big of a jump in RAM speed, coupled with a good CPU and cache can reach 30 percent faster update / build times. When those are seconds, nobody cares. When they are an hour, yeah. Big deal.

CAD is also compute intensive, meaning it's a great system stress case.

<comment><AUTHOR> Thanks ddingus!

</comment></comment><comment><USER3> Gaming is really, really different from programming.

As with most non-gaming activities, your bottleneck would most likely be your storage device. Get a great SSD.

Depending on what you're actually programming, your CPU, GPU, and RAM speed might matter a little. What are you programming?

<comment><AUTHOR> I will do lots of text parsing. I also will be doing some neural nets. Does RAM speed matter in this context?

<comment><USER3> For text parsing, it'll depend on your buffer size. If you're able to use a buffer smaller than a few GB, then you'll be fine for RAM. For parsing code or human language (or any file smaller than that), you won't need anything even close to that.

For neural nets, it depends heavily and how the code is optimized and what your inputs are. I know that isn't very helpful.

In general, the people I know who have trouble with high-end, consumer-grade hardware (~$1,000 in parts for a single machine) are usually researchers. Then you're getting to the point where you'd want to look into distributed processing.

<comment><AUTHOR> Thanks. that clarifies a lot.

</comment></comment></comment></comment><comment><USER4> Generally, Programming not very resource intensive so it requires very little ram..

<comment><USER3> I disagree with "generally". It depends on what kind of programming you do.

I'm a web developer, so when I'm programming, I often have a database GUI, full IDE, multiple browsers, multiple Docker containers, and RDBMS running.

That ends up at about 4GB of RAM, depending on what's in my database.

</comment></comment><comment><USER5> No</comment>


France makes billion euro tax claim against Google - <AUTHOR> http://finance.ninemsn.com.au/newsbusiness/8556732/france-makes-billion-euro-tax-claim-against-google-report

<comment><USER2> This basically seems like a tax on hyperlinking, which is at the core of the web. Absurd.

A Forbes article ([http://www.forbes.com/sites/timworstall/2012/10/30/explainin...](http://www.forbes.com/sites/timworstall/2012/10/30/explaining- this-french-thing-about-google-and-newspapers/)) explains further that the complaint from French publishers is about the portion of the search results page that shows links to those publishers' content (since that results page has ads on it). They could exclude themselves from indexing easily (and forego traffic of course).</comment>


The Amazon Flywheel (2016) - <AUTHOR> http://www.samseely.com/blog/2016/5/2/the-amazon-flywheel-part-1 <comment><USER2> > But all of this was only part of the Amazon recipe for customer experience. > The other half was lower prices, which, for a long time, Amazon mostly > maintained through ruthless willpower. (An example: the "no-more-free- > Ibuprofen" story.)

What is this ibuprofen story? Search results are just links to the article and product listings.

<comment><USER3> Here's a book relating the story of painkillers being removed before a reorg: [https://books.google.com/books?id=4pqCrMzKZxYC&pg=PA181&lpg=...](https://books.google.com/books?id=4pqCrMzKZxYC&pg=PA181&lpg=PA181&dq=amazon+cost+cutting+ibuprofen)

</comment></comment><comment><USER4> The article also links to [1], which explains why Amazon has no profits.

[1] [http://ben-evans.com/benedictevans/2014/9/4/why-amazon- has-n...](http://ben-evans.com/benedictevans/2014/9/4/why-amazon-has-no- profits-and-why-it-works)

</comment><comment><USER5> Part 2 of the post: [http://www.samseely.com/blog/amznsupplychain](http://www.samseely.com/blog/amznsupplychain)</comment>


Making wordpress shine with Varnish caching system: Part 1 - <AUTHOR> http://kaanon.com/blog/work/making-wordpress-shine-varnish-caching-system-part-1 <comment><AUTHOR> Perhaps ironically, the page is served from a Drupal site.</comment>