| 00:04.07 | ``Erik | O. |
| 00:04.09 | ``Erik | O.o even |
| 00:04.32 | ``Erik | I either watch "stupid comedy" or throw it on one of the history channels |
| 00:13.26 | yukonbob | <PROTECTED> |
| 00:14.27 | yukonbob | feh |
| 00:15.02 | ``Erik | 15? sheesh |
| 00:15.19 | ``Erik | I tend to stack slower channels into the same window |
| 01:12.18 | CIA-28 | BRL-CAD: 03johnranderson * r34581 10/jbrlcad/trunk/ (5 files in 4 dirs): |
| 01:12.18 | CIA-28 | BRL-CAD: Fixed a bug where a Ray missing a BoxNode resultsed in a NPE. |
| 01:12.18 | CIA-28 | BRL-CAD: Added support for vertex normal averaging in PreppedTriangle. (jBrlcad now raytraces Sean's SMOOTHBOT correctly, although about an order of magnitude slower than brl-cad) |
| 01:27.16 | *** join/#brlcad mafm (n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) | |
| 02:26.52 | madant | heh.. long read http://www.theatlantic.com/doc/200906/happiness |
| 03:22.26 | *** join/#brlcad madant_ (n=madant@117.196.128.247) | |
| 07:01.50 | *** join/#brlcad hippieindamakin8 (n=hippiein@202.3.77.38) | |
| 07:38.22 | *** join/#brlcad yukonbob (i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT VICTIM] | |
| 07:38.22 | *** join/#brlcad piksi (i=piksi@pi-xi.net) [NETSPLIT VICTIM] | |
| 11:30.35 | *** join/#brlcad _sushi_ (n=_sushi_@80-219-41-226.dclient.hispeed.ch) | |
| 12:02.46 | *** join/#brlcad roberthl (n=robert@cobalt.rhl.me.uk) | |
| 14:51.31 | *** join/#brlcad hippieindamakin8 (n=hippiein@202.3.77.38) | |
| 16:25.01 | *** join/#brlcad jdoliner (n=jdoliner@c-98-227-157-38.hsd1.il.comcast.net) | |
| 16:25.11 | jdoliner | the game is afoot! |
| 17:14.18 | jdoliner | brlcad |
| 17:26.48 | *** join/#brlcad _sushi_ (n=_sushi_@77-58-234-169.dclient.hispeed.ch) | |
| 17:37.07 | brlcad | jdoliner: heh woo hoo! |
| 17:37.26 | jdoliner | woo hoo |
| 17:38.04 | jdoliner | okay I've succesfully added a file in librt and I have it working with the makefile |
| 17:38.20 | jdoliner | so that's one small accomplishment |
| 17:39.17 | jdoliner | my first step is to add in additional polynomial functionality |
| 17:39.25 | jdoliner | I've looked around in poly.c |
| 17:40.05 | jdoliner | and it certainly needs to be extended for what I'm doing |
| 17:40.24 | jdoliner | but I wanted to make sure there weren't some polynomial functions hiding somewhere else that I wasn't finding |
| 17:40.38 | jdoliner | particularly do you have anything for computing sturm sequences? |
| 17:50.13 | brlcad | numerics generally do get generalized and separated out into libbn (brl-cad numerics library) |
| 17:50.30 | brlcad | librt's poly.c is in flux, moving to libbn |
| 17:51.12 | brlcad | madant's sf patch takes care of it, just haven't fully finished testing it yet (anything that affects ray-tracing has to go through more extensive testing) |
| 17:51.50 | brlcad | I don't think we have anything specific to sturm, but should rummage around and survey what's in libbn regardless |
| 17:52.20 | brlcad | as well as src/other/tnt |
| 17:52.57 | brlcad | that latter has more specific routines various vector/matrix operations |
| 17:54.15 | jdoliner | okay and this also seems to suggest that I should put sturm's work in libbn |
| 17:54.45 | brlcad | what exactly is it? |
| 17:55.20 | jdoliner | it's an efficient way to compute the number of roots of a multivariate polynomial |
| 17:55.41 | brlcad | no I mean implementation-wise |
| 17:55.42 | jdoliner | and it's good for giving you and idea where they are |
| 17:56.12 | brlcad | exists as a set of C-functions, or just the general technique itself? |
| 17:56.18 | jdoliner | it works like a euclidean algorithm taking successive remainders from polynomial division |
| 17:56.20 | brlcad | i.e. something you'd need to implement |
| 17:56.26 | jdoliner | which you guys do have |
| 17:56.34 | jdoliner | I noticed there's polynomial division |
| 17:56.40 | brlcad | yes |
| 17:56.45 | jdoliner | but remainders can be computed faster by not dividing |
| 17:56.57 | jdoliner | and in this case the speed boost is needed |
| 17:58.03 | brlcad | because you have run some tests and encountered a performance problem? :) |
| 17:58.19 | jdoliner | I haven't run any tests personally |
| 17:58.29 | jdoliner | I've been reading the literature from other projects though |
| 17:58.49 | brlcad | then claiming a 'need' for speed is bogus :) |
| 17:59.12 | brlcad | not that a speedup wouldn't be nice, it's always nice, but it also might not matter -- lot of other factors |
| 17:59.55 | jdoliner | that's true |
| 18:00.24 | jdoliner | well then perhaps the most prudent thing is to implement sturm sequences using the old routine (in a wrapper) |
| 18:00.38 | jdoliner | and then we'll see how long it takes when we do some real life tests |
| 18:00.48 | brlcad | case in point, I actually had an inclination that our poly solver was slow so it was isolated and direclty compared against every other solver implementation I could get my hands on (which was about 9 at the time) |
| 18:01.38 | brlcad | turned out that our solver implementation actually outperformed all of them with same results (a couple came within 10%) |
| 18:01.47 | brlcad | which was flat out surprising frankly |
| 18:02.42 | brlcad | so yeah, I'd just wrap it if that's quickest -- and make it easy enough to refactor out if it turns out to be an issue |
| 18:03.59 | brlcad | should be able to test that pretty earily on if you're set on using sturm sequences in the first place |
| 18:04.21 | jdoliner | yeah |
| 18:05.10 | jdoliner | and I have a general idea of how high a degree of polynomials we need to be able to solve efficiently |
| 18:09.18 | brlcad | high-degree polynomials might outright make libbn unsuitable (at least librt's newtonian-based solver) |
| 18:09.39 | brlcad | keep an eye out for validity if you jack up the compile-time limite |
| 18:13.19 | jdoliner | k |
| 18:26.59 | *** join/#brlcad madant (n=madant@117.196.135.248) | |
| 20:08.37 | *** join/#brlcad samrose (n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) | |
| 20:46.31 | *** join/#brlcad andax (n=andax__@d213-102-40-15.cust.tele2.ch) | |
| 20:47.16 | starseeker | brlcad: Here's that durable paper I was talking about for BRL-CAD cheat sheets: http://www.xerox.com/Static_HTML/never_tear/index.shtml |
| 20:48.47 | *** join/#brlcad madant (n=madant@117.196.135.248) | |
| 20:50.20 | ``Erik | make it work, then make it fast |
| 22:51.08 | starseeker | ``Erik: hmm? |
| 22:51.28 | starseeker | oh, you mean jdoliner's solver? |
| 23:37.32 | *** join/#brlcad samrose (n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) | |