Redian新闻
>
求 matlab R2007b unix license file
avatar
求 matlab R2007b unix license file# Computation - 科学计算
S*n
1
请教各位大师, 如图所示
1. 环形小区房子,都算反弓吗?
2. 这里31,32号房子,算路冲吗?
请不吝赐教
avatar
a*d
2
长恨歌
汉皇重色思倾国,御宇多年求不得。
杨家有女初长成,养在深闺人未识
天生丽质难自弃,一朝选在君王侧。回眸一笑百媚生,六宫粉黛无颜色。
春寒赐浴华清池,温泉水滑洗凝脂。侍儿扶起娇无力,始是新承恩泽时
云鬓花颜金步摇,芙蓉帐暖度春宵。
春宵苦短日高起,从此君王不早朝。
承欢侍宴无闲暇,春从春游夜专夜。
后宫佳丽三千人
三千宠爱在一身。
金屋妆成娇侍夜,玉楼宴罢醉和春。
姊妹弟兄皆列土,可怜光彩生门户。
遂令天下父母心,不重生男重生女。
骊宫高处入青云,仙乐风飘处处闻
缓歌慢舞凝丝竹,尽日君王看不足。
渔阳鼙鼓动地来,惊破霓裳羽衣曲。
九重城阙烟尘生,千乘万骑西南行。翠华摇摇行复止,西出都门百馀里。
六军不发无奈何,宛转蛾眉马前死。
花钿委地无人收,翠翘金雀玉搔头
君王掩面救不得,回看血泪相和流。黄埃散漫风萧索,云栈萦纡登剑阁。
http://www.dhcca.org/Lit%20with%20graph/Changhenge/CHH4.h18.jpg .
峨嵋山下少人行,旌旗无光日色薄。
蜀江水碧蜀山青,圣主朝朝暮暮情。行宫见月伤心色,夜雨闻铃肠断声。
天旋地转回龙驭,到此踌躇不能
avatar
h*a
3
【 以下文字转载自 ChinaNews 讨论区 】
发信人: hpanda (panda), 信区: ChinaNews
标 题: 中国顶级域名CN注册始末
发信站: BBS 未名空间站 (Thu Nov 6 12:48:33 2008)
http://tech.sina.com.cn/i/2008-11-06/09502560636.shtml
编者按:1987年的秋季,在成功发出中国第一封电子邮件后,王运丰教授更加频繁
的往返于中国和德国之间,在积极推进中国网络应用的过程中,他清楚的意识到注册中
国顶级域名的重要性,并开始思考用哪两个字母代表中国。1990年11月28日,.CN域名
完成注册。1994年5月21日,CN域名服务器回到中国。
作为《中国互联网发展大事记》的编撰者,CNNIC互联网发展研究部高级研究顾问
王恩海耗时一年,通过走访、资料收集和与当事人交流等方式,对这段特殊的经历进行
考证和梳理,还原了这段鲜为人知的历史。
口述人:王恩海 身份:《中国互联网发展大事记》编撰者 采访/整理:韩枝、连巍
1990年10月10日,王运丰教授在德国卡尔斯鲁大学与措恩教授商讨中国
avatar
c*3
4
其实是个数据问题。想构建一个可快速查询的字典。很n久没有用比较复杂的数据结构
了。
插入和删除估计不多,所以性能要求不高。对查询要求比较高。字典估计有50万左右的
词。
第一想法是用B+树。不知道合适不?有别的更好的数据结构和算法没有?
谢谢
avatar
j*3
5
哪位有的 给传一份吧。
谢谢了。s*******[email protected]
avatar
l*r
6
不算,要看路的限速多少,限速高的煞气越大,限速低的煞气小
avatar
j*b
7
呵呵,好漂亮啊
avatar
g*g
8
要我说做个数据库,建个索引就行了。50万不是太多。

【在 c*********3 的大作中提到】
: 其实是个数据问题。想构建一个可快速查询的字典。很n久没有用比较复杂的数据结构
: 了。
: 插入和删除估计不多,所以性能要求不高。对查询要求比较高。字典估计有50万左右的
: 词。
: 第一想法是用B+树。不知道合适不?有别的更好的数据结构和算法没有?
: 谢谢

avatar
w*r
9
这不是反弓,是内弓。
也不是路冲。

【在 S*********n 的大作中提到】
: 请教各位大师, 如图所示
: 1. 环形小区房子,都算反弓吗?
: 2. 这里31,32号房子,算路冲吗?
: 请不吝赐教

avatar
S*t
10
是谁画的啊?很赞!
avatar
c*3
11
考虑过这种可能。种种情况限制,不太可能用数据库。要不也不问了。数据库就简单多
了。谢谢
avatar
a*d
12
一个著名的画家,猜猜是谁?猜对有包子

【在 S*******t 的大作中提到】
: 是谁画的啊?很赞!
avatar
c*t
13
Both B trees and B+ trees are for databases, not for generic in-memory
access. They are also quite complex, so forget them.
BST should be faster (for in-memory data access) and simpler and there
are a lot of libraries supporting it.
50k isn't a lot of data, so you could even try simple array, or simple
sorted array with binary search.
You could also consider hash and trie, which could be even faster.
In most cases, pre-emptive optimization is a bad idea. You should just
pick a easy to implemen

【在 c*********3 的大作中提到】
: 其实是个数据问题。想构建一个可快速查询的字典。很n久没有用比较复杂的数据结构
: 了。
: 插入和删除估计不多,所以性能要求不高。对查询要求比较高。字典估计有50万左右的
: 词。
: 第一想法是用B+树。不知道合适不?有别的更好的数据结构和算法没有?
: 谢谢

avatar
r*y
14
戴敦邦

【在 a***d 的大作中提到】
: 一个著名的画家,猜猜是谁?猜对有包子
avatar
r*r
15
use patricia trie
B+ tree is not the best choice
avatar
c*l
16
好看、、、
avatar
s*e
17
C++的话用STL的map,Java的话用HashMap应该就够用了。

【在 c*********3 的大作中提到】
: 其实是个数据问题。想构建一个可快速查询的字典。很n久没有用比较复杂的数据结构
: 了。
: 插入和删除估计不多,所以性能要求不高。对查询要求比较高。字典估计有50万左右的
: 词。
: 第一想法是用B+树。不知道合适不?有别的更好的数据结构和算法没有?
: 谢谢

avatar
f*Q
18
SQLite?
avatar
r*r
19
using SQLite is same as using a B tree. hehe
avatar
f*Q
20
SQLite现在性能如何?
avatar
c*c
21
binary search tree就可以啦

【在 c*********3 的大作中提到】
: 其实是个数据问题。想构建一个可快速查询的字典。很n久没有用比较复杂的数据结构
: 了。
: 插入和删除估计不多,所以性能要求不高。对查询要求比较高。字典估计有50万左右的
: 词。
: 第一想法是用B+树。不知道合适不?有别的更好的数据结构和算法没有?
: 谢谢

avatar
c*3
22
是用C++。最初实现是用STL map. 速度达不到要求。因为原来的代码不是我写的,刚刚
接手。看来我还是先看看原来的代码先。先谢谢了
avatar
t*m
23
B+ tree主要用于database的index实现,主要是支持基于page I/O的树索引,这里不合
适。
你需要的是内存结构,但取决于你的需求。如果是普通查询,i.e., 输入一个词,返回
它的解释,用hash table: key 是词的string, value是解释,也是string. 50万个词
,每个词平均远低于10 byte (不考虑unicode), 共 5MB, 假定每个词的解释 1KB, 则
共 500MB, 全部load进内存没问题。
不要用C++ STL 的map, 那个不是hash table, 是 tree 结构,一般实现是 red-black
tree, 有很多 C++ STL extension, 如 SGI C++ STL 的 hash_map, 是hash table,
Linux GNU C++ 中也有。
如果你需要支持其他查询,如范围查询, 模糊查询,等, 你可以考虑其他结构,一般
是各种 tree

【在 c*********3 的大作中提到】
: 其实是个数据问题。想构建一个可快速查询的字典。很n久没有用比较复杂的数据结构
: 了。
: 插入和删除估计不多,所以性能要求不高。对查询要求比较高。字典估计有50万左右的
: 词。
: 第一想法是用B+树。不知道合适不?有别的更好的数据结构和算法没有?
: 谢谢

avatar
o*u
25
trie 确实是个好办法,自己写一个也不复杂。这是一种单词查找树,每个节点存一个
字母,从根节点下来到叶子,就是这个字符串。 在 bst 中, log2(500000)=19, 而在
trie中,每个单词的查询时间就是单词的长度,大部分单词少于19个字母。
hash table 更快,但是最好根据需要自己设计hash function, 这样控制得比较好。速度取决于 hash 的 collision.

【在 g*****e 的大作中提到】
: Trie is your best bet!
: http://en.wikipedia.org/wiki/Trie

avatar
d*h
26
如果是load in memory, Suffix tree 也是个不错的选择:
1.build time O(n) -> on-line structured
2.space O(n)
3. searching time O(m) -> m is the search query size
avatar
s*e
27
以前还真不知道stl的map不是用的hash table,多谢提醒啊。

black

【在 t*******m 的大作中提到】
: B+ tree主要用于database的index实现,主要是支持基于page I/O的树索引,这里不合
: 适。
: 你需要的是内存结构,但取决于你的需求。如果是普通查询,i.e., 输入一个词,返回
: 它的解释,用hash table: key 是词的string, value是解释,也是string. 50万个词
: ,每个词平均远低于10 byte (不考虑unicode), 共 5MB, 假定每个词的解释 1KB, 则
: 共 500MB, 全部load进内存没问题。
: 不要用C++ STL 的map, 那个不是hash table, 是 tree 结构,一般实现是 red-black
: tree, 有很多 C++ STL extension, 如 SGI C++ STL 的 hash_map, 是hash table,
: Linux GNU C++ 中也有。
: 如果你需要支持其他查询,如范围查询, 模糊查询,等, 你可以考虑其他结构,一般

avatar
w*g
28
如果程序运行中不需要增加单词,那么应该用perfect hash。

【在 c*********3 的大作中提到】
: 其实是个数据问题。想构建一个可快速查询的字典。很n久没有用比较复杂的数据结构
: 了。
: 插入和删除估计不多,所以性能要求不高。对查询要求比较高。字典估计有50万左右的
: 词。
: 第一想法是用B+树。不知道合适不?有别的更好的数据结构和算法没有?
: 谢谢

avatar
N*d
29
suffix tree?

【在 c*********3 的大作中提到】
: 其实是个数据问题。想构建一个可快速查询的字典。很n久没有用比较复杂的数据结构
: 了。
: 插入和删除估计不多,所以性能要求不高。对查询要求比较高。字典估计有50万左右的
: 词。
: 第一想法是用B+树。不知道合适不?有别的更好的数据结构和算法没有?
: 谢谢

avatar
x*u
30
除了面试以外,你要是上来就想到设计个算法做,那是不专业的表现。
牛人会告诉你,用数据库或者用微型数据库。凡事都自己用个数据结构裸搞是软件品质
下降的万恶之源。

【在 c*********3 的大作中提到】
: 其实是个数据问题。想构建一个可快速查询的字典。很n久没有用比较复杂的数据结构
: 了。
: 插入和删除估计不多,所以性能要求不高。对查询要求比较高。字典估计有50万左右的
: 词。
: 第一想法是用B+树。不知道合适不?有别的更好的数据结构和算法没有?
: 谢谢

avatar
c*3
31
貌似有理。
请教一下什么是专业的表现?是CS专业吗?我都不是学这个。问个问题,那里有这么多
道理。知道就指点一下。
用数据结构和软件品质好像没有什么直接联系吧!
avatar
c*3
32
貌似有理。
请教一下什么是专业的表现?是CS专业吗?我都不是学这个。问个问题,那里有这么多
道理。知道就指点一下。
用数据结构和软件品质好像没有什么直接联系吧!
相关阅读
logo
联系我们隐私协议©2024 redian.news
Redian新闻
Redian.news刊载任何文章,不代表同意其说法或描述,仅为提供更多信息,也不构成任何建议。文章信息的合法性及真实性由其作者负责,与Redian.news及其运营公司无关。欢迎投稿,如发现稿件侵权,或作者不愿在本网发表文章,请版权拥有者通知本网处理。