修复模糊因子解决方法和q
前几天，我花了大量时间跟踪我的一个例程中的一个意外行为，最终意识到我是使用fix函数的著名模糊因子的另一个受害者。费克斯，骗我一次，你真丢脸。。。骗我两次，我真丢脸！
(defun fuzzfix (input / *error*)
;Jef! 2015-12-15. Automatic addition of a fuzz factor to avoid fix
;returning a bad value due to a fuzz difference.
(defun *error* ( msg )
(if (not (member msg '("Function cancelled" "quit / exit abort")))
(princ (strcat "\nError: " msg))
)
(princ)
)
(if (> 0 input)
(fix (- input 0.000000000000001))
(fix (+ input 0.000000000000001))
)
)
以下是我的问题：
-您是否会放弃任何反指示，即每次使用修复程序时自动添加模糊？
-你会换一种方式吗？
-你知道有没有其他函数（除了fix）可能会受到模糊影响并返回意外结果？
还有一个更一般的问题。。。何时使用/不使用*error*？在这里，我想我可能只是进行了numberp验证，在这两种情况下，在函数中使用fuzzfix都会触发该函数中的错误，无论fuzzfix是否返回（通过*error*）“错误：错误参数类型：numberp:nil”或自定义消息，如“fuzzfix需要一个数字”，由我自己的numberp“else”返回。欢迎就此提出任何建议。
谢谢，干杯！ 我会使用舍入函数
(round test 1e-15)
至于*error*，作为一般规则，如果数据库要修改DBMOD>0，我总是使用它
如果未指定模糊因子，则（equal）将受到影响 嗨，大卫。
实际上，我很惊讶地看到，这里没有本机舍入函数。我应该考虑寻找一个lisper制作的，它不仅可以处理模糊因素，而且具有更大的灵活性，因此比我刚才制作的函数有更多的用途。
事实上，equal受到影响，但允许指定模糊。我对需要完全不同方法的函数提出了更多要求（例如fix，它需要自制的舍入函数）。根据我目前的经验，fix似乎是。。。唯一的
至于你关于“错误”处理的一般规则，这很有道理，我几乎为我的提问感到羞愧。我最好使用numberp验证。我也觉得避免错误总是一种更好的做法，而不是在错误发生时处理它们，只要可能。。。
非常感谢你的意见，大卫。 我强烈反对在这样的支持函数中使用局部误差函数；在我看来，参数的有效性（例如，参数数据类型）应该由调用函数负责（与标准AutoLISP函数的行为一致）。
更重要的是，请注意，当发生错误时，局部错误函数不会在堆栈上求值-也就是说，如果一个错误函数在局部定义为函数A，而另一个错误函数在局部定义为函数B，那么如果从函数A内求值函数B，并且发生错误，则只会求值在局部定义为函数B的错误函数。这很容易导致在发生错误时无法执行与函数A相关的清理操作。
考虑以下示例：
(defun funA ( / *error* )
(defun *error* ( m )
(princ "\nfunA error handler.")
(princ)
)
(funB nil)
)
(defun funB ( x / *error* )
(defun *error* ( m )
(princ "\nfunB error handler.")
(princ)
)
(rtos x)
)
现在，作为另一个例子，考虑一种情况，在计算funB时funA有一个打开的文件描述符-需要在funB局部的错误函数和funA局部的错误函数中包含表达式来关闭该文件描述符，这意味着funB不再是库函数。 我想我完全明白你的意思，李。就像在你的例子中，在funA中，你会改变变量，在那种设置中，它们永远不会被重置回来。
调用函数的责任。。。。
(defun funA (passedvalue / *error* )
(defun *error* ( m )
(princ "\nfunA error handler.")
(princ)
)
(if (numberp passedvalue)
(funB passedvalue)
(princ "I think i understood, thanks!")
)
(princ)
)
(defun funB ( x / *error* )
(rtos x)
)
5
从我的理解来看，库函数应该总是返回相同的内容/格式。听起来很符合逻辑。
大卫，李，谢谢你的意见！非常感谢！
页:
[1]