One interesting paper I read from this years SIGGRAPH paper on the creation of an interesting real life tagging technology called Bokode. Here’s a DIY page detailing an implementation. It’s really quite simple (and neat!) I might have to code this together.
Yep, I’m actually at the NVIDIA (why do I type NVIDIA like nVidia? everything seems to indicate that it is all caps now, I dunno) GPU Technology Conference, trying to once again get into the swing of things with respect to GPUs. Sadly, almost everything I know about computer graphics (which is actually considerable) predates the ongoing revolution that GPUs have brought to the table. We’ll see if some of this sticks this time around. For the first time, I’m beginning to grasp the functionality of current machines, and see where the evolution is going such that I feel it might be worth committing a significant fraction of my (seemingly always shrinking) store of available brain cells.
It’s about time for the 2nd day keynote by Hanspeter Pfister from Harvard, to start. I was lucky enough to serve with Hanspeter on a SIGGRAPH Sketch committee a few years back, and it seems like he’s been busy since then.
I might blog more about what’s going on here, but you might as well track what’s going on using NVIDIA’s official conference blog:
My previous post on using PyEphem to compute satellite locations was based upon my experience with the latest version (184.108.40.206). Apparently this includes a fairly serious change to previous versions: by default my FreeBSD box seems to install 220.127.116.11 still, and the
next_pass method for observers doesn’t exist. So I thought I’d go back and use whatever calls they did, but
next_rising followed by
next_setting didn’t seem to return what I would expect. For example, this little program (first find the next rising, then, after that, return the next setting):
#!/usr/bin/env python import sys import os try: import ephem print "Using pyephem version", ephem.__version__ except: print "couldn't find an installed version of pyephem" print "try downloading and installing it from http://rhodesmill.org/pyephem/" sys.exit(1) iss = ephem.readtle("ISS (ZARYA) ", "1 25544U 98067A 09270.93046296 .00012316 00000-0 87133-4 0 6870", "2 25544 51.6378 139.3506 0009010 136.5725 48.2903 15.74423743622138") obs = ephem.city("San Francisco") iss.compute(obs) print "ISS is currently at alt %f az %f" % (iss.alt, iss.az) rise = obs.next_rising(iss) set = obs.next_setting(iss) print rise, set sys.exit(0)
When I run this rather simple little program, I get this:
Using pyephem version 18.104.22.168 ISS is currently at alt -1.181396 az 4.241607 Traceback (most recent call last): File "./iss", line 22, in <module> rise = obs.next_rising(iss) File "/usr/local/lib/python2.5/site-packages/ephem/__init__.py", line 385, in next_rising return self._riset_helper(body, start, True, False) File "/usr/local/lib/python2.5/site-packages/ephem/__init__.py", line 363, in _riset_helper d1 = visit_transit() File "/usr/local/lib/python2.5/site-packages/ephem/__init__.py", line 317, in visit_transit % (body.name, d)) ephem.NeverUpError: 'ISS (ZARYA)' transits below the horizon at 2009/10/2 07:44:16
I haven’t tracked down what the deal is with this yet, but maybe I should keep on with my Python Plan13 code a bit longer.