| 00:44:19 | CIA-11: | neteler * r32441 /grass-addons/contributors.csv: +William Richard |
| 00:44:20 | sigq: | grassfeed: Changeset [32441]: +William Richard <https://trac.osgeo.org/grass/changeset/32441> |
| 02:08:44 | sigq: | grassfeed: Ticket #241 ( defect reopened ): v.proj: broken ( ? ) -z description and missing -l description in wxGUI <https://trac.osgeo.org/grass/ticket/241#comment:2> |
| 03:31:57 | CIA-11: | martinl * r32442 /grass/trunk/vector/v.proj/main.c: v.proj: switch -l flag label/description, trac #241 |
| 03:33:09 | sigq: | grassfeed: Changeset [32442]: v.proj: switch -l flag label/description, trac #241 <https://trac.osgeo.org/grass/changeset/32442> |
| 03:42:55 | CIA-11: | martinl * r32443 /grass/trunk/gui/wxpython/gui_modules/menuform.py: wxGUI: fix flags label/description in dialog |
| 03:42:56 | sigq: | grassfeed: Changeset [32443]: wxGUI: fix flags label/description in dialog <https://trac.osgeo.org/grass/changeset/32443> |
| 03:45:23 | CIA-11: | martinl * r32444 /grass/branches/develbranch_6/gui/wxpython/gui_modules/menuform.py: wxGUI: fix flags label/description in dialog ( merge from trunk r32443 ) |
| 03:46:03 | CIA-11: | martinl * r32445 /grass/branches/develbranch_6/vector/v.proj/main.c: v.proj: switch -l flag label/description, trac #241 ( merge from trunk r32442 ) |
| 05:34:34 | CIA-11: | martinl * r32446 /grass/trunk/vector/v.in.dxf/ ( 12 files ): v.in.dxf: message cleaning, -l flag: print also GRASS compliant name ( used by wxGUI ) |
| 05:39:37 | CIA-11: | martinl * r32447 /grass/trunk/vector/v.in.dxf/ ( layer_list.c main.c ): v.in.dxf: cosmetics in layer list format, update r32446 |
| 05:39:45 | sigq: | grassfeed: Changeset [32447]: v.in.dxf: cosmetics in layer list format, update r32446 <https://trac.osgeo.org/grass/changeset/32447> |
| 07:07:05 | CIA-11: | martinl * r32448 /grass/trunk/vector/v.in.dxf/main.c: v.in.dxf: don't overwrite output map if not specified by 'output' argument |
| 07:08:01 | CIA-11: | martinl * r32449 /grass/branches/develbranch_6/vector/v.in.dxf/main.c: v.in.dxf: don't overwrite output map if not specified by 'output' argument ( merge from trunk r32448 ) |
| 07:28:18 | CIA-11: | martinl * r32450 /grass/trunk/gui/wxpython/ ( 5 files in 2 dirs ): wxGUI: initial version of dialog for multiple dxf file import ( each layer is imported as separate vector map ) |
| 08:02:01 | CIA-11: | martinl * r32451 /grass/trunk/gui/wxpython/gui_modules/ ( gdialogs.py goutput.py ): wxGUI: dxf-dialog cosmetics, import only checked layers from the list, optionally add imported layers into layer tree |
| 13:41:51 | RMatev: | _wolf_: all the problems are because of a tolerance constant |
| 13:42:12 | : | <_wolf_> say what? |
| 13:42:13 | RMatev: | if I increase it, it works fine on the lines you gave me yesterday |
| 13:42:20 | : | <_wolf_> ahah |
| 13:42:46 | RMatev: | floating point sucks |
| 13:43:00 | : | <_wolf_> yeah. it is a bit inaccurate :P |
| 13:43:11 | RMatev: | I'm thinking of using more acurate calculations in certain spots |
| 13:43:14 | : | <_wolf_> what is this constant? |
| 13:43:17 | : | <_wolf_> what does it do? |
| 13:44:05 | RMatev: | it basically says that two points in the same EPSILONxEPSILON square are the same |
| 13:44:37 | RMatev: | I should probably define the behavior better |
| 13:44:43 | RMatev: | do some math... |
| 13:44:58 | : | <_wolf_> : ) it sounds like it would need it... |
| 13:45:10 | RMatev: | I was thinking of getting the constant from the input line |
| 13:45:20 | : | <_wolf_> that is also one possibility |
| 13:45:25 | : | <_wolf_> with a reasonable default |
| 13:45:40 | RMatev: | yep, but still it sucks |
| 13:45:45 | RMatev: | that approach |
| 13:45:50 | RMatev: | cause I tried... |
| 13:46:45 | RMatev: | Is there a possibility that I can use <big> floating point numbers in my segment intersection function |
| 13:46:48 | : | <_wolf_> well it puts more responsibility on the user |
| 13:47:14 | RMatev: | this will certainly solve a part of the problem |
| 13:47:15 | : | <_wolf_> you mean long doubles 64-bit floating points? |
| 13:48:00 | RMatev: | I mean floating point numbers with arbitrarily long mantisa |
| 13:48:16 | RMatev: | there are such libraries there |
| 13:48:50 | : | <_wolf_> ah you mean adding a dependency... hmm or are these libraries standard to ( most systems )? |
| 13:48:54 | RMatev: | actually I only need precision which is twice more than double |
| 13:49:22 | RMatev: | I had an article but I lost it |
| 13:49:29 | RMatev: | I''l do some research |
| 13:49:43 | RMatev: | probably they are not |
| 13:50:44 | : | <_wolf_> long double is I think exactly that |
| 13:51:50 | RMatev: | http://en.wikipedia.org/wiki/Long_double |
| 13:51:51 | sigq: | Title: Long double - Wikipedia, the free encyclopedia ( at en.wikipedia.org ) |
| 13:51:56 | RMatev: | not enogh |
| 13:52:15 | RMatev: | 10 bytes versus 8 for double |
| 13:53:49 | RMatev: | I'll try to figure something out. We want as little user responsibility as possible |
| 13:53:51 | : | <_wolf_> so you want 64-bit mathematics |
| 13:53:58 | : | <_wolf_> yes that is true |
| 13:54:04 | RMatev: | more like 128 bit |
| 13:54:35 | : | <_wolf_> hmm well that means pue software implementation |
| 13:54:43 | RMatev: | yes |
| 13:54:55 | : | <_wolf_> there should be a gnu scientific library or something like that |
| 13:55:31 | : | <_wolf_> http://www.gnu.org/software/gsl/manual/html_node/ |
| 13:55:32 | RMatev: | well don't bother to search. I'll think whether its absolutely necessary |
| 13:55:32 | sigq: | Title: GNU Scientific Library -- Reference Manual ( at www.gnu.org ) |
| 13:55:52 | : | <_wolf_> I think that GRASS might already use that for some BLAS stuff |
| 13:55:55 | : | <_wolf_> I'll check |
| 13:55:57 | : | <_wolf_> hang on |
| 13:56:43 | RMatev: | thanks |
| 13:57:04 | : | <_wolf_> ah no it uses a frotran BLAS implementation |
| 13:57:51 | : | <_wolf_> nope but I think that GSL could be a possibility |
| 13:58:45 | : | <_wolf_> hmm maybe it contains GSL |
| 13:58:55 | : | <_wolf_> I have a strong feeling of GRASS GSL connectivity |
| 14:01:00 | : | <_wolf_> Atleast the Native wingrass contains GSL |
| 14:01:03 | : | <_wolf_> http://grass.itc.it/grass63/binary/mswindows/native/ |
| 14:01:04 | sigq: | Title: Index of /grass63/binary/mswindows/nativeWinGRASS Project Web Page ( at grass.itc.it ) |
| 14:02:23 | RMatev: | aha |
| 14:02:34 | RMatev: | ok I'll check out that gsl |
| 14:04:44 | : | <_wolf_> hmm gsl is not used by GRASS |
| 14:08:31 | : | <_wolf_> I think that you should probably ask on the devel list |
| 14:09:00 | : | <_wolf_> people there might know more about the problem and maybe know of a solution |
| 14:09:04 | RMatev: | yep, after I check more precision is absolutely necessary |
| 14:12:24 | RMatev: | I need to find out what is the highest ratio ( max map feature coordinate )/( map detail ) for all maps |
| 14:13:50 | RMatev: | map detail is the distance at which two points should become the same |
| 14:14:57 | RMatev: | actually map detail is the cell size of the grid, to which all map features are snapped |
| 14:16:14 | : | <_wolf_> but vector calculations are not affected by the cell size |
| 14:17:52 | RMatev: | I didn't say it right |
| 14:18:43 | RMatev: | for example see the map you gave me yesterday |
| 14:19:37 | RMatev: | 197437.69470405 166394.08099688 |
| 14:19:37 | RMatev: | 404361.37071651 166394.08099688 |
| 14:20:35 | RMatev: | all vertices of the lines are given with 0.00000001 acuracy |
| 14:21:16 | : | <_wolf_> well that I guess is depending on projection and floating point accuracy |
| 14:21:51 | : | <_wolf_> 1.0 in long-lat is a whole lot more then 1.0 in a transverse-mercator projection |
| 14:22:17 | RMatev: | yep |
| 14:23:30 | RMatev: | looking into the lines you gave me is making me thing that using some kind of greater precision is inevitable |
| 14:23:37 | RMatev: | if we want to do things right |
| 14:23:58 | : | <_wolf_> hmmh... |
| 14:24:32 | : | <_wolf_> well if it is unavoidable, then, but let's take this discussion to the mailinglists |
| 14:25:14 | RMatev: | I'll do that as soon as I know exactly what I want : ) |
| 14:25:48 | : | <_wolf_> : ) |
| 14:26:01 | RMatev: | d = ( ax2-ax1 )*( by1-by2 ) - ( ay2-ay1 )*( bx1-bx2 ); |
| 14:26:02 | RMatev: | d1 = ( bx1-ax1 )*( by1-by2 ) - ( by1-ay1 )*( bx1-bx2 ); |
| 14:26:02 | RMatev: | ra = d1/d; |
| 14:26:11 | : | <_wolf_> my point was that someone on the list might help you in finding what you want ; ) |
| 14:26:37 | RMatev: | may be, but I want to try myself first |
| 14:26:43 | : | <_wolf_> :D |
| 14:26:57 | RMatev: | see the caclulations above |
| 14:27:35 | RMatev: | all ax1, bx2, ... are doubles. When we multiply we lose precision |
| 14:27:43 | RMatev: | then again we lose it |
| 14:28:44 | : | <_wolf_> right, but I don't think there is a way to reduce the number of multiplications ( at least I can't think of any directly ) |
| 14:29:16 | RMatev: | yes |
| 14:29:41 | : | <_wolf_> so a1 to a2 is one segment and b1 to b2 is another? |
| 14:29:50 | RMatev: | if there was a trick, the one who wrote segment intersection would have thought it |
| 14:30:00 | RMatev: | yes thats the case |
| 14:32:41 | : | <_wolf_> and If I've understood the floating point numbers correctly the only solution would be to increase the number of bits used for each number |
| 14:32:50 | : | <_wolf_> which in turn will make the calculation slow |
| 14:35:53 | RMatev: | yes |
| 14:36:10 | RMatev: | or, there is another option |
| 14:37:05 | RMatev: | first snap input lines so that their coordinates use only half of the mantissa bits in double |
| 14:37:26 | RMatev: | then do the calculations with double types |
| 14:37:37 | RMatev: | but that way we lose information |
| 14:38:32 | : | <_wolf_> that is not really feasible since in long-lat the numbers can be very small => everything is 0 |
| 14:39:04 | : | <_wolf_> but now I most go to sleep |
| 14:39:13 | : | <_wolf_> talk tomorrow, ok? |
| 14:39:18 | RMatev: | ok |
| 14:39:25 | RMatev: | good night |
| 14:39:33 | : | <_wolf_> good night |
| 14:57:09 | CIA-11: | glynn * r32452 /grass/trunk/scripts/d.rast.edit/d.rast.edit.tcl: Set weights on .overview, not . |
| 14:58:46 | sigq: | grassfeed: Changeset [32452]: Set weights on .overview, not . <https://trac.osgeo.org/grass/changeset/32452> |
| 23:56:03 | sigq: | grassfeed: Ticket #248 ( defect created ): v.info vs. r.info: different region output formats <https://trac.osgeo.org/grass/ticket/248> |