- 浏览: 307468 次
- 性别:
最新评论
-
pf8123829456:
你好,文中的地址访问不了,我想下载个最新的包,能给我发个或者给 ...
通过SSH的交互式Java应用开发和管理 -
congdepeng:
代码既文档 还是 文档既代码。DSL!
关于”代码既文档“的新思考 -
huhang1986:
追求终极根本的简单原理。
我正在思考这些问题。
并有一点想 ...
做事境界几步走 -
huhang1986:
文档是代码的冗余,所以同时维护代码和文档很痛苦。
关于”代码既文档“的新思考 -
huhang1986:
计算机得发展也就这些年,还有很远的路要走吧...
计算机系统复杂性难免,准备找机会学习逻辑语,寻找突破之道
最近又看到一些关于框架侵入性的讨论, 有些想法, 谨此抛砖引玉.
我觉得软件开发框架之所以跟侵入性纠缠不清, 根本的原因还是框架要支持应用的某种/某些逻辑和功能, 可以说是部分的去实现应用的目标. 但是这些功能如果不能让应用去定制, 其现实应用代价就又很微渺了. 所以框架是需要和应用交流的, 而交流的主要目的是为了定制.
想到这个地方, 我的反应是声明式编程, 让应用通过某种方式表达出自己的定制需求, 这个表达的方式就可以是多种多样的了: 通过遵循约定, 继承特定框架基类, 实现特定框架接口, 标注Annotation, 编写配置文件, 调用框架API, 等等.
而像Java这样的静态语言所能支持的表达方式, 无论怎么看都可以挂上 "侵入性" 的标签, 因为如果框架一旦定了它要求应用采纳的方式, 应用就得跟着它走. 在应用需求表达方式问题上, 框架之间的相容性既没有理论研究, 更没有实践习惯.
这里提到 "框架的侵入性" 好像用的是它最宽泛的涵义, 就是对应用编程行为的影响. 要是这么说任何框架都不可能没有侵入性了, 只是有些让应用开发人员的日子很难过, 有些则好一点. 不过以目前的软件体系局势来看, 绝对的 "侵入性" 问题还没有办法解决, 更现实一点, 似乎只有它对单元化开发和测试的影响比较有可能解决, 眼下讨论才比较有现实意义.
不过对下一代软件框架体系, 我倒是感到有些期望, 随着Annotation的成熟和普及, 对于基于Java的开发来说, 我觉得这个趋势已经临近了. 我的想法是可以运用一下逆向思维, 既然应用与框架的交互无可避免, 那么与其被动的接受框架的 "侵入" 不如由应用自身采取主动行为, 进行 "引入".
应用的主动引入可以从已有的 声明式编程 出发, 对于比较大的综合应用方向, 比如 Web应用, 以制定通用的应用需求表达规范为手段, 通过公开的规范, 协调应用程序和系统框架之间的交流. 这听起来就是JCP要为JavaEE做的事情, 是的, 以截至到目前的软件体系局势, 这个事情还不得不由人力, 物力, 财力丰厚的商业实体去完成, 它们也必须在这个领域有足够的商业利益吸引也才有动力去做.
但是同样是JCP出来的J2EE规范, Servlet很成功, 而EJB却不是. 并且Servlet很好的解决了它那个年代的Web开发问题, 而软硬件的发展所推动出来的新需求, 新问题又飞快增长, 对新规范的需求不仅是本身增长很快, 它的增长速度也会随着时间增长. JCP已经开始显得笨拙且乏力了.
一个本质性的问题是: 目前的规范是基于少量编程语言API的大部分的自然语言描述. 基于这样的模式, 成本太高, 就算是目前的大型开源社区要开发自己的体系规范也会是难上加难.
在这个方向上, DSL(Domain Specific Language)是个很好的创意, 可以有针对性的简化专门领域的规约方式. 不过, 我觉得还有DSL没有特别关注的一点, 就是同一种语言中声明与实现语法的分离与融汇:
DSL倾向于作为一种声明式的语言, 被设计为独立使用, 它很可能由另一种通用语言进行解释而实现. 它的语法很可能可以直接调用实现语言, 但很难变成编写应用所用语言的一部分. (我很期望它变成应用代码的声明部分)
回到解决侵入性的问题上来, 我设想的方式是目前还没有的, 至少还没有系统化. 那就是可以用一种语法给应用编程语言增加用于声明的语法, 同时这种语法也照顾到给应用声明的需求提供实现的系统编程语言语法, 从而这样的语法可以同时 表达/约束/支持 应用声明和系统实现.
看上去动态语言在这个方向上有最深厚的长远潜力, 不过用于有分析需求的通用工业开发领域, 动态语言要走的路还有点长.
目前基于Java的开发, 利用起Annotation机制会在这个方向上有长足进展, 应用通过引用标注来声明需求, 系统在编译时通过Annotation Processor以及Language Model, 在运行时通过反射, 两者结合起来去理解和实现应用的需求. 而定义和引用Annotation都受到新增的Java语法约束.
不过基于Annotation机制的 应用/系统 交流有时候还是需要一些自然语言描述的规范, 好在这个已经比纯粹描述/理解大篇的约定和接口调用逻辑顺序简易多了. 同时Annotation引用只能放在modifier的位置还是一个过大的约束, 这个还需要Java语言进一步的演进去解决.
总结下来, 系统框架通过 "侵入" 要达到的 应用定制 目的是不可避免的, 而要解决被动的受到 "侵入" 的局面, 我所能想到的最好方法就是去主动 "引入". 而 "引入" 所能达到的 "主动" 程度取决于其方式方法的灵活程度和负面影响大小. 当应用的特定需求可以通过统一的(声明)方式利用大多不同系统(包括测试时的Mock系统)而实现时, 应用的 "引入" 行为也就达到了一个比较理想的主动程度, 从而可以视为没有被特定系统 "侵入" 了.
评论
比如 某框架对某种定义的异常有特殊处理,那么我们的应用代码如果需要相关的功能就要被框架侵入。
那如果约定对相对路径:web-inf/classes/exception/*****下的所有*.class 自动处理此异常,也许在侵入上会有一点突破,不过还是有 xml配置的另一种说法而已。 当然只是想看看大家是怎么想的 ?
但是如果所有的单元全独立管理又无法管理
好管理了又无法重用.....
根本方法是不重用
只要重用就得侵入
少侵入就扩大了适用面
但减少了重用可能
很多是用引入框架的类或接口,稍微人性化点的则是使用xml或者其他配置文件(并不认为使用配置文件是一种侵入,侵入应该是在代码级别).
提供某种或某类服务的框架,不应该强制应用遵循或者执行某种条件来进行交换.
链接库 给应用的只有一堆白纸黑字写好的接口签名和或多或少的说明文档, 应用按照这些库期望的先后顺序和逻辑结构, 通过调用的方式向库代码传递参数和执行控制权, 并获得它们承诺的结果.
通过 链接库 的方式使用第三方软件功能, 应用程序在执行控制上占有绝对主动权, 但在那些功能的实现和定制上却处于绝对的被动地位, 只能通过该库所提供的定制接口调用来显式的定制.
但是到了框架时代应用程序和第三方功能之间的关系发生了微妙的变化, 应用 和 框架 之间变成了协作关系, 框架实现的逻辑 不再像 链接库的逻辑 那样是预先开发好以后就一成不变的了, 而是拥有了对 应用逻辑 的适应性, 能够通过 定义接口规范 以外的一些途径, 比如 约定, 框架基类/接口, 配置文件, Annotation 等等进行为了完成应用目标功能为目的的接触和融合. 这些变化也为目前的 IoC 思维大行其道提供了可能的舞台.
从此也就诞生了 "侵入" 的概念, 我感觉可以大致理解为 "在软件组件接合方式上, 本无必要或者过份的要求" 的意思. 而目前的局势下还没有轮到 应用 可以在语法上给 框架 提要求的份儿, 所以 "侵入" 一般是讨论 框架 对 应用 的非份要求.
但是在编程要求方面, 框架对应用的这种 单边关系 在下一代软件开发体系中是有望改变的, 我的信心来源是 元编程 理论和实践的日渐成熟. 而理想的结果就是 应用 可以通过公认的声明方式提出自己对 框架 的要求, 而各种框架也能够在成熟的公共知识基础上找到简易的方式来解释和实现 应用 的要求. 这里去实现这些 框架 的简易程度是关键因素, 因为这时对框架的丰富性要求也大增, 比如同一套 应用需求声明, 这时已经不仅仅是须要有至少一个框架能支持它的部署和运行就够了, 其他比如在单元测试方面, 就需要另一套框架逻辑的支持. 在不同平台上对相同应用需求的满足也需要它们各自提供的框架能够容易实现.
那时候的框架也许会另有其名, 它们对应用需求的适应性比目前的 框架 是要更提高了一个级别, 如果以我一直在思考研究的 面向能力编程 的思想来命名, 可能会称其为 能力提供者 (Capability Provider).
ajoo看到的是前点,所以自然无法认同你的观点。而楼主本身对两者定义的模糊,才有了希望主动侵入的观点。
另外,也需要说明一点,对于规范和协议的遵守,并非所谓的侵入(这种规范自然包括Javabean)。其实我想楼主的所谓的侵入应该是应用程序组件级的强制依赖。当你所开发的系统强制依赖于某个框架组件,并且不能进行轻松并有效的替换或者调节时,那么它就对你的系统形成了侵入。
(也简单说明一点,我至今并不认为EJB是种侵入。其实ajoo也表述了类似的思想,在框架集成的地方并不能称为侵入。)
虚是正常的,从标题中的就已经给出定位了。
对一个后验系统,讨论它的根本解决办法,本身就是一件虚的事情。
不过ajoo的类比很有意思,形象!
如果侵入能够大幅提高效率,减小代码量,又有一定的扩展性,也是欢迎的。
框架的移植、数据库的移植、应用服务器的移植,只是讨论多于实践,有多少人在闲着没事,移过来移过去。
侵入性并不一定是坏事。
前面说了, 因为最终目的的不可避免性, 所以目前来说是没有实际的解决可能的, 只有在单元化开发和测试方面还有些现实问题可以讨论. 不过顶楼大部分是在表述我对下一代软件体系里相关问题的一些期望.
看到大家的讨论又想起来一点相关的东西, 对于 "框架" 这个东西似乎流行的时间还不太长, 我觉得从本质方面看, 以现在的 "框架" 向前追溯, 依次可以找到 "设计模式", "算法", 和 "数据结构". 把这个顺序倒过来就是 计算机程序设计专业知识的共享和传播 这件事所经过的一个发展历程.
最早的时候连面向对象的指导思想都没有, 也没有系统程序员与应用程序员之分, 计算机也就是做运算, 比自动计算器强不了多少, 那时候用编程解决问题的主要手段就是设计一个适合的数据结构, 再设计, 利用起一些相应的算法, 最终解决的是一些 "运算问题".
后来这个行业发展飞快, 迅速的向数学以外的应用领域延伸, 于是软件被开始用于解决 "自动化管理问题". 大量新问题的引入严重增加了对编程手段的需求, 于是软件开发自然拆分为 "设计" 和 "编码" 两个部分. 算法和数据结构的作用在基本的编码问题以外能发挥的作用不大, "软件设计" 更像是新增加出来的工种, 于是专门从事软件设计的人把一些精妙有效的程序模板归纳总结成 "设计模式" 来加以利用.
不久以前计算机在一些领域(比如互联网网站开发)的应用产生了质的飞跃, 这方面的开发工作从设计原则到编码技巧都已经发展出了成熟的公众基础, 人们已经不再需要自己凭空探索就能从广泛的资源获得可以实际应用的指导原则和解决手段. 于是智力投入的焦点就转移到综合,总结一定的公众知识资源, 转化成可以直接运行, 直接提供一部分软件功能的可重用组件上.
这大概就是框架的来历.
从框架出来的本意是简化程序,或者应用的开发,
java bean或者default ctor应该作为一个convention over configuration机制。如果不提供额外的configuraton倒也罢了,可以认为scope就这样。但是如果或者只能通过侵入来提供,就不能不说是一种遗憾了。
无侵入性真的很难么?ArrayList对容器内部的对象有侵入么?很难么?
框架.registerComponent(MyComponent.class, "请用initService1()来设置service1的依赖")
这也许无非也是框架的一种能力, 当你写下这句话的时候,是否意味着, initService1() 不能带参数?
框架都能天才到分析我的自然语言了,猜测我的意思其实是initService1(someService1)应该不是难事吧?:)
convention over configuration 倒是很好的途径,
毕竟大家都是守规矩的人, 真的不想守的时候, 可以 configuration..
守规矩的时候大家都半斤八两,无所谓侵入性了。但是当无法守规矩的时候,就得看框架的侵入性了。spring是通过“你想要额外的功能?好吧,你让我进入,大爷我就帮你。没人逼你亚,是你自愿的”。而我认为更理想的是:"要额外的功能?你可以告诉我说“请通过某某方法注入对某某的依赖”。什么?你觉得这么说太麻烦?想跟我心有灵犀一下?那样更爽一点?好吧,恭敬不如从命。"
这世界是多样化的。有人不在乎被进入,而有人在乎的。
从框架出来的本意是简化程序,或者应用的开发, 从这一点上,程序员也应该不会做一些自找麻烦的的事。
当然这对开发新的程序,或代码也许并不成为问题 ,因为在开发的过程中自然会考虑到“一些限制”,
但就像上文提出, 对于旧的系统,
框架.registerComponent(MyComponent.class, "请用initService1()来设置service1的依赖")
这也许无非也是框架的一种能力, 当你写下这句话的时候,是否意味着, initService1() 不能带参数?
从某种意义上讲,这不是限制吧
不过我现在越来越讨厌复杂的“配置”
convention over configuration 倒是很好的途径,
毕竟大家都是守规矩的人, 真的不想守的时候, 可以 configuration..
我在顶楼提了一个
所谓 "侵入" 其最终目的是为了让应用能够 "定制" 框架给它带来的功能
这个想法, 不知道 ajoo 是什么看法?
我和你的看法不太一致。
一个框架到底定制能力要多强,这很难说,而且很容易陷入过渡设计或者设计不足之间的两难。
当然,通过侵入确实可以实现一些方便的定制,但是,几乎必然地,它同时也会影响一些其它的定制。只不过我们可以争辩说侵入实现的定制是有用的,而它妨碍的是你根本不需要的之类。
我对“侵入”的反感更多的是一种先验的哲学化倾向。本能地我就反感侵入。
今天看佛本,看到“圣人不死,大盗不止”。一个框架如果自以为是地说“我的侵入是为了给你提供方便性1,2,3”,在我看来这就是一种“自以为圣人”的倾向。
当然,现实中,有的“圣人”做的很失败,如ejb。而有的圣人则作得很成功,如spring,拥有大量的圣人门徒(acegi等)。
基本上,“圣人”就是说:放下你的锄头,跟我走,永远不要背叛,你就有福了。你要泡妞?一个好人不应该这么想的。你要在公共场合拉屎?你不觉得羞耻吗?
我认为好的框架不是这种圣人式框架,而是那些甘愿谦虚地作为一种工具,它不对你的编程方式作任何指手画脚的框架。
没有侵入性的副产品,是定制性几乎无穷,你愿意怎么使用这个框架都可以,即使是匪夷所思的方式。比如,你愿意拿砖头来磨成粉末然后放到烤箱里面去烤,可以,做就是了。框架并不需要弄个Grindable, Bakable接口来特地“支持”这个定制(当然,圣人的门徒会说,除了圣人提供的定制性,其它的都是你绝对不需要的。你为什么会想磨砖头?有病?),再就是你可以任意组合这些框架,你的生活你做主,这些框架只处理自己职责范围内的事情,绝对不会互相打架(当然,如果你的圣人说,你只许相信我,不许根别人钩三搭四,那就没办法了。实际上很多圣人系统的代价之一就是你不能随便和别人搭讪了,或者搭讪的代价比较大。看看那些“spring integrated”的广告语吧。难道一个组件不是天然就可以用在IoC容器里面吗?什么时候开始“IoC容器集成”居然也堂而皇之地算一个可以吹嘘的特性了?)
另一个考虑,是自恰性。很多有侵入的系统不是自恰的。比如spring里面,你的对象可以实现任意接口,除了以下几个:
BeanFactoryAware, ApplicationContextAware, BlahBlahAware (本列表持续更新中)
你可能觉得没什么阿。也许吧。反正我写和spring的集成代码时就很头疼这个持续更新的列表。如果明天spring又加了一个YetAnotherAware的marker interface,我还要回来增加一个"if(obj instanceof YetAnotherAware)",crap!
就像我们现实生活中没有人会用到String[][][][][]这种类型吧?我也没用过。但是如果某位圣人作了一个语言或者系统,然后告诉我说String[][][][][]被用作一个特殊的用途,我不能用,我也会觉得不爽的,非常不爽。特殊规则是对一个系统的美感(即使没有其它实际意义上的缺点)的严重伤害。
当然,事实上到底是那种哲学更实用,老实说我不知道。
我在顶楼提了一个
所谓 "侵入" 其最终目的是为了让应用能够 "定制" 框架给它带来的功能
这个想法, 不知道 ajoo 是什么看法?
传统的avalon为什么说侵入性高?因为它要求你的组件都要实现一个接口。一个没有实现这个接口的遗留系统怎么办?对不起,没办法?
spring/pico为什么侵入性低?因为它们把这个框架和组件之间的协议从一个proprietary接口降低成一个一般来说比较约定俗成的convention:java bean或者constructor。
不是spring/pico没有侵入性,而是这种侵入性一般来说采取了群众比较喜闻乐见的形势。
问:如果我的组件没有遵循java bean规范,或者没有实现要求的constructor怎么办?
答:这是一个伪问题么?有谁会不遵循java bean或者constructor呢?
统计上的优势(大量的人和应用都事实上遵循了java bean规范)掩盖了侵入性,或者说这个侵入性无足轻重了。这就叫convention over configuration吧。
然后annotation的引入也没有彻底解决侵入性。它解决的是delcarative programming这一部分。语法漂亮了。但是你还是要引入框架要求的annotation类型。
真正的无侵入性,在我看来,是框架对组件完全没有任何要求(不妨碍框架应用convention over configuration,缺省情况仍然假设组件遵循java bean规范)。比如说,你的组件没实现setService1(),而是initService1()。框架当然不可能预见到这点。但是你可以告诉框架亚:
框架.registerComponent(MyComponent.class, "请用initService1()来设置service1的依赖")
这里用的是自然语言来和框架交互。事实上框架当然不会这么聪明,肯定是要用某种框架理解的api来和框架交互。但是基本的意思就是这样,对MyComponent完全无侵入。
其实,这和用xml配置文件来配置没有本质区别。于是,又回到了原始的“xml配置也是侵入”,“框架理解的api也是侵入”的悖论。
而且,这种配置从实际角度不见得有通过annotation侵入MyComponent来得方便。
spring对这类非标准的问题的解决方案和我提的不同。它回避了困难,放弃了“无侵入性”的目标,转而用侵入这个万应灵丹来解决问题(BeanFactoryAware等等)。可以看作一种折衷吧。
对此,我要说的有两点:
1。在组建级别的侵入和在和框架集成部分的侵入本质上是不同的。和框架集成的地方侵入是自然的。或者根本不能叫做“侵入”。叫“依赖”可能更合理些。
2。考验功夫的就是这个xml配置或者api是否很麻烦。框架的目标应该是这部分做起来很简单,而且还足够灵活。如果它足够简单(搭配上convention over configuration),花在集成部分的工作量可以忽略,那么就可以在方便性上和annotation的declarative方法媲美,而且从侵入性上又优越,那么无论理论还是实际都可以站得上风了。不幸的是,spring这点上作的不好,配置文件繁琐地让人根本不敢考虑移植问题。而acegi之类的框架又走回了框架侵入的老路。当然,这并不妨碍spring的成功。(或者甚至有所帮助?)
发表评论
-
做事境界几步走
2009-05-11 11:42 1364对于一种事情(工作),熟而生巧,精益求精,逐步提升的层次: ( ... -
关于”代码既文档“的新思考
2009-04-19 12:37 3487我原来也很赞成”代码既文档“的想法,认为有很大的可行性,只是没 ... -
计算机系统复杂性难免,准备找机会学习逻辑语,寻找突破之道
2009-04-07 19:16 2491关于为什么软件一定是越做越复杂,成本越来越高,越做越枯燥,冥想 ... -
实例观察网络模型与关系模型对现实世界的建模差异
2007-09-24 16:53 4155我感觉受 主流/传统的 Object Orientation ... -
Introducing Hosting Based Interfacing
2007-09-17 16:21 3027HBI - Hosting Based Interfacing ... -
最小权限原则应用于面向对象的软件设计开发
2007-08-07 06:34 5871偶然看到Wiki百科的 Lua ... -
Object-Relational Mapping The Fake
2007-04-03 12:06 2919Object-Relational Mapping The F ... -
ORM其实是在映射网络模型和关系模型,OO的关系模型无需映射,且更简单高效
2006-12-28 04:44 15626O-R Mapping 从字面上理解 ... -
利用互动协作的思维导图增量持久化敏捷迭代的头脑风暴过程
2006-12-10 18:50 3447最近写教程了解了一些敏捷相关内容, 想到 WoW http:/ ... -
一个可能比SOA更好的思路
2006-11-18 13:44 14730本文英文版发在: http://www.theserversi ...
相关推荐
因此,这些被称为半侵入式攻击(semi-invasive attacks)的方法介于非侵入式攻击和侵入式攻击之间,它们在硬件安全性上的威胁更大,因为它们几乎和侵入式攻击同样有效,但成本却能接近非侵入式攻击。 在这份技术...
为了解决这些问题,本文提出了一种电力系统负荷非侵入式监测方法,该方法不需要安装任何专门的监测设备,能够实时监测电力系统负荷的暂态和稳态工作状况。该方法基于自筛选的优化遗传算法(AOGA),将电力参数模型...
通过这种模型和方法的应用,可以实现非侵入式负荷监测技术的精确识别,从而为能源管理提供支持。 文章进一步讨论了HMM模型在负荷监测中的应用,指出该模型是适合处理电力消耗模式识别问题的。HMM模型是一种统计模型...
在这篇综述中,我们介绍了可用的非侵入性方法来检测可疑病变,包括活体染色,口腔细胞学,光学检测,唾液生物标志物检测和图像分析,这些方法可以提高OPMD的早期诊断和监测的检测效率。 。 然而,仍然存在限制这些...
为了准确校正地层的真电阻率,在不分析泥浆侵入规律的情况下,提出一种利用常规孔、渗构造连续的毛管压力曲线,通过构造的毛管压力曲线计算油藏的含水饱和度,再利用导电模型正演得到地层真电阻率的新校正方法。...
本文介绍了一种基于卷积神经网络的非侵入式负荷识别方法,旨在解决非侵入式负荷识别中的低识别准确率问题。该方法首先对电阻类负荷、电容类负荷、电感类负荷进行数学建模,并结合tracebase master数据集构建样本库,...
本文的主要贡献是提出了基于Rhino引擎的低侵入式JavaScript内置对象扩展方法,解决了Rhino引擎在客户端JavaScript脚本解析中的不足,提高了Rhino引擎的性能和可扩展性。 知识点: 1. Rhino引擎:Rhino引擎是一个...
本文提出了一种基于人工神经网络的非侵入式居民用电负荷识别方法,旨在解决非侵入式负荷识别问题的数学优化算法效率低的问题。该方法利用人工神经网络来识别家用电器的工作状态,并构成负荷特征识别库,以获取不同...
探针技术是一种无侵入式的监控方法,通过在软件运行时动态插入监控代码,可以实时监控系统状态而不需要重启服务或修改应用程序代码。这种方法的优点是减少对应用程序性能的影响,并且可以快速应用在任何已部署的应用...
阿里非侵入式热修复方案SophixDemo是一个创新的技术实践,旨在解决移动应用在发布后出现bug时,无需用户下载新版本即可实现问题修复的问题。Sophix是阿里巴巴开源的、针对Android平台的热修复框架,它允许开发者在不...
本研究旨在解决非侵入式负荷识别问题,提出了一种基于卷积神经网络的方法,以识别电器的负荷特征。该方法通过对电器的V ̄I轨迹图像进行特征提取,使用卷积神经网络对图像进行分类,从而识别电器的负荷特征。 在该...
这种非侵入式的监测方法减少了安装和维护成本,同时也便于用户通过智能终端远程查看和控制用电,有助于节能减排,提升用电安全性,是智能电网领域的重要发展趋势。 总之,基于云平台的非侵入式负荷监测与识别系统...
与传统的侵入式监测方法相比,非侵入式负荷监测具有以下优势: 1. 成本更低:不需要为每个电器安装额外的硬件设备。 2. 维护简便:集中式的监测系统便于维护和升级。 3. 易于推广:适合大规模部署,便于实现整个社区...
由于提供的文件名为“一种碳酸盐岩储层中火成岩侵入范围的识别方法.pdf”,我们可以期待这份文档将详细阐述以上提到的各个知识点,给出具体的操作步骤、技术细节和可能遇到的问题及解决方案。对于从事油气行业地质...
总的来说,《基于低维算子机器学习逼近的非侵入式非线性模型降阶》为解决高维度动态系统分析中的计算瓶颈提供了一种创新的解决方案。通过结合机器学习与降阶模型技术,它为实现非侵入式和高效模拟开辟了新的道路,...
大兴煤矿S2905工作面火成岩侵入复杂,火与瓦斯耦合灾害严重,在回采末期采空区出现低浓CO,对工作面正常回撤影响较大。从火成岩侵入条件下,煤层自燃倾向性、断层及火成岩侵入构造带遗煤量,瓦斯治理影响下工作面推进速度...
火成岩侵入是造成矿井瓦斯异常涌出的重要影响因素之一。对火成岩侵入影响下瓦斯涌出量影响进行了研究。预测结果表明:一盘区由于火成岩侵入范围较小,瓦斯涌出量为9.49~14.19 m~3/min;二盘区火成岩侵入范围较大,瓦斯...