Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
Slashdot Deals: Deal of the Day - 6 month subscription of Pandora One at 46% off. ×

Comment First fully reusable? (Score 2) 111

This is the first time that a vehicle has made it into space and had all components fully recovered for reuse since the NASA flights of the X-15 in the 1960s

Weren't both the White Knight and SpaceShipOne fully recovered for reuse? Wasn't that the point of the X-prize (and doing it twice in two weeks)?

links: SpaceShipOne and X-Prize.

Comment Fantastic math there, guys (Score 4, Interesting) 131

This gem caught my eye:

To test the theory some experiments were performed. A consumer quality GPS was walked around a 10m square with segment lengths of 1m and 5m. The average measured segments were 1.2m and 5.6m. That is, an overestimate of between 20% and 60%. Clearly a smaller segment length is a good idea.

That's some amazing math there. (1.2 m - 1.0 m) / 1 m = 0.2, indeed a relative error of 20%. But (5.6 m - 5.0 m) / 5 m = 0.12, a relative error of 12%, not 60%! So, let's fix this thing, with of course the opposite conclusion:

To test the theory some experiments were performed. A consumer quality GPS was walked around a 10m square with segment lengths of 1m and 5m. The average measured segments were 1.2m and 5.6m. That is, an overestimate of between 20% and 12%. Clearly a longer segment length is a good idea.

Comment Re:Bad design? (Score 1) 64

That's foolish beyond reason (shock, amazement) because every boarding pass I've ever had has had personal information right on it that I'd rather not leave to the whims of trash collection. I haven't flown in a while (hate it now) but it's easy enough to keep your documents in your suitcase until you get home.

OK, I appreciate a good discussion, and you made me think twice about it. I went back and looked at a boarding pass (United). Please tell me what personal information I'm missing that's "foolish beyond reason" to throw out:
Name: not top-secret
Starting point/flight time: not sensitive after travel is done
Destination/landing time: not sensitive after travel is done
Flight number: not sensitive after travel is done
date: not sesitive after travel is done
gate: not terribly sensitive
seat: well, I suppose I'll guard this information jealously
boarding group: not sensitive
reservation confirmation code: not useful after flight
ticket number: not useful after flight
last 3 digits of United frequent flyer pass: the only thing that is remotely sensitive

In particular, I don't see an credit card information, home address, social security number, date of birth, driver's license number, or passport number. The receipt for any luggage payments is another matter, but what am I missing on the boarding pass? Thanks -- Paul

Comment Re:Bad design? (Score 1) 64

Is it actually bad design? It's fault-tolerant design. If there's a problem with their network, they can still retrieve the data from the boarding pass itself. Protect your boarding pass, and you won't have a problem. You were already planning to treat it as a secret, right?

And how many people are shredding their boarding passes when they get home instead of throwing them away?

This doesn't seem to be current practice, because most regard it as a "permission slip to board an individual flight" instead of a "embedding of personalized information beyond the individual flight."

Comment Re:What? (Score 4, Informative) 14

Hi, I've used a FuelBand (SE+) for a year or so.

They do log / track locally. There is enough onboard memory to store several days' worth of activity, in one minute increments as far as I can tell. (I only sync my data once a day when recharging by USB, but I've often gone a few days between. All the data make it home.)

Moreover, the FuelBand has a display that gives real-time feedback: it can give you move reminders if you've been still for too long, or "encouragement" if you start up. (I've disabled this feature on mine.) It makes a little animation when you've hit your daily goal. You can press the button to get statistics on Fuel (more on that in a moment), number of steps, and number of "hours won" (hours with at least several minutes of continuous activity) at any time in the day.

So yes, there is local storage, tracked minute by minute, accessible on demand for visual feedback. It can communicate via Bluetooth with an Android phone or iPhone for a bit more capability. (The button broke on my FuelBand, so this is my sole means of real-time communication with the device.)

I'd imagine that where they might have had more trouble is the "health" than the "tracking". They use an arbitrary unit called "Fuel" that correlates well with physical activity, but tries to scale many types of activity onto a single unit of measure. I've noticed that on very inactive days (couch potato sick day), I'm under 1000 Fuel. On a moderately active office day where I take a walk in the afternoon, 2000-2500. On days where I go for a run, 4000-5000+. It seems to scale well. But they may not have enough trials and other tests to validate that tracking Fuel means tracking health.

Comment Re:Web sites (Score 4, Informative) 277

Here's the TRUSTe info:

It only seems to cover security/privacy of their ecommerce site. So, their shopping cart may be secure, but it says nothing about app security as they seem to imply in their press releases, etc.

Comment Re:Is FORTRAN still winning? Was Re:Poor Alan Kay (Score 1) 200

Repeatedly allocating and deallocating can give a huge performance hit, so I tend to do all my allocations before the main loop. Not entirely sure why the penalty is so big, but it seems to be - these are allocations of hundreds of MB or even a few GB, so the cost of operations done on the arrays should dwarf the cost of the allocation.

It's a hardware thing -- the memory bus and memory read/write speeds are still a limiting factors, particularly as CPU cores get faster and more efficient. In any code, memory operations (allocations, copies, and deallocations) are performance killers and best avoided wherever possible (e.g., pre-allocating memory as you are, using temp variables that don't get deallocated, overloading operator+= operations to avoid hidden allocation and copy operations, etc.) The general rule:

[Disk access] is much slower than [memory access] is much slower than [CPU operations] (esp. those in the cache)

FWIW, I'm writing big finite volume codes in C++ (preparing for an open source release), and we deal with these very same issues. Our biggest performance gains (outside of choosing stable algorithms without time step restrictions and using OpenMP) are from avoiding memory allocations and copies, working on vectors of variables rather than individual variables, overloading things like operator+= on std::vector, and using BLAS (particularly axpy). Also identifying any operations that can be pre-computed (like certain steps in Thomas solvers) is helpful. :-)

You can tell the ideals of a nation by its advertisements. -- Norman Douglas