A bit unrelated: I was just browsing your website (the one in your signature), and was noting that I couldn't watch the embedded youtube video (talking about this video). They are included as html object element and require flash to be played (which I don't have). Its better to support HTML5 as well by using a more modern embedding code via iframes. It will still offer a fallback for users who can't play back html5 videos, e.g. on outdated browsers. You can get the embed code by clicking "share" and then "embed".
Ah, thanks for the reminder! I worked on embedding those videos back in the HTML4 strict days. (And before YouTube, we had XVID-encoded AVI files, with a support page on how to play the videos.:-/ Embedded video has come a long, long way!)
I completely agree--they should be embedded as real HTML5, particularly as browser support is much more widespread now. And the "share / embed" code works very well for that now. I'll try to get back to it over the weekend.
Thanks for dropping by and giving the work a look! I plan to submit a method paper on PhysiCell (the 3-D agent-based model in the video you linked) and open source it soon. I should have some much cooler videos available for you then.;-)
For what it's worth, we're keeping our NCI-funded cancer/biology projects there for the time being. (We just posted our 3-D diffusion code there in December, and we're about to post 3-D agent-based models and parameter estimation code.) SourceForge was a good and user-friendly home to me when I just got started in open source, so I'm happy to keep trying it now and see where it goes.
We may have some feature requests down the road (some of which may already be there, but hidden behind UI design)...
I miss the old days where there was a side bar freshmeat feed of new SourceForge releases. Could we possible increase the SlashDot / SourceForge links this way? A running feed of releases would be nice, and it would help bring us back to our FOSS roots.
Also, in the scientific community (I'm in the cancer simulation field), "grand challenges" are popping up, where there would be a dataset or two, and a challenge to create an analysis or modeling tool for those data. Some really amazing creativity can emerge from those challenges.
It would be interesting if such a thing could be done here, similarly to the "ask slashdot" articles, but then linking to a development space on SourceForge to keep it going. I would love to engage the developer community here on our data standards and other cancer projects, and I hope they'd like to pitch in.
Thanks -- Paul
PS: Please consider stopping the SourceForge spam. I'm not sure I need any more "SourceForge Resources" emails on "Flash Storage for Dummies" and business intelligence / analytics / etc.
Thanks so much for introducing yourself and taking the time to respond to comments and questions.
On a related SourceForge note, I miss the old days where there was a side bar freshmeat feed of new SourceForge releases. Could we possible increase the SlashDot / SourceForge links this way? A running feed of releases would be nice, and it would help bring us back to our FOSS roots.
Also, in the scientific community (I'm in the cancer simulation field), "grand challenges" are popping up, where there would be a dataset or two, and a challenge to create an analysis or modeling tool for those data. Some really amazing creativity can emerge from those challenges.
It would be interesting if such a thing could be done here, similarly to the "ask slashdot" articles, but then linking to a development space on SourceForge to keep it going. I would love to engage the developer community here on our data standards and other cancer projects, and I hope they'd like to pitch in.
Thanks -- Paul
PS: Please consider stopping the SourceForge spam. I'm not sure I need any more "SourceForge Resources" emails on "Flash Storage for Dummies" and business intelligence / analytics / etc.
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)?
That's a really great point. So much of this has to do with sampling frequency vs. resolution. The whole thing is funny. The original article is bad enough, but the post on the article is that much worse.
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.
It's a deep-fried, breaded piece of meat product (usually chicken), best served with sweet and sour sauce. Proprietary synonyms include Chicken McNuggets
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
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."
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.
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.
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.:-)
It would be neat, however, to see gyroscope inputs added to regular audio inputs to improve speech-to-text. This seems to be a nice proof of concept for that.
It's not just that people can "write their own tickets", but that promotions and raises seem to happen much more at time of hire than after good performance. Work on that and there might be a lot less churn..
I've encountered these, and I'm told they're pretty loud.
I'm a fairly young guy (37 yo) with perfect hearing below about 1500 Hz, and almost zero hearing above 2000 Hz. To me, these loud clicks are tough to hear unless close up.
I run into the same problem with high-pitched fire alarms (most of them), the "you left your headlights on" beep, seat belt beeps, kitchen timers, the little beep on my FasTrak transponder, etc.
This is probably a widespread problem--we tend to lose hearing in the higher frequencies first. The solution isn't to use annoying high pitches and make them louder; the solution is to use broader frequencies or use lower pitches that more people can hear.
Please keep this in mind when you're considering using a little chirpy piezoelectric in your next circuit project...
I suspect the real story here is likely finding a good target (SFRP2), more so than the microbubbles. Finding a specific enough target always seems to be the limiting factor in immunotherapy, nanoparticle-based drug delivery, GNP-based radiothermal therapy, etc.
Now if they could find a good target for more cancers (I definitely agree on breast as a good target--elastography ultrasound is already a big topic of interest there), it could have a nice impact on treatment options. Since you can't really image too frequently by MRI, CT, etc. due to exposure limits, you can't do high-frequency watchful waiting, which biases clinicians and patients towards intervention when they detect something.
In breast cancer, this is a pretty hot topic: all these frequent / early mammograms are detecting lots of DCIS, and the standard thing to do is lumpectomy. But there's growing evidence that these are likely being overtreated, and many if left alone would likely not progress to invasive carcinoma for a long time. But since there's no great way to know on a patient-by-patient basis, and since you can't really keep a close eye on them by frequent imaging, it's tough to do otherwise.
But if you could image the breast cancer really well by ultrasound, you could do such a watchful waiting: image frequently, and so long as there's no change, keep monitoring. (Not sure if this would have have the resolution to detect an in situ cancer like DCIS, though. Will have to read the article.) It would be nice to see such watchful waiting options open up for other cancers where treatment choices are perhaps otherwise unclear.
I've also seen early work attempting to use interference patterns in ultrasound (putting a few piezoelectric membranes at the right spacing, etc.) to induce apoptosis at specific spots. It would be interesting to see if this work could help enhance that...
Slashdot Mirror
Completely agreed! I lurked for a long time before registering. (Too bad I passed up a low UID around 1997 when I started reading the site!)
Ah, thanks for the reminder! I worked on embedding those videos back in the HTML4 strict days. (And before YouTube, we had XVID-encoded AVI files, with a support page on how to play the videos. :-/ Embedded video has come a long, long way!)
I completely agree--they should be embedded as real HTML5, particularly as browser support is much more widespread now. And the "share / embed" code works very well for that now. I'll try to get back to it over the weekend.
Thanks for dropping by and giving the work a look! I plan to submit a method paper on PhysiCell (the 3-D agent-based model in the video you linked) and open source it soon. I should have some much cooler videos available for you then. ;-)
Very best -- Paul
For what it's worth, we're keeping our NCI-funded cancer/biology projects there for the time being. (We just posted our 3-D diffusion code there in December, and we're about to post 3-D agent-based models and parameter estimation code.) SourceForge was a good and user-friendly home to me when I just got started in open source, so I'm happy to keep trying it now and see where it goes.
We may have some feature requests down the road (some of which may already be there, but hidden behind UI design) ...
Thanks for all your work. -- Paul
I miss the old days where there was a side bar freshmeat feed of new SourceForge releases. Could we possible increase the SlashDot / SourceForge links this way? A running feed of releases would be nice, and it would help bring us back to our FOSS roots.
Also, in the scientific community (I'm in the cancer simulation field), "grand challenges" are popping up, where there would be a dataset or two, and a challenge to create an analysis or modeling tool for those data. Some really amazing creativity can emerge from those challenges.
It would be interesting if such a thing could be done here, similarly to the "ask slashdot" articles, but then linking to a development space on SourceForge to keep it going. I would love to engage the developer community here on our data standards and other cancer projects, and I hope they'd like to pitch in.
Thanks -- Paul
PS: Please consider stopping the SourceForge spam. I'm not sure I need any more "SourceForge Resources" emails on "Flash Storage for Dummies" and business intelligence / analytics / etc.
Thanks so much for introducing yourself and taking the time to respond to comments and questions.
On a related SourceForge note, I miss the old days where there was a side bar freshmeat feed of new SourceForge releases. Could we possible increase the SlashDot / SourceForge links this way? A running feed of releases would be nice, and it would help bring us back to our FOSS roots.
Also, in the scientific community (I'm in the cancer simulation field), "grand challenges" are popping up, where there would be a dataset or two, and a challenge to create an analysis or modeling tool for those data. Some really amazing creativity can emerge from those challenges.
It would be interesting if such a thing could be done here, similarly to the "ask slashdot" articles, but then linking to a development space on SourceForge to keep it going. I would love to engage the developer community here on our data standards and other cancer projects, and I hope they'd like to pitch in.
Thanks -- Paul
PS: Please consider stopping the SourceForge spam. I'm not sure I need any more "SourceForge Resources" emails on "Flash Storage for Dummies" and business intelligence / analytics / etc.
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.
That's a really great point. So much of this has to do with sampling frequency vs. resolution. The whole thing is funny. The original article is bad enough, but the post on the article is that much worse.
This gem caught my eye:
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:
It's a deep-fried, breaded piece of meat product (usually chicken), best served with sweet and sour sauce. Proprietary synonyms include Chicken McNuggets
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
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."
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.
Because scaling supersonic aerodynamics up to a spacecraft with twice the size is nontrivial?
Here's the TRUSTe info:
http://privacy.truste.com/privacy-seal/NQ-Mobile-US-Inc-/validation?rid=e0f97027-af9a-4b8a-91b5-2a33c58a520a
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.
In that exceedingly rare circumstance, there is the National Vaccine Injury Compensation Program.
Thanks! Will brush up in that more. Looks similar to what we avoid with operator+=, passing by reference, etc.
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. :-)
Indeed.
Funding will go to both Boeing and SpaceX:
NASA's tweet
It would be neat, however, to see gyroscope inputs added to regular audio inputs to improve speech-to-text. This seems to be a nice proof of concept for that.
It's not just that people can "write their own tickets", but that promotions and raises seem to happen much more at time of hire than after good performance. Work on that and there might be a lot less churn ..
I've encountered these, and I'm told they're pretty loud.
I'm a fairly young guy (37 yo) with perfect hearing below about 1500 Hz, and almost zero hearing above 2000 Hz. To me, these loud clicks are tough to hear unless close up.
I run into the same problem with high-pitched fire alarms (most of them), the "you left your headlights on" beep, seat belt beeps, kitchen timers, the little beep on my FasTrak transponder, etc.
This is probably a widespread problem--we tend to lose hearing in the higher frequencies first. The solution isn't to use annoying high pitches and make them louder; the solution is to use broader frequencies or use lower pitches that more people can hear.
Please keep this in mind when you're considering using a little chirpy piezoelectric in your next circuit project ...
BTW, that's a very cool paper! Have you considered using these techniques towards image processing, segmentation, etc.?
We also use very similar force algorithms in our cancer models. :-) e.g., http://www.sciencedirect.com/s...
The description of the agents and forces in this summary was actually very well done.
Shouldn't this be 1.7 decaearths?
Since the sun is about 333 kiloearths in mass, wouldn't a megaearth be about 3 solar masses? :-)
I suspect the real story here is likely finding a good target (SFRP2), more so than the microbubbles. Finding a specific enough target always seems to be the limiting factor in immunotherapy, nanoparticle-based drug delivery, GNP-based radiothermal therapy, etc.
Now if they could find a good target for more cancers (I definitely agree on breast as a good target--elastography ultrasound is already a big topic of interest there), it could have a nice impact on treatment options. Since you can't really image too frequently by MRI, CT, etc. due to exposure limits, you can't do high-frequency watchful waiting, which biases clinicians and patients towards intervention when they detect something.
In breast cancer, this is a pretty hot topic: all these frequent / early mammograms are detecting lots of DCIS, and the standard thing to do is lumpectomy. But there's growing evidence that these are likely being overtreated, and many if left alone would likely not progress to invasive carcinoma for a long time. But since there's no great way to know on a patient-by-patient basis, and since you can't really keep a close eye on them by frequent imaging, it's tough to do otherwise.
But if you could image the breast cancer really well by ultrasound, you could do such a watchful waiting: image frequently, and so long as there's no change, keep monitoring. (Not sure if this would have have the resolution to detect an in situ cancer like DCIS, though. Will have to read the article.) It would be nice to see such watchful waiting options open up for other cancers where treatment choices are perhaps otherwise unclear.
I've also seen early work attempting to use interference patterns in ultrasound (putting a few piezoelectric membranes at the right spacing, etc.) to induce apoptosis at specific spots. It would be interesting to see if this work could help enhance that ...