学习使用大语言模型进行推理

问题描述

本文描述了一个密码解码问题。给定一个示例：密文“oyfjdnisdr rtqwainr acxz mynzbhhx”解码为明文“Think step by step”。任务是利用该示例解码新密文“oyekaijzdf aaptcg suaokybhai ouow aqht mynznvaatzacdfoulxxz”。

解码过程分析

观察示例

• 密文与明文长度对比：密文单词长度是明文单词长度的两倍。例如，密文第一个单词有10个字母，对应明文单词5个字母；第二个密文单词8个字母，对应明文4个字母；依此类推。
• 假设解码规则：每个明文字母由密文中的两个字母对表示。通过计算每个字母对的字母数值平均值来解码。

验证示例解码

• 字母数值映射：A=1, B=2, ..., Z=26。
• 示例解码步骤：
  • 密文对“oy”对应明文字母“T”：o=15, y=25，平均值=(15+25)/2=20，对应T。
  • 密文对“fj”对应“h”：f=6, j=10，平均值=8，对应h。
  • 类似解码其他字母对，验证规则一致。
• 该规则适用于示例中的所有单词，确认解码方法为：对每个字母对的字母数值求平均，得到明文字母。

解码新密文

密文分割

将新密文按空格分割为单词，并根据示例长度关系推测明文单词长度：

• “oyekaijzdf”（10个字母）→ 明文单词5个字母
• “aaptcg”（6个字母）→ 明文单词3个字母
• “suaokybhai”（10个字母）→ 明文单词5个字母
• “ouow”（4个字母）→ 明文单词2个字母
• “aqht”（4个字母）→ 明文单词2个字母
• “mynznvaatzacdfoulxxz”（22个字母）→ 明文单词11个字母

应用解码规则

对每个单词，将字母分成对，计算每对字母数值的平均值，得到明文字母：

1. 单词“oyekaijzdf”：
   • 对：oy, ek, ai, jz, df
   • 解码：oy→T, ek→H, ai→E, jz→R, df→E → “THERE”
2. 单词“aaptcg”：
   • 对：aa, pt, cg
   • 解码：aa→A, pt→R, cg→E → “ARE”
3. 单词“suaokybhai”：
   • 对：su, ao, ky, bh, ai
   • 解码：su→T, ao→H, ky→R, bh→E, ai→E → “THREE”
4. 单词“ouow”：
   • 对：ou, ow
   • 解码：ou→R, ow→S → “RS”（表示“R's”）
5. 单词“aqht”：
   • 对：aq, ht
   • 解码：aq→I, ht→N → “IN”
6. 单词“mynznvaatzacdfoulxxz”：
   • 分成10个对：my, nz, nv, aa, tz, ac, df, ou, lx, xz
   • 解码：my→S, nz→T, nv→R, aa→A, tz→W, ac→B, df→E, ou→R, lx→R, xz→Y → “STRAWBERRY”

解码结果

所有单词组合后，明文为：“THERE ARE THREE R'S IN STRAWBERRY”。

总结

本文通过逐步推理，展示了如何从示例中推导出密码解码规则（基于字母对数值平均），并成功应用于新密文解码。关键点包括观察长度关系、假设字母对映射、验证规则一致性，以及系统解码过程。

OpenAI o1 系列模型摘要

OpenAI 于2024年9月12日发布了新型号 o1-preview 和 o1-mini，核心创新在于通过强化学习训练，使模型在回答前进行更长时间的“思考”，从而提升复杂推理能力。

核心特性与训练

• 思维链训练：模型通过大规模强化学习，学习在内部生成并优化思维链，能分解复杂步骤、纠正错误并尝试不同策略。其性能随训练时计算和测试时思考时间的增加而提升。
• 主要权衡：相比 GPT-4o，o1 模型在深度推理上更强，但响应时间更长、成本更高，且暂不支持图像输入、函数调用、系统提示或流式输出。

API 使用细节

• 访问层级：需达到 API 使用等级 5（累计消费至少 1000 美元）。
• 推理令牌：模型会生成用户不可见的“推理令牌”，这些令牌计入输出成本。API 文档建议为此类令牌分配约 25000 的预算。
• 输出限额增加：o1-preview 和 o1-mini 的输出令牌上限分别提高至 32,768 和 65,536，远高于 GPT-4o 的 16,384。
• RAG 建议：建议在检索增强生成中仅提供最相关上下文，避免信息过载。

推理过程为何隐藏

• OpenAI 选择隐藏原始思维链，主要出于安全与政策合规（防止泄露违规中间步骤）和竞争性保护两方面考虑。在 ChatGPT 界面中，会以摘要形式展示简化的推理步骤。

应用示例与挑战

• 示例展示了模型在生成脚本、解决填字游戏、解析笑话等方面的能力，特别是需要多步推理的任务。
• 社区反馈指出，目前难以系统性地找到 GPT-4o 失败但 o1 成功的优质提示案例，但当遇到合适任务时，其表现“极其神奇”。

展望

• o1 模型扩展了 LLM 可解决的任务范围，尤其适合需要深度推理的场景。预计其他 AI 实验室（包括开源模型社区）将跟进开发类似技术。
• 在实际应用中，开发者需权衡其推理优势与速度、成本及功能限制，GPT-4o 等模型在多数通用任务中仍将是首选。

FlowTracker：Java 程序数据流跟踪工具

FlowTracker 是一个 Java 代理，用于跟踪程序如何读取、处理和写入数据。它通过观察程序运行，不仅能显示发生的文件和网络 I/O，更重要的是能连接其输入和输出，从而展示输出结果的来源。这有助于理解任何 Java 程序输出的含义及其产生原因。

核心功能与演示

FlowTracker 是一个插桩代理，在 JVM 加载类文件时，将自身代码注入字节码中。该代码在程序读取、传递和写入数据时，维护一个内存数据与其来源的映射关系。其主要跟踪目标是文本和二进制数据（如 String、char 和 byte 数组），而非数值、结构化或计算得出的数据。

一个基于 Spring PetClinic 的演示展示了其能力：当它观察到 PetClinic 处理一个 HTTP 请求并基于模板和数据库数据生成 HTML 页面时，可以做到：

• HTTP 处理：显示哪段代码产出了哪部分输出。
• Thymeleaf 模板：展示程序读取的输入（如 HTML 模板）如何对应到输出。
• 数据库：追踪网页中表格内信息的来源，甚至可以回溯到最初插入该数据的 SQL 脚本（对于内存数据库）。对于外部数据库（如 MySQL），则可以跟踪到数据库连接，查看发送的 SQL 查询。

该工具不依赖于任何特定框架或库。

工作原理概述

FlowTracker 的实现结合了多种技术：

1. 基本插桩：使用 ASM 库进行字节码操作。通过替换对特定 JDK 方法（如 System.arraycopy）的调用，或在关键 JDK 类（如 FileInputStream, FileOutputStream 及其内部通道实现）中注入钩子代码，来跟踪 I/O 操作。
2. 原始值跟踪与数据流分析：跟踪原始值（如 byte, char）更具挑战。FlowTracker 扩展了 ASM 的分析能力，在方法内部进行数据流分析，构建局部变量和栈上值的来源模型，以跟踪值的流动。
3. 方法调用跟踪：使用 ThreadLocal 在方法调用前后存储和传递参数的跟踪点（TrackerPoint）信息，实现跨方法的数据流跟踪。
4. 代码作为数据源：对于代码本身的常量（如原始值和字符串字面量），会为每个类创建一个 ClassOriginTracker，包含该类的文本表示及其中的常量。字符串字面量会被重新创建并关联到此跟踪器，这打破了 JVM 的常规字符串驻留保证，但通过 ConstantDynamic 等技术尽量减少影响。

数据模型核心是 Tracker 对象，它保存被跟踪对象的内容，并将其内容的不同范围映射到其他 Tracker 的源范围，从而记录数据的精确来源。

当前状态与使用

• 状态警告：FlowTracker 目前更接近一个概念验证，而非生产就绪工具。它在多个示例程序上运行良好，但不一定适用于所有场景，且会带来显著的运行时开销，导致程序运行大幅变慢。
• 使用方法：用户需从 GitHub 发布页面下载代理 JAR 文件，并通过 -javaagent 参数将其添加到 Java 启动命令中，同时需要禁用一些会干扰跟踪的 JVM 优化。默认情况下，它会在 8011 端口启动一个 Web 服务器，用户可通过浏览器访问交互界面。

总结来说，FlowTracker 提供了一个独特的视角，通过跟踪程序行为中的数据流动，来帮助开发者理解程序输出的构成和来源，是一个用于研究、调试和理解程序内部数据流的强大实验性工具。

美国邮政新世代邮车首次亮相获得邮递员好评，尽管其外观设计被批评为“不美观”：车身高大、挡风玻璃巨大、引擎盖形似鸭嘴、保险杠宽大。但该型号邮车在乔治亚州投入使用后，凭借实用性与安全升级获得邮递员热烈欢迎。

新车核心优势：

• 舒适性与安全性：配备空调、安全气囊、360度摄像头、盲点监测、碰撞传感器及防抱死刹车系统，彻底解决了旧款邮车无空调、夏季闷热的问题，且车厢内空间允许邮递员站立行走。
• 功能性与效率：载货区扩大，可容纳更大包裹；优化的设计减少了邮递员弯腰动作，缓解了旧车频繁故障、后视镜易偏移以及约100辆旧车去年起火的安全隐患。
• 电动化转型：初期计划因成本问题备受争议，环保组织起诉要求提高电动化比例。后通过政府30亿美元资助（部分用于充电设施建设），最终确定到2028年采购10.6万辆新车，其中6万辆为新一代邮车（含4.5万辆电动车型），并承诺2026年起新购车辆全面电动化。

旧车痛点： 1987年启用的旧款邮车虽超期服役，但油耗高（9英里/加仑）、维护成本高昂、缺乏现代安全配置，且夏季仅靠电扇降温。

转型意义： 新车是邮政局长路易斯·德乔伊领导的10年、400亿美元改革计划的重要部分，旨在通过车队电动化、路线优化等措施，在2030年前将碳排放减少40%。该转型近期获得白宫“总统联邦可持续发展奖”认可，标志其应对运营、财务及环境挑战的综合能力。

FDA批准首款非处方助听器软件

美国食品药品监督管理局 (FDA) 于2024年9月12日批准了首款非处方助听器软件设备——“助听功能”(Hearing Aid Feature, HAF)。该软件专为兼容的苹果AirPods Pro耳机设计。

功能与适用人群 该软件安装并根据用户的听力需求定制后，可使兼容的AirPods Pro耳机转变为非处方助听器，旨在放大声音，帮助18岁及以上、自认为有轻度至中度听力损失的成年人。

背景与意义 听力损失是影响数千万美国成年人的重大公共卫生问题，可能导致沟通障碍、情绪问题及认知能力下降。FDA于2022年10月确立的非处方助听器法规，使轻度至中度听力损失患者无需医学检查、处方或听力学家即可直接购买助听器。此次批准体现了FDA在提供安全有效听力解决方案的同时，促进创新和便利性的承诺。

工作原理与临床验证

• 软件特性：HAF是一款纯软件移动医疗应用，通过iOS设备（如iPhone、iPad）进行设置。它采用“自我适配”策略，从iOS HealthKit获取用户听力水平进行定制。用户可自行调整音量、音调和平衡设置。
• 临床研究：在一项针对118名轻度至中度听力损失受试者的临床研究中，结果显示，使用HAF自我适配策略的受试者，其获得的感知效益与接受专业设备调试的受试者相似。在耳内放大水平测量和噪声环境下的言语理解测试中，两者表现也相当。研究中未观察到与该设备相关的不良事件。
• 监管途径：该申请通过FDA的“De Novo”上市前审查途径进行审核，该途径适用于一些中低风险且市场上无先例的新型设备。

获批与展望 FDA已向苹果公司授予该助听功能的上市许可。作为促进健康公平的战略重点之一，FDA将继续支持扩大重要技术可及性、将医疗保健直接带给患者的创新。

哈佛商学院教授弗朗西斯卡·吉诺（Francesca Gino）因涉嫌数据造假被Data Colada团队调查并揭露后，以诽谤罪起诉了该团队及相关大学。法院最终裁定，Data Colada团队的研究人员免受诽谤指控，而针对哈佛大学的大部分诉讼也被驳回。

法院判决的核心在于，研究者的指控是基于证据的科学结论，并采用了典型的科学谨慎表述方式。法官援引先例指出，“科学争议应通过科学方法而非诉讼方式解决”，并认为Data Colada团队向哈佛大学提交的材料“构成了其对所掌握事实的主观解读”。由于吉诺是因其高调的学术生涯被认定为公众人物，该行为未达到诽谤标准。此外，尽管Data Colada团队明确判定数据存在操纵，但他们在证据是否明确指向吉诺本人实施操纵这一问题上保持了谨慎。

研究者通过提供指向数据来源的超链接，使其结论能够被读者自行复核，这也成为了他们的重要保护性措施。法院认为，这种做法“使读者能够自行审查基础信息并得出自己的结论”。

这一事件对科学界具有重要启示意义。近年来，在线科学社区发展迅速，研究人员在其中识别和讨论图像与数据操纵行为，这些活动有时会导致论文撤回或其他职业后果，偶尔也会引发针对调查者或报道记者的诉讼威胁。法院的此次判决表明，以谨慎的科学语言进行指控，并提供可验证的数据链接，是保护揭露学术不端行为的研究者的有效方式。这类诉讼难以成功，长远来看有利于维护科学记录的诚信。

据报道，知名独立游戏发行商Annapurna Interactive全体员工已集体辞职，原因是未能说服公司老板Megan Ellison同意将游戏部门独立成为新公司。据彭博社及IGN确认，该团队全部25名成员均已辞职。

前总裁Nathan Gary及团队成员称，这是他们“做出的最艰难的决定之一”。Annapurna方面则表示，现有游戏及项目将继续归属于公司。

此次辞职事件发生前，该公司已有高管变动。上周报道称，Nathan Gary以及Annapurna Interactive的联合负责人Deborah Mars和Nathan Vella将离职。Annapurna计划将其内部游戏业务与公司其他部门（包括电影、电视和戏剧）进行整合。此外，Epic Games前高管、Annapurna Interactive联合创始人Hector Sanchez已出任Annapurna互动与新媒体总裁。

Annapurna以电影制作闻名，近年来积极扩展至游戏发行和开发领域。公司曾宣布开发自研游戏，并于2022年成立了内部动画部门。2023年，其动画部门宣布将改编游戏《Stray》为电影。近期，Annapurna还与Remedy Entertainment合作，探索将《控制》和《心灵杀手》改编为影视作品。

Annapurna Interactive今年发行了《Lorelei and the Laser Eyes》和《Open Roads》等游戏。其即将推出的作品包括自研的《银翼杀手2033：迷宫》以及《Ghost Bike》和《Wanderstop》等。

本文的核心观点是：初创公司应避免盲目追求复杂的云基础设施，简单的单服务器设置往往足以满足需求，从而让团队专注于产品市场匹配。

主要内容总结：

1. 核心理念：作者受Pieter Levels的启发，认为许多初创团队过度设计基础设施，为复杂而复杂。对于小型开发团队，特别是刚度过MVP阶段的公司，优先考虑产品迭代和找到产品市场匹配比管理复杂的分布式系统更重要。

2. 问题案例：

   • 项目一（Lambda过度使用）：使用了20-30个Lambda函数和SQS等服务，导致调试困难、部署复杂。本可简化为一个单体应用加Redis。
   • 项目二（微服务滥用）：为规模不大的应用部署了7个Kubernetes微服务，团队大部分时间花在基础设施而非功能开发上。

3. 推荐方案：单服务器设置：

   • 优势：现代服务器（如Hetzner、GCP VM、EC2）性价比高，性能强大（大内存、多核），管理集中化。
   • 基本要素：强大服务器、安全访问（HTTPS/SSH）、CI/CD、DNS配置、数据库定期备份、备用VM以实现冗余。
   • 工具推荐：作者创建了Docker Compose Anywhere模板，旨在简化单服务器部署，支持一键设置、零停机部署、多应用、自动SSL和数据库备份。

4. 安全与数据保护提醒：

   • 安全：设置严格防火墙、保护SSH密钥、使用堡垒机、保护密钥、考虑WAF。
   • 数据：将加密备份发送到云存储、定期磁盘快照、制定备份和快照保留策略。

5. 结论：工程师应倡导设置简单化，核心是与用户沟通并找到产品市场匹配，而非模仿大企业复杂的基础设施。

本书《机器学习实用程序员》（2023）的序言指出，尽管“数据是新石油”等口号已成陈词滥调，机器学习正深刻改变我们处理数据的方式，融合了信息论、统计学、计算机科学和优化理论。然而，它也带来了文化冲突：学术界注重新颖模型与理论，工业界则追求实用价值与商业结果。作者认为，软件工程在机器学习中的作用被严重低估，其质量对学术界的“可复现性危机”和工业界的技术债务、性能问题乃至系统故障至关重要。

现有的软件工程经典著作多面向通用商业软件，未能涵盖机器学习实践中的关键工程问题，如算法分析、硬件适配、数据软件化、测试文档、流水线构建和变量命名等。本书旨在填补这一空白，强调任何数据分析软件（无论称作机器学习、数据科学还是商业分析）的可行性，都取决于对这些工程实践的审慎思考。

全书结构分为四部分：

1. 科学计算基础：涵盖硬件配置权衡、数据类型与结构、算法复杂性分析等基础主题。
2. 机器学习与数据科学最佳实践：从软件工程角度讨论代码编写、故障排查、生产部署及技术文档编写。
3. 工具与技术：探讨塑造机器学习流水线可行性的工具类别，包括前沿示例及其权衡。
4. 案例研究：结合自然语言理解任务，将前述建议付诸实践。

作者不提供僵化规定，而是希望读者结合自身经验思考并适用相关实践。全书内容将持续更新于 https://ppml.dev。

防范“吸血鬼”窃听：实现10Gbps网络加密

本文探讨了如何保护通过光纤连接的跨建筑或同建筑内不同空间的L2以太网延伸网络（使用交换机主干端口连接光纤以实现VLAN间通信），防止其遭受物理窃听。核心问题是共享线缆路径缺乏物理安全，攻击者可能通过光纤分流器（如FOD5516等仅需200美元的设备）轻松窃取数据。

主要内容概述

1. 光纤窃听的现实威胁：铜缆窃听历史悠久且简单，而光纤窃听一度被认为需要昂贵设备，但实际演示表明仅需廉价夹式耦合器即可实现，可读取甚至注入数据，发起中间人攻击。

2. 加密解决方案的探索：作者考虑了几种方案：

   • 路由+VPN：若网络已采用路由架构，可在路由器间建立IPSec或WireGuard隧道，但本场景中“扩展L2”网络难以回退至路由架构。
   • 强制应用层加密：要求所有应用流使用加密协议，但难以全面覆盖且无法保证万无一失。
   • 混合方案思路：提出“虫洞”项目概念，在光纤两端部署设备，将802.1q中继流量封装在加密隧道中传输，对现有网络改动最小。

3. MACsec方案的测试与问题：作者测试了思科支持MACsec的交换机（Catalyst 3560 CX）。MACsec（802.1ae）理论上可加密802.1q中继，但测试发现：

   • 配置复杂，文档难寻。
   • 无法隐藏通信设备的真实MAC地址，泄露设备品牌信息。
   • 在特定攻击条件下（结合中间人攻击和管理员操作），可能导致部分流量以明文发送，且交换机无错误报告，存在安全隐患。

4. 基于Linux的VXLAN+WireGuard方案：最终采用开源且成熟的Linux内核功能构建解决方案。

   • VXLAN：用于在UDP上封装L2帧。通过iproute2命令（利用vlan_filtering、vlan_default_pvid、vlan_tunnel等特性）配置单个网桥和VXLAN接口，可自动映射所有VLAN，无需为每个VLAN创建单独接口。
   • WireGuard：在“虫洞”设备间建立加密隧道，VXLAN流量通过WireGuard隧道传输。
   • 性能优化：通过启用巨型帧（9000字节MTU）、调整网络接口队列长度和缓冲区大小、优化内核网络参数、设置CPU调频策略为“性能”模式等，大幅提升吞吐量。

5. 性能测试结果：

   • 硬件：使用SuperMicro SuperServer 5019D-4C-FN8TP（约1300欧元），支持10Gbps SFP+及所需硬件卸载功能。
   • 优化前：加密传输存在明显性能损失，且多客户端并发时吞吐量受限。
   • 优化后：在10Gbps光纤上，未加密传输约9.86 Gbps，WireGuard加密传输达9.71 Gbps（性能损失<2%），末端设备（1Gbps）能满速通信（942 Mbps），且支持多客户端并发满速。

结论

作者成功构建了基于开源Linux内核的“虫洞”设备，以低于旗舰手机的成本，实现了对10Gbps 802.1q中继的强加密，几乎达到线速（性能损失小于2%），有效防御了光纤上的“吸血鬼”式物理窃听。该方案充分利用了现代廉价服务器硬件和成熟的Linux网络协议栈（中继、桥接、路由、VXLAN、WireGuard），通过细致的配置和调优即可实现高性能加密。

文章背景与目的

文章讨论了语音作为计算机输入方式的现状，认为其已足够成熟，适合用于起草想法和记录笔记，但对于编程或正式文稿等结构化写作的适用性有限。作者指出，现有的转录工具虽能用于听写，但容易出错且难以处理语音不流畅处，导致后期修改耗时。因此，作者探索将大型语言模型与转录工具结合，以实现实时编辑，目标是获得如同与人类作家对话般的听写体验。

核心工具介绍

作者为此开发了Emacs 软件包 esi-dictate.el。该工具通过一个次要模式工作：口述的文字会输入到缓冲区一个独立的语音光标处，并根据用户的语音指令进行实时校正。其主要特点包括：

1. 语音光标与上下文：输入文本的位置由语音光标指示，下划线的文本区域用作提供给 LLM 的语音上下文。
2. 灵活的上下文控制：用户可以通过设置标记来移动语音光标位置并重置上下文；设置选区则可以改变用于 LLM 参考的语音上下文内容。
3. 无需显式指令模式：作者尝试过需要按热键才能进入修正的显式命令模式，但使用体验不佳。最终发现所用的 LLM（GPT-4o-mini）已足够智能，能自动区分指令和普通口述内容。

未来改进方向

作者认为当前的工作流程已基本满足需求，但仍有提升空间：

1. 降低延迟：当前体验的主要瓶颈在于语音识别和 LLM 处理的延迟，可以通过优化异步调用、缓存等方式部分改善。
2. 脱离第三方服务：目前工具依赖 Deepgram 和 OpenAI 的商业服务，作者计划未来替换为轻量级的本地或自托管替代方案。
3. 修复已知问题：存在语音光标与文本光标操作冲突时偶尔引发的小错误，将在后续修复。

AWS优化25519椭圆曲线密码学性能

AWS团队针对其开源加密库AWS-LC中的x25519（密钥交换）和Ed25519（数字签名）算法进行了深度优化，提升了性能并增强了正确性保证。

优化方法与技术创新

1. 微架构优化：团队针对不同CPU微架构进行了专门优化。

   • x86_64架构：利用 MULX、ADCX、ADOX 指令实现并行进位链，将性能提升高达30%。
   • Arm64架构：为 Graviton 3（乘法器性能强）采用直接的学校乘法；为 Graviton 2（乘法器较小）采用减法形式的 Karatsuba 乘法，以优化吞吐量。
   • 优化主要集中在底层的字段运算层面。

2. 形式化正确性证明：

   • 使用交互式定理证明器 HOL Light 对核心汇编代码进行功能正确性证明。
   • 证明流程已集成至持续集成管道，确保任何代码修改都必须通过形式化验证。
   • 通过在真实硬件上进行随机化测试，验证CPU指令规范描述的准确性。

3. 常数时间实现：所有实现均设计为常数时间，执行完全相同的指令序列，且避免使用任何可能泄露秘密信息的时序可变指令，以抵御侧信道攻击。

性能提升结果

在 AWS Graviton 2、Graviton 3 和 Intel Ice Lake 三种微架构上测试，新实现相比旧实现：

• Ed25519 签名：平均性能提升 108%。
• Ed25519 验证：平均性能提升 37%。
• x25519 密钥交换：平均性能提升 113%（包含基点乘法和变量点乘法）。
• 整体平均：性能提升 86%。

应用与集成

这些优化已通过 AWS-LC 库应用于多种AWS服务。开发者可通过以下方式利用这些优化：

• 直接在应用中集成 AWS-LC 库。
• 使用 AWS 提供的多语言绑定，如 Java 的 ACCP、Rust 的 aws-lc-rs，以及为 CPython 贡献的集成补丁。

团队表示将持续优化 x/Ed25519 及其他加密算法的性能。

Aesthetic Computer 是一个基于浏览器的开放创作计算平台，允许用户使用 JavaScript 和 KidLisp 制作艺术、游戏和工具。用户可以通过在命令提示符中输入作品名称（如 "painting"、"line"、"wand"、"prompt"）并按 Enter 键来导航浏览平台上的各类作品。此外，用户还可以点击垫片或使用键盘按键来播放音乐音符。

该平台的相关资源包括：

• 完整文档：可访问 https://aesthetic.computer/llms.txt 查阅。
• 源代码：托管于 https://tangled.org/aesthetic.computer/core。
• 作品（程序）集合：位于 https://tangled.org/aesthetic.computer/core/tree/main/system/public/aesthetic.computer/disks。
• 运行时库：见 https://tangled.org/aesthetic.computer/core/tree/main/system/public/aesthetic.computer/lib。

平台在启动时会显示“booting...”提示。

异常HP-12c金融计算器事件总结

背景与起因

作者因研究货币时间价值（TVM）计算，在科学计算器上编写了TVM求解器，并构建了包含13个边缘场景的TVM测试集，用于严格评估各类金融计算器的准确性与稳定性。

HP-12c的行业地位

HP-12c自1981年投产以来，是最具标志性和历史最悠久的金融计算器。为确保高价值合同中的计算结果绝对一致，HP在数十年的跨平台代码移植中极其谨慎，严格维护其算法的准确性与声誉。

异常设备的发现

作者通过Reddit和巴西亚马逊的用户评价发现，巴西市场新售出的部分HP-12c存在无法切换小数点格式以及内部收益率（IRR）计算失败的问题。经跨国网友协助进行取证测试，确认这批“流氓”HP-12c的计算结果与常规设备完全不同，且算法精度出现严重倒退。

TVM边缘场景测试分析

• 极小利率与极大期数：在“每秒存一便士”的高频微小利率测试中，由于浮点数加1时的精度丢失，异常设备的计算精度远低于常规HP-12c，退步至1970年代早期设备的水平。
• 零利率场景：在计算零利率贷款的月供时，异常设备因未处理除以零的边界情况而报错；在已知月供反求零利率时，也因求解器在趋近零时不稳定而再次失败。
• 多解场景：在存在两个有效利率的罕见现金流测试中，多数常规计算器会拒绝计算，但该异常设备罕见地成功输出了其中一个正确解。

原因推测与官方修复

异常设备的固件日期为2023年3月，而常规最新固件停留在2015年。推测有人完全重写了TVM求解器，导致算法退化。HP目前已着手修复此问题，近期从巴西售出的新设备已恢复使用2015年的正确固件并输出准确结果。

核心意义

此事件不仅揭示了金融计算器底层TVM算法优化的工程复杂性，也证明了构建严密的边缘测试集在验证数值计算硬件固件正确性方面的重要价值。

Safe C++ 摘要

背景与动机

• 美国政府及行业研究（如微软、谷歌）持续警告内存不安全语言（C/C++）的风险，大量漏洞源于内存安全问题。
• 迁移现有 C++ 代码到完全安全的语言（如 Rust）面临挑战：生态系统差异、语言特性不匹配、工具摩擦大。
• 目标：将 C++ 扩展为拥有严格安全子集的超集，在不破坏现有代码的前提下，为新代码提供与 Rust 相当的安全保证。

核心设计

• 安全上下文：函数可用 safe 说明符标记，在此上下文中禁止可能导致未定义行为（UB）的操作。
• 借用检查：通过编译期静态分析防止使用悬垂引用、迭代器失效等问题。关键规则是“独占可变或共享引用”。
• 显式变异：引入 mut 关键字显式进入可变上下文，明确绑定可变引用，避免默认绑定带来的混淆。
• 重定位对象模型：采用仿射/线性类型系统。对象默认未初始化，支持 rel（重定位，使源对象未初始化）和 cpy（复制）操作，提升类型安全。
• 选择类型与模式匹配：提供类型安全的枚举 choice 和 match 表达式，通过穷尽性检查增强安全性。
• 内部可变性：通过 unsafe_cell 及其包装类型（如 cell、mutex）安全地实现共享可变状态。
• 线程安全：利用 send 和 sync 接口约束类型的跨线程使用，编译期防止数据竞争。

关键安全特性

1. 生命周期与借用检查：引入生命周期参数、借用类型（T^ 和 const T^）及生命周期约束（where 子句），通过区域推断和约束求解实现过程间存活分析。
2. 安全标准库（std2）：提供生命周期感知、类型安全的容器（如 vector、string_view）和算法，替代可能引发 UB 的旧有 API。
3. unsafe 的使用与控制：
   • unsafe 上下文块：显式退出安全上下文，执行必要但无法保证安全的操作。
   • unsafe 类型限定符：允许在安全上下文中安全地操作包含 unsafe 元素（如遗留类型）的容器。
   • unsafe 下标：可跳过边界检查以提升性能，但由程序员承担责任。
4. 模式匹配与选择类型：choice 定义带载荷的枚举变体，match 表达式通过模式解构和守卫进行类型安全访问。
5. 运行时检查：对数组越界、除零等无法静态检查的操作进行运行时 panic/中止，避免 UB。
6. 重构与实现细节：
   • 对现有 C++ 代码兼容，通过 #feature on safety 按文件启用新特性。
   • 编译器将函数降至中级表示（MIR），执行初始化分析和借用检查。
   • 提供详细的错误报告，指出借用创建、失效操作和过期使用的位置。

设计权衡与挑战

• 可表达性与安全性平衡：在移除不安全机制（如裸指针）时，需提供安全的替代方案（如借用、选择类型）。
• 与遗留代码的互操作：通过 unsafe 类型限定符和显式 unsafe 块，安全地集成不安全的旧代码。
• 未解决问题：包括表达式生命周期约束、函数参数所有权（ABI 适配）、从引用中重定位等。

实施与展望

• 实现指导：建议通过 MIR 进行 AST 到代码生成，核心是初始化分析、存活分析、类型关系、约束求解和借用检查等七轮操作。
• 渐进采用：项目可逐步增加安全代码比例，无需一次性重写。
• 目标：在 18 个月内解决剩余设计问题，形成可供主流评估的语言和标准库。

结论

Safe C++ 提案旨在吸收 Rust 的所有权与借用模型等安全知识，为 C++ 提供内存安全路径。它通过扩展现有语言、提供安全子集和重构标准库，在保持与传统代码兼容的同时，系统性提升软件安全性与质量。