eonwe

This is only partially related, but I remember watching the news in the nineties and being dumbstruck on how Académie française policed the usage of language in public life. It was probably about use of Anglicisms in television or by politicians.

I forgot about it for years until I learned from Wikipedia that that wasn't just a reaaction against Internet, but a policy that has been going on for centuries: https://en.wikipedia.org/wiki/Vergonha

So the mandarinisation doesn't seem that odd against such a background. The similar effort bore fruit in France as I think now virtually all people in France speak Parisian French compared to 12% or so at the advent of French Revolution and the following policies.

Degrees cause higher earnings. Part of that effect is accumulated human capital in the form of the thing learned and new networks, but part of the degree is just signaling.

There's a drastic difference between earnings for unfinished and finished college degree and in general this effect is dubbed as sheepskin effect.

Here's a Wikipedia starter on the effect: https://en.wikipedia.org/wiki/Signalling_(economics)#Spence_...

It seems to have been introduced the same year as Pentium 2 which had clock rates of 233-300 MHz. I don't know about the architectural differences at that time, but at least currently Intel processors smoke ARMs with same clock rate. The difference was probably a lot less pronounced at that time as the architectures were simpler.

Only place I've seen some security checks was at Ben Gurion airport in Tel Aviv, where there was a mild security check when entering the airport.

This consisted of a small interview on what I've been doing in Israel, where I am going to, with whom and who packed my stuff. This all was before even entering the actual terminal building.

In some cases they could perhaps do the same thing that's done with Ruby: interpret the C-extensions.

It's not as crazy as it may seem and JRuby benefits hugely from it: http://chrisseaton.com/rubytruffle/cext/

To give you a counter-anecdote, I use macbooks in work. For the last five years, I've had two hardware failures and gray screens maybe once every four months. In addition to that, I have issues maybe once a month where the machine more or less locks up (from the logs it looks like windowserver/loginwindow has crashed and OS X is trying to do spindump to them).

Compare that with the _desktop_ Windows 7 machine. It first crashed intermittently (memory failures), but after I changed the motherboard, it has not crashed at all. But then again, I am not using, for example, the most cutting-edge graphic drivers.

I remember quite some crashes during the Windows XP times, but I've since taken a more conservative approach to hardware and drivers.

Thanks, this helped. Using CSC and CRS is probably quite problematic with JVM bounds check elimination (or the lack of it). So if they would need to be used on JVM, I think it would be wise to drop the safety and use _sun.misc.Unsafe_ for unchecked array access.

For normal dense matrix laid out as a double[] and accessed directly as i* N_ROW + j probably won't get its loop check elided. For double[][] I would _think_ that happens more easily.

But how are sparse matrices then generally laid out? A naive approach would be some hash map, perhaps with some locality, in which I don't see JIT problems.

Could you elaborate a bit on how JVM hinders reaching maximum FLOPS when multiplying sparse matrices?

I could think some examples where lacking SSE/AVX support would hinder it, but I don't see the connection with sparse matrices.

"The most familiar quotations are the most likely to be misquoted...Some have settled down to false versions that have obscured the true ones. They have passed over from literature into speech." -- Carl Van Doren (maybe)

I think this can be mostly implemented in Java with bytecode re-writing which will check for the conditions on time to time.

Stopping the thread can still leave some of the stuff in indeterminate state if the thread has some resources it needs to release manually.

I wonder how much of these problems static analysis could catch.

Also, does Google use fuzzing to test its own libraries? The original Stagefright bugs were found by a fuzzer: http://lcamtuf.coredump.cx/afl/

I've run into a few, but they've been mostly of the kind where a library/framework infers JDK version and assumes 1.8 is < 1.4 or whatever is the earliest they support.

Android has precise GC so it will free the unused memory even if there are loops within it.

What it won't help with are cases like: public class MainStuff { private byte[] myBuffer;

      public void doStuff() {
          myBuffer = new byte[20 * 1024 * 1024];
          doStuffWithBuffer(myBuffer);
      }
  
      private void doStuffWithBuffer(byte[] buffer) {
          /* omitted */
      }
  
  }

Here, we program keeps myBuffer around as long as MainStuff lives which can be very long if it is, say, a main class of your program.

It's just that the cases where the memory is kept around are not as easy for the programmer to spot as this example for reference-hierarchies are deeper.

To be a pedantic here, I don't think term amortized average cost is useful.

For what I've understood, average cost means average over all possible random inputs. So for specific set inputs, the cost can be larger than that.

Amortized cost means the average cost of the operation over any combination of inputs. So for specific set of inputs, the cost is the stated.

For hash table insertion, both the amortized and average cost can be O(1) with linked-list confliction resolution, but whereas average time of a lookup operation is O(1), amortized is larger (I don't know if there's analysis on this, but O(n) seems correct by gut-feeling).

Path dependence.

People keep saying that because an earlier version of the page did not include Nexus 4.

And robots doing what? Creating cardboard for the people in favelas to eat?

I think you're being a bit overly pessimistic here.

You can do that partially. Because of the sub-classing and covariant return-types, I think you cannot prevent a CustomCollection from returning a CustomList. The definition would be:

  public interface Mappable<T extends Mappable<T>> {
      T map();
  }

I feel the title should tell that the releases are because of a directory traversal vulnerability: https://groups.google.com/forum/#!msg/rubyonrails-security/N...

Depending on the software and what it's used for, the first class or errors might and should be recoverable from.

I've seen that set of slides before. But it's quite dense and seems to require (at least for me) Kahan's speech to get all the nuances.

As for the horrible floating point support, are there other factors than lack of signaling NaNs, being unable to set rounding mode and exception policy, floats using floats for intermediate results?

For many purposes such flaws don't seem that bad.

Why is Java code unable to use vector instructions? I guess there's something in the Java spec that prevent compilers from using them, but what is it? I think that the 80-bit floats the Intel FPU offers are used in Java by default unless a method is defined as strictfp, but this a different issue.

I'd like to see if there's a difference in the output and/or in the speed of the C results without -ffast-math.

That option results some changes in the floating point math (see http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Optimize-Options...) which Java is unable to set, but which may be okay for limited domain the DSP filter works in.

And then commit to the choice you've made: http://xkcd.com/310/

Not that I am so sure about he usefulness of this, but there is at least a double of this question:

  [typeof null, null instanceof Object]

Sadly, the IE7 compatibility-mode is not a perfect copy: http://blogs.msdn.com/b/ie/archive/2009/03/12/site-compatibi...

You might want to mark up your sarcasm slightly better as people are already falling for it in other posts you made.

Poe's law and all that.

One goal for prisons could be rehabilitation?

By usual I mean what our application was tuned for.

Which, sadly, may or may not be what it encounters. There are still some usage patterns that can cause large amount of time being spent doing gc (without Zing).

Latency was greatly reduced, I cannot really say about throughput (except that it was not clearly worse at least).

That seems to be the case in Oracle Java at least. With 80+ GB heaps, you can experience multi-minute stop-the-world collections when a full GC strikes. Luckily, that can be tuned to be very rare (for the usual load).

For better latency without such hiccups, the only solution I know of is Azul's Zing (http://www.azulsystems.com/zing/pgc) which really did away with larger pauses at least with our software.