今天等公共汽车的时候，看到一辆374路车经过，看的名字这么眼熟。想想，原来是最近在淘宝网浏览的时候，经常出现矿卡代号。
网上对矿卡的称呼跟黑话似的，应该是约定俗成的。比如374显卡，就是AMD的rx370显卡4g显存版，同样还有474，对应的478则是rx470的8G显存版。
相对而言N卡的称呼更专业一点，和老黄的刀法精准明确有关，比如我买的3g显存矿卡，就叫做p106-90，而6g显存版则是p106-100。因为不止是显存有差异，核心数也不同。
在家里用gtx1660显卡下棋的时候，lizzie下，胜率变化和变化图显示明显要快过p106-90的矿卡，而相同参数下用sabaki对弈，一盘收完单官的对局，在1个半小时左右，比矿卡要少1个小时。
但如果使用双矿卡，那样速度应该就应该就会反超，因为本身功耗已经缩减，付出的代价就是闹人的噪音了。
分类： IT天地
Windows下安装围棋AI程序
昨天返程终于涨经验了，取票之前计算一下时间，改签了合适时间的票，省却了候车时间，早到家半个小时。
回家后离给儿子做饭时间还有段时间，就利用这段时间把leelazero、katago、sabaki和lizzie一并安装了。
时间紧迫，就没有再专门安装Linux系统，直接安装在原先的Win7系统上。首先更新NVIDIA驱动，安装最新版的cuda，而其他系统则是直接安装编译好的windows 64位GPU程序，都还顺利，就是下载leelazero最新权重的文件时候，下载不了10M就断线。
暂且不管leelazero，先测试katago。但sabaki中设置好后，总是提示gtp错误，而换到lizzie下，用lizzie自带编译的katago则正常运转。
这看来是katago程序的问题了，于是直接运行出错那个katago程序，果然，是提示找不到某个版本的cuda的dll文件。看来是那个版本的katago编译时cuda版本较低。
懒得更换cuda版本了，直接找到那个高版本dll文件，拷贝到桌面上，将文件名修改为所缺失dll的文件名，然后拷贝回去。简单粗暴解决问题。
在解决gtp问题到网上搜索的时候，发现主要都是针对leelazero的，katago很少。好容易找到一篇，也是文不对题。但看着看着，怎么这么眼熟，全文一看，这不是我前段时间写的katago环境搭建的随笔吗？
不是说不能用我的文章，不署名也无所谓，但既然附在katago介绍文的下面，当做技术文，总要把环境注明，再说也帮俺改改语顺什么的吧。
django通过字典新增数据
django一对一信息的创建可以通过几种方式
a、使用create方式
方式一: Publish.objects.create(“name”=”人民出版社”,city=”北京”}
方式二: Publish.objects.create(**{“name”:”文艺出版社”,”city”:”上海”}）
b、使用save方式
方式一:
book1=Book(title=”python”,price=”88″,publish_id=”1″,publication_date=”2017-06-18″)
book1.save()
方式二:
author1=Author(name=”jerry”)
author1.save()
其中使用create方式中第二种时，可以直接使用根据数据表字段设置的字段直接新增：
dict={“name”:”文艺出版社”,”city”:”上海”}
Publish.objects.create(**dict）
小米电纸书，矛盾的产品
许久之前，就注意到小米要做电纸书的报道，开始还颇为期待。前些日子网上草图放出，看到那宽阔的边框后，已经颇为失望。
今天正式发布，更失望的是高价格和212的低ppi。
小米产品一向以低价格高指标吸引人，对标的往往是世面上流行的高端产品，电纸书自然是要跟亚马逊的kindle抢市场。但这次发布的电纸书，硬件指标上唯一压倒kindle的只有存储容量了，而这又和他们宣传的云端存储亮点相矛盾，虽说现在存储芯片价格跳水，但成本放在存储上实在浪费。
电纸书的高存储主要应对的是PDF、漫画等文件，而6寸屏加低ppi，看漫画及PDF文件绝无乐趣可言。
如果说这样的配置是为了看正版书，推广自家的多看云平台，但多看本身是提供客户端的，而客户端最受欢迎的应该是kindle版，那就不如买个低配低价口碑好的kindle，装上多看客户端，谁还会买小米自家的电纸书？
怎么看，小米电纸书，都是一个矛盾的产品。
小米多看电纸书发布：6寸212ppi背光墨水屏、16GB存储、大电池
https://m.mydrivers.com/newsview/657876.html?fr=kkj
捅破硬件数据传输窗户纸
经过近半天的摸索，终于将设备modbus的数据接收发送搞明白了。
两年前就曾经接触过，当时因为第一次接触硬件，也是一头雾水，后因为种种原因也就搁下了。
两年过去，再接触还是一头雾水。好在两年之间，网上相关的资料多了一些，再加上对某些技术关键细节进行了沟通，终于算是落实于理论，就等实际测试了。
学习新知识，理解自然重要，但和自己过往知识划清界限也是非常必要。经验主义要不得，否则总会时不时蹦出来捣乱，要么抵触，要么带偏。
还好，算是捅破一层窗户纸。
使用PostgreSQL的用户(Role)和密码登陆
PostgreSQL可以使用系统的用户进行登录，使用peer方式认证，这样设置较为简单。
如果使用PostgreSQL的用户(Role)和密码登陆，需要切换到postgres用户下，进行配置
sudo -i -u postgres
psql
create user mydata with encrypted password ‘123’; //如果pg_hba.conf设置为md5，需要加密
create database mydata;
grant all privileges on mydata to mydata;
这样就可以通过psql -h 127.0.0.1 -U mydata mydata -W进行登录。
昨日黄花cms
原先帮同事、朋友拾掇电脑，宁可重装，不愿意修修补补。而重装系统最麻烦的就是倒腾原先的数据。
最近几天把一个到期的云服务器网站，转移到新服务器上去。磕磕绊绊，终于算是有了一个还算满意的结果。
期间学了新知识，回顾了旧历程。
前段时间还回忆过当初cms的纷杂，现在看老的已是昨日黄花，新的也是遍地开花。
这一方面是信息更新太快，以采集、罗列、保存为主的旧式个人网站跟不上节奏，已经无存在的必要。另一方面，就是现在影音信息代替文字新闻成为主流，手机代替了电脑，大流量，快节奏，一切都在变快。
django中ImageField图片上传更名
在django的models中的图片字段，按照时间归档到设定的media静态目录下，并自动更名。
from django.db import models
import os
import time
def update_filename(instance, filename):
path = ‘image/book/’+time.strftime(“%Y/%m”,time.localtime())
ext = filename.split(‘.’)[-1]
unix_time = int(time.time())
format = str(unix_time)+’.’+ext
return os.path.join(path, format)
class Book(models.Model):
title = models.CharField(max_length=100,verbose_name=’书籍名称’)
publishDate = models.DateField()
image = models.ImageField(default=’image/book.png’, upload_to=update_filename, verbose_name=’封面’, max_length=100)
publish = models.ForeignKey(Publish,on_delete=models.CASCADE,verbose_name=’出版社’)
author = models.ManyToManyField(Author,verbose_name=’作者’)
class Meta:
verbose_name_plural = ‘书籍’
verbose_name = ‘书籍’
def __str__(self):
return self.title
文字识别初试
上次笔记本罢工前，是想用它测试一下深度学习框架的文字识别，以为它狗狗都能跑起来，没想到吓得罢工了。
后来重装系统后，安装好框架运行那个文字识别系统，结果直接提示out of memory，换矿卡机登场，运行一会之后同样提示后退出。
看来罢工是有原因的。
高级的搞不定，就用现成的。申请了百度的文字识别功能接口，用一张未调整的手机拍摄书页做测试，效果出奇的好。
毕竟百度的免费文字识别有期限，又测试了一下pytesseract，这个也算是出身名门，但对手机拍摄未经处理的图片中的文字识别率差了点。又换成扫描仪扫描的文档，效果立马提升到百度ocr的档次，但是后台运行系统的老笔记本风扇噪音骤起，看了一下cpu占用，linux下到了380%多，应该是四核都快满载了。
最后用百度的ocr处理了扫描完的电子文档，速度很快，效果已经非常满意。毕竟那些文档的清晰度，再想想扫描的过程，不提也罢。
本来为了提高扫描质量，在后期使用了百度文字识别的高精度版，也是书籍的纸张差了点，ocr出来的文字，居然把很多背面的文字给模糊识别出来了，真是晕了…
django2.2安装填坑记
因为近日有个工作需要快速录入，所以又想起django来了，准备使用xadmin提高效率，但没想到一个坑接着一个坑。
安装xadmin
安装xadmin的时候不要使用默认的pip install xadmin，因为它会二话不说就把某django1.x版本给装上，使用： pip3 install git+git://github.com/sshwsfc/xadmin.git@django2安装完毕。
安装数据库
安装mysql数据库的时候出现症状，总是提示’mysqlclient 1.3.13 or newer is required’，到网上一查，已经成为公害了，解决办法需要修改诸多文件，本来就像换Postgresql，所以直接安装psycopg2后，设置setting文件，比照mysql，只是后面参数增加了：
client_encoding: ‘UTF8’,
default_transaction_isolation: ‘read committed’
然后：
python manage.py migrate
python manage.py createsuperuser
数据库就建立完毕了，比mysql可是简单多了。
设置xadmin
修改setting.py文件，将xadmin和crispy_forms添加到INSTALLED_APPS中
修改urls.py文件，把原先admin前面加个x解决。
然后将xadmin一股脑clone到static目录下，setting.py中debug设为Ture，LANGUAGE_CODE = ‘zh-hans’，TIME_ZONE = ‘Asia/Shanghai’
启动后，正常进入后台，在添加组件的时候出错，修改项目中xadmin/views/dashborad.py中的render()，在render()中添加参数：renderer=None，即可解决。