Posted by md
on November 02, 2009
Green energy is good. Finally, people around the world begin to realize that the climate change is a serious problem for mankind. Driving with a car harms the environment – more efficient cars (or electric vehicles) are the new SUVs. On the other hand, a lot of energy is consumed in private households. In Germany, energy-efficient remodeling is rewarded with cheap credits. Often, solar power is used to heat water and generate electricity. More and more wind parks are built which also draw their energy from the sun, indirectly.
Unfortunately, renewable energy source create problems for the conventional power grids. In a power grid, demand and supply of electricity must match at all times. If a consumer draws power from it, the exact amount of power needs to be fed back into the power grid as fast as possible. There is almost no reservoir for electrical power (except for pump storage hydro power plants, but the capacity is limited). Since renewable energy sources such as solar and wind power cannot be planned additional power capacities need to be in place in order to compensate for the lack of power.
Continue reading…
Posted by md
on September 16, 2009
I live close to the DCF77 radio transmitter, so my signal was always pretty strong and clear. This is of course not the case for everybody :-) Gwen Roelants did run into problems. He writes:
Although your code works (thanks for that!) it looked like it was very sensitive to how the antenna was positioned.
I found that I did receive a signal every second, but that for the longer signals, I sometimes got a short flash interrupting it, causing the library to add 2 seconds instead of one. Since I got such a flash in almost every minute it could take a very long time before a proper sync was found, and because 2 seconds were counted the time would also drift during the time no new signal could be decoded.
I found a rather simple fix for your code that greatly improved the reliability and time to find a correct signal.
I don’t have an Arduino around so I did not test it, but the proposed changes seem to be reasonable. You can find the changes in the Arduino forums. Thanks, Gwen!
The photo was CCed on flickr by Nathan Gibbs.
Posted by md
on April 17, 2009
I’m currently using Ruby to optimize schedules based on a simulated annealing approach. For my current intermediate version I rely on marshalling internal datastructures really frequently. Out of curiosity I compared the runtimes of Ruby 1.8 and 1.9:
- Ruby 1.8.6: 21 minutes, 55 seconds
- Ruby 1.9.0: 22 minutes, 13 seconds
I certainly did not expect any wonders, but in theis case, the runtimes are about the same. So I’m investigating further, using the ruby 1.8 profiler on a smaller test problem:
% cumulative self self total
time seconds seconds calls ms/call ms/call name
33.20 32.96 32.96 661 49.86 77.25 Marshal.load
17.80 50.63 17.67 6365 2.78 14.96 Array#each
17.52 68.03 17.40 601659 0.03 0.03 IO#getc
9.19 77.15 9.12 660 13.82 13.82 Marshal.dump
6.01 83.12 5.97 187158 0.03 0.03 Float#+
My code spends 42.39 percent of its runtime doing marshalling operations. For Ruby 1.9, the code spends 48.98 percent of its runtime doing marshalling. This is somewhat disappointing. In a second round I changed my code to not relying on marshalling – basically, I am using clone on essential internal datastructures. All other information can be reconstructed afterwards. This means that I need to recompute certain values, but evidently this is a much faster approach:
- Ruby 1.8.6: 1 minute, 34 seconds
- Ruby 1.9.0: 1 minute, 17 seconds
Note to self: always use a profiler before refactoring code for performance reasons.