V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  wxf666  ›  全部回复第 30 页 / 共 33 页
回复总数  656
1 ... 22  23  24  25  26  27  28  29  30  31 ... 33  
2022-08-01 17:04:37 +08:00
回复了 wyc9296 创建的主题 Python Python for 循环的效率是这么差么?还是别的什么原因?
@xgdgsc 不会吧,就算那个测评榜,C/C++ 之类也就比 Python 快两个数量级,你这啥能 3+ 个?
2022-08-01 16:48:13 +08:00
回复了 wyc9296 创建的主题 Python Python for 循环的效率是这么差么?还是别的什么原因?
@wyc9296 你把 str(i)+'->' 改成 f'{i}->' 应该还能再快些
2022-08-01 16:43:51 +08:00
回复了 Geon97 创建的主题 问与答 [讨论] 关于 MySQL 和 postgraSQL
不是一堆人把数据库当 kv 用的吗?那么多功能对他们有啥用?
2022-08-01 16:38:33 +08:00
回复了 wyc9296 创建的主题 Python Python for 循环的效率是这么差么?还是别的什么原因?
这个例子中,Google 花这么多钱搞的 V8 ,也没甩开 Python 多少啊?

这 8 楼 9 楼( 9 楼还少了个数量级)和楼主的没 JIT 的 Python 一比(第一个例子改成 += 就好),也没快多少啊
2022-08-01 15:42:11 +08:00
回复了 wyc9296 创建的主题 Python Python for 循环的效率是这么差么?还是别的什么原因?
你换成 a += str(i)+'->' 就差不多一样了
s='HELLO|*.py'
IFS='|' read -ar arr <<<$s

『 declare -p arr 后输出』
declare -a arr=([0]="HELLO" [1]="*.py")
2022-08-01 11:49:50 +08:00
回复了 yagamisam 创建的主题 问与答 关于删除重复项
假设按行分割,不要求按顺序输出的话:

sort a b | uniq -u > c
2022-07-29 21:24:52 +08:00
回复了 xyzzyssd 创建的主题 Apple 在家挂着一个 iPhone 作为副卡收短信怎么充电比较好?
手机充电后,还会用电池的电吗?
2022-07-29 12:37:12 +08:00
回复了 hahaFck 创建的主题 程序员 Java 关于数据库 Entity 如何设计
@LeegoYih 这数据量小,可能都缓存至内存了也说不定

有试过每张表的 B+树三 /四 /五层高(视行记录长度的不同,可能分别能容纳几千万、几百亿、几十兆行记录)时,俩 /仨表 join 的耗时差异吗?
2022-07-29 03:49:13 +08:00
回复了 hahaFck 创建的主题 程序员 Java 关于数据库 Entity 如何设计
@LeegoYih 数据库范式是有点理想化,

所以,若有性能(你 join 多一个表,肯定性能差些)、分库分表难 join 等实际问题,你会妥协地加入『部门 ID 』至『用户表』吗?
2022-07-29 03:45:06 +08:00
回复了 aflynoob 创建的主题 问与答 双拼输入法有必要学吗
就再打一两周试试呗,反正要耗的精力不像五笔那么大
2022-07-28 21:02:36 +08:00
回复了 hahaFck 创建的主题 程序员 Java 关于数据库 Entity 如何设计
@LeegoYih 数据库新手说下看法,有不对的请指正


这是另外一种什么范式吗?


以前学过的数据库范式说,

1. 每个字段都必须是不可再分割的原子数据项,不能是集合、数组、另一行记录等

2. 其他字段必须完全依赖整个主键组(如:用户部门表『「用户 ID ,部门 ID 」,用户名,省份名』,用户名只依赖用户 ID ,省份名不依赖任何其他字段,故不符)

3. 非主键不依赖其他非主键(如:学生表『「学号」,学院 ID ,学院名称』,学院名称依赖学院 ID ,故不符)

然而实际出于性能、分库分表难 join 等原因,总会冗余一些字段


回到你的回复,你说 用户表『「用户 ID 」,……,部门 ID 』不妥,

1. 部门 ID 业务不依赖 用户 ID (是说违反第二范式?但感觉实际上是依赖的?用户所属部门?)

2. 或用户可所属多个部门(部门 IDs ?但这违反第一范式?)


总的看起来,感觉你像是在说违反了数据库范式

所以,若有性能(你 join 多一个表,肯定性能差些)、分库分表难 join 等问题,你会妥协地加入『部门 ID 』?
2022-07-28 12:58:36 +08:00
回复了 hahaFck 创建的主题 程序员 Java 关于数据库 Entity 如何设计
@LeegoYih 即使一对多关系,也『不应该直接关联另一个实体』嘛
2022-07-28 10:47:50 +08:00
回复了 hahaFck 创建的主题 程序员 Java 关于数据库 Entity 如何设计
怎么感觉有的在说数据库的设计,有的在说 API 的设计……
@lmshl 懂的,都用递归下降了,肯定可以支持递归文法嘛

上条回复我是说,你当前代码里,没有用到递归文法,所以应该是三型文法

仅从『是否匹配』角度说,是可用『正则表达式』描述 你的文法 的(每个文法的结果处理函数就算了)
@lmshl 瞅了瞅,没用过 scala ,只能大概看得懂

这是扩展了自带正则库的文法规则,其递归下降去匹配?

int 、bool 、double 、string 是词法分析,其余是语法分析?(感觉全说成是语法分析也无不可?)

全部是三型文法?(因为没有递归?如:options ::= "options" ":" (options_tuple ("," options_tuple)* | options))

也是高度依赖 tuple 有明确不同于其他文法的规则(要是 {options: opt1: val1, opt2: val2, label: user_id} 就完蛋了)


估计上游不好好用 json 库,自己手动拼接去了,真的是搞事情
2022-07-26 08:03:13 +08:00
回复了 kerrspace 创建的主题 程序员 如何确保移动硬盘的大量数据不会损坏?
@wizardyhnr 能用 100% 冗余度 代替原文件吗?否则出现所有备份各损坏一部分,咋办
2022-07-26 06:42:34 +08:00
回复了 kerrspace 创建的主题 程序员 如何确保移动硬盘的大量数据不会损坏?
@kerrspace 根据 @wizardyhnr #3 所说,利用 par2 (类似 winrar 冗余校错)写个小脚本,来实现:

(对于 A 盘任意文件 D:/path/src_file ,应对应于 a 盘中的 E:/path/src_file.par2 冗余校检文件)

1. src_file.par2 不存在,则自动生成( 50% 冗余度?允许 < 50% 错误?)

2. src_file.par2 上次访问 /修改时间已超过 30 天,则校检一次(并自动修复错误),并更新访问 /修改时间

3. src_file 不存在,则删除 src_file.par2

效果会好吗?
2022-07-26 06:26:05 +08:00
回复了 kerrspace 创建的主题 程序员 如何确保移动硬盘的大量数据不会损坏?
@kerrspace 假如一个压缩包内容是 ABC ,A 盘内容变成 BBC ,a 盘内容变成 ABB ,咋办?
@FYFX 我这方面没啥经验。但总感觉,你的『解析 options 的值』这个步骤,适合放到语法分析中


如你所说,『在碰到下个<keyword, 关键字>或者<}, 右花括号>之前……』,

即『在碰到两种 Token 之前……』?


另外,放到语法分析中,后续若想解析成 下列形式,也更容易些?(可扩展性强些?)

1. {"options": {"1": "a:aa", "2": "b:bb"}}

2. {"options": ["1:a:aa", "2:b:bb"]}


好吧,如果放到词法分析中,要打算用啥方法解析 Token 呢?

NFA/DFA ?应该不够用吧(也就是,三型文法的正则表达式,无法胜任了)

LL/LR/SLR/LALR ?(我瞅瞅去)
1 ... 22  23  24  25  26  27  28  29  30  31 ... 33  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2619 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 23ms · UTC 04:54 · PVG 12:54 · LAX 20:54 · JFK 23:54
Developed with CodeLauncher
♥ Do have faith in what you're doing.