九度OJ-1435-迷瘴(HDOJ-2570)
2017-01-26 22:10
281 查看
题目地址:点击打开链接
题目描述:
通过悬崖的yifenfei,又面临着幽谷的考验——
幽谷周围瘴气弥漫,静的可怕,隐约可见地上堆满了骷髅。由于此处长年不见天日,导致空气中布满了毒素,一旦吸入体内,便会全身溃烂而死。
幸好yifenfei早有防备,提前备好了解药材料(各种浓度的万能药水)。现在只需按照配置成不同比例的浓度。
现已知yifenfei随身携带有n种浓度的万能药水,体积V都相同,浓度则分别为Pi%。并且知道,针对当时幽谷的瘴气情况,只需选择部分或者全部的万能药水,然后配置出浓度不大于 W%的药水即可解毒。
现在的问题是:如何配置此药,能得到最大体积的当前可用的解药呢?
特别说明:由于幽谷内设备的限制,只允许把一种已有的药全部混入另一种之中(即:不能出现对一种药只取它的一部分这样的操作)。
输入:
输入数据的第一行是一个整数C,表示测试数据的组数;
每组测试数据包含2行,首先一行给出三个正整数n,V,W(1<=n,V,W<=100);
接着一行是n个整数,表示n种药水的浓度Pi%(1<=Pi<=100)。
输出:
对于每组测试数据,请输出一个整数和一个浮点数;
其中整数表示解药的最大体积,浮点数表示解药的浓度(四舍五入保留2位小数);
如果不能配出满足要求的的解药,则请输出0 0.00。
样例输入:
样例输出:
此题调试了接近三个小时,通过与他人AC代码合拍,抽丝剥茧,再加上google到了HDOJ同题的discuss,最后确定了问题出在浮点数计算时带来的精度缺失问题。这是本菜鸟第一次接触到此类问题。
通过某大神的博文系统了解了一下关于浮点数的比较大小问题的处理。附上博文地址:http://www.cnblogs.com/crazyacking/p/4668471.html
引用并加工其博文精髓如下:
double类型存储的数据精度位数达到了14位,但有些浮点运算的结果精度并达不到这么高,可能准确的结果只有10~12位左右。那低几位呢?自然就是不可预料的数字了。这给我们带来这样的问题:即使是理论上相同的值,由于是经过不同的运算过程得到的,他们(存储进double变量的运算结果)在低几位有可能(一般来说都是)是不同的。这种现象看似没太大的影响,却会一种运算产生致命的影响:
==。恩,就是判断相等。
我们解决的办法是引进eps,来辅助判断浮点数的相等。eps缩写自epsilon,表示一个小量,但这个小量又要确保远大于浮点运算结果的不确定量。eps最常见的取值是1e-8左右。
定义三出口函数如下: int sgn(double a){return a < -eps ? -1 : a < eps ? 0 : 1;}
则各种判断大小的运算都应做如下修正:
这样,我们才能把相差非常近的浮点数判为相等;同时把确实相差较大(差值大于eps)的数判为不相等。
所以,养成好习惯,尽量不要再对浮点数做==判断。例如,我的修正写法2里就没有出现==。
对其总结归纳:由于计算误差的存在,浮点数比较大小,应该把相差非常近的浮点数判为相等,同时把确实相差较大(差值大于eps)的数判为不相等。故不应直接使用等号与不等号,应按照上表作出对应的修正,将原逻辑判断式进行替换。(要根据具体情况试出合适的eps,通常可取为0.000001)
以上。
题目描述:
通过悬崖的yifenfei,又面临着幽谷的考验——
幽谷周围瘴气弥漫,静的可怕,隐约可见地上堆满了骷髅。由于此处长年不见天日,导致空气中布满了毒素,一旦吸入体内,便会全身溃烂而死。
幸好yifenfei早有防备,提前备好了解药材料(各种浓度的万能药水)。现在只需按照配置成不同比例的浓度。
现已知yifenfei随身携带有n种浓度的万能药水,体积V都相同,浓度则分别为Pi%。并且知道,针对当时幽谷的瘴气情况,只需选择部分或者全部的万能药水,然后配置出浓度不大于 W%的药水即可解毒。
现在的问题是:如何配置此药,能得到最大体积的当前可用的解药呢?
特别说明:由于幽谷内设备的限制,只允许把一种已有的药全部混入另一种之中(即:不能出现对一种药只取它的一部分这样的操作)。
输入:
输入数据的第一行是一个整数C,表示测试数据的组数;
每组测试数据包含2行,首先一行给出三个正整数n,V,W(1<=n,V,W<=100);
接着一行是n个整数,表示n种药水的浓度Pi%(1<=Pi<=100)。
输出:
对于每组测试数据,请输出一个整数和一个浮点数;
其中整数表示解药的最大体积,浮点数表示解药的浓度(四舍五入保留2位小数);
如果不能配出满足要求的的解药,则请输出0 0.00。
样例输入:
3 1 100 10 100 2 100 24 20 30 3 100 24 20 20 30
样例输出:
0 0.00 100 0.20 300 0.23
#include <iostream> #include<stdio.h> #include<algorithm> using namespace std; int main(){ int c; int n,V; double W; int volume=0; double cur=0; double buf[101]; double temp; cin>>c; while(c>0){ c--; volume=0; cur=0; cin>>n>>V>>W; W/=100; for(int i=0;i<n;i++){ cin>>buf[i]; buf[i]/=100; } sort(buf,buf+n); for(int i=0;i<n;i++){ temp=(cur*volume+buf[i]*V)/(volume+V); if(temp-0.000001<=W){ volume+=V; cur=temp; }else break; } if(volume==0) printf("%d 0.00\n",volume); else printf("%d %.2lf\n",volume,cur); } return 0; }
此题调试了接近三个小时,通过与他人AC代码合拍,抽丝剥茧,再加上google到了HDOJ同题的discuss,最后确定了问题出在浮点数计算时带来的精度缺失问题。这是本菜鸟第一次接触到此类问题。
通过某大神的博文系统了解了一下关于浮点数的比较大小问题的处理。附上博文地址:http://www.cnblogs.com/crazyacking/p/4668471.html
引用并加工其博文精髓如下:
double类型存储的数据精度位数达到了14位,但有些浮点运算的结果精度并达不到这么高,可能准确的结果只有10~12位左右。那低几位呢?自然就是不可预料的数字了。这给我们带来这样的问题:即使是理论上相同的值,由于是经过不同的运算过程得到的,他们(存储进double变量的运算结果)在低几位有可能(一般来说都是)是不同的。这种现象看似没太大的影响,却会一种运算产生致命的影响:
==。恩,就是判断相等。
我们解决的办法是引进eps,来辅助判断浮点数的相等。eps缩写自epsilon,表示一个小量,但这个小量又要确保远大于浮点运算结果的不确定量。eps最常见的取值是1e-8左右。
定义三出口函数如下: int sgn(double a){return a < -eps ? -1 : a < eps ? 0 : 1;}
则各种判断大小的运算都应做如下修正:
传统意义 | 修正写法1 | 修正写法2 |
a == b | sgn(a - b) == 0 | fabs(a – b) < eps |
a != b | sgn(a - b) != 0 | fabs(a – b) > eps |
a < b | sgn(a - b) < 0 | a – b < -eps |
a <= b | sgn(a - b) <= 0 | a – b < eps |
a > b | sgn(a - b) > 0 | a – b > eps |
a >= b | sgn(a - b) >= 0 | a – b > -eps |
所以,养成好习惯,尽量不要再对浮点数做==判断。例如,我的修正写法2里就没有出现==。
对其总结归纳:由于计算误差的存在,浮点数比较大小,应该把相差非常近的浮点数判为相等,同时把确实相差较大(差值大于eps)的数判为不相等。故不应直接使用等号与不等号,应按照上表作出对应的修正,将原逻辑判断式进行替换。(要根据具体情况试出合适的eps,通常可取为0.000001)
以上。
相关文章推荐
- 九度OJ 1435 迷瘴
- 【WA】九度OJ题目1435:迷瘴
- 九度OJ 1435 迷瘴
- 【九度】题目1435:迷瘴
- HDOJ-1878欧拉回路 && 九度OJ-1027欧拉回路
- 【hdoj2570】迷瘴
- 九度oj 1435
- hdoj 2570 迷瘴
- 九度OJ108 HDOJ3790:最短路径问题 迪杰斯特拉算法
- hdoj 2570 迷瘴
- hdoj 2570 迷瘴
- HDOJ 2570 迷瘴(贪心)
- hdoj 2570 迷瘴
- HDOJ 2570 迷瘴
- 【九度OJ】题目1435:迷瘴 解题报告
- 九度考研机试教程 23-题目1435:迷瘴
- 【重点】九度OJ 1163&1440/HDOJ 1397 Goldbach's Conjecture(素数筛法)
- hdoj-2570 迷瘴(贪心,数学)
- 【九度OJ】1029【二分查找】
- 九度oj-1073-杨辉三角