维度

【代码解读】yolov3测试过程

夙愿已清 提交于 2019-12-11 05:32:42
yolov3项目完整的代码_tensorflow版本 一 分析yolov3的测试部分 首先看一下整体的测试代码:Image_demo.py 写了一些注释: import cv2 import numpy as np import core . utils as utils import tensorflow as tf from PIL import Image ###############——————————第1部分:参数定义——————————————############## return_elements = [ "input/input_data:0" , "pred_sbbox/concat_2:0" , "pred_mbbox/concat_2:0" , "pred_lbbox/concat_2:0" ] #加载pb文件的时候,需要 输入节点和输出节点的 tensor返回值, #参考:https://blog.csdn.net/fu6543210/article/details/80343345 pb_file = "./yolov3_coco.pb" image_path = "./docs/images/road.jpeg" num_classes = 80 input_size = 416 graph = tf . Graph ( ) #计算图

Apache Kylin

寵の児 提交于 2019-12-10 11:19:23
Overview Kylin 的使命是超高速的大数据 OLAP (Online Analytical Processing),也就是要让大数据分析像使用数据库一样简单迅速,用户的查询请求可以在秒内返回。其中的关键就是打破查询时间随着数据量成线性增长的这个规律。解决方案是针对维度聚合的预计算,因为由于业务范围和分析需求是有限的,有意义的维度组合也是相对有限的,一般不会随着数据的膨胀而增长。传统的Hadoop生态提供了 大规模并行处理 和 列式存储 两大关键技术, 预计算 是Kylin提供的第三大关键技术。 Concept MOLAP(Multidimensional Online Analytical Processing)Cube 多维立方体分析 Dimension and Measure(维度和度量) 维度是观察数据的角度,度量是被聚合的统计值 Cube and Cuboid N个维度,组合的可能性共有2^N种;对于每一种维度的组合,将度量做聚合运算,然后将运算的结果保存为一个物化视图,称为 Cuboid ;所有维度组合的 Cuboid 作为一个整体,被称为 Cube 。一个 Cube 就是许多按维度聚合的物化视图的集合。 Process Kylin的工作原理就是对数据模型做 Cube 预计算,并利用计算的结果加速查询: 指定数据模型,定义维度和度量 预计算Cube

压缩感知与稀疏模型——Convex Methods for Sparse Signal Recovery

自作多情 提交于 2019-12-10 00:09:15
第三节课的内容。这节课上课到半截困了睡着了,看着大家都很积极请教认真听讲,感觉很惭愧。周末不能熬太晚。这个博客就记录一下醒着时候听到的内容。 Motivation 目前的时代需要处理的数据量维度可能很高,比如1024*960分辨率的图片转化成向量维度就是100万左右。对于当代搜索引擎需要处理的数据更是如此,大数据时代已经来临。 而我们直到,对于普通的对比信息检索,时间复杂度为$O(n)$,当然,如果加上维度$D$,数据检索复杂度变成了$O(Dn)$,要知道这里的D很大,属于高纬度数据,甚至远大于数据的个数$n$,是一定不可以忽略的。 有没有一种方法,能对数据降维,使得D变小?这样可以大大降低数据检索的复杂度。但是,对数据降维不能随机降,需要保矩,也就是对各个向量的相对关系需要进行保持,如下图: 我们希望原来维度上两个向量差多少,降维之后他们每一对向量之间的距离没有变化太多。 The Johnson-Lindenstrauss Lemma 下面介绍一条定理,简称为Lemma定理。它是当代搜索引擎对高维数据Hashing的核心。首先,我们要知道对于高维如果要完全用低纬度保存所有的信息是不可能的,因此会有一定的错误率,但是我们在统计角度上可以证明当数量大的时候这个错误率趋于0即可。 Johnson-Lindenstrauss Lemma :假定向量$v_1,v_2,…,v_n in

链家大数据多维分析引擎实践

被刻印的时光 ゝ 提交于 2019-12-08 22:29:17
前言 大数据背景下,传统关系型多维分析 ROLAP 引擎遇到极大挑战,因而链家转向基于 Hadoop 生态的 MOLAP(Kylin)及 HOLAP (多引擎)。在架构师实践日北京站中,链家大数据集群架构组负责人邓钫元进行演讲,分享了链家在多维分析引擎方面的一些实践经验,主要从 OLAP 的背景和简介、链家多维分析架构演进和展望、OLAP 平台链路优化这三部分来介绍。 一、OLAP 的背景和简介 > > > > 1. OLAP vs OLTP OLAP 翻译成中文叫 联机分析处理 ,OLTP 叫 联机事务处理 。OLTP 它的核心是事务,实际上就是我们常见的数据库。我们业务数据库就是面向于事务。它的并发量会比较高,但是操作的数据量会比较小。它是实时更新的。数据库的设计会按照 3NF 范式,更高的话可能会按照 BC 范式之类的来做。而 OLAP 的核心是分析,面向应用是分析决策,需要分析的数据级会非常大,可能 TB,甚至 PB 都会有。它的数据更新会稍微慢一些,它的设计一般是反范式的,因为面向分析。常见的是雪花模型和星型模型。 实际上 OLAP 是什么呢? 非常简单,就是一个 SQL,这里按照两个维度,一个 returnflag,一个 orderstatus 来做 Group By,然后做一下 Sum,Group By 这段就叫维度,From 这段叫做指标,非常简单。 > > > >

Pytorch实现基本循环神经网络RNN

空扰寡人 提交于 2019-12-08 14:57:00
RNN Recurrent Neural networks(Rumelhart, 1986) 主要用来处理序列型数据,具有对以往数据的记忆功能。下图所示,输入为input和一个状态Hidden0,输出为output和Hidden1. 一般地,对输入到RNN进行处理的第 t t t 个数据,也就是第 t t t 时刻,输出的隐藏状态可以表示为 h ( t ) = f ( h ( t − 1 ) , x ( t ) ; θ ) h^{(t)}=f(h^{(t-1)},x^{(t)};\theta) h ( t ) = f ( h ( t − 1 ) , x ( t ) ; θ ) 在RNN对序列数据进行处理时,采用参数共享机制,即权重是相同的。RNN有很多变体,上述的是最简单的一种形式,中间也可以输入 y ( t ) y^{(t)} y ( t ) 。 标准RNN如下: 对时刻 t t t ,更新的方程为: h t = tanh ⁡ ( w i h x t + b i h + w h h h t − 1 + b h h ) h_{t}=\tanh(w_{ih}x_{t}+b_{ih}+w_{hh}h_{t-1}+b_{hh}) h t ​ = tanh ( w i h ​ x t ​ + b i h ​ + w h h ​ h t − 1 ​ + b h h ​ ) 在实际中使用nn

案例分析:设计模式与代码的结构特性

ぃ、小莉子 提交于 2019-12-08 14:17:27
关于设计模式我选择的是桥接模式 一、桥接模式的定义   桥接模式就是把事物和其具体实现分开,使他们可以各自独立的变化。桥接的用意是:将抽象化与实现化解耦,使得二者可以独立变化。 抽象类起到一个连接实体类和接口的作用,类似于架起了一座沟通的桥梁,因此称为桥接模式。 二、桥接模式的优缺点 桥接模式有哪些优点? (1)分离抽象接口及其实现部分。桥接模式使用“对象间的关联关系”解耦了抽象和实现之间固有的绑定关系,使得抽象和实现可以沿着各自的维度来变化。所谓抽象和实现沿着各自维度的变化,也就是说抽象和实现不再在同一个继承层次结构中,而是“子类化”它们,使它们各自都具有自己的子类,以便任何组合子类,从而获得多维度组合对象。 (2)在很多情况下,桥接模式可以取代多层继承方案,多层继承方案违背了“单一职责原则”,复用性较差,且类的个数非常多,桥接模式是比多层继承方案更好的解决方法,它极大减少了子类的个数。 (3)桥接模式提高了系统的可扩展性,在两个变化维度中任意扩展一个维度,都不需要修改原有系统,符合“开闭原则”。 桥接模式有哪些缺点? (1)桥接模式的使用会增加系统的理解与设计难度,由于关联关系建立在抽象层,要求开发者一开始就针对抽象层进行设计与编程。 (2)桥接模式要求正确识别出系统中两个独立变化的维度,因此其使用范围具有一定的局限性,如何正确识别两个独立维度也需要一定的经验积累。 三

CNN神经网络一维卷积和二维卷积

牧云@^-^@ 提交于 2019-12-07 15:27:27
一维卷积只在一个维度上进行卷积操作,而二维卷积会在二个维度上同时进行卷积操作。 转载自: https://www.cnblogs.com/LXP-Never/p/10763804.html 一维卷积:tf.layers.conv1d() 一维卷积常用于序列数据,如自然语言处理领域。 tf.layers.conv1d( inputs, filters, kernel_size, strides=1, padding='valid', data_format='channels_last', dilation_rate=1, activation=None, use_bias=True, kernel_initializer=None, bias_initializer=tf.zeros_initializer(), kernel_regularizer=None, bias_regularizer=None, activity_regularizer=None, kernel_constraint=None, bias_constraint=None, trainable=True, name=None, reuse=None ) 参数: [1] inputs :张量数据输入,一般是[batch, width, length] filters :整数,输出空间的维度,可以理解为卷积核

NaN数据的处理

守給你的承諾、 提交于 2019-12-07 02:46:09
平均值替换 一组数据存在放m*n的array或mat中,其中m表示数据的个数,n表示数据的属性维度。数据中会有NaN类型的数据,可以使用平均值的方式替换。 替换方法: 分别计算每一维度(每一列)上非NaN数据的平均值,然后替换每一维度(每一列)的NaN数据。 # dataMat为np.mat类型 def replaceNanWithMean(dataMat): # 获取属性的维度 num_feat = np.shape(dataMat)[1] for i in range(num_feat): # 计算每一维度上的平均值, .A的意思是将mat -> array类型 meanVal = np.mean(dataMat[np.nonzero(~np.isnan(dataMat[:, i].A))[0], i]) dataMat[np.nonzero(np.isnan(dataMat[:, i].A))[0], i] = meanVal return dataMat 来源: oschina 链接: https://my.oschina.net/u/4228078/blog/3138224

NaN数据的处理

[亡魂溺海] 提交于 2019-12-07 02:20:59
平均值替换 一组数据存在放m*n的array或mat中,其中m表示数据的个数,n表示数据的属性维度。数据中会有NaN类型的数据,可以使用平均值的方式替换。 替换方法: 分别计算每一维度(每一列)上非NaN数据的平均值,然后替换每一维度(每一列)的NaN数据。 # dataMat为np.mat类型 def replaceNanWithMean(dataMat): # 获取属性的维度 num_feat = np.shape(dataMat)[1] for i in range(num_feat): # 计算每一维度上的平均值, .A的意思是将mat -> array类型 meanVal = np.mean(dataMat[np.nonzero(~np.isnan(dataMat[:, i].A))[0], i]) dataMat[np.nonzero(np.isnan(dataMat[:, i].A))[0], i] = meanVal return dataMat 来源: oschina 链接: https://my.oschina.net/u/4228078/blog/3138224

NaN数据的处理

冷暖自知 提交于 2019-12-06 16:29:28
平均值替换 一组数据存在放m*n的array或mat中,其中m表示数据的个数,n表示数据的属性维度。数据中会有NaN类型的数据,可以使用平均值的方式替换。 替换方法: 分别计算每一维度(每一列)上非NaN数据的平均值,然后替换每一维度(每一列)的NaN数据。 # dataMat为np.mat类型 def replaceNanWithMean(dataMat): # 获取属性的维度 num_feat = np.shape(dataMat)[1] for i in range(num_feat): # 计算每一维度上的平均值, .A的意思是将mat -> array类型 meanVal = np.mean(dataMat[np.nonzero(~np.isnan(dataMat[:, i].A))[0], i]) dataMat[np.nonzero(np.isnan(dataMat[:, i].A))[0], i] = meanVal return dataMat 来源: https://my.oschina.net/u/4228078/blog/3138224