这样的问题你遇到过嘛?!关于公制,英制,小数点问题

dch4890164 2009-02-18 02:10:27
由于做的运动控制软件,随着设备要出口到很多国家,我们只负责把软件提供给客户(设备生产商)
本来从软件质量上,实时性,精度,使用习惯上直接客户(直接购买者)反应都很好,这些客户的国家里就没有北美的(谁让人是发达国家呢)
但是最近客户在北美的展会上,直接客户 提出一个要求,哈哈真让我郁闷了
他们有些地区据说还是以英制为主,我们的软件用的都是公制(大部分软件都是这样的吧,最起码我还没有看到英制的软件呢!)
本来也能做,只要单独发布一个英制版本的软件就可以了(这个只要稍加修改现有软件即可,专用键盘上加一个小数点按键,因为英制比较大)
呵呵可惜我们的客户不同意,他要求必须保留公制 ,而且要求公制不能改变现有习惯(所有数据不能带小数点),而英制要求所有数据能带小数点。并且公制和英制可以随时切换。
这是什么世道啊,秦始皇为什么伟大,单从度量衡上我就体会到了,他老人家真不是一般的高瞻远瞩
===========================================================
程序后台工艺数学模型都是整数(单位分别是mm,0.1mm),显示和后台数据做了隔离,目前的配方存储也是这样的单位
问题是公制英制如何才能无缝的切换,怎么控制小数点的问题,谁有这方面的经验,怎么样才能重构软件,并且尽量少的出错
另外补充一下,数学模型参数有几百个,直接和英制相关的有不到100个参数,嵌入式wince
==================================================================
程序的根本是数学模型,我认为本质上不但数学模型变了,还要求两种数学模型能并存
由于有保密协议规定,程序上的事情不能说太多,大家谈谈想法
呵呵顶者有分,分数不够还可以家,有好的想法另开贴再送你500分
=====================================
另外还不是很急,我有时间等,也请大家帮助思考一下,或者拿你们自己的软件做对比,遇到这样的问题怎么办

...全文
528 41 打赏 收藏 转发到动态 举报
写回复
用AI写文章
41 条回复
切换为时间正序
请发表友善的回复…
发表回复
hemiya 2009-02-19
  • 打赏
  • 举报
回复
最主要就是数据的精度问题,楼上也有很多人说了.
会思考的草 2009-02-19
  • 打赏
  • 举报
回复
The ViewModel is a fully self-contained class that represents all of the data, state, and behavior of the View, but without any of the controls used to render that UI. Strictly speaking, it is the Model for a given View. The DataContext for a View should be a ViewModel. Typically, only a small subset of application UI can be data bound directly to Model classes, especially if the Model is a pre-existing class or data schema over which the application developer has no control. The Model is very likely to have a data types that cannot be mapped directly to controls. The UI may want to perform complex operations that must be implemented in code which doesn't make sense in our strict definition of the View but are too specific to be included in the Model (or didn't come with the pre-existing model).
会思考的草 2009-02-19
  • 打赏
  • 举报
回复
会破坏模块内部实现?不这么认为。
存储,Model层使用任意方式,双精度,单精度,或者说你自己定义一种格式存储数据,随你便;
逻辑层,或者说Controller层,使用native的数据存储方式进行计算,实现算法;
View 层和Controller之间仅仅需要加一个转换而已。
或许你应该采用MVVM pattern。
会思考的草 2009-02-19
  • 打赏
  • 举报
回复
多国语言包安装后会导出一系列Lpk打头的函数,GDI在处理的时候,如GetTextExtentExPoint,会先检查有没有安装LPK,有的话就调用LpkGetTextExtentExPoint。其实还是就是加了一个中间层。
dch4890164 2009-02-19
  • 打赏
  • 举报
回复
[Quote=引用 35 楼 LBPeking 的回复:]
直接底层处理最好,就像“多国语言”一样
[/Quote]
呵呵有不一样的了,能更具体一点吗?
闪破风浪 2009-02-19
  • 打赏
  • 举报
回复
直接底层处理最好,就像“多国语言”一样
hityct1 2009-02-19
  • 打赏
  • 举报
回复
还有硬件限制,不好办。等待高人。
dch4890164 2009-02-19
  • 打赏
  • 举报
回复
像进制这样的问题仍然能破坏掉模块内部的实现
==================================================
我说的这句话是指UI层得很多模块要被破坏掉,请别误解
还有如果我以后中间算法层遇到这样的能破坏掉几个模块的问题的话,是否也要加层
呵呵,这种解决方法太不理想
======================================
我认为本质上这时一种软件重构,怎么重构?
昨天我还想的不太清楚,怎感觉这个问题不太对,说不上来,我想这些才是我感觉的
这样重构,根本就不行!不够灵活
dch4890164 2009-02-19
  • 打赏
  • 举报
回复
看来大家都是这个意见,谢谢各位
============================
呵呵我并不认为这个问题到这一步就解决了
最起码解决的还不够漂亮,试想一下如果是大家自己手头的程序,大家有多少人会这样做!
因为很讨厌思路不清的事情,转来转去还要做一些逻辑处理
============================================================
难道大家就没有意识到,虽然程序分层了,每层又分块了
但是还是有一些问题,所预料不到的,能同时破坏掉同层的很多模块吗(注意不是一两个模块被破坏掉)?
虽然可以通过增加接口或者保留接口,但是像进制这样的问题仍然能破坏掉模块内部的实现
这个问题不值得深究吗?通过哪些方法才能避免,而且还要合理,满足需求
而我们加上的转换层,本质上也只是见招拆招而已,拿不出原理性的解决方法
=======================
这个问题真的很特殊,这是我的想法
为什么会有这样的问题,难道除了加层就没有其他方法




lllsui 2009-02-19
  • 打赏
  • 举报
回复
关注
jyh_baoding 2009-02-19
  • 打赏
  • 举报
回复
搞清算法,写函数实现!
dch4890164 2009-02-19
  • 打赏
  • 举报
回复
[Quote=引用 39 楼 codewarrior 的回复:]
The ViewModel is a fully self-contained class that represents all of the data, state, and behavior of the View, but without any of the controls used to render that UI. Strictly speaking, it is the Model for a given View. The DataContext for a View should be a ViewModel. Typically, only a small subset of application UI can be data bound directly to Model classes, especially if the Model is a pre-…
[/Quote]
MVC就这点不好,占内存,我把所有数据都放在model里,之后让不同的VIEW 指向他
另外我用的是对话框模版,这一切都是我自己实现的,程序要比他小得多,在这里臭屁一下呵呵
dch4890164 2009-02-19
  • 打赏
  • 举报
回复
[Quote=引用 13 楼 dch4890164 的回复:]

所有的程序都是我们自己做的,前台也的确用的是MVC,但是略有不同,为了节省内存,VIEW那部分直接用的指针,指向的是MODEL里的数据
传统的MVC太过占内存了,因为数据量会扩大,我现在要做的是再中间再加一层即可
但是这种方法还无法令人满意,因为这种转换代价肯定是昂贵的,何况还有小数点控制的问题
[/Quote]
Typically, only a small subset of application UI can be data bound directly to Model classes
哈哈我就是这么做的,属于这个极少数,只不过我的变量关联没有用DataContext
呵呵这个东西好遥远,我显示模块 和操作模块分开并且完全不相关(只不过用户看着好像是在同一个地方输入和显示的,本质上和Excel差不多风格,这种分离和MVC有些不同),也就是说UI层上是完全不负责数据处理的,仅接受数据输入和显示,因为显示和输入都可以单独控制,这也是我对这个问题心里有底的原因
===================================
单位换算是UI上的事情,既然是这样你怎么可能不破坏这一层上的模块,怎么可能不修改原来的代码,而且还不是一个模块
菜牛 2009-02-18
  • 打赏
  • 举报
回复
只要改动显示和输入部分就可以了,内部算法、数据存储什么的都不要改。
一条晚起的虫 2009-02-18
  • 打赏
  • 举报
回复
关键是精度问题?
保留足够的位数,可以做到转换无损失。(只是说多次切换后数据不会改变)

加一层显示和存储转换,对于代码量,并不会增加多少。根据一个flag决定计算或存储或计算时是否要转换。不管计算还是存储都按照公制进行。
看lz描述,硬件应该会有改动,要加一个键位。如果不想改变布局的话,完全可以通过上档键的方式解决。
会思考的草 2009-02-18
  • 打赏
  • 举报
回复
加一个转换未必有多复杂吧,曾经做过一个工控计算的项目,跑在6808上,OS kernel、CAN通信、应用程序、IEEE754单精度浮点库全部采用汇编,计算蒸汽,液体,天然气,在工况(P,T)下的比容和比焓进一步计算瞬时流量和累计流量(热量,质量,体积三种)。
会思考的草 2009-02-18
  • 打赏
  • 举报
回复
数学模型没变,计算的算法还是一样的,只不过数据的单位变了。
关键是客户要求保留多少精度?如果用户输入英制的数据,你们允许他们使用到小数点后多少位?
dch4890164 2009-02-18
  • 打赏
  • 举报
回复
[Quote=引用 22 楼 cnzdgs 的回复:]
你还是举个简单的例子吧,这样说感觉不到难度在哪。
[/Quote]
呵呵大家现在都认为只要转一下就可以了,没有难度
但是肯定有更好的方法,大家真的没有感觉到这个问题很特殊嘛
我就感觉到它特殊,就是和别的不一样
下班了,回家再想
dch4890164 2009-02-18
  • 打赏
  • 举报
回复
或者抛开我的想法,重新做,大家认为怎么做合理
或者让你设计你怎么设计
代码量要小,内存占用要少,客户输入什么就得到什么,能无缝切换

[Quote=引用 9 楼 hityct1 的回复:]
我觉得这应该怪架构设计师没有设计好,传统的三层模型没有规划好。应该加个纯虚基类,公制和英制作为子类。

要是重构,我的想法是将显示和存储隔离,定义显示类。存储依然用公制,显示公制/英制;公制为基类,英制为子类,改变基类的行为。

总之都是用多态。
[/Quote]
这个方法合理,在xp上可以,ce下不要想,只能满足扩展要求,其他更重要的要求满足不了,因为这样设计的话,会有很多的子类,因为系统内还有其他的很多切换呢,不止单位这一种,只不过这是唯一一个和工艺相关的状态切换
cnzdgs 2009-02-18
  • 打赏
  • 举报
回复
你还是举个简单的例子吧,这样说感觉不到难度在哪。
加载更多回复(21)
CAM350 软件培训 1. 用户界面(User Interface)和 Gerber 数据的熟悉 不同编辑器(Editors)的基本功能 (CAM、CAP 和 Part) 不同 Gerber 文件的格式(RS-274D、274X、Fire 9000 和 Barco DPF) 2. 开始 AutoImport 和 Manual Import 加载 Gerber 和 孔径(Aperture)数据,设置正确的 Gerber 格式并加载层(layers) 孔径(Aperture) 孔径表(Aperture Table), 以及怎样输入和删除孔径(apertures)。 本身的(Intrinsic)和用户定制孔径(Custom aperture) 之间的不同之出。 热键(Hot Keys) 热键(Hot Keys)功能将分配在键盘上的哪些键用于热键,帮助用户快速地查看和移动应用程序中的数据。 3. 编辑(Editing)功能 查看(Viewing)选项 层(Layering)的功能 (Layer Bar, 层的颜色和标识) 编辑(Editing)命令(Add、Delete、Copy、Move 等) "组(Grouping)"功能和过滤(filtering) 多边灌注(Polypour)功能 (Vector 和 Raster 多边形等) 4. 绘图(Plotting) 选择和配置不同的打印机/绘图机驱动程序 绘图(Plotting)选项(Fit、Center、Separate Sheets、Scale 等) 5. 实用程序(Utilities) CAP Editor Draw-to-Flash Netlist Extract Clear Silkscreen Pad Removal Teardrop Over/Under Size Drill (Setup, Create, Sort, Add, Gerber-to-Drill) Mill (Setup, Create, Tab, Sort) Net Check DRC DRC Histogram Panelization (Autofilm, Panelize, Repanelize, Unpanelize) Venting Copper Area Part Editor 6. CAM350 快捷键 7. CAM350 实用经验技巧集 用户界面(User Interface) GERBER FILE 简介 GERBER 格式的数据特点: -----数据码:ASCLL、EBCDIC、EIA、ISO 码,常用:ASC II 码。 -----数据单位:英制公制、常用:英制 -----坐标形式:相对坐标、绝对坐标,常用:绝对坐标。 -----数据形式:省前零、定长、省后零,常用:定长 常见数字和字母意义: D01:LIGHT ON D02:LIGHT OFF D03:FLASH D10~Dn: APETURE CODE G54:更换镜头 M02:结束 坐标格式: *LEADING ZERO SUPPRESS:坐标整数字前面的 0 省略,小数字数不够以 0 补齐。 *TRAILING ZERO SUPPRESS:坐标小数字后面的 0 省略,整数字数不够以 0 补齐。 *NONE ZERO SUPPRESS:整数和小数字数不够均以 0 补齐。 *FORMAT(小数点之隐藏) :共有十种格式。 单位制: METRIC(mm) *UNIT ENGLISH(inch or mil) 单位换算: 1 inch = 1000 mil = 2.54 cm = 25.4 mm 1 mm = 0.03937 inch = 39.37 mil GERBER FILE 极性介绍: 正片(POSITIVE) :GERBER 描述是线路层,并且描述之图形主要是有铜部分。或 GERBER 描述是防焊层,并且 描述之图形主要是防焊部分(即盖油墨部分)。 负片(NEGTIVE) :GERBER 描述是线路层,并且描述之图形主要是无铜部分。或 GERBER 描述是防焊层,并且 描述之图形主要是无防焊部分(即不盖油墨部分)。 复合片(COMPOSTIVE) :GERBER 所描述的层次由不同极性层合成。通常是挖层和正极性层叠加。 挖层极性为 c,主要起线路防护或追加制程资料等作用。 四.镜头档(APETURE FILE)介绍 *镜头档主要描述相应 Gerber File 所用镜头之形状和大小 *APETURE FILE+GERBER FILE=完整的 PCB LAYOUT 图形 常用字段: D_CODE:D 码,即镜头编号 SHAPE:镜头形状 SIZE :镜头大小 基本镜头: :ROUND,CIRCLE,C,CIR…….. :

16,467

社区成员

发帖
与我相关
我的任务
社区描述
VC/MFC相关问题讨论
社区管理员
  • 基础类社区
  • Web++
  • encoderlee
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告

        VC/MFC社区版块或许是CSDN最“古老”的版块了,记忆之中,与CSDN的年龄几乎差不多。随着时间的推移,MFC技术渐渐的偏离了开发主流,若干年之后的今天,当我们面对着微软的这个经典之笔,内心充满着敬意,那些曾经的记忆,可以说代表着二十年前曾经的辉煌……
        向经典致敬,或许是老一代程序员内心里面难以释怀的感受。互联网大行其道的今天,我们期待着MFC技术能够恢复其曾经的辉煌,或许这个期待会永远成为一种“梦想”,或许一切皆有可能……
        我们希望这个版块可以很好的适配Web时代,期待更好的互联网技术能够使得MFC技术框架得以重现活力,……

试试用AI创作助手写篇文章吧