该楼层疑似违规已被系统折叠 隐藏此楼查看此楼
正是因为这个帖子本身就是LZ在学习离散数学时从两者在具体表现上的相似性,从而推导出来的观点,因此定义本身就是不严格的。而具体讨论时为了防止范围无限扩大,必然会加上一些前提。这些前提的不同就会出现不同的讨论结果。因此讨论这些问题就不得不从数学领域和工程领域两者之间跳跃,的确有些麻烦。
就我个人的观点,我并没有认为数学对实际没有指导,事实正相反,在这一点上我非常赞成你的观点。我的观点只是认为拿数学领域里面的概念和工程领域里面的概念进行横向比较的话,很容易因为具体场合的不同而得出截然不同的结论。
至于泛函分析和**论其本身研究的范围就已经非常巨大,用到实践中当然是“放之四海皆准”,用来思考问题自然非常让人愉快,但它们作为数学范畴中的概念在工程领域内显得过于抽象,因此并不适合直接拿来分析非常具体的工程问题。否则,大部分工程问题最后都会归结于近世代数中的理论。因此泛函分析和**论这样的数学工具更适合研究和思考,对于工程技术问题则需要结合实际应用场景采用更具体的数学工具,比方说微积分和级数等。
因为计算机科技本质上就是应用数学的具体应用,因此从数学的高度分析 less(ls()) 和 ls | less 自然能比较容易地阐述两者之间的共同特征。但就LZ所描述的实际场景来看,他很有可能是在学习离散数学的同时也在掌握 shell 编程语言的应用,他需要了解的是 less(ls())和 ls | less 是不是一回事,从他的角度上讲,如果答案是肯定的,则以后编写脚本时 less(ls()) 就可以和 ls | less 等效使用而不再区分两者之间的真正区别。
从数学上讲 less() 是不需要也不可能去处理 ls() 的异常这种情况的,因为出现异常的概念就是两者的函数关系无法保持成立。在实践中,less() 则必须保持对 ls() 异常的响应。而在实际分析时,复合函数这个说法本身就意味着只要关注 less() 的返回结果,而不需要关注 ls()到底返回什么,这也间接等于作为上层函数的 less() 必须处理下层函数返回的一切问题。而管道线中如果前驱出现问题则由shell本身处理,后继只不过获得了已有的输出或干脆就是个空集而已,并不会处理异常。
同样对数学的理解,却得出了截然不同的结论,原因就是因为在这里数学概念并不是拿来知道实践,而是成了横向比较的对象。所以我个人的观点就是:数学问题在数学领域内讨论,技术问题在技术领域内讨论。
如果需要LZ提出的涉及到具体技术领域的概念性问题,那越具体越容易沟通。如果讨论具体问题时太过抽象的话,那就会碰到类似“经典力学是相对论力学在低速下的特例,欧氏几何是非欧几何在经典空间中的特例”这样非常正确但却没有什么具体的技术指导意义的讨论。
从以上的话题来看,我们讨论的问题已经不完全是技术问题了,我们各自都掺入了自己的知识体系和专业背景对同一具体问题的不同理解,并得出了看似矛盾的结果。这样的现象对我们两个倒是很不错的交流。但对LZ的思考并没有太直接的帮助,在我看来已经有点离题了。依我看不如到此为止。具体就让LZ自己在实践过程中逐步去把握吧。希望我们的讨论对LZ有实在的帮助。