Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).


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

by macklin01 (#48895229) Attached to: Bjarne Stroustrup Awarded 2015 Dahl-Nygaard Prize

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. :-)

Comment: Re:Not for deaf/hard of hearing... (Score 4, Insightful) 579

by macklin01 (#47369535) Attached to: Unintended Consequences For Traffic Safety Feature

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 ...

Comment: Re:'Radiation Free' (Score 1) 35

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 ...

Comment: Re:3D Printing is too complex. There is an easier (Score 1) 234

by macklin01 (#46106813) Attached to: 3D Printing of Human Tissue To Spark Ethics Debate

I disagree with a lot of the parent's post, but this part is reasonably solved. When you decellularize an ECM, the vessel walls remain intact. Then you reseed with HUVECs (an endothelial cell line), and they tend to find their way back onto the old vessel walls to form a vasculature.

But you are absolutely right that the microarchitecture of the tissue is very, very significant to proper function.

Comment: Re:3D Printing is too complex. There is an easier (Score 2) 234

by macklin01 (#46106797) Attached to: 3D Printing of Human Tissue To Spark Ethics Debate

While the ECM molecular components are conserved as you point out in another post, their distribution (e.g., how much collagen IV, matrix-embedded glycoproteins, etc.), stiffness, and microarchitecture vary quite a bit from species to species, organ to organ, and even individual to individual. And this radically affects the phenotype of the cells that you transplant on them. Both cancer and "normal" epithelial cells are known to change their motility, proliferation, and even polarization characteristics based upon the stiffness of the tissue, for example.

And take a look at livers: pig livers have a very thick membrane between hepatic lobules, making them great for textbooks, as you can very clearly see portal triads and central veins and the overall lobular outlines. Human tissue, by contrast, has very thin membranes between lobules that can scarcely be seen in H&E pathology. This makes pig liver ECM a very poor starting point for growing a human organ replacement. When our collaborators build bioengineered liver tissue, they actually start with decellularized ferret livers because their structures are closer to humans than pigs.

This is why a mix of 3-D printing and seeding progenitor cells could be promising in the future. If you could 3-D print the ECM to have the correct spatial distribution and mechanical properties, you'd have a much better starting point when you seed them with progenitor cells to grow the epithelium / parenchyme, HUVECs to grow the vessels, etc.

Aside: I have yet to see XCM in 10+ years of cancer research and tissue biomechanics work. It's ECM.

Behind every great computer sits a skinny little geek.