--- Day changed Sat Sep 05 2009 00:09 -!- ve [n=a@94-193-95-252.zone7.bethere.co.uk] has quit [Read error: 110 (Connection timed out)] 00:09 -!- ve_ is now known as ve 00:12 -!- mason-l [n=x@202-89-188-136.static.dsl.amnet.net.au] has quit [Remote closed the connection] 00:32 < fenn> "A more subtle virus which targets intellectual property is the GNU public license, which has infected countless pieces of property to date, destroying capitalistic opportunity; the GNU public license is 35kbytes." 00:33 < fenn> poor poor capitalism 01:23 -!- mason-l [n=x@202-89-188-136.static.dsl.amnet.net.au] has joined #hplusroadmap 01:29 -!- genehacker [n=noko@pool-173-57-48-104.dllstx.fios.verizon.net] has quit [Read error: 104 (Connection reset by peer)] 01:29 -!- genehacker [n=noko@pool-173-57-48-104.dllstx.fios.verizon.net] has joined #hplusroadmap 01:32 -!- parolang [n=user@keholmes.oregonrd-wifi-1261.amplex.net] has quit [Read error: 110 (Connection timed out)] 01:42 -!- wrldpc2 [n=benny@ool-ad03fe34.dyn.optonline.net] has joined #hplusroadmap 01:43 < wrldpc2> http://www.filedropper.com/theblacksmithscraft-1952 02:13 -!- mason-l [n=x@202-89-188-136.static.dsl.amnet.net.au] has quit [Read error: 60 (Operation timed out)] 02:26 -!- mason-l [n=x@202-89-188-136.static.dsl.amnet.net.au] has joined #hplusroadmap 02:43 -!- nchaimov [n=cowtown@c-24-21-45-17.hsd1.wa.comcast.net] has quit [] 02:48 -!- nchaimov [n=cowtown@c-24-21-45-17.hsd1.wa.comcast.net] has joined #hplusroadmap 03:05 -!- nchaimov [n=cowtown@c-24-21-45-17.hsd1.wa.comcast.net] has quit [Read error: 104 (Connection reset by peer)] 03:05 -!- nchaimov [n=cowtown@c-24-21-45-17.hsd1.wa.comcast.net] has joined #hplusroadmap 03:57 -!- genehacker [n=noko@pool-173-57-48-104.dllstx.fios.verizon.net] has quit [Read error: 60 (Operation timed out)] 04:39 < CIA-32> skdb: fenn * r de3d4d3 /packages/threads/threads.py: start describing standard thread series 04:39 < CIA-32> skdb: fenn * r 0c58288 /packages/threads/threads.py: finished UNC and UNF series. not sure where to find data for ISO_Fine_Thread yet 05:08 -!- drazak [n=drazak@drazak.net] has quit [Read error: 60 (Operation timed out)] 05:19 -!- drazak [n=drazak@drazak.net] has joined #hplusroadmap 07:04 -!- wrldpc2_ [n=benny@ool-ad03fe34.dyn.optonline.net] has joined #hplusroadmap 07:04 -!- wrldpc2 [n=benny@ool-ad03fe34.dyn.optonline.net] has quit [Read error: 104 (Connection reset by peer)] 07:04 -!- wrldpc2_ is now known as wrldpc2 07:25 < fenn> guh. from UN declaration of human rights: (3) Parents have a prior right to choose the kind of education that shall be given to their children. 07:26 < fenn> Elementary education shall be compulsory. 07:44 -!- wrldpc2 [n=benny@ool-ad03fe34.dyn.optonline.net] has quit [] 08:05 < CIA-32> skdb: fenn * r a68395c /core/units.py: uncertainty is actually a range of units, not a unit itself 08:05 < CIA-32> skdb: fenn * r fa04ebe /packages/threads/threads.py: Merge branch 'master' of adl.serveftp.org:/var/www/skdb 08:18 -!- any25527960 [n=someone@75-120-45-160.dyn.centurytel.net] has joined #hplusroadmap 08:32 < kanzure> IBM autopass: "Autopass: An Automatic Programming System for Computer-Controlled Mechanical Assembly" 08:33 < kanzure> hm there's an ieee comp sci journal called "tutorial on robotics" 08:33 -!- any85001797 [n=someone@75-120-45-160.dyn.centurytel.net] has joined #hplusroadmap 08:33 -!- katsmeow-afk [n=someone@75-120-23-164.dyn.centurytel.net] has quit [Nick collision from services.] 08:34 -!- any85001797 is now known as katsmeow-afk 08:35 < kanzure> "The AUTOPASS language is oriented towards objects and assembly operations, rather than motions of mechanical assembly machines. It is intended to enable the user to concentrate on the overall assembly sequence and to program with English-like statements using names and terminology that are familiar to him." 08:35 < kanzure> "To relate assembly operations to manipulator motions, the AUTOPASS compiler uses an internal representation of the assembly world. This representation consists of a geometric data base generated prior to compilation and updated during compilation; it thus represents the state of the world at each assembly step." 08:36 -!- kardan| [n=kardan@p54BE454F.dip.t-dialin.net] has joined #hplusroadmap 08:36 < kanzure> stalk: lieberman, wesley 08:39 -!- any25527960 [n=someone@75-120-45-160.dyn.centurytel.net] has quit [Read error: 60 (Operation timed out)] 08:40 < kanzure> ibm journal of research and development, ridiculously large bibtex bibliography: http://ftp.math.utah.edu/pub//tex/bib/ibmjrd.html 08:46 < kanzure> http://en.wikipedia.org/wiki/A_Manufacturing_Language 08:46 < kanzure> stubs suck :( 08:49 < fenn> pot, meet kettle 08:49 < kanzure> ah here's the pdf: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.87.4319&rep=rep1&type=pdf 08:50 < kanzure> for the autopass paper, I mean 08:50 < fenn> just from the quote it sounds like it was written in fortran or something 08:53 < fenn> it's impeccably typeset for a 1977 paper 08:55 < fenn> looking at the 'functional module hierarchy' of the movement planner, it seems to be pretty advanced 08:55 < fenn> collision detection with swept volumes.. i can't even do that with all the tools at my disposal 08:56 < kanzure> page 332 shows the grammar (somewhat) 08:57 < kanzure> it was a PS/1 language 08:57 < kanzure> IIRC, that dates even fortran 08:57 < kanzure> not sure why those commands just so happen to be the ones they cohse 08:57 < kanzure> *chose 08:57 -!- |kardan| [n=kardan@p54BE5EDB.dip.t-dialin.net] has quit [Read error: 110 (Connection timed out)] 08:57 < ybit> well i'm impressed 08:57 < fenn> eh? what's special about the commands? 08:58 < ybit> heh, not the commands, autopass itself 08:58 < kanzure> place, insert, extract, lift, lower, slide, push, orient, turn, grasp, move, release, operate, clamp, unclamp, load, unload, fetch, replace, switch, lock, unlock, attach, drive in, rivet, fasten, unfasten, verify, open state, closed state, name assembly 08:58 < kanzure> well why are those the commands? 08:59 < kanzure> I mean, how did they figure that this would be good enough? 08:59 < fenn> seems rather arbitrary to me 08:59 < kanzure> yeah 08:59 < ybit> kanzure: how'd you come across autopass, nearly every page with it is expired 08:59 < ybit> would have to be while scraping for papers 09:01 < kanzure> ybit: no, it was a search result for one of my google scholar queries about assembly operations and assembly planners 09:03 < fenn> i don't think it's super worthwhile to worry about what particular verbs to use if there's no code to back it up 09:04 < kanzure> well I had this dream last night that a better way to do it would be as follows: 09:04 < kanzure> actions are specified as some collection of Vector, Torque, Force objects (the last two have yet to be written) 09:04 < kanzure> or, actually, those are Unit objects, so nevermind 09:04 < fenn> ugh 09:04 < kanzure> anyway, these actions have a definition 09:04 < kanzure> and they are matched to whatever verbs the tool has 09:04 < kanzure> so the tool then executes the verb that fulfills the action 09:05 < fenn> but that says nothing about what you're actually trying to do 09:05 < kanzure> yes but it solves the other problem 09:05 < fenn> vector+torque+force != drilling a hole, or aligning some part wrt another part 09:05 < kanzure> the one where you're making up batshit fucking crazy verbs 09:06 < kanzure> I think it would be adequate to have a text description appended I guess 09:06 < kanzure> vector+torque+force "drill a hole from here to there" 09:06 < fenn> the thing is they're intrinsically closed loop processes.. and you're trying to describe it as if it were open loop 09:06 < kanzure> what is a closed loop process? 09:06 < fenn> uh, like the difference between a stepper and servo 09:06 < fenn> not some ecological bullshit 09:07 < kanzure> you lost me 09:07 < fenn> servos utilize feedback from sensors 09:07 < fenn> steppers blindly assume that everything is perfect 09:07 < kanzure> which one is closed and which one is open 09:07 < fenn> servo = closed feedback loop 09:07 < kanzure> yet it's getting data input? 09:08 < fenn> because a command goes out, changes the state of the motor, is sensed, and comes back into the control 09:08 < fenn> closed like a closed circuit 09:08 < kanzure> ok 09:08 < kanzure> so just add an end condition then 09:09 < kanzure> vector+force... the vector has a starting position and an end position 09:09 < kanzure> er that's not a vector 09:09 < kanzure> but you get the idea 09:09 < fenn> FAIL 09:09 < kanzure> some geometric description object 09:09 < kanzure> like a line maybe 09:09 < fenn> yeah, welcome to my world 09:09 < fenn> remember me asking about a geometric constraints language? 09:09 < kanzure> yes but that was in a different context 09:09 < fenn> not really 09:10 * kanzure is thinking about instruction generation if you haven't noticed 09:10 < kanzure> I'm sure it can be applied in both areas 09:10 < fenn> putting a slab on a milling machine is a sort of assembly process 09:10 < kanzure> "putting" isn't in your taxonomy though 09:10 < kanzure> your process taxonomy I mean 09:10 < fenn> it doesn't just sit there, you have to bolt it down a certain way 09:11 < fenn> the manufacturing techniques book assumes it's a machine doing the work 09:11 < fenn> blarg 09:11 < kanzure> we are the blarg, you will be assimilated 09:12 < fenn> a robot would have a certain positioning tolerance, but depending on the human and how much effort they expended you could get anywhere from 0.001" to 10" position error 09:12 < kanzure> yeah 09:12 < fenn> or more, depending on context 09:12 < fenn> 'put beacon at these geospatial coordinates' 09:13 < kanzure> yes but where did that string come from 09:13 < fenn> package "robot corral" 09:13 < kanzure> wtf? 09:13 < kanzure> so there's a corral tool that is telling you to put something somewhere? 09:14 < kanzure> honestly I don't think you've thought this out either 09:14 < fenn> what's the problem now? 09:14 < kanzure> instruction generation 09:14 < kanzure> it's on the todo list, you see 09:14 < fenn> that's so overly broad as to be almost useless 09:15 < kanzure> the todo list? 09:15 < fenn> no, "instruction generation" 09:15 < kanzure> do you know what instructions are? 09:15 < fenn> yes 09:15 < kanzure> an assembly doesn't just magically assemble 09:16 < fenn> it's sort of like "write me a program that plays games" 09:16 < kanzure> does it need to play well? 09:16 < kanzure> actually I think you could do something where you have a config file where you tell it what key codes to send 09:16 < fenn> and then getting mad because the program doesn't understand your poker terminology 09:16 < kanzure> and then have it randomly select which keys to press 09:16 < kanzure> no, most games have only a limited amount of input 09:16 < kanzure> and games that require a mouse suck anyway 09:17 < fenn> i wasn't talking about computer games 09:17 < fenn> any sort of game 09:17 < fenn> that's how broad "instructions" is 09:17 < kanzure> I disagree 09:17 < kanzure> to me I see an assembly graph and I see connections between parts 09:17 < fenn> that's just assembly instructions 09:17 < kanzure> yes 09:18 < fenn> there's a lot more to manufacturing than just assembly 09:19 < kanzure> when we come up with manufacturing classes we'll do that then 09:19 < kanzure> but for now shouldn't we be working with the assembly graph class we already have? 09:19 < fenn> the igraph thing? 09:19 < kanzure> er, the graph of connections for assemblies 09:20 < fenn> -_- 09:20 < kanzure> so yes? 09:20 < kanzure> I haven't looked at the code 09:20 < kanzure> you deleted what I wrote, but I'm assuming it does the same thing 09:20 < fenn> well, for one thing there's not enough information there 09:20 < fenn> i didn't delete it 09:21 < fenn> anyway it does the same thing i guess 09:21 < kanzure> ok you put it into a go_away string :p 09:21 < fenn> only my local copy 09:21 < fenn> rest assured your crap is still there 09:22 < kanzure> what information do you think is missing? 09:22 < fenn> uh. so anyway as i was saying, there's not enough information to figure out how to assemble the lego graph, because we don't have geometric collision detection or even something like david's rectangular constraint 09:23 < kanzure> "press lego1 to lego2" isn't good? 09:23 < fenn> no 09:23 < kanzure> I think we should try it out actually 09:23 < fenn> how do you know what order to assemble the legos? 09:23 < kanzure> you make a lego assembly, we press "generate" 09:23 < kanzure> the order in which they were added would be a good start 09:23 < kanzure> and then I try to make it on the table 09:23 < fenn> magical thinking 09:23 < kanzure> ? 09:23 < fenn> it won't work. actually you were the one that told me that 09:23 < kanzure> was I on or off the drugs? 09:24 < fenn> sometimes it adds bricks in between other bricks (not colliding, just impossible to do in that order) 09:24 * ybit wants to know what is doing the adding of lego bricks 09:24 < fenn> add_lego() 09:24 < ybit> what machine 09:24 < kanzure> a chimpanzee 09:24 < fenn> uh, "minsky" 09:24 < fenn> ybit: not a robot, if you're confused 09:25 < fenn> this is virtual legos 09:25 < ybit> no i figured it was a name of one of the computers there so you are saying it's simulated 09:25 < fenn> i guess i could constrain it to only add bricks where the interface vector is clear.. but without collision detection i dont know how to implement that 09:26 < kanzure> "is clear" what? 09:26 < fenn> sweep the volume of the added brick along the interface vector; boolean intersect with all the other bricks; if you get a volume back it must have collided with something 09:26 < fenn> but that's horribly computationally expensive 09:27 < fenn> humans do it with feedback; in effect using reality as a massively parallel computer 09:27 < kanzure> oh you mean to check if the approach motion would be possible 09:27 < fenn> yes 09:28 < fenn> ever played "operation"? 09:28 < ybit> :) 09:30 < fenn> in other news, metric thread tolerance classes are confusing 09:31 < ybit> kanzure: when you lieberman, are you referring to J. Lieberman who was a co-author of 'introduction to operations research'? 09:31 < kanzure> no 09:31 < ybit> +say 09:31 < kanzure> the author of autopass 09:31 < ybit> wouldn't know since i can't read pdfs currently 09:32 < ybit> LI Lieberman 09:42 < fenn> kanzure: do you know of any papers that actually do collision detection in assembly planning? 09:44 < kanzure> no 09:45 < fenn> "development of computer aided assembly planning systems have not, in general, been successful... One of the main reasons for this lack of success is that assembly is dependent on a great deal of expert knowledge which has proven very difficult to formalize" 09:45 < kanzure> eh? that's the difficulty? 09:45 < ybit> Virtual Reality in Assembly Simulation?Collision Detection, Simulation Algorithms, and ... 09:45 < kanzure> some of these may be useful: http://adl.serveftp.org/papers/review/ 09:45 < ybit> that's the closest thing to what you guys are doing currently 09:45 < kanzure> but none of them are specifically about collision detection 09:46 < kanzure> for instance: A connector-based hierarchical approach to assembly sequence planning for mechanical assemblies 09:46 < ybit> http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.125.7125&rep=rep1&type=pdf Fast continuous collision detection between rigid bodies 09:46 < kanzure> Constraint-based interactive assembly planning 09:46 < fenn> ybit: that paper (VADE) is basically just "make a human do the assembly planning, wah!" 09:47 < ybit> heh, i can't read, just finding titles which seem relevant 09:48 < ybit> i don't see anything as requested 09:49 < kanzure> how about this one? 09:49 < kanzure> http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.50.4931&rep=rep1&type=pdf 09:49 < fenn> VADE simulates inter-part interaction for planar and axisymmetric parts using constrained motions along axes/planes. These axes and planes are obtained as part of the assembly design intent from the CAD system. This allows simulation of sliding, rotating, etc., without compute-expensive numerical methods 09:49 < kanzure> "A general framework for assembly planning - the motion space approach" 09:49 < ybit> http://www.informaworld.com/smpp/ftinterface?content=a713804846&rt=0&format=pdf Motion planning for multi-robot assembly systems is kind of what you were talking about a few mins ago 09:49 < kanzure> ybit: you can stop 09:49 < kanzure> at least read the paper a little bit :) 09:49 < ybit> :) 09:49 < ybit> that was the last one anyway 09:53 < fenn> gah that citseer paper is so slow to render 09:53 < kanzure> it renders just fine in evince 09:54 < kanzure> why am I using evince 09:54 < ybit> because you haven't realized kpdf is the bomb-diggidy 09:55 < ybit> only gripe is that it doesn't handle chm files 09:55 < ybit> have to use a seperate viewer such as kchmviewer 09:58 < fenn> does evince do chm? 09:59 < fenn> too slow and too mathy.. /me gives up 10:02 < kanzure> "spatial constraint graphs" 10:02 < kanzure> "this graph represents the list of obstructing parts that prevent the mating of other part along certain mating directions if the blocking parts are placed earlier in the sequence than the other part." 10:02 < kanzure> "the SCG is a directed graph in which the source node denotes the obstructed part and each of the arcs ends in an obstructing part" 10:03 < kanzure> apparently there are some algorithms for generating SCGs in "An integrated approach to automated assembly planning for three-dimensional mechanical products" 10:03 < fenn> i don't really think graphs are the way to do thi 10:03 < fenn> s.. 10:04 < kanzure> well using a GPU for collision detection of loaded models isn't the way to do it either :p 10:05 < fenn> no? 10:05 < fenn> sounds like awesome to me 10:06 < fenn> i'm thinking something involving voronoi diagrams or electrostatic force like the graph layout algorithms 10:06 < kanzure> gah isn't this campbell's job? 10:07 < fenn> don't make me talk bad about the man behind his back 10:07 < kanzure> how about in front? 10:08 < fenn> i guess i can add assembly planning to the lunch agenda since i have no idea what we're going to be talking about next week 10:08 < kanzure> lunch agenda? 10:08 < fenn> wants to meet on 9/9 for some reason 10:32 -!- wrldpc2 [n=benny@ool-ad03fe34.dyn.optonline.net] has joined #hplusroadmap 11:40 < ybit> well that was a quick arch install 11:40 < ybit> thank it took a total of 1 hour to get to xorg+xmonad 11:41 < ybit> thin* 11:42 < kanzure> http://www.kickstarter.com/projects/701662757/makerbeam-an-open-source-building-kit 11:42 < kanzure> why the fuck does he need $10k? 11:43 < kanzure> http://makerbeam.com/ 11:50 < kanzure> http://www.garagefab.cc/contraptor/ 11:50 < kanzure> http://contraptor.svn.sourceforge.net/viewvc/contraptor/tags/contraptor-1.5.0.tar.gz?view=tar 12:10 -!- ybit [n=ybit@unaffiliated/ybit] has quit ["leaving"] 12:16 * kanzure compiles heekscad r819 12:16 < kanzure> hopefully dxf->anything will have improved 12:31 -!- parolang [n=user@keholmes.oregonrd-wifi-1261.amplex.net] has joined #hplusroadmap 12:33 < kanzure> hey parolang 12:38 < parolang> hi 12:58 -!- splicer [n=patrik@h55n1c1o261.bredband.skanova.com] has joined #hplusroadmap 13:06 -!- ybit [n=heath@unaffiliated/ybit] has joined #hplusroadmap 13:54 -!- strages [n=strages@c-68-62-216-5.hsd1.al.comcast.net] has quit [Read error: 113 (No route to host)] 13:55 -!- strages [n=strages@c-68-62-216-5.hsd1.al.comcast.net] has joined #hplusroadmap 14:10 < CIA-32> skdb: kanzure * r 5a3e4b6 /geom/ode_collider.py: pyODE collision detection code in progress. weird error, see last two lines in file. 14:10 < kanzure> note that pyODE is no substitute for a propper engineering-level collider 14:17 -!- splicer [n=patrik@h55n1c1o261.bredband.skanova.com] has quit [Read error: 104 (Connection reset by peer)] 14:18 -!- dira [n=chatzill@86.99.40.183] has joined #hplusroadmap 14:52 < kanzure> hey dira 14:52 < dira> hey 14:52 < dira> how are ya doing? 14:52 < kanzure> doing well 14:52 < kanzure> what's up? 14:53 -!- Irssi: #hplusroadmap: Total of 31 nicks [0 ops, 0 halfops, 0 voices, 31 normal] 14:53 < dira> not much here, struggling to setup DotNetNuke web portal 14:54 < dira> what's up with you? 14:54 < kanzure> nuke is very old 14:54 < kanzure> doodling around with collision detection 14:54 < dira> OpenGL ? 14:54 < kanzure> a little. actually I'm using pyODE, the python bindings to the open dynamics engine 14:55 < kanzure> but there's an opengl visualizer around here somewhere 14:56 < dira> if your python programmer and you are serious in game development AND you can deal with M$ take , http://en.wikipedia.org/wiki/Microsoft_XNA and http://en.wikipedia.org/wiki/IronPython might be good mix 14:57 < kanzure> sorry, I'd rather not 14:57 < kanzure> been there, done that 14:57 < kanzure> this is for collision detection between brep models 14:58 < dira> hmmm, GPA inline features? 14:58 < kanzure> GPA? 14:58 < dira> *GPU ! 14:58 < kanzure> not at the moment 14:58 < kanzure> but I'm considering that, yes 14:58 < kanzure> not sure how to do it. maybe opencv? 14:59 -!- kanzure changed the topic of #hplusroadmap to: http://adl.serveftp.org/dokuwiki/skdb 15:00 < dira> I'm not sure if there is one standard portal for such hardware specific actions but take a look at www.nvidia.com , I'm sure I saw something about collision detection there 15:01 < kanzure> gpgu.org has some stuff, but no specific libraries 15:01 < kanzure> not everyone is using nvidia 15:01 < dira> true 15:02 * dira gets headache every time he thinks of game development 15:02 < dira> btw , what portal do you suggest ? 15:03 < kanzure> back in 2003 I wrote my own called "mPort Gold" 15:03 < kanzure> but I wouldn't recommend it. these days all the cool kids use django or drupal. 15:04 < dira> does they support multi portal systems ? 15:04 < kanzure> what does that mean? 15:04 < kanzure> btw, why are you in here? have we met? 15:04 < dira> having N web sites with one shared code based and administration 15:05 < kanzure> sure drupal has something like that 15:05 < kanzure> django too 15:05 < kanzure> python plugin for sketchup: http://www.cosc.canterbury.ac.nz/greg.ewing/SuPy/ 15:05 < dira> and I'm here because H+ sounds interesting to me ? 15:06 < kanzure> ah 15:06 < kanzure> how'd you find me? 15:06 < dira> find you ? you found me ! 15:06 < kanzure> you came in here :p 15:07 < dira> then if "H+ channel" == "kanzure" then I found you , correct 15:07 < dira> ;) 15:07 < kanzure> so you searched for a transhuman channel? 15:08 < dira> Utopiah is the link 15:08 < kanzure> oh okay 15:08 * Utopiah was watching silently 15:08 < kanzure> hi Utopiah 15:08 < Utopiah> hi kanzure , hi dira , hi #hplusroadmap 15:09 < dira> howdy 15:09 < Utopiah> afaik is knowledgeable in physics and CS and interested in H+ thus... his presence 15:09 < kanzure> neat 15:10 < Utopiah> unfortunately he's also developing a cult to Feynman and C# ;) 15:11 < dira> Feyman is the Man ! 15:11 < Utopiah> (shouldn't have started it) 15:11 < kanzure> a carl feynman cult wouldn't be too bad 15:12 < dira> Utopiah, I know your weak spot , http://research.microsoft.com/apps/tools/tuva/#data=5|0||d71e62e2-0b19-4d82-978b-9c0ea0cbc45f|| 15:14 < dira> the relation of Mathematics to Physics , but that's more than that ... it's more like philosophy of mind and science ! 15:14 < Utopiah> either that or talking on IRC before finishing my dinner ;) bbl 15:15 < dira> TYT 15:22 -!- ybit [n=heath@unaffiliated/ybit] has quit ["leaving"] 15:29 < kanzure> gear-wheel.py http://www.salome-platform.org/user-section/tui-examples/gear_wheel.py 15:51 -!- genehacker [n=noko@pool-173-57-48-104.dllstx.fios.verizon.net] has joined #hplusroadmap 16:00 < kanzure> technically the collision detection only needs to be done when making the virtual assembly. path planning for whether or not it is possible to actually make it is a different question. 16:34 -!- wrldpc2 [n=benny@ool-ad03fe34.dyn.optonline.net] has quit [] 17:06 < kanzure> neat, uzbl made slashdot 17:09 -!- dira [n=chatzill@86.99.40.183] has quit ["ChatZilla 0.9.85 [Firefox 3.5.2/20090729225027]"] 17:09 -!- dira [n=chatzill@86.99.40.183] has joined #hplusroadmap 17:16 -!- dira [n=chatzill@86.99.40.183] has quit ["ChatZilla 0.9.85 [Firefox 3.5.2/20090729225027]"] 17:20 -!- ybit [n=heath@unaffiliated/ybit] has joined #hplusroadmap 17:22 < parolang> I wasn't able to get uzbl to compile. 17:22 < kanzure> ouch 17:22 < kanzure> uzbl just made slashdot, btw 17:22 < parolang> yeah, I'm looking for it right now 17:23 < parolang> I'm gonna use conkeror for now. 17:23 < kanzure> it's on github 17:25 < parolang> Yeah, that's where I got it from. Maybe that's the problem, I got a version that won't compile. 17:25 < kanzure> dieterbe's repo? 17:25 < parolang> Yeah. 17:27 < parolang> I love your approach to the web, btw :) 17:27 < parolang> I've seen some of the files on your site about bookmarking, etc. 17:27 < kanzure> thanks :) 17:28 < kanzure> did you see my slashdot comment? 17:29 < parolang> Yeah. Googling surfraw now :) 17:37 -!- ybit [n=heath@unaffiliated/ybit] has quit ["leaving"] 17:39 < kanzure> parolang: ? 17:39 < parolang> You mention surfraw in your slashdot comment. 17:39 < kanzure> yeah 17:39 < kanzure> did you find it? 17:39 < parolang> Yes I did, I'm reading about it now :) 17:41 < parolang> I guess I don't know what it does. Does it download the web pages? output the pages to stout? 17:41 < kanzure> it's a scraper 17:41 < kanzure> so for google search results, it spits out links and titles 17:41 < kanzure> and for other things it does other things 17:41 < parolang> Okay, cool. 17:41 < kanzure> the problem though is that there are too few developers to keep up 17:42 < kanzure> so that's why I came up with that xpather+uzbl plan of attack 17:42 < parolang> Yeah, I read that, but I have no clue about xpath. 17:42 < kanzure> xpath is like a URL except it specifies a specific element in an HTML document 17:43 < kanzure> for pages with generated content, you just look for an element with the CSS class that you want, or something 17:43 -!- ybit [n=ybit@unaffiliated/ybit] has joined #hplusroadmap 17:43 < parolang> But don't you have the same trouble if the div structure, for instance, changes between layout changes? 17:43 < kanzure> so you can say: /a @attr(href="http://google.com/")/b/ and get back the text inside any link that is also bolded 17:43 < kanzure> that's right 17:44 < kanzure> so that's why uzbl is great for this 17:44 < kanzure> let's say you're using some shell scripts to do your scraping 17:44 < kanzure> and suddenly it detects that the layout has changed 17:44 -!- kibombo [n=ubuntu@unaffiliated/akafubu] has joined #hplusroadmap 17:44 < kanzure> and everything is fucked up 17:44 < kanzure> in the traditional way, you have to go into a browser and spend an hour writing a new scraper 17:44 < kanzure> in the uzbl way with xpather, it might be only a two minute task 17:44 < kanzure> of you clicking on the regions of the page that correspond to the content you want 17:45 -!- kibombo [n=ubuntu@unaffiliated/akafubu] has left #hplusroadmap [] 17:45 < kanzure> then your shell-based scraper is updated and everything is all well 17:45 < parolang> How do you return the selected section of the page in uzbl? 17:45 < kanzure> yeah I'm working on that 17:45 < kanzure> not sure yet 17:46 < kanzure> it's more of a webkit issue I think 17:46 < parolang> That's a question I had in mind for a somewhat different task: annotating web pages. 17:47 < parolang> I want to be able to select a section of the web page, hit a command, the command opens emacs and I can edit my annotation there. It could save teh page offline in case the page changes. 17:47 < parolang> *the 17:48 < kanzure> okay 17:48 < kanzure> yeah firefox has this "view selection source" feature, so I know it's able to figure out relatively where in the document corresponds to the general region you're clicking in 17:49 < parolang> Yeah. Which is why I think this might be easier in conkeror which uses javascript for scripting. I'll see :) 17:50 < kanzure> I had some complaint about KHTML back in the day 17:50 < kanzure> I forget what it was 17:50 < kanzure> I mean, what I disliked about it 17:50 < kanzure> besides the way the rendered pages look :p 17:51 < parolang> heh :) 17:52 < kanzure> is O(nlog(n)) less or greater than O(n**2)? 17:52 < parolang> Don't know. 17:53 < kanzure> ah looks like it 17:53 < kanzure> er, looks like it's always less than 17:53 < parolang> That would be my guess but don't want to steer you wrong :) 17:54 < kanzure> I think I can do a collision detection algorithm that is O(nlog(n)) 17:55 < kanzure> oops, O(n**(k) * log(n)) where k is the number of parts 17:56 < kanzure> hm wait does that even make sense? 17:57 < kanzure> n**k makes it suck immensely 17:57 < parolang> Sorry but this stuff is over my head :) 17:58 < kanzure> n**k means n multiplied by n except k times of that operation. 17:59 < parolang> Well, I know math. Just not O-notation (what does the n mean?) 17:59 < kanzure> let's say you had a for loop (for each blah in some_list). in this case, n is the length of some_list 18:00 < parolang> And in the collision detector? 18:00 < parolang> I thought n would be the number parts. 18:00 < kanzure> that's correct 18:00 < kanzure> so O(n) would be an absolutely ideal situation 18:00 < parolang> Then what's k? 18:00 < kanzure> but you need to check if parts are intersecting 18:00 < kanzure> well, there's this certain algorithm you can use called k-means 18:00 < kanzure> k-means is a way of clustering up all data points into k clusters by taking the values' means 18:01 < kanzure> then if I have stuff from one part in two different clusters, I know something is fucked up 18:01 < kanzure> with respect to a given threshold value of course that I'll have to tweak 18:01 < kanzure> but if the computational complexity (big o notation) tells me that k-means is going to suck worse than just doing collision detection regularly (which is the O(n**2) method where you compare every part to every other part), why should I bother 18:02 < parolang> ah :) 18:02 < parolang> That's clever. 18:02 < kanzure> if I was thinking more clearly I'd have my answer 18:02 < kanzure> the points that I would cluster would be the vertices in the part models I guess 18:03 < kanzure> minus all vertices involved in mated interfaces 18:03 < kanzure> because in those cases, parts are supposed to be very close to each other :) 18:03 < kanzure> so those vertices shouldn't be considered 18:03 < kanzure> but if there are other clusters of vertices/points that are within the same cluster, then that should be a red flag 18:04 < kanzure> doing this without comparing every point to every other point, or every part to every other part, is key 18:04 < parolang> So you just want to know whether the objects collide, and not when they collide? If you are moving parts around, then you'd want to know the latter. 18:04 < kanzure> that's right 18:04 < kanzure> but in this case I just want to know whether or not adding a part in a certain location will suck 18:04 < parolang> makes sense then 18:05 < kanzure> for path planning, yes, you'd want to detect whether or not the sweep of the part over some path would make it collide with anything 18:06 < kanzure> that would be useful for figuring out whether or not steps can actually be carried out to put something together 18:06 < kanzure> although in some cases you can be pretty sure that anything you can make (per some rules) can be made, like with legos 18:06 < kanzure> as long as you don't violate some laws of physics .. like collision and the whole pauli exclusion principle deal 18:06 < parolang> Okay...you're thinking about the interfacing of parts, right? That is, if it is physically possible for one part to interface with the other part, given the law that they can't coexist in the same space. 18:06 < kanzure> right 18:07 < kanzure> so skdb already has the part interface mating code down 18:07 < kanzure> I even wrote some code to check for the "common" intersection set between two part models 18:07 < kanzure> but this requires you to do O(n**2)-- to run the algorithm for each part against each other part 18:07 < kanzure> the problem is that this "common intersection" takes 2 seconds to compute for each part 18:07 < kanzure> so even if you only have ten or twenty parts, your computer cries 18:07 < kanzure> this is non-ideal :( 18:09 -!- ybit [n=ybit@unaffiliated/ybit] has quit [Remote closed the connection] 18:09 < parolang> But isn't there a way you can narrow down the edges and vertices you have to consider? 18:10 < kanzure> the only way I can think of to do that would be to do some proximity testing 18:10 < kanzure> but the way to figure out what's in the local proximity is to scan through the list 18:10 < kanzure> I guess that's O(n) and not as terrible 18:13 < parolang> For what it's worth, it seems to me that there should be some data attached to the part itself that contains the criteria on what kind of parts can fit into it's interfaces. You can save this data with the part so you don't have to generate each time you want to combine it with another part. 18:15 < parolang> Maybe it gets more complicated than what I'm thinking of in my head where this won't work. But determining the criteria might be what takes most of the processing, so this can be "compiled" when the part is first constructed. 18:15 < kanzure> yes parts already have that 18:16 < kanzure> check it out: http://adl.serveftp.org/skdb/packages/lego/data.yaml 18:16 -!- ybit [n=ybit@unaffiliated/ybit] has joined #hplusroadmap 18:16 < parolang> So, for instance, a part should be able to say "Whatever part that firts within this solid can interface" with me on this juncture. 18:16 < kanzure> right 18:16 < kanzure> yes mating compatibility for an interface/port is simple 18:16 < kanzure> but what if the part that connects has this weird thing 18:16 < kanzure> that comes back around and goes through the part it just mated to? 18:17 < kanzure> this should generate an error right? 18:17 < kanzure> or what if it collides with another object in the design, too? 18:18 < parolang> I'm having trouble picturing what you're talking about. 18:18 < kanzure> uhrm. 18:18 < kanzure> imagine an assembly with multiple parts 18:19 < kanzure> one of these parts connects properly, but another region of the same part collides with another part in the assembly 18:20 < parolang> Okay, that's clearer. 18:20 < parolang> Yeah, see what you mean. 18:20 -!- xp_prg [n=xp_prg3@dsl081-249-107.sfo1.dsl.speakeasy.net] has joined #hplusroadmap 18:21 < parolang> You'd have to recompute the clearance not just for each individual part, but also for each combination of parts. 18:21 < parolang> So you couldn't save it each individual part. 18:21 < kanzure> well in skdb there's a way to figure out which "options" exist 18:21 < kanzure> but maybe collision detection would be used only when you want to try an option 18:21 < kanzure> actually that kind of sucks 18:22 < kanzure> if the detection algorithm is good enough, computing it for the part.options(other_thing) would be nice 18:22 < parolang> It would be nice if there was some way to memoize that collision detection, I think that's all I've added to the discussion :) 18:24 < parolang> I'm overthinking it. It's an interesting problem though. 18:24 < kanzure> you're not overthinking 18:27 < kanzure> actually now that I think about it, 18:27 < kanzure> solidworks has this sort of part mating feature of sorts 18:27 < kanzure> and what they do is totally ignore any collision detection issues 18:27 < kanzure> you can literally mate a part that screws up the rest of the assembly by intersecting oddly 18:27 < kanzure> you can also make screws go through walls, etc. 18:28 < parolang> Hmm. 18:29 < parolang> How does skdb figure out what position can the parts interface at? e.g., what angle; or does the port specify only one angle? 18:29 < kanzure> pixel perfect (or voxel or "bounding box") methods might be a good fall back. it's what's used in most 2D/3D games. plus you can add in a resolution throttle/knob/variable thingy. 18:29 < kanzure> in skdb an interface has an "interface point" or "control point" 18:29 < kanzure> this control point has a vector pointing out of it 18:30 < kanzure> this vector is defined as the mating vector 18:30 < kanzure> if you mean "can an interface be at an angle", yes 18:31 < parolang> I'm thinking in terms of legos here...things get more complicated quickly after that (e.g., materials that can bend, or squish like a sponge). 18:31 < kanzure> if a cylinder in a cylindrical hole has to have a certain rotation, ther'es currently nothing about that at the moment because a cylinder is completely unlabeled 18:31 < kanzure> but it wouldn't be hard to add that in 18:32 < kanzure> so anyway, since the commercial CAD systems don't do collision detection when making assemblies, maybe it doesn't have to be done here either, until "the end" where it can be checked 18:32 < kanzure> and then you'll get a report about what sucks 18:32 < kanzure> one expected use of skdb is generating alternative designs 18:32 < kanzure> so in that case you might be generating hundreds of thousands of bullshit designs that, in the end, are evaluated to be impossible due to collision 18:32 < parolang> :( 18:33 < kanzure> solidworks (etc.) were made with the idea of a person looking at the design at all times I guess 18:33 < kanzure> oh maybe it could be something like this: 18:33 < kanzure> each part has a certain volume 18:34 < kanzure> the total assembly has a certain volume as well (the sum of the volumes of the parts) 18:34 < kanzure> the current BRepAlgoAPI_Common method does O(n**2) to figure out the volume between every part to every other part 18:34 < kanzure> but a better way might be to just take the volume of the entire object and make sure it is within a certain threshold 18:34 < kanzure> in some cases there will be proper interference fits so that has to be taken into account 18:35 < kanzure> but that shouldn't be more than a total that you can count by looking at the assembly 18:35 < ybit> could you please stop talking so you don't f' my logs ;) 18:35 < kanzure> what's wrong with your logs? 18:35 < ybit> (i'm about to reboot again) 18:35 < kanzure> oh 18:35 < kanzure> try getting on adl? 18:35 < ybit> that's an idea 18:35 < kanzure> there's a local copy of irssi 18:35 < ybit> a good one too 18:37 -!- ybit2 [i=ybit@unaffiliated/ybit] has joined #hplusroadmap 18:37 < ybit2> continue on :) 18:37 < parolang> Well, you know if the sum of the volumes of each of the objects is greater than the sum of the objects together in configuration, then you have a collision. Not sure if that's what you're talking about above. 18:37 < kanzure> er I think you're wrong 18:38 -!- ybit2 [i=ybit@unaffiliated/ybit] has quit [Client Quit] 18:38 < kanzure> oh, no, that's what I said 18:38 < kanzure> yes 18:38 < kanzure> ybit: it died 18:38 -!- ybit2 [i=ybit@unaffiliated/ybit] has joined #hplusroadmap 18:38 < ybit> i realized i hadn't started it in screen, so i restarted 18:39 < parolang> I think CAD programs store solid objects as being composed of geometric primitives (or I think BRLCAD did, when I last looked at it), so it could be easier doing the math this way. 18:39 < kanzure> right, but not all CAD models are made up of primitives unfortunately 18:39 < kanzure> maybe STEP and IGES are, actually 18:40 < kanzure> and in that case I agree that breaking it up into the primitives and just doing primitive collision would be so much easier 18:40 < kanzure> brlcad does do that, yes, that's the "dot g object database" format 18:40 < kanzure> poo poo to stl and dxf 18:40 -!- ybit [n=ybit@unaffiliated/ybit] has quit [Remote closed the connection] 18:40 < parolang> :) 18:41 < kanzure> on the todo list in skdb/doc/todo there's a line that mentions coming up with an algorithm to convert from stl and povray into step or iges formats 18:41 < kanzure> povray files are written in a scripting language of sorts, so with the parser from pypovray- if it can be subdued into reading povray files (not just writing them)- then we might have a chance at at least that. 18:42 < kanzure> there's about ~700 lego parts in the povray format in some free lego software package .. but they are unusable because they are in the povray format 18:43 < parolang> Yeah. 18:44 * parolang googles constraint satisfaction. 18:45 < kanzure> constraint satisfaction is usually mentioned (in here at least) with respect to geometric constraints on CAD models 18:51 < parolang> Thinking practically about this, collision detection is something that people have been working on for years, so if there's a better way I'm sure someone has found it. Some of the game sites mention bounding boxes, which isn't relevant for this application (I don't think), as bounding boxes are an approximation. You need something exact. 18:51 < kanzure> the problem is that the "exact" method takes a long time 18:52 < kanzure> so approximations like bounding boxes might give enough speed.. 18:52 < kanzure> if I was going to do an approximation, I would probably want to try a voxel grid approach or something 18:52 < kanzure> where a part takes up a certain chunk of 3D space, little tiny boxes 18:52 < kanzure> and then anything else that tries to "register" those same spaces gets the shit whacked out of it 18:53 < parolang> So you fill the part up with voxels? How efficient is that? 18:53 < kanzure> haven't done the calculation. probably not very efficient. 18:53 < kanzure> it would be like doing a riemann integral on the interior of the part's surface or something 18:53 < kanzure> and then registering those voxels in its name 18:53 < parolang> You still have to figure out when the voxel is outside of the part. At least this can be precomputed and stored with the object. 18:53 < kanzure> so yeah not a good idea overall 18:54 < kanzure> right 18:56 < parolang> It seems that filling the part just submitted to the repository with voxels is something that can be done on the repository server when idle. You want it to be fast when someone downloads a part and tries it in their design. 18:57 < kanzure> ewww 18:57 < kanzure> no thank you 18:57 < parolang> I'm saying if a trade off has to be made. I don't know if it has to be or not. 18:58 < kanzure> we'll see with the volume method 19:00 < parolang> good luck 19:44 < kanzure> what are the correct units on torque? 19:45 < kanzure> joule per rad? 19:47 < ybit2> If you really need the data you'll have to hit the dead tree, I'm 19:47 < ybit2> afraid. 19:48 < ybit2> so eugen means google.com/books right? :) 19:49 < kanzure> N*m =~ lbf * feet 19:50 < parolang> Newton meter (N*m) according to Wikipedia. 19:50 < kanzure> there's also a "wrong" torque that people like to use 19:52 -!- genehacker [n=noko@pool-173-57-48-104.dllstx.fios.verizon.net] has quit [Read error: 148 (No route to host)] 19:54 < parolang> kanzure: You've been modded troll and some smartass gets modded up for giving you sarcasm. 19:56 -!- xp_prg [n=xp_prg3@dsl081-249-107.sfo1.dsl.speakeasy.net] has quit ["This computer has gone to sleep"] 20:00 < kanzure> aw :( 20:00 < kanzure> well I'm probably a troll anyway 20:00 < kanzure> rawr! 20:01 < parolang> I corrected the error :) 20:01 < parolang> Although...I've never used 450 tabs either :) 20:01 < parolang> But...with recursive searching, you could easily go over 50. 20:02 < parolang> But, ultimately, the userbase of slashdot has changed. 20:03 < parolang> There used to be a lot more core Unix people, but most of them have all left, and now it's filled with Mac fanboys. 20:04 < kanzure> it's weird now. I was late to show up on slashdot, 20:04 < kanzure> but even when I did back in 2006 or 2007, it wasn't this bad 20:05 < kanzure> now it seems that everyone wants to hate on RMS 20:05 < kanzure> even though nobody knows him :p 20:05 < parolang> I think the issue is with the lack of quality of slashdot articles, lots of dupes, poor summaries, and general flamishness. 20:06 < parolang> So the people who used to frequent have all left. 20:09 < kanzure> class II theta is interesting 20:19 -!- genehacker [n=noko@pool-173-57-48-104.dllstx.fios.verizon.net] has joined #hplusroadmap 20:33 < kanzure> does anyone know the name and group who did the remix of the blue oyster cult song used in the 2010 lincoln mks commercial? 20:33 < kanzure> http://www.lincoln.com/extras/tvads.asp?id=7&intcmp=B_FreeSongDownload_MKZHome_LincolnTVAds_20090408 20:33 -!- any41308722 [n=someone@75-120-26-209.dyn.centurytel.net] has joined #hplusroadmap 20:35 -!- katsmeow-afk [n=someone@75-120-45-160.dyn.centurytel.net] has quit [Nick collision from services.] 20:35 -!- any41308722 is now known as katsmeow 20:36 -!- davidnunez [n=davidnun@209-6-203-217.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com] has quit [] 20:39 -!- nchaimov [n=cowtown@c-24-21-45-17.hsd1.wa.comcast.net] has quit [] 20:39 -!- genehacker [n=noko@pool-173-57-48-104.dllstx.fios.verizon.net] has quit [Read error: 60 (Operation timed out)] 20:51 -!- davidnunez [n=davidnun@209-6-203-217.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com] has joined #hplusroadmap 21:33 -!- genehacker [n=noko@pool-173-57-48-104.dllstx.fios.verizon.net] has joined #hplusroadmap 21:49 < ybit2> fenn_adl, kanzure: did either of you try using occ .deb? 21:51 < kanzure> http://adl.serveftp.org/dokuwiki/occ 21:51 < kanzure> http://adl.serveftp.org/dokuwiki/pythonocc 21:51 < kanzure> you'll see that on the top of the pythonocc page in the instructions there's an apt-get call 21:51 < kanzure> if you're asking whether or not it worked, the answer is yes :) 22:15 < genehacker> http://www.physorg.com/news171034413.html 22:15 < genehacker> this sounds very fishy 22:19 -!- xp_prg [n=xp_prg3@208.54.15.112] has joined #hplusroadmap 22:23 < CIA-32> skdb: kanzure * r ccace42 /doc/ (lists/adesign-library.yaml todo): adesign library component list 22:23 < CIA-32> skdb: kanzure * r c021c3b / (core/interface.py geom/geom.py): functions to determine whether or not an added part collides unwantedly. see estimate_collision_existence in geom/geom.py 22:26 -!- genehacker [n=noko@pool-173-57-48-104.dllstx.fios.verizon.net] has quit [Read error: 60 (Operation timed out)] 23:07 < ybit2> the suzanne gilbert talk which was forwarded to tt Quantum Computers and the creation of human-level artificial intelligence - Uploading Schrodinger's Cat?!... will be recorded and the annoucement of the upload will be on the ExtroBritannia list 23:07 < katsmeow> transcript? 23:07 < ybit2> dunno estropico@gmail.com might know though 23:08 < ybit2> he's the person whom told me he heard/read or found out somehow just a few hours ago 23:09 < katsmeow> i broke Google again: 23:09 < katsmeow> Results 1 - 10 of about 26,500 for suzanne gilbert talk which was forwarded to tt Quantum Computers and the creation of human-level artificial intelligence. (0.37 seconds) 23:09 < katsmeow> Search ResultsMichigan Channel: Channel 22: Search Results for “um” 23:09 < katsmeow> "um" ? 23:09 < ybit2> :) 23:13 -!- genehacker [n=noko@pool-173-57-48-104.dllstx.fios.verizon.net] has joined #hplusroadmap 23:19 < kanzure> >>> geom.shape_volume(box1.Shape()) 23:19 < kanzure> 1000.0000000000001 23:19 < kanzure> >>> geom.shape_volume(box2.Shape()) 23:19 < kanzure> 1000.0000000000001 23:19 < kanzure> >>> geom.shape_volume(fused_shape) 23:19 < kanzure> 1000.0000000000001 23:20 < kanzure> where: box1 = BRepPrimAPI_MakeBox(gp_Pnt(0,0,0), gp_Pnt(10,10,10)) 23:28 < CIA-32> skdb: kanzure * r 1047d2e /unittests/test_geom.py: test fused shape volumes and shape_volume function in geom/geom.py 23:29 < fenn> ok what if you move one cube to the side a bit 23:29 < fenn> and how long does it take to calculte that? 23:31 < kanzure> it doesn't take long at all as it is right now 23:32 < kanzure> but we don't know how long it takes to calculate the BRepAlgoAPI_Common of two boxes either 23:32 < kanzure> it might be that custom brep models take longer across the board 23:32 < kanzure> or BRepAlgoAPI_Common sucks 23:33 < CIA-32> skdb: kanzure * r e900647 /unittests/ (test_part.py test_transformation.py): cleaning up some tests 23:34 < kanzure> is there some profiling module in python that you prefer? 23:35 < CIA-32> skdb: kanzure * r 7a8b75f /geom/ode_collider.py: ode collider link 23:36 < kanzure> http://pyode.sourceforge.net/tutorials/tutorial3.html 23:40 -!- tropology [n=michael@adsl-68-255-98-211.dsl.chcgil.ameritech.net] has quit [] 23:41 < kanzure> uhrm... what? 23:42 < kanzure> for box 0,0,0..10,10,10 and box 5,5,5..15,15,15, the fused volume is 1875.0 23:42 < kanzure> I should probably do something I can mentally check 23:47 < kanzure> AssertionError: 125.00000000000001 != 125.0 23:59 < kanzure> fenn: http://en.wikipedia.org/wiki/Big_O_notation#Orders_of_common_functions 23:59 < kanzure> http://en.wikipedia.org/wiki/Time_complexity