62bit的秘密基地

HTTP请求12345POST /user/info?new_user=true HTTP/1.1Host: www.example.comUser-Agent: curl/7.77.0Accept: */*{"username":"62bit","email":"123456@qq.com"} 请求行POST /user/info?new_user=true HTTP/1.1 PPST：方法类型 /user/info?new_user=true：资源路径，问号❓后面是查询参数，不同参数之间用&符号分隔 HTTP/1.1：协议版本 请求头Host: www.example.com：主机域名 User-Agent: curl/7.77.0：将客户端的信息告知服务器，客户端类型、版本 Accept: */*：表示客户端想要接受什么类型的响应数据，以下是一些常见类型，接受多个类型时用逗号分隔 接受HTML：text/html 接受JSON：application/json ...

看了B站上的一个视频：Stable diffusion采样器全解析，30种采样算法教程_哔哩哔哩_bilibili 视频中基于速度优先推荐了一些算法 对采样器的区别有了初步的认识 老派采样器一些概念 采样器名称中的“a”：代表祖先采样器，画面不能收敛 什么是不收敛：每一步采样时都会加入一些噪声，使画面变得不一样，增加了随机性 什么是收敛：随着采样步数的增加，画面内容会趋于稳定，不怎么改变 采样器描述 Euler a Euler：渲染画面简单直接，不容易出错 LMS：线性多步法，速度与Euler差不多，但没Euler稳定 Heun：Euler的改进算法，画面更好，但速度慢一倍 DDIM：最早的算法（过时） LMS Karras PLMS：最早的算法（过时） DPM采样器一些概念 DPM2 代表DPM的2代算法，画面效果好了一些，但时长翻了一倍 Karras是什么：采样到8步后，噪点会变少，也就是能用更少的采样步数产出清晰的图像 S和M是什么：S代表单步算法，M代表多步算法，M是S的升级版本 SDE是什么：SDE代表随机微分方程，不收敛，高品质，速度慢 采样器描述 DPM2 DPM2 ...

AI绘画最近挺火的，我也来试试。一开始使用的是在自己电脑上本地部署，但是磁盘空间不够多，且显存也不够大，用起来很不爽。后来采用了应用市场 – 揽睿星舟-一站式AI服务平台和AI应用生态的Stable Diffusion Web UI打包应用，真的省了很多心。 以下是我在没有了解任何相关知识的情况下，用单一的提示词魔改了我大学社团的团徽： Prompt 提示词基础 提示词之间要用英文逗号分隔 提示词之间是可以换行的 权重默认为1，提示词越靠前权重越高 数量控制在75个单词以内 分类 内容提示词 画质提示词 画风提示词 建议顺序：画质 -> 画风 -> 内容 -> 环境 -> 画幅 -> Lora -> 负面词 123456789101112131415161718192021222324252627282930313233人物及主体特征 服饰穿搭 white dress 发型发色 blonde hair, long hair 五官特点 small eyes, big mouth 面部表情 smiling 肢体动作 stretching arms ...

看到一篇不错的文章：一种朴素但受用终身的卡片笔记法 (notion.site) 为什么要记笔记原因一：太轻松的东西，大脑懒得去记需要通过记笔记，让大脑认识到：“哦，这是重要的”，加深印象 原因二：回顾时可以轻松看懂，不用去重新揣摩原文记笔记时，要做到让未来的自己可以轻松看懂 回顾的时候看一大段的原文，不如看你自己写的一小段话，因为那是你的思维加工过的知识，你会很熟悉。 原因三：笔记之间产生关联，成为知识图谱暂时没体会到，以后有感悟了再来写一下。。。 如何记笔记 让未来的自己可以一分钟内看懂，超过一分钟的考虑拆分（这个过程中需要不停地组织精炼语言） 尽量用自己的话来写，如果原文很精辟或者暂时没时间组织语言，可以考虑附上原文 万事万物皆可记笔记 如何管理笔记 所有的新笔记堆在一起，每周找个特定的时间归档 划分各个领域，把新笔记归档进去 有些文章或者视频，暂时没时间细细去看，可以专门放到一个文件中，以后有时间再看（类似于B站的稍后再看功能） 有时脑子中会冒出来一些奇怪的想法，抓住他们，记录下来，专门放到一个文件中，留给未来的自己与它们对话

平均值：不要被骗了，它不能代表整体水平整体平均值是在数据均匀分布或正态分布的情况下才会有意义 辛普森悖论：在分组比较中都占优势的一方，有的时候在总评中反而是失势的一方。 辛普森悖论产生的原因：权重小的因素在整体中的数量过大，影响了结果 辛普森悖论也给我们一个启示，就是：每次小范围内的输赢，其实和你在整体上的输赢没有太大直接的关系。（赢一堆小的不如赢一把大的） 摘自百度百科：辛普森悖论 回避方式： 为了避免辛普森悖论出现，就需要斟酌个别分组的权重，以一定的系数去消除以分组资料基数差异所造成的影响，同时必需了解该情境是否存在其他潜在要因而综合考虑。 管理应用： 辛普森悖论就像是欲比赛100场篮球以总胜率评价好坏，于是有人专找高手挑战20 场而胜1场，另外80场找平手挑战而胜40场，结果胜率41%，另一人则专挑高手挑战80场而胜8场，而剩下20场平手打个全胜，结果胜率为28%，比 41%小很多，但仔细观察挑战对象，后者明显较有实力。 量与质是不等价的，无奈的是量比质来得容易量测，所以人们总是习惯用量来评定好坏，而此数据却不是重要的。除了质与量的迷思之外，辛普森悖论的另外一个启示是：如果我们 ...

问题描述前两天面试的时候面试官问了我一个问题： 在方法f外部创建一个HashMap的引用m，f的形参列表是HashMap m，返回值是void，f内部的代码是让m指向另一个HashMap，问调用f方法后，m指向哪个HashMap 例子： 12345678910111213141516171819202122232425262728import java.util.HashMap;public class Test { public static void main(String[] args) { // 在方法外面定义了一个HashMap的引用，引用名为m HashMap<String, Integer> m = new HashMap<>(); // 给m赋值 m.put("a", 1); m.put("b", 2); // 打印m System.out.println("Before c ...

上一步完成了维度建模：数据仓库之维度建模 | 62bit的秘密基地 这一步把数据统计后存入MySQL（ADS层），然后用python的matplotlib包对数据进行可视化 DW to ADS导包 12345<dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>8.0.27</version></dependency> 配置hive和mysql 123456789val conf = new SparkConf() .setAppName("ADS") .setMaster("local[*]")val spark = SparkSession.builder().config(conf) .config("hive.metastore.uris","thrift:/ ...

上一步实现了数仓分层：数据仓库之数仓分层 | 62bit的秘密基地 这一步进行维度建模 目前的数据是一整张表，为了提高查询效率和减少数据存储空间，可以将整张大表拆成几张小表 目前的表有如下字段：title（视频标题）、author（作者）、play（播放量）、partition（分区）、subpartition（子分区）、tag（标签）、pic（封面url）、pubdate（发布日期+发布时间）、arcurl（视频链接）、review（评论数）、video_review（弹幕数）、favorites（收藏数）、year（发布年份）、week（发布周次）、time（发布时间）、date（发布日期） 为了方便查询，先给每条数据一个编号 12345678val df = spark.sql("select * from dw.blbl")spark.sparkContext.setLogLevel("ERROR")def indexer(df: DataFrame, columnName: String): DataFrame = { va ...

遍历递归序12345678void process(Node root){ if(root == null) return; //第一次到达root process(root.left); //第二次到达root process(root.right); //第三次到达root} 在递归序中，每个节点都会被经过3次，这就意味着二叉树递归遍历时，可以从左子树收集一些信息，再从右子树收集一些信息，然后返回头节点，完成信息的整合 非递归显然需要回溯，所以要用到压栈的方式 123456789101112131415161718192021222324252627void process(Node root){ Stack<Node> s = new Stack<>(); while(root != null || !s.isEmpty()){ while(root != null){ s.push(root); / ...

情况描述用hexo+github搭建了个人博客，每次上传博客时，执行hexo d命令上传Github总是卡住，只能ctrl + c中断然后反复尝试 原因国内墙对 GitHub 的阻挡影响，导致国内用户在向 GitHub 仓库 pull 或者 push 的时候速度都会受到不同程度的影响。 解决方案一些不适用于我的情况的解决方案：(44条消息) 执行 hexo d 部署到 GitHub 上的时候总是卡住解决办法_info deploy done: git_缓月的博客-CSDN博客 我的解决方案：我用的科学上网工具是Clash，它可以直接用代理的方式打开终端，这样打开终端后再执行上传命令就不会卡住了 命令： 1234#CMDset http_proxy=http://127.0.0.1:7890 & set https_proxy=http://127.0.0.1:7890#PowerShell$Env:http_proxy="http://127.0.0.1:7890";$Env:https_proxy="http://127.0.0.1:7890&q ...