如何在data步中调用proc

Posted 2023-05-12

SAS中没有专门的处理缺失值的过程步，但是在标准化变量的过程步中可以实现缺失值的填补。其基本过程如下：
PROC STDIZE DATA=dataset REPONLY METHOD= OUT=outdata ;
VAR variables ;

RUN;
其中proc stdize 是调用标准化过程步，data=表示需要进行缺失值填补的数据库，reponly的意思是只取代缺失值（replace missing data only）,这个在均数填补法中必须要加上，不然就得不到想要的结果，method=就是选择填补方法，一般在针对计量资料时，我们一般选用均数填补法和中位数填补法（数据符合正态分布时METHOD=mean，偏态分布时选用METHOD=median），在填补计数资料没有什么好的办法，一般也使用中位数填补法，目的是尽量不要出现带小数点的填补项，但是其实使用中位数填补法有可能会产生带小数点的值，那就是当样本量（这里专门指排除缺失值后的样本量）是偶数的时候，打个比方：有一个100例的样本量，缺失2个，那么在这剩下的98个样本量中，中位数=[an/2+ a(n+2)/2]/2,当an/2和a(n+2)/2不相等时则中位数肯定为带小数的值。
当然这种情况其实发生的概率很小，特别是大样本以及分类数很小的时候，万一发生了，者只好使用众数填补，即用出现频率最高的频数来填补，要是使用众数填补则不能使用以上的过程步了，目前没有找到很好的方法，只能使用最笨的方法，即使用proc means 过程步求出众数，然后在记录这个数值，在放到data 步中进行填补。
总结一下：在使用sas（目前我用的是SAS9.2版本）进行均数填补法时，先看数据类型（当然这里只针对数值型数据，字符型在这里不做讨论），如果是计量资料，使用均数填补法，过程如下：
PROC STDIZE DATA=dataset REPONLY METHOD=mean OUT=outdata ;
VAR variables ;
RUN;
把dataset改成你要填补的数据库，把outdata改成经过均数填补法填补以后你要保存的数据库名字（如果没有这个语句那么SAS将自动保存，形如data1,data2…），把variables改成你要进行填补的变量。

要是数据类型明显的偏态，则使用中位数填补法，只需把mean改成median就行了。 参考技术A proc expand,

/proc信息的系统调用接口

【中文标题】/proc信息的系统调用接口

【英文标题】：System call interface to /proc information

【发布时间】：2017-08-30 04:22:12

【问题描述】：

我可以通过系统调用而不是处理文件中的文本来获取存储在/proc 中的信息吗？

---

我正在尝试list inotify watches which are preventing the unmount of a filesystem。

我已经编写了一部分 shell 脚本，但它已经太慢了。我正在考虑用 Perl 重写。

有没有办法从系统调用中获取/proc 信息以进一步加快速度？

【问题讨论】：

我相信/proc 伪文件系统的全部意义在于将许多不同的系统调用或对受保护内核内存的直接访问聚合在一个简单的结构下。

Inotify watch 不能阻止文件系统的卸载。该文档甚至提到了专门的 inotify 事件，该事件在文件系统卸载时被调度：“IN_UNMOUNT - 包含监视对象的文件系统已卸载”。而且，如果您阅读有关该主题的一点点内容，您会发现，专门创建了 inotify/fanotify 来解决其前身 dnotify 的问题，该问题不支持卸载监视目录。

不正确，他们can indeed。

@TomHale 不，他们不能。我的评论中引用的这段话来自Linux manpage of inotify，它明确指出，可以卸载带有 inotify 监视对象的分区。您已链接到 Symantec 文章，该文章提到了 Veritas 文件系统（一种专有的 HP UX 文件系统，不久前移植到 Linux）的一个已知问题。那篇文章承认这个问题是一个错误，并指出缺乏解决方法。 AFAIK，上游 Linux 官方支持的所有文件系统都没有出现此类问题。

我在btrfs 上体验过，显示它发生的记录显示在here。

【参考方案1】：

不，除了open() 和read() 系统调用之外，没有其他与/proc 节点的接口。

请记住，/proc 下的节点不是真实文件。从它们读取的内容将在内核生成内容时尽快返回——备用接口不会更快。

话虽如此，用任何可以直接读取文件的编程语言（如 Perl）重新实现你的 shell 脚本已经可以大大加快它的速度。在 shell 脚本中，每次调用 ls 或 grep 时，您都会启动一个新进程，甚至可能是多个进程。启动过程相对较慢 - 摆脱它可能会解决您的速度问题。

【讨论】：

“替代接口不会更快” - 不同之处在于 proc 中的“文件”是文本流，因此内核必须以文本格式写入数据并且然后应用程序必须将其解析回来，而替代接口可以提供“原始”数据。

@el.pescado：将单个整数转换为字符串并返回很少是瓶颈。打开一个文件要消耗更多（至少，因为它是一个系统调用，而不是一个纯粹的用户空间函数）。但是，正如@duskwuff 所说，/proc 没有其他接口。