bkil vs. programming

Here's a neat little utility function which I commonly find useful. ef2_1 :: (a -> a -> a) -> (a -> a -> Bool) -> [a] -> [a] -> [a] ef2_1 = ef0 [] where  ef0 zs f lt (x:xs) (y:ys) | lt x y = ef0 (x:zs) f lt xs (y:ys)  ef0 zs f lt (x:xs) (y:ys) | lt y x = ef0 (y:zs) f lt (x:xs) ys  ef0 zs f lt (x:xs) (y:ys) = ef0 (f x y:zs) f lt xs ys  ef0 zs _ _ xr yr = reverse $ xr ++ yr ++ zs main = print $ ef2_1 (\x _->x) (\(x,_) (y,_)->x<y) d1 d2 where  d1 = [(1,9), (3,8), (4,7), (5,6), (7,5)]  d2 = [(2,5), (4,4), (6,3)]

It would make a difference if they have published the exact synchronization of traffic lights and/or broadcast timely phase signals (via UDP over GPRS or such). Using this data combined with the readings of the bicycle odometer, software on your PDA or mobile phone could continuously suggest a velocity that should minimize idling at each traffic light. Manual settings for maximal speed, acceleration and cardiovascular pulse could be given. Note that this strategy only works well for uncongested networks, like dedicated bicycle lanes or paths. Trained cyclist already apply a similar technique manually, however, not all lights are synchronized to each other.

let f l 1=l++[1];f l k|mod k 2==0=f(l++[k])(div k 2);f l k=f(l++[k])(3*k+1)in putStr $ unlines $ map (show . f[]) [1..11] let f l 1=reverse(1:l);f l k|mod k 2==0=f(k:l)(div k 2);f l k=f(k:l)(3*k+1)in putStr $ unlines $ map (show . f[]) [1..11] let f 1=Nothing;f k=Just(g k,g k);g k|mod k 2==0=div k 2;g k=3*k+1 in putStr $ unlines $ map (show . \n -> n:unfoldr f n) [1..11] let f 1=Nothing;f k=let x=(if mod k 2==0 then div k 2 else 3*k+1)in Just(x,x)in putStr $ unlines $ map (show . \n -> n:unfoldr f n) [1..11]

They have conducted the following interesting experiment. Electrodes were placed on the skin of a subject at the neck. Then a specially trained person imitated a phone call without sounding an utterance or even moving his lips! They say, when "articulating" text in one's mind, the nerves relevant to speech are activated similarly to when reading the text aloud. They have achieved fair decoding accuracy from these signals. There could exist many use cases for an interface built around these findings. On top of all previously known applications for speech recognition, those could also be realized which were inappropriate at certain locations because of the noise induced by speech. Imagine the workplace perspective of talking on the phone without opening your lips or making any sound, all with the speed of speech! Too bad it has such a low speed in practise today. I wonder how far they can push it. You can also view a video demonstration at the original article: Nerve-tappin...

I've been considering if it would make sense to construct a bike "from scratch" using general materials for a frame. It could also be equipped with standard bicycle components to make repairs much easier. The concept of building the frame (and thus the bike) akin to playing with a metal toy construction set sounds interesting. It would allow great innovation in portability.

It would be feasible to protect as much information created by the user as possible. Certain software have evolved the ability to partially provide a feature similar to this via periodically created temporary document copies (editors) or constantly refreshed configuration files (browsers). Most of them use their own, unconfigurable, error-prone ad-hoc solutions. I propose that a solution be found at the operating system level which any software can reuse. Keyboard input could be considered the most entropy rich for most users, however, selection and positioning via the mouse pointer must also be taken into account. The good solution would probably model widget activation in an abstract manner.

WorstBuy Trains Employees to Boo Linux to Customers [linuxinnovations] Microsoft 'indoctrinates' Best Buy workers with anti-Linux 'lies' [DailyFinance] "First they ignore you, then they laugh at you, then they fight you, then you win." - Mohandas Karamchand Gandhi