推荐理由：目前，大部分深度学习框架都提供了 Python 的用户界面，其训练过程的状态通常以日记的形式被记录下来，这种方式可以观察短期内的训练状态，但是难以从全局把握训练过程中的变化趋势，导致提取信息时受到较多限制。反观 Visual DL，它可以使得深度学习任务变得生动形象，实现可视分析，改变了传统的日记式记录形态，便于用户将训练过程可视化，帮助更好地把控全局。
首先，它的“Scalar”功能支持 Scalar 打点数据展示，可将训练信息以折线图的形式展现出来，方便观察整体趋势，还能在同一个可视化视图中呈现多条折线，方便用户对比分析。
其次，Visual DL 的“Image”功能支持图片展示，用户可轻松查看数据样本的质量，也可以方便地查看训练的中间结果，例如卷积层的输出或者 GAN 生成的图片。
同时，Visual DL 还具有 Histogram 参数分布展示功能，方便用户查看参数矩阵中数值的分布曲线，并随时观察参数数值分布的变化趋势。
最后，Visual DL 中的“Graph”还能帮助用户查看深度神经网络的模型结构。据悉，Graph 支持直接对 ONNX 的模型进行预览，由于 MXNet、Caffe2、Pytorch 和 CNTK 都支持转成 ONNX 的模型，这意味着 Graph 可间接支持不同框架的模型可视化功能，让用户便于排查网络配置的错误，帮助理解网络结构。
Visual DL 除了功能全面以外，还具有易集成、易使用等优势。
它可提供独立的 Python SDK，若用户的训练任务基于 Python，可直接安装 Visual DL 的 WHL 软件包，随后输入到项目中进行使用，使用方式简单便捷。
为了满足用户的不同操作需求，用户在其 Python 代码中可加入 Visual DL 日志记录逻辑，启动 Visual DL 后即可通过浏览器查看日志的可视化结果。
此外，Visual DL 在底层使用 C++ 编写，提供原生的 C++ SDK，用户可将其深入集成到自己 C++ 的项目，以实现更高效的性能。
值得一提的是，Visual DL 现已完全开放，同时支持大部分的深度学习框架。其 SDK 层面可轻松集成到 Python 或者 C++ 项目中，此外， Graph 通过 ONNX 还可直接支持 PaddlePaddle、TensorFlow、MxNet、PyTorch 和 Caffe2 等流行的深度学习框架。对于开发者来说，Visual DL 可以将深度学习任务的训练过程可视化，减少用户的观察比对时间，让整个训练过程更高效。
VisualDL 同时提供了 Python SDK 和 C++ SDK ，我们可以快速地将数据可视化。
import random from visualdl import LogWriter logdir = "./tmp" logger = LogWriter(dir, sync_cycle=10) # mark the components with 'train' label. with logger.mode("train"): # create a scalar component called 'scalars/scalar0' scalar0 = logger.scalar("scalars/scalar0") # add some records during DL model running, lets start from another block. with logger.mode("train"): # add scalars for step in range(100): scalar0.add_record(step, random.random())
visuaIDL --logdir <some log dir>
VisualDL 是由百度团队PaddlePaddle & ECharts 团队开发的深度学习可视化工具。
今日推荐英文原文：《3 tests for NOT moving to blockchain 》作者：
3 tests for NOT moving to blockchain
So, there’s this thing called “blockchain” which is quite popular…
You know that already, of course. I keep wondering if we’ve hit “peak hype” for blockchain and related technologies yet, but so far there’s no sign of it. As usual for this blog, when I’m talking about blockchain, I’m going to include DLTs – Distributed Ledger Technologies – which are, by some tight definitions of the term, not really blockchains at all. I’m particularly interested, from a professional point of view, in permissioned blockchains. You can read more about how that’s defined in my previous post Is blockchain a security topic? – the key point here is that I’m interested in business applications of blockchain beyond cryptocurrency.
And, if the hype is to be believed – and some of it probably should be – then there is an almost infinite set of applications for blockchain. That’s probably correct, but that doesn’t mean that they’re all good applications for blockchain. Some, in fact, are likely to be very bad applications for blockchain.
The hype associated with blockchain, however, means that businesses are rushing to embrace this new technology without really understanding what they’re doing. The drivers towards this move are arguably three-fold:
- you can, if you try, make almost any application with multiple users which stores data into a blockchain-enable application;
- there are lots of conferences and “gurus” telling people that if they don’t embrace blockchain now, they’ll go out of business within six months;
- it’s not easy technology to understand fully, and lots of the proponents “on-the-ground” within organisations are techies.
I want to unpack that last statement before I get a hail of trolls flaming me. I have nothing against techies – I’m one myself – but one of our characteristics tends to be enormous enthusiasm about new things (“shinies”) that we understand, but whose impact on the business we don’t always fully grok. That’s not always a positive for business leaders.
The danger, then, is that the confluence of those three drivers may lead to businesses deciding to start moving to blockchain applications without fully understanding whether that’s a good idea. I wrote in another previous post (Blockchain: should we all play?) about some tests that you can apply to decide whether a process is a good fit for blockchain and when it’s not. They were useful, but the more I think about it, the more I’m convinced that we need some simple tests to tell us when we should definitely not move a process or an application to a blockchain. I present my three tests. If your answer any of these questions is “yes”, then you almost certainly don’t need a blockchain.
Test 1 – does it have a centralised controller or authority?
If the answer is “yes”, then you don’t need a blockchain.
If, for instance, you’re selling, I don’t know, futons, and you have a single ordering system, then you have single authority for deciding when to send out a futon. You almost certainly don’t need to make this a blockchain. If you are a purveyor of content that has to pass through a single editorial and publishing process, they you almost certainly don’t need to make this a blockchain.
The lesson is: blockchains really don’t make sense unless the tasks required in the process execution – and the trust associated with those tasks – is distributed between multiple entities.
Test 2 – could it work fine with a standard database?
If the answer to this question is “yes”, then you don’t need a blockchain.
This question and the previous one are somewhat intertwined, but don’t need to be. There are applications where you have distributed processes, but need to store information centrally, or centralised authorities but distributed data, where one may be yes, but the other “no”. But if this is question is a “yes”, then use a standard database.
Databases are good at what they do, they are cheaper in terms of design and operation than running a blockchain or distributed ledger, and we know how to make them work. Blockchains are about letting everybody see and hold data, but the overheads can be high, and the implications costly.
Test 3 – is adoption going to be costly, or annoying, to some stakeholders?
If the answer to this question is “yes”, then you don’t need a blockchain.
I’ve heard assertions that blockchains always benefit all users. This is a patently false. If you are creating an application for a process, and changing the way that your stakeholders interact with you and it, you need to consider whether that change is in their best interests. It’s very easy to create and introduce an application, blockchain or not, which reduces business friction for the owner of the process, but increases it for other stakeholders.
If I make engine parts for the automotive industry, it may benefit me immensely to be able to track and manage the parts on a blockchain. I may be able to see at a glance who’s supplied what, when, and the quality of the steel used in the ball-bearings. On the other hand, if I’m a ball-bearing producer, and I have an established process which works for the forty companies to whom I sell ball-bearings, then adopting a new process for just one of them, with associated changes to my method of work, new systems and new storage and security requirements is unlikely to be in my best interests: it’s going to be both costly and annoying.
Tests are guidelines: they’re not fixed in stone. One of these tests looks like a technical test (the database one), but is really as much about business roles and responsibilities as the other two. All of them, hopefully, can be used as a counter-balance to the three drivers I mentioned.
1 – which, don’t get me wrong, is definitely interesting and a business application – it’s just not what I’m going to talk about in this post.
2 – the trick is knowing which bits. Let me know if you work out how, OK?
3 – it’s actually quite a large set of technologies, to be honest.
4 – which is patently untrue, unless the word “they” refers there to the conferences and gurus, in which case it’s probably correct.
5 – which may happen anyway due to my egregious mixing of metaphors.
6 – there’s a word to love. I’ve put it in to exhibit my techie credentials.
7 – and before you doubt them, yes, I’ve read the book, in both cut and uncut versions.
8 – within reason.
每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，欢迎关注开源日报。交流QQ群：202790710；电报群 https://t.me/OpeningSourceOrg