# revision

rev: 7
author: count0
message:
  removing edge selectors, since the same behaviour can be obtained by using the --undirected and --reverse filters, as long as the in-degree is also seen when the undirected filter is turned on


rev: 9
author: count0
message:
  * removed neighbour selectors (not really needed at all). Improves compilation speed, memory usage and binary size!
  * removed clustering specific code in favour of more generic property code
  * added GetEdgeHistogram()
  * renamed some functions/options ("degree"->"vertex")


rev: 17
author: count0
message:
  * move distance stuff to src/graph/graph_distance.cc
  * average distances now accept weights
  * added DynamicPropertyMapWrap


rev: 18
author: count0
message:
  * generalized GetCombinedDegreeHistogram() into GetCombinedVertexHistogram()
  * removed GetVectorScalarCorrelation(), since it is substituted by the above
  * changed range filter policy: if property is non-double, use generic python filtering instead


rev: 29
author: count0
message:
  * added GetAverageCombinedVertexCorrelation()
  * put combined degree correlation stuff in src/graph/graph_correlations_combined.cc
  * some code cleanups in src/graph-tool


rev: 33
author: count0
message:
  * changed python filtering semantics: edges are filtered before vertices, not simultaneously. Original (unfiltered) vertices degrees are available to the vertex filter prefixed with "orig_".
  * added missing boost licence file to src/boost-workaround/LICENSE_1_0.txt
  * updated FSF address in src/graph-tool


rev: 34
author: count0
message:
  * new python filtering code with different syntax. Now faster...
  * definition of HashedDescriptorMap


rev: 36
author: count0
message:
  * added extended clustering code
  * separated graphml code into graphml.hpp and graphml.cpp, and added support for default property values
  * added HashedDescriptorMap with automatic memory management


rev: 38
author: count0
message:
  * add GetDistanceHistogram, instead of GetAverageDistance
  * add GetSampledDistanceHistogram (in src/graph/graph_distance_sampled.cc)
  * fix BFS initialization bug in src/graph/graph_extended_clustering.cc


rev: 40
author: count0
message:
  * fix bug in graph/graph_extended_clustering.cc (error in BFS target management)
  * fix bug in graph/graph_correlations_combined.cc (precision error when error is very small)


rev: 42
author: count0
message:
  * src/graph/graph.cc: fixed range filter fallback
  * src/graph/graph_python_filtering.hh: changed is_loop to is_self
  * src/graph-tool: fixed memory leak related to exec statements and filtering


rev: 46
author: count0
message:
  * Added minimum spanning tree support
  * Range filters now support all kinds of scalar properties without falling back to python code


rev: 47
author: count0
message:
  * correct graphml headers
  * fix ticket [9]
  * fix --for bug with multiple options with different parameters
  * Add initial support for community detection (ticket [6])


rev: 52
author: count0
message:
  * src/graph/graph_community.cc: Extensively re-written. Now it's a bit slower, but hopefully correct.


rev: 53
author: count0
message:
  * ComponentSizeHistogram() becomes LabelComponents()
  * fixed saving of undirected filtered graphs in graph_io.cc
  * fixed correlated community detection in graph_community.cc


rev: 54
author: count0
message:
  * graph_community.cc: 
     - added support for saving annealing history to file
     - added support for continuing from an existing community partition


rev: 56
author: count0
message:
  * Added community network generation
  * Added line graph generation
  * src/graph-tool: some code de-uglification
  * src/graph-tool: terminal output format changes


rev: 62
author: count0
message:
  graphml.cpp: fixed handling of node ids, which are now optional (ignored, actually) and added support for xml namespaces


rev: 64
author: count0
message:
  included option to disable python and range filtering during compilation, thus reducing compile-time memory requirements


rev: 71
author: count0
message:
  * make range and python filtering independently optional
  * accept external files for property editing routines
  * include in_PROP() andd out_PROP() functions to be used in python filtering/property editing routines.


rev: 74
author: count0
message:
  * src/graph/graph.cc: fix reset filter when it's not enabled
  * src/graph-tool allow for parameter setting before loading property editing script


rev: 75
author: count0
message:
  added __eq__ and __hash__ member functions to Vertex and Edge python classes, so they can be compared.


rev: 81
author: count0
message:
  * added "--list-properties" option
  * added support for specifying property type when creating/editing properties
  * added initial support for graph properties (are loaded, listed, and saved)


rev: 82
author: count0
message:
  * edit graph property support
  * 'Graph' type now available to python editing, with iterators to access all vertices and edges
  * out_edges and in_edges return iterators instead of lists for python editing


rev: 97
author: count0
message:
  * Initial support for parallel code with openmp from GCC 4.2.0. The following code is now parallel:
    * src/graph/graph_clustering.cc
    * src/graph/graph_distance.cc
    * src/graph/graph_extended_clustering.cc
    * src/graph/graph_distance_sampled.cc
  * fixed "jacknife" variance bug in src/graph/graph_clustering.cc


rev: 98
author: count0
message:
  * graph_community.cc: code parallelization and speed improvements
  * graph/graph_distance.cc: trivial "one-liner" speed improvement


rev: 99
author: count0
message:
  * fixed bug in graph_assortativity.cc
  * further code parellelization with openmp (vertex and edge histograms, correlations, and reciprocity)


rev: 102
author: count0
message:
  * add support for betweenness centrality 
  * change from HashedDescriptorMap to vector_property_map in several
    algorithms to save memory and increase speed in the most common
    case, where the graph is unfiltered.


rev: 113
author: count0
message:
  * fixed bug in scalarS where undirected edge properties were not properly handled
  * removed exeption throwing in scalarS to improve performance


rev: 114
author: count0
message:
          * ChangeLog: updated ChangeLog file with svn history

          * src/graph/graph_filtering.hh: added add_edge() and remove_edge() functions for filtered graphs

          * src/graph/shared_map.hh: included SharedContainer

          * src/graph/graph_rewiring.cc: initial support for random graph rewiring


rev: 115
author: count0
message:
  * src/graph/graph_extended_clustering.cc (GraphInterface::SetExtendedClusteringToProperty): init vector_property_map size, so that access becomes thread safe.

  * src/graph/graph_clustering.cc (GraphInterface::SetLocalClusteringToProperty): init vector_property_map size, so that access becomes thread safe.


rev: 116
author: count0
message:
  * src/graph/Makefile.am: added 'boost_workaround' files

  * src/Makefile.am: removed 'boost_workaround' dist files

  * src/graph/graph_rewiring.cc: deleted blank lines.


rev: 117
author: count0
message:
          * src/graph-tool: added better error handling (output to stderr, cleaner information, return error status)  

          * src/graph/graph_bind.cc: added license info

          * src/graph-tool: added python metadata


rev: 119
author: count0
message:
          * src/graph/graph.cc (GraphInterface::LabelParallelEdges): use vector_property_map instead of HashedDescriptorMap.


rev: 120
author: count0
message:
  * src/graph/graph.cc (GraphInterface::LabelParallelEdges): use long instead of size_t for parallel edges property.

  * src/graph/graph_properties.cc: call size_t by "size_t" not "long", since those are not the same type. This removes a bug where it is impossible to create/edit properties with type long.

  * src/graph/graph.cc (GraphInterface::LabelParallelEdges): use vector_property_map instead of HashedDescriptorMap.


rev: 121
author: count0
message:
  	* src/graph-tool: change layout and community graph options.

  	* src/boost-workaround/boost/graph/kamada_kawai_spring_layout.hpp: annotated code with openmp constructs.

  	* src/graph/graph_adaptor.hh: graph_type should be a typedef to the original graph.

  	* src/graph/graph_properties.hh, src/graph/graph_properties.cc: added pos_t type.

  	* src/boost-workaround/boost/graph/fruchterman_reingold.hpp: annotated code with openmp constructs.

  	* src/graph/graph_layout.cc: new file with graph layout routines.

  	* src/graph/graph.cc: removed graph layout routines.

  	* src/graph/graph_community_network.cc (struct get_community_network): fixed inversion of directedness test.

  	* src/graph/graph.cc (GraphInterface::LabelComponents): use vector_property_map instead of HashedDescriptor. Don't use a static map!

  	* src/graph/graph_adaptor.hh: fixed edge descriptor equality comparison, which must rely on underlying edge, regardless of whether it's inverted or not.


# ticket

type: enhancement
component: graph-tool
priority: normal
owner: count0
reporter: count0
version: devel
milestone: 0.9
status: closed
resolution: fixed
summary: Combined (in,out) degree histogram should be generalized
description:
  Combined (in,out) degree histogram should be generalized to accept any degree type or scalar property.

  It would also imply the death of --vertex-scalar-correlation-histogram


type: enhancement
component: graph-tool
priority: normal
owner: count0
reporter: count0
version: devel
milestone: 0.9
status: closed
resolution: fixed
summary: Average distance and average harmonic distance should accept weights
description:
  Average distance and average harmonic distance should be able to accept an edge scalar property as weights.


type: enhancement
component: graph-tool
priority: normal
owner: count0
reporter: count0
version: devel
milestone: 1.0
status: reopened
summary: Add support for reciprocity
description:
  Add support for reciprocity, defined as

  [[Equation(\[\rho=\frac{L_{bd}/L-\bar{a}}{1-\bar{a}}\])]] where [[Equation(\[\bar{a}=\frac{L}{N(N-1)}\])]].


type: enhancement
component: graph-tool
priority: normal
owner: count0
reporter: count0
version: devel
milestone: 0.9
status: closed
resolution: fixed
summary: Add support for assortativity based on scalar properties
description:
  Add support for assortativity coefficient based on scalar properties [[Equation($x$)]] and [[Equation($y$)]], defined by

  [[Equation(\[ r = \frac{\sum_{x,y} xy (e_{xy} -a_x b_y)}{\sigma_a\sigma_b} \])]], where  [[Equation($a_x = \sum_ye_{xy}$)]] and [[Equation($b_y = \sum_xe_{xy}$)]].


type: enhancement
component: graph-tool
priority: minor
owner: count0
reporter: abdo@member.fsf.org
cc: abdo@member.fsf.org
version: devel
milestone: 1.0
status: closed
resolution: fixed
summary: extended clustering indexes should start with 1
keywords: properties, indexing, nomenclature
description:
  Extended clustering indexes should start with 1, to be descriptive of the concept they represent.

  It is not a "C" index, but a value related to the distance between neighbors.

  Otherwise we might start calling "out-degree" as "built_in_property_0" and "in degree" as "built_in_property_1", and so on... why not?

  ;-)P


type: enhancement
component: graph-tool
priority: normal
owner: count0
reporter: abdo@member.fsf.org
version: devel
milestone: 1.0
status: closed
resolution: fixed
summary: --history should be named --for and have a --history flag
keywords: history, for, iteration
description:
  Due to its more generic usefulness, --history="" should be named --for="" and have a --history flag in case the user wants it to behave as a history calculation, starting from the point where it stopped instead of overriding the previous results.

  Another, perhaps more interesting way would be to keep the --history option as it is and just add a --for option that does not try to continue previous calculations, overwriting the destination file.


type: enhancement
component: graph-tool
priority: normal
owner: count0
reporter: abdo@member.fsf.org
version: devel
status: closed
resolution: fixed
summary: load from stdin and save to stdout
keywords: load, save, stream
description:
  There are several problems when writing too large gzip files.

  Usually it is better to split data among several gziped files.

  This would be a lot easier if graph-tool supported receiving the graph from stdin and writing it to stdout, so the "slicing/dicing" job could be left to a complementary application.

  i.e.

  {{{
  $zcat graph_*.gz | graph-tool --load=- --save=- | zslicer -m 100 --prefix graph
  }}}

  zslicer, in this case, is a program taking the stream and saving every 100MB in a sequence of gziped files


type: enhancement
component: graph-tool
priority: normal
owner: abdo@member.fsf.org
reporter: abdo@member.fsf.org
version: devel
milestone: 1.0
status: closed
resolution: fixed
summary: Add support for graph properties in graphml reader.
keywords: graphml, dynamics
description:
  Graphml reader should support graph properties, thus better conforming to the graphml specification.

  In the context of dynamics on graphs, that would also give users the ability to record global simulation parameters, making it easier to write code to stop the dynamics, save the graph with the vertex properties and global parameters,  and later continue a simluation from where it stopped.


type: enhancement
component: graph-tool
priority: normal
owner: count0
reporter: count0
version: devel
milestone: 1.0
status: closed
resolution: fixed
summary: Add namespace support for graphml reader
description:
  Modify reader so it is able to read things like:
  {{{
  #!xml
  <node id="n1">
        <data key="d0" >
          <y:ShapeNode >
            <y:Geometry  x="2.457598996954175" y="498.06375265283157"
  width="10.0" height="10.0"/>
            <y:Fill color="#FF0000"  transparent="false"/>
            <y:BorderStyle type="line" width="1.0" color="#000000" />
            <y:NodeLabel x="3.0" y="3.0" width="4.0" height="4.0"
  visible="true" alignment="center" fontFamily="Dialog" fontSize="12"
  fontStyle="plain" textC
  olor="#000000" hasBackgroundColor="false" hasLineColor="false"
  modelName="internal" modelPosition="c"
  autoSizePolicy="content"></y:NodeLabel>
            <y:Shape type="rectangle"/>
          </y:ShapeNode>
        </data>
  </node>
  }}}

  reference thread: http://thread.gmane.org/gmane.comp.lib.boost.user/22092/focus=22092


type: defect
component: graph-tool
priority: minor
owner: count0
reporter: abdo@member.fsf.org
version: devel
status: closed
resolution: fixed
summary: "prefix = None" in history should not output initial TAB
keywords: history, prefix, tab
description:
  When using "--for" or "--history" with "prefix=None", an initial TAB should not be appended.

  A patch is attached that fixes this problem.

  Also, documentation does not reflect the shift of no prefix syntax from "prefix=''" to "prefix=None".


type: defect
component: graph-tool
priority: normal
owner: count0
reporter: abdo@member.fsf.org
version: devel
status: closed
resolution: wontfix
summary: in_edge_iterator for UndirectedAdaptor breaks in_edge_iterator requirements
keywords: undirected
description:
  in_edge_iterator is typedef'ed to UndirectedAdaptorOutEdgeIterator

  thus, source() and target() functions are not switched as they should be for an in_edge_iterator

  tough the graph is undirected, this is important so that algorithms work properly for directed and undirected graphs without modification

  A working UndirectedAdaptorInEdgeIterator seems to have been 77%-implemented, I just finished the job.

  Patch attached.


type: enhancement
component: graph-tool
priority: normal
owner: count0
reporter: count0
version: devel
status: new
summary: Add "edge based" correlated graph generation
description:
  The probability [[Equation($p(k,k')$)]] of an edge having source and target with degrees [[Equation($k$)]] and [[Equation($k'$)]] should describe completely the graph since it contains both [[Equation($P(k)$)]] and the correlations: [[Equation($p(k,k')=P(k)P(k')r(k,k')$)]], where [[Equation($r(k,k')$)]] determines the correlation. Thus, it should be possible to generate a random correlated graph with E edges by sampling all the source and target degrees of each edge, and later randomly grouping the tips of the edges in vertices of the correct degree. The number V of vertices would fluctuate, in contrast to the correlated configurational model where V is fixed and E fluctuates. The advantage is that everything would be controlled by a single distribution.


type: enhancement
component: graph-tool
priority: normal
owner: count0
reporter: count0
version: devel
milestone: 1.2
status: new
summary: Add support for graph "rewiring"
description:
  It is often useful to determine whether some statistical property of a graph is simply due to its degree distribution and/or correlation, or if it is something more subtle. One way of detecting this is to modify, i.e randomly rewire, the graph, such that the resulting graph has the same number of edges and vertices of the original, and where each vertex has the same degree as before, as well as (optionally) some of the following:

   * degree-degree correlation: The target and source of each edge (and their degrees) are sampled according to the graph's original degree-degree correlation.
   * "strict" degree-degree correlation: The degree of each target or source is kept the same, but the vertices themselves are randomly sampled

  otherwise, everything else is random. Proper care should be taken to sample each possible random alternative with equal probability.


type: enhancement
component: graph-tool
priority: normal
owner: count0
reporter: count0
version: devel
status: new
summary: Add support for closeness centrality
description:
  Add support for closeness centrality of a vertex, defined as

  [[Equation(\[C_C(v)=\frac{1}{\sum_{t \in V}d_G(v,t)}\])]]

  See http://en.wikipedia.org/wiki/Closeness_(graph_theory), for an algorithm and references.


type: enhancement
component: graph-tool
priority: normal
owner: count0
reporter: count0
version: devel
status: new
summary: Add support for graph spectral properties
description:
  Add support for relevant spectral properties based on the laplacian matrix:

  [[Equation(\[l_{i,j}:=\left\{\begin{matrix} \deg(v_i) & \mbox{if}\ i = j \\ -1 & \mbox{if}\ i \neq j\ \mbox{and}\ v_i\ \mbox{adjacent}\ v_j \\ 0 & \mbox{otherwise} \end{matrix} \right.\])]]


  See: http://en.wikipedia.org/wiki/Laplacian_matrix, http://arxiv.org/abs/0706.3069, http://arxiv.org/abs/0706.1176, http://arxiv.org/abs/0708.1862


type: enhancement
component: graph-tool
priority: normal
owner: count0
reporter: count0
version: devel
status: new
summary: Add support for k-cores
description:
  Add support for the computation of k-cores, computed by pruning all the vertices (with their respective edges) with degree less than k. To each vertex it should be assigned a number, representing the highest k-core it belongs to.

  See: http://en.wikipedia.org/wiki/K-core, http://arxiv.org/abs/cs.DS/0202039 (contains algorithm), [http://scitation.aip.org/getabs/servlet/GetabsServlet?prog=normal&id=PLEEE8000073000005056101000001&idtype=cvips&gifs=yesk-core k-core (bootstrap) percolation on complex networks: Critical phenomena and nonlocal effects] 


type: enhancement
component: graph-tool
priority: normal
owner: count0
reporter: count0
version: devel
status: new
summary: Add support for community detection, based on eigenvectors of matrices
description:
  Add support for community detection, based the method described in [http://arxiv.org/abs/physics/0605087 physics/0605087], which uses the eigenvectors of a modularity matrix.


type: enhancement
component: graph-tool
priority: normal
owner: count0
reporter: count0
version: devel
status: new
summary: Add support for community detection, based on random walk
description:
  Add support for community detection, based on a random walk method described in [http://arxiv.org/abs/physics/0512106 physics/0512106].

  Use available GPL C++ implementation from http://www.liafa.jussieu.fr/~pons/index.php?item=prog&item2=walktrap&lang=en


type: enhancement
component: graph-tool
priority: normal
owner: count0
reporter: count0
version: devel
status: new
summary: Add support for community detection, based on edge centrality
description:
  Community structure detection based on the edge betweenness centrality of the network, as defined in [http://www.pnas.org/cgi/content/abstract/99/12/7821 M. Girvan and M. E. J. Newman: Community structure in social and biological networks, Proc. Nat. Acad. Sci. USA 99, 7821-7826 (2002).].


type: enhancement
component: graph-tool
priority: normal
owner: count0
reporter: count0
version: devel
status: new
summary: Add support for community detection, based on modularity optimization
description:
  Add support for community detection based on the greedy optimization of modularity, as defined in [http://www.arxiv.org/abs/cond-mat/0408187 cond-mat/0408187].


type: enhancement
component: graph-tool
priority: normal
owner: count0
reporter: count0
version: devel
status: new
summary: Add support for PageRank calculation
description:
  Add support for [http://en.wikipedia.org/wiki/PageRank PageRank] calculation of vertices:

    !PageRank is a probability distribution used to represent the likelihood that a person randomly clicking on links will arrive at any particular page. !PageRank can be calculated for any-size collection of documents. It is assumed in several research papers that the distribution is evenly divided between all documents in the collection at the beginning of the computational process. The !PageRank computations require several passes, called "iterations", through the collection to adjust approximate !PageRank values to more closely reflect the theoretical true value.


type: enhancement
component: graph-tool
priority: normal
owner: count0
reporter: count0
version: devel
status: new
summary: Add support for eigenvector centrality
description:
  Add support for the eigenvector centrality of vertices.

    Eigenvector centrality is a measure of the importance of a node in a network. It assigns relative scores to all nodes in the network based on the principle that connections to high-scoring nodes contribute more to the score of the node in question than equal connections to low-scoring nodes.

  See: http://en.wikipedia.org/wiki/Eigenvector_centrality


type: enhancement
component: graph-tool
priority: normal
owner: count0
reporter: count0
version: devel
status: new
summary: Add support for specific random graph generators
description:
  Add support for generation of some specific, but commonly used, random graphs:

   * [http://en.wikipedia.org/wiki/Preferential_attachment Barabási-Albert] networks (undirected)
   * [http://www.garfield.library.upenn.edu/papers/pricenetworks1965.pdf Price network] (directed)
   * Erdős-Reyni graphs (can be just an alias to the specific parameters of the general correlated configurational model)
   * [http://en.wikipedia.org/wiki/Watts_and_Strogatz_model Watts-Strogatz] small world network
   * ...


type: defect
component: graph-tool
priority: normal
owner: count0
reporter: anonymous
version: devel
status: closed
resolution: invalid
summary: LED显示屏、全彩色LED电子显示屏专业制造商 百润慧通 13911588988
description:
  LED显示屏、全彩色LED电子显示屏专业制造商  百润慧通 13911588988

  北京百润慧通电子技术有限公司是集LED显示屏、LED电子显示屏外延应用产品科研开发、生产、销售、安装及培训服务于一体的高新科技产业公司。公司的产品已形成完整的系列，应用于室内、室外、半室外各种场所的单色LED显示屏、伪彩色LED显示屏、全彩色LED显示屏等达二十多个品种。产品应用范围涉及机场、火车站、汽车站、大型体育及会展场馆、智能交通、高速公路、银行、广告、电力、商业、电信、医院、税务、银行、交易市场、市民广场等几乎所有的相关系统及行业。公司建立了具有现代化管理、设备先进的显示屏生产加工基地。公司视产品品质为企业的生命,对每一项产品都进行严谨的工艺设计、严密生产监督和质量检测，从而确保了产品的高可靠性。

  公司特别重视产品的售后服务，建立了完善的售后服务体系，向用户提供免费培训、定期巡检、反应迅捷、终身维护的服务承诺。本公司将秉承“执着进取、追求完美”的理念以孜孜不倦的勤奋精神向用户提供优质的服务。

  公司产品全面贯彻信息产业部<<LED显示屏通用规范>>的要求,秉承“以质量、服务、诚信为发展根本”的企业精神，从产品开发、试制、生产、检测、安装、服务建立健全了完善的产品质量保证体系。公司与规模庞大的支持屏体生产的管芯厂、封装厂、LED数码管，LED发光管、LED点阵模块、电源、PCB、加工生产厂等数家专业配套厂有良好的商业合作关系，我们将共同完成LED产业纵向一体化宏伟目标。

  我们相信：我们以优良的整体设计、完美的细节表现及完善的服务体系，终将成为您真诚永远的合作伙伴。

  企业宗旨：发展光电科技
  企业目标：打造知名品牌
  企业精神：追求卓越品质
  企业价值观：开拓创新，诚实守信，以客户为本  

  百润慧通具有从LED显示屏的开发、设计到制造、组装等一条龙生产设备。有国际先进水平的全自动贴片机、波峰焊、回流焊机、超声波清洗机；专用生产、调试车间和成套测试仪器等。经过多年的发展，自身的管理机制、技术开发、品质体系、服务导向等已日趋成熟，在国内LED业界始终保持着领先地位。

  北京百润慧通电子技术有限责任公司   

  销售部:

  联系电话：010-52566097  52566451  

  24小时售前产品咨询热线：13911588988


  技术部:

  联系电话: 010-52566452  

  24小时售后产品技术支持：13911205351


  生产工程部:

  联系电话：010-52566453  

  24小时售后产品维修电话：13811164442


  地址：北京市昌平区定福皇庄钢材木材市场7号院（102208）  
   

   
  电子邮件：panelway@126.com
   
   

  网址：http://www.panelway.com

  http://www.panelway.com.cn

  http://www.panelway.cn


type: defect
component: graph-tool
priority: normal
owner: count0
reporter: anonymous
version: devel
status: closed
resolution: invalid
summary: LED显示屏|LED电子显示屏 百润慧通 13911588988
description:
  LED显示屏|LED电子显示屏  百润慧通 13911588988

  北京百润慧通电子技术有限责任公司是集LED显示屏、LED电子显示屏外延应用产品科研开发、生产、销售、安装及培训服务于一体的高新科技产业公司。公司的产品已形成完整的系列，应用于室内、室外、半室外各种场所的单色LED显示屏、伪彩色LED显示屏、全彩色LED显示屏等达二十多个品种。产品应用范围涉及机场、火车站、汽车站、大型体育及会展场馆、智能交通、高速公路、银行、广告、电力、商业、电信、医院、税务、银行、交易市场、市民广场等几乎所有的相关系统及行业。公司建立了具有现代化管理、设备先进的显示屏生产加工基地。公司视产品品质为企业的生命,对每一项产品都进行严谨的工艺设计、严密生产监督和质量检测，从而确保了产品的高可靠性。

  公司特别重视产品的售后服务，建立了完善的售后服务体系，向用户提供免费培训、定期巡检、反应迅捷、终身维护的服务承诺。本公司将秉承“执着进取、追求完美”的理念以孜孜不倦的勤奋精神向用户提供优质的服务。

  公司产品全面贯彻信息产业部<<LED显示屏通用规范>>的要求,秉承“以质量、服务、诚信为发展根本”的企业精神，从产品开发、试制、生产、检测、安装、服务建立健全了完善的产品质量保证体系。公司与规模庞大的支持屏体生产的管芯厂、封装厂、LED数码管，LED发光管、LED点阵模块、电源、PCB、加工生产厂等数家专业配套厂有良好的商业合作关系，我们将共同完成LED产业纵向一体化宏伟目标。

  我们相信：我们以优良的整体设计、完美的细节表现及完善的服务体系，终将成为您真诚永远的合作伙伴。

  企业宗旨：发展光电科技
  企业目标：打造知名品牌
  企业精神：追求卓越品质
  企业价值观：开拓创新，诚实守信，以客户为本  

  百润慧通具有从LED显示屏的开发、设计到制造、组装等一条龙生产设备。有国际先进水平的全自动贴片机、波峰焊、回流焊机、超声波清洗机；专用生产、调试车间和成套测试仪器等。经过多年的发展，自身的管理机制、技术开发、品质体系、服务导向等已日趋成熟，在国内LED显示屏业界始终保持着领先地位。

  LED显示屏|LED电子显示屏|北京LED电子显示屏  百润慧通 13911588988

  北京百润慧通电子技术有限责任公司   

  销售部:

  联系电话：010-52566451/6452/6453/6097转分机8001

  24小时售前产品咨询热线：13911588988



  地址：北京市昌平区定福皇庄钢材木材市场7号院（102208）  
   

   
  电子邮件：panelway@126.com
   
   

  QQ: 374532766



  MSN：panelway@hotmail.com



  网址：http://www.panelway.com

  http://www.panelway.com.cn

  http://www.panelway.cn

  LED显示屏|LED电子显示屏|北京LED电子显示屏  百润慧通 13911588988
  LED显示屏|LED电子显示屏|北京LED电子显示屏  百润慧通 13911588988
  LED显示屏|LED电子显示屏|北京LED电子显示屏  百润慧通 13911588988


type: enhancement
component: graph-tool
priority: normal
owner: count0
reporter: count0
version: devel
milestone: 1.2
status: new
summary: Random graph generation without parallel edges
description:
  Modify the RandomGraphGeneration code to optionally build random graphs without parallel edges.

  Useful reference for the undirected case: http://arxiv.org/abs/0708.4161


# milestone

name: 2.0
description:
   * Calculate [http://en.wikipedia.org/wiki/NP_%28complexity%29 non-deterministic polynomial time] algorithms in polynomial time.
   * Cure [http://en.wikipedia.org/wiki/Cancer cancer].


name: 1.0
description:
   * Add a couple more [https://projects.forked.de/graph-tool/query?milestone=1.0 interesting algorithms]
   * Some possible modifications based on user feedback


# session_attribute

sid: 070e5c961173cd0f13f3c0a8
name: query_href
value:
  /graph-tool/query?status=new&status=assigned&status=reopened&group=owner&verbose=1&order=priority&desc=1


sid: 02d0ca8fd1ccdfaf2ed40618
name: query_href
value:
  /graph-tool/query?status=new&status=assigned&status=reopened&group=owner&verbose=1&order=type&desc=1


sid: 1b71dbc2ba418022c9dac2ee
name: query_href
value:
  /graph-tool/query?status=new&status=assigned&status=reopened&group=owner&verbose=1&order=status&desc=1


sid: 12d23f0c1080671f231381ce
name: query_href
value:
  /graph-tool/query?status=new&status=assigned&status=reopened&group=owner&verbose=1&order=milestone&desc=1


sid: 95a2283b3a803c5140c50d48
name: query_href
value:
  /graph-tool/query?status=new&status=assigned&status=reopened&group=owner&verbose=1&order=component&desc=1


sid: d9f638d39a060fe516fa3855
name: query_href
value:
  /graph-tool/query?status=new&status=assigned&status=reopened&group=owner&verbose=1&order=summary&desc=1


sid: fa065f440d7bccad76714901
name: query_href
value:
  /graph-tool/query?status=new&status=assigned&status=reopened&component=graph-tool&milestone=1.0&order=priority


# ticket_change

author: count0
field: description
oldvalue:
  Combined (in,out) degree histogram should be generalized to accept any degree type or scalar property.

newvalue:
  Combined (in,out) degree histogram should be generalized to accept any degree type or scalar property.

  It would also imply on the death of --vertex-scalar-correlation-histogram


author: count0
field: comment
newvalue:
  This was fixed in [36]. See source:trunk/src/graph/graph_extended_clustering.cc#36

  Abdo, I modified your code in the following manner (besides cleanup and some reorganization):

   * your code was of complexity of at least O(V^2^)! This was because you had to initialize the distance map for every vertex before every BFS. The `breadth_first_search()` also does the same thing automatically for the color property it uses. I fixed this by defining a distance map and a color map which are automatically initialized with a specified value when an element is asked for the first time. I also used `breadth_first_visit()` instead, which does not initialize the colors. The complexity than reduces to O(V*N(d)) where N(d) is the average number of vertices + edges visited during a BFS of maximum depth d.
   * the algorithm now stores one property for each `C`, instead of only one property with all `C`s.

  I did some quick checks and the algorithm seems to be correct. But I'd really like for you to test this when you have the time...

  (this is activated in graph-tool by calling, for instance, `--set-extended-clustering-to-property="c|5"` to get the Cs assingned to the properties c0, c1, ..., c5.)


author: count0
field: comment
newvalue:
  Correction: The complexity of the new algorithm is O(V<k>^2^N(d)), where <k> is the average undirected degree, and N(d) is as explained above. It's still better than O(V^2^) for most cases...

  I also detected a problem with graphs with parallel edges (where k != number of neighbours). This should be fixed in [37].


author: count0
field: comment
newvalue:
  I preffer the second option, with both "--history" and "--for" options, with the semantics you specified.

  This was fixed in [43].


author: count0
field: comment
newvalue:
  This is a very cosmetic thing, and rather silly. But since this extended clustering thing is your baby, I'm going to grant your wish. ;-)

  This was fixed in [44].


author: count0
field: comment
newvalue:
  This was fixed in [9]. I used most of your patch. I changed only how it handles the case where it should infer the format from the file name, where I took out the "from_file_extension" format and used a function overload instead. Thanks!


author: anonymous
field: comment
newvalue:
  Initial support for this was added in [47]. It's still experimental, and it still needs to be checked for correctness. So don't use it in a production situation. Plus, I'm not sure I've done it in the most efficient way. I'm still working on it, but help and comments are appreciated.


author: count0
field: comment
newvalue:
  Things were much improved in [50], and should be usable now. I'll be adding some documentation soon.


author: count0
field: comment
oldvalue: 1
newvalue:
  Thanks for point this out. In fact, as you probably noticed, this was never used in the rest of the program, and that's why the problem was never noticed. The reason why it was never used, is that it is impossible, in a general way, to make algorithms behave equally for directed and undirected graphs, simply by pointing the out and in-edges to the same edges. Several semantical things get broken this way, such as the total number of edges (the sum of in + out of each vertex must be equal to 2E). In other words, directed and undirected graphs are different animals, and except in very specific cases, the algorithm must know at some point what it is dealing with. So defining "in_edges" for an undirected graph is quite misleading, and the best approach in my opinion is to remove this from the adaptor.

  I is still quite possible to make unique code which works for both types of graph by simply abstracting the edge iteration locally, by asking graph_traits<Graph>::directed_category.


author: count0
field: comment
oldvalue: 3
newvalue:
  Add support for alternative reciprocity definition, as specified in [http://arxiv.org/abs/0706.3372 0706.3372]:

    The network reciprocity [[Equation($r$)]] is classically defined as [[Equation($r = \frac{L^{bd}} {L}$)]] where [[Equation($L^{bd}$)]] is the number of directed links [[Equation($s \to t$)]] that also have a reciprocal (bidirectional) counterpart [[Equation($s \gets t$)]], and [[Equation($L$)]] is the total number of directed links. Reciprocal links are loops of the lowest order, and are therefore, important as a natural measure of feedback in the	network.


# report

title: Active Tickets
query:
  SELECT p.value AS __color__,
     id AS ticket, summary, component, version, milestone, t.type AS type,
     (CASE status WHEN 'assigned' THEN owner||' *' ELSE owner END) AS owner,
     time AS created,
     changetime AS _changetime, description AS _description,
     reporter AS _reporter
    FROM ticket t, enum p
    WHERE status IN ('new', 'assigned', 'reopened')
  AND p.name = t.priority AND p.type = 'priority'
    ORDER BY p.value, milestone, t.type, time

description:
   * List all active tickets by priority.
   * Color each row based on priority.
   * If a ticket has been accepted, a '*' is appended after the owner's name


title: Active Tickets by Version
query:
  SELECT p.value AS __color__,
     version AS __group__,
     id AS ticket, summary, component, version, t.type AS type,
     (CASE status WHEN 'assigned' THEN owner||' *' ELSE owner END) AS owner,
     time AS created,
     changetime AS _changetime, description AS _description,
     reporter AS _reporter
    FROM ticket t, enum p
    WHERE status IN ('new', 'assigned', 'reopened')
  AND p.name = t.priority AND p.type = 'priority'
    ORDER BY (version IS NULL),version, p.value, t.type, time

description:
  This report shows how to color results by priority,
  while grouping results by version.

  Last modification time, description and reporter are included as hidden fields
  for useful RSS export.


title: All Tickets by Milestone
query:
  SELECT p.value AS __color__,
     milestone||' Release' AS __group__,
     id AS ticket, summary, component, version, t.type AS type,
     (CASE status WHEN 'assigned' THEN owner||' *' ELSE owner END) AS owner,
     time AS created,
     changetime AS _changetime, description AS _description,
     reporter AS _reporter
    FROM ticket t, enum p
    WHERE status IN ('new', 'assigned', 'reopened')
  AND p.name = t.priority AND p.type = 'priority'
    ORDER BY (milestone IS NULL),milestone, p.value, t.type, time

description:
  This report shows how to color results by priority,
  while grouping results by milestone.

  Last modification time, description and reporter are included as hidden fields
  for useful RSS export.


title: Assigned, Active Tickets by Owner
description: List assigned tickets, group by ticket owner, sorted by priority.
query:
  SELECT p.value AS __color__,
     owner AS __group__,
     id AS ticket, summary, component, milestone, t.type AS type, time AS created,   changetime AS _changetime, description AS _description,
     reporter AS _reporter
    FROM ticket t,enum p
    WHERE status = 'assigned'
  AND p.name=t.priority AND p.type='priority'
    ORDER BY owner, p.value, t.type, time


title: Assigned, Active Tickets by Owner (Full Description)
query:
  SELECT p.value AS __color__,
     owner AS __group__,
     id AS ticket, summary, component, milestone, t.type AS type, time AS created,   description AS _description_,
     changetime AS _changetime, reporter AS _reporter
    FROM ticket t, enum p
    WHERE status = 'assigned'
  AND p.name = t.priority AND p.type = 'priority'
    ORDER BY owner, p.value, t.type, time

description:
  List tickets assigned, group by ticket owner.
  This report demonstrates the use of full-row display.


title: All Tickets By Milestone (Including closed)
description: A more complex example to show how to make advanced reports.
query:
  SELECT p.value AS __color__,
     t.milestone AS __group__,
     (CASE status
        WHEN 'closed' THEN 'color: #777; background: #ddd; border-color: #ccc;'
        ELSE
          (CASE owner WHEN '$USER' THEN 'font-weight: bold' END)
      END) AS __style__,
     id AS ticket, summary, component, status,
     resolution,version, t.type AS type, priority, owner,
     changetime AS modified,
     time AS _time,reporter AS _reporter
    FROM ticket t,enum p
    WHERE p.name=t.priority AND p.type='priority'
    ORDER BY (milestone IS NULL), milestone DESC, (status = 'closed'),
          (CASE status WHEN 'closed' THEN modified ELSE (-1)*p.value END) DESC


title: My Tickets
query:
  SELECT p.value AS __color__,
     (CASE status WHEN 'assigned' THEN 'Assigned' ELSE 'Owned' END) AS __group__,
     id AS ticket, summary, component, version, milestone,
     t.type AS type, priority, time AS created,
     changetime AS _changetime, description AS _description,
     reporter AS _reporter
    FROM ticket t, enum p
    WHERE t.status IN ('new', 'assigned', 'reopened')
  AND p.name = t.priority AND p.type = 'priority' AND owner = '$USER'
    ORDER BY (status = 'assigned') DESC, p.value, milestone, t.type, time

description:
  This report demonstrates the use of the automatically set
  $USER dynamic variable, replaced with the username of the
  logged in user when executed.


title: Active Tickets, Mine first
query:
  SELECT p.value AS __color__,
     (CASE owner
       WHEN '$USER' THEN 'My Tickets'
       ELSE 'Active Tickets'
      END) AS __group__,
     id AS ticket, summary, component, version, milestone, t.type AS type,
     (CASE status WHEN 'assigned' THEN owner||' *' ELSE owner END) AS owner,
     time AS created,
     changetime AS _changetime, description AS _description,
     reporter AS _reporter
    FROM ticket t, enum p
    WHERE status IN ('new', 'assigned', 'reopened')
  AND p.name = t.priority AND p.type = 'priority'
    ORDER BY (owner = '$USER') DESC, p.value, milestone, t.type, time

description:
   * List all active tickets by priority.
   * Show all tickets owned by the logged in user in a group first.


# templates

name: TemplatesIndex
author: Wiki Templates Plugin
text:
  = What is the !WikiTemplates Plugin =
  It's a macro plugin that if called like '''`[[T(....)]]`''', grab's a wiki page and includes it inside another with pre-formated text replacing the vars '''''`{{n}}`''''' by the args passed, '''''`n`''''' being a number. If called like '''`[[Include(....)]]`''' grabs  a wiki page and include it's full contents inside another.

  Great aint it? Just imagine the posibilities...[[BR]]
  More info on the WikiMacros wiki page and http://wikitemplates.ufsoft.org

  = How to create new templates =
  As you might have noticed, there's a tiny box on the right side that says '''Create a New Template''', just put a string on that box and click the '''Create''' button, and you're good to go, next step is just like you'd do on a wiki page, or go to '''__`http://domain.com/templates/TheName`__''', '''!TheName''' being the name of the template you want to create.

  = List of Wiki Templates =
  Bellow you'll find a list of all Wiki Templates included on this Trac environment. It keeps growing as you add templates.


name: Parallel
author: count0
ipnr: 201.81.210.76
text:
  {{{
  #!html
  <span class="complexity">
  Runs in [wiki:ParallelAlgorithms parallel]: '''{{1}}'''
  </span>
  }}}


name: Parallel
author: count0
ipnr: 201.81.210.76
text:
  {{{
  #!html
  <span class="complexity">
  }}}
  Runs in [wiki:ParallelAlgorithms parallel]: '''{{1}}'''
  {{{
  #!html
  </span>
  }}}


name: Parallel
author: count0
ipnr: 201.81.210.76
text:
  {{{
  #!html
  <span style:"float: right">
  }}}
  Runs in [wiki:ParallelAlgorithms parallel]: '''{{1}}'''
  {{{
  #!html
  </span>
  }}}


name: Parallel
author: count0
ipnr: 201.81.210.76
text:
  {{{
  #!html
  <span style="float: right">
  }}}
  Runs in [wiki:ParallelAlgorithms parallel]: '''{{1}}'''
  {{{
  #!html
  </span>
  }}}


name: Parallel
author: count0
ipnr: 201.81.210.76
text:
  {{{
  #!html
  <span class="complexity" style="margin-top:1em">
  }}}
  Runs in [wiki:ParallelAlgorithms parallel]: '''{{1}}'''
  {{{
  #!html
  </span>
  }}}


name: Parallel
author: count0
ipnr: 201.81.210.76
text:
  {{{
  #!html
  <span class="complexity" style="margin-top:0.1em">
  }}}
  Runs in [wiki:ParallelAlgorithms parallel]: '''{{1}}'''
  {{{
  #!html
  </span>
  }}}


name: Parallel
author: count0
ipnr: 201.81.210.76
text:
  {{{
  #!html
  <span style="padding-top:0.1em" class="complexity">
  }}}
  Runs in [wiki:ParallelAlgorithms parallel]: '''{{1}}'''
  {{{
  #!html
  </span>
  }}}


name: Parallel
author: count0
ipnr: 201.81.210.76
text:
  {{{
  #!html
  <span style="padding-top:0.5em" class="complexity">
  }}}
  Runs in [wiki:ParallelAlgorithms parallel]: '''{{1}}'''
  {{{
  #!html
  </span>
  }}}


