| 00:02.27 | *** join/#brlcad jpjacobs (n=jpjacobs@dib.ulyssis.student.kuleuven.be) [NETSPLIT VICTIM] |
| 00:02.38 | *** join/#brlcad archivist (n=archivis@host217-35-76-52.in-addr.btopenworld.com) [NETSPLIT VICTIM] |
| 00:04.24 | *** join/#brlcad dtidrow_work (n=dtidrow@host169.objectsciences.com) [NETSPLIT VICTIM] |
| 00:04.26 | *** join/#brlcad _jack- (i=jack@dub.minimal.nl) |
| 00:04.31 | *** join/#brlcad dtidrow (n=dtidrow@c-69-255-182-248.hsd1.va.comcast.net) [NETSPLIT VICTIM] |
| 02:25.29 | dtidrow | brlcad: still on? |
| 04:25.54 | ntroutman_ | any photon mapping people in here? |
| 04:34.43 | *** join/#brlcad ntroutman (n=nathanie@prox.snu.edu) |
| 08:15.25 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) |
| 10:21.53 | *** join/#brlcad docelic (i=docelic@ri02-043.dialin.iskon.hr) |
| 14:49.23 | Maloeran | Can anyone confirm my understanding of floating point math, specifically that if a < b, then floor(a) will always be <= floor(b) ? |
| 14:49.55 | Maloeran | Without possibility of bad rounding once in a billion |
| 14:50.55 | clock_ | Maloeran: in floating point, no logic can be used. |
| 14:51.13 | clock_ | For example the following program printf("%f",a); printf("%f",a); printed two different numbers. |
| 14:51.27 | clock_ | And it was still in accordance to the behaviour of floating point numbers. |
| 14:52.21 | Maloeran | My present understanding of IEEE floats and floor() would imply that the logic above would always be true |
| 14:54.24 | clock_ | yes, the floor() function is a nondecreasing one |
| 14:55.33 | Maloeran | I'm just unsure about broken implementations doing 32<->80 bits conversions randomly, I know how the extra bits are discarded, truncation or rounding? |
| 14:55.40 | Maloeran | I don't* know how |
| 14:55.53 | clock_ | well there is no logic in floating point numbers |
| 14:56.04 | clock_ | if you need to be able to predict the behaviour, use fixed point :D |
| 14:56.38 | Maloeran | There's logic for sure, it's still clearly predictable |
| 14:57.15 | archivist | floats are not predictable never compare to 0 etc |
| 14:57.40 | Maloeran | Yes, I know that |
| 14:58.13 | Maloeran | ( And you can compare if you know for sure you are looking for an identical result ) |
| 14:59.02 | Maloeran | Basically, the point here is to do bin sorting, indexing floats in buckets. Can I be sure that all floats landing in bucket A will be < than the ones in bucket A+1 ? |
| 15:00.33 | Maloeran | That holds true as long as the implementation don't go around converting between multiple precisions ; I don't know if extra bits are truncated or rounded in that case |
| 15:02.00 | Maloeran | If that's a problem, I may as well extract mantissa and exponent manually, and work with that |
| 15:07.35 | clock_ | Do you know how to get red_mask,... etc. from XWindowAttributes? |
| 15:08.15 | ``Erik | ieee specifies several rounding models... down, up, truncation, nearest... |
| 15:09.24 | ``Erik | I THINK most x86 DEFAULTS to simple truncation, but it's not a defined thing... ummmmm, often there's an ieee header... like on fbsd, it's machine/ieeefp.h and I think on linux it's machine/ieee854.h |
| 15:09.58 | clock_ | floor is always down |
| 15:10.24 | ``Erik | floor is always down, but in conversion (32/80 or 64/80), it's definable |
| 15:10.39 | ``Erik | by the standard... most chips don't implement ALL of the standard |
| 15:12.12 | ``Erik | (also, floor 3.000000000000000000000000000001 maybe interpreted as floor 2.99999999999999999999999999999 due to fp instabilities, and give 2.0ish) |
| 15:12.30 | ``Erik | and visa versa |
| 15:12.51 | Maloeran | The way floor() should work, that should never happen |
| 15:13.07 | Maloeran | I'm concerned by any internal rounding though.. Ah, what a mess |
| 15:13.09 | ``Erik | fixed bit representation of floating point sucks arse |
| 15:13.48 | ``Erik | and dynamic width floating points (precise numbers) tend to incur a performance and memory penalty (scheme, ruby, libgmp, ...) |
| 15:14.35 | Maloeran | The point at the moment is to sort points and planes faster than my initial quick and lazy balanced binary tree |
| 15:14.51 | Maloeran | Bin sorting by floor() indexing would work, unless chips play dirty tricks on me |
| 15:15.41 | ``Erik | the dirty tricks will likely be in cases where #'s are so close, they don't really matter... |
| 15:15.59 | Maloeran | It matters a whole lot if 3.0000001 rounds to 2.0 |
| 15:16.26 | ``Erik | it'd take more 0's than that |
| 15:16.40 | Maloeran | Then the count of triangles in each bin is wrong, the traversal cost calculation is off, the actual sorting by comparison against the plane will give incorrect results, and it gets stuck in an infinite loop |
| 15:17.02 | ``Erik | I don't think you'd see it if you're happy with float precision |
| 15:17.54 | Maloeran | If I do such bin indexing, it is required for all points in bin A to be < than the ones in bin A+1 |
| 15:18.01 | Maloeran | Unless things will go really bad :) |
| 15:18.06 | Maloeran | Otherwise* things |
| 16:27.32 | *** join/#brlcad docelic (i=docelic@ri01-191.dialin.iskon.hr) |
| 16:39.21 | brlcad | Maloeran: for IEEE floating point, I believe that is a valid assertion <= |
| 16:41.26 | brlcad | but that isn't to say that there are plenty of libs and implementations that are not conformant out there (really a lot) |
| 16:43.15 | dtidrow | arg |
| 16:43.17 | brlcad | at the hardware and library level really, to the point of not hoping for IEEE |
| 16:43.51 | ``Erik | http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/msun/src/s_floorf.c?rev=1.7&content-type=text/x-cvsweb-markup |
| 16:43.52 | ``Erik | gnarley |
| 16:48.26 | Maloeran | Right, brlcad.. so I guess I can't rely on a comformant behavior on this point |
| 16:49.17 | brlcad | depends what the purpose is really |
| 16:49.18 | brlcad | i mean it should make things more stable overall |
| 16:49.27 | brlcad | but it won't necessarily be rock solid |
| 16:51.24 | brlcad | all you can guarantee rock solid is that you're within some epsilon, and doing greater/less than comparisons |
| 16:51.46 | ``Erik | *nod* fp sucks |
| 16:52.00 | Maloeran | With a big impact on performance |
| 16:52.10 | ``Erik | it's an approximate representation, so full on precision can't be guaranteed |
| 16:52.44 | brlcad | pretty much a necessity for analytic purposes, but you could certain finagle some #cludgyness that would make it compile-time optional if you wanted |
| 16:53.40 | Maloeran | ``Erik, I love floating point. I just wish implementations would all be perfectly predictable and conform to the standard |
| 16:53.51 | ``Erik | erm |
| 16:53.53 | ``Erik | the, uh |
| 16:53.58 | ``Erik | standard is not perfectly predictable |
| 16:54.04 | ``Erik | 754 OR 854... :/ |
| 16:54.36 | Maloeran | It is for the things I tend to care about, like this floor() thing |
| 16:54.50 | ``Erik | floor() is totally predictable |
| 16:55.04 | ``Erik | the number you THINK you have may not be the number you actually have |
| 16:55.22 | Maloeran | Yes well, the internal conversions between different representations ( 80<->32 ) mess things up a bit |
| 16:55.26 | ``Erik | if I have a very precise function and I feed it an imprecise input, I cannot expect the output to be any more precise than the input |
| 16:55.43 | Maloeran | I'm aware of that, I just need consistency |
| 16:55.58 | Maloeran | If a < b, I need floor(a) to be <= floor(b), always |
| 16:56.04 | ``Erik | it's not the function, it's the notion that you're using an approximate representation that induces the numeric instabilities |
| 16:56.38 | ``Erik | if floor() is floorf(), that's probabably a pretty safe assumption... it's probably safe on floord() as well |
| 16:57.09 | Maloeran | I would need to force the implementation to truncate back to 32 bits before floor(), if it's x87 |
| 16:58.48 | ``Erik | floor() might not execute on the fpu |
| 16:59.12 | ``Erik | the url I pasted was how fbsd does it, it's a bit twiddle in integer there... I d'no leenewx or others |
| 16:59.14 | ``Erik | *shrug* |
| 16:59.28 | ``Erik | (and I don't know if that's a POSSIBLE path on fbsd, or an always path) |
| 16:59.55 | Maloeran | There are faster hardware solutions, a couple cycles |
| 17:00.27 | ``Erik | it's highly unlikely you'll have problems, but there's that one little caveat that exists when you do anything at all involving floating point representation... :) |
| 17:01.51 | clock_ | Now if someone tells me how to run the damned mged in vnc server I can do screenshot videos in Theora, DivX and Windows Media Video |
| 17:01.55 | Maloeran | Oh, I hit some very annoying fp problems with the old prototype before... :) |
| 17:02.38 | Maloeran | I had a static function that would compute the bin index, and it was meant to always return the same index when given the same input. It makes sense of course, I had to debug for a long while to discover that... it didn't! |
| 17:02.53 | ``Erik | clock: um, /usr/brlcad/bin/mged ? |
| 17:02.56 | Maloeran | The reason : GCC was inlining it, and it messed up the 80<->32 bits x87 conversions |
| 17:03.24 | ``Erik | heh |
| 17:06.49 | ``Erik | 1) Correct 21081851083600.37596259382529338 0x42b32c803ebb5060 |
| 17:06.49 | ``Erik | 2) SPARC-quad 21081851083600.37500000000000 0x42b32c803ebb5060 |
| 17:06.49 | ``Erik | 4) IA32 21081851083600.38281250000000 0x42b32c803ebb5062 |
| 17:06.53 | ``Erik | interesting |
| 17:07.23 | brlcad | Maloeran: subtracting the two and comparing against an epsilon should be way faster than calling floor() twice (or even once) |
| 17:08.05 | ``Erik | http://www.validlab.com/goldberg/paper.pdf |
| 17:08.12 | Maloeran | brlcad, it was for sorting in bins... Make yourself 256 bins, find in which bin a point lands by a mere floor() |
| 17:08.13 | ``Erik | http://72.5.124.65/sunstudio/articles/fp_errors.html |
| 17:09.22 | brlcad | "by a mere floor()" sounds rather misleading |
| 17:09.47 | brlcad | I'd then say that "by a mere macro" you could do that same thing much faster |
| 17:11.00 | Maloeran | Hum, a macro? I mean it's a serial operation without branching, you get the bin index directly after an add and a mul |
| 17:11.25 | ``Erik | floor() has several branch points in the msun package |
| 17:11.37 | Maloeran | floor() has no branches when executed by the hardware ;) |
| 17:11.51 | Maloeran | These are probably fallbacks |
| 17:12.00 | ``Erik | hrm |
| 17:12.14 | ``Erik | I'd expect certain flags to be set depending on what exactly happened |
| 17:12.26 | ``Erik | :/ |
| 17:13.09 | ``Erik | -ffast-math purposefully breaks ieee for speed |
| 17:14.07 | *** join/#brlcad docelic (i=docelic@ri01-094.dialin.iskon.hr) |
| 17:14.31 | Maloeran | Even that software implementation is better than the 8 nodes of a binary tree to sort in 256 buckets for example |
| 17:14.45 | ``Erik | *shrug* |
| 17:14.47 | ``Erik | so do it |
| 17:14.51 | ``Erik | and see if the test cases get faster |
| 17:14.53 | ``Erik | :) |
| 17:21.21 | ``Erik | heh http://support.microsoft.com/kb/214118 |
| 17:24.22 | clock_ | Use Precision as Displayed option in Word ;-) |
| 18:48.24 | *** join/#brlcad docelic (i=docelic@ri01-229.dialin.iskon.hr) |
| 20:33.25 | Maloeran | Tip of the day : Blizzards and bicycles are a poor combination |
| 20:42.36 | *** join/#brlcad b0ef (n=b0ef@084202024060.customer.alfanett.no) |
| 20:58.06 | *** join/#brlcad docelic (i=docelic@ri01-207.dialin.iskon.hr) |
| 21:20.51 | *** join/#brlcad clock_ (i=clock@84-72-63-202.dclient.hispeed.ch) |
| 21:35.07 | brlcad | heh, "tip" of the day, nice pun |
| 22:31.53 | *** join/#brlcad docelic (i=docelic@ri01-220.dialin.iskon.hr) |
| 23:29.33 | *** join/#brlcad b0ef (n=b0ef@084202024060.customer.alfanett.no) |