Трето предизвикателство

1. Трето предизвикателство е вече налице. Ако имате въпроси по условието, може да питате тук :)

   Публикувано преди около 9 години

2. Числата в редицата, която подаване не е нужно да са естествени, нали така? Т.е. възможно е да викаме fibonacci_like? с [2, -1, 1, 0, 1, 1 , 2, 3]?

   Публикувано преди около 9 години

3. @Дарин, да - възможно е.

   Публикувано преди около 9 години

4. Поради странната точност на Float-а в Ruby се получава следната интересна ситуация:

   irb(main):005:0> 0.1 + 0.2 => 0.30000000000000004

   Това поражда въпроса дали ще има Float стойности?

   ... и ще оставя това тук.

   Публикувано преди около 9 години

5. @Кузман, може да има, но не се притеснявай за точността.

   Публикувано преди около 9 години

6. Тоест точността при смятане на Float-ове няма да ни спъне на тестовете ?

   Публикувано преди около 9 години

7. Не е нужно да проверяваме дали образувата такава редица в разбъркан рен нали така? Тоезт 1,1,2 връща true a 1,2,1 връща false.

   Публикувано преди около 9 години

8. @Константин,

   • 1, 1, 2 изпълнява условията за fibonacci_like? (1 + 1 е 2) => връщаме true
   • 1, 2, 1 не изпълнява условията за fibonacci_like? (1 + 2 не е 1) => връщаме false

   Отделно, идеята на това да имаш редица е, че имаш определен ред. Ако разбъркаш реда, имаш друга редица.

   Публикувано преди около 9 години

9. Първо, float на който и да е език има неточност. Това произлиза от начина, по който се представя числото в хардуера/паметта. Просто някои десетични числа нямат точно представяне, пък и има определен брой битове, в които трябва да се побере числото. Между другото, Float типът в Ruby всъщност използва double-precision floating-point числа. Тоест, double-и, които са много по-точни от (single-precision) float.

   За почти всички практически цели floating point числата дават достатъчно голяма точност.
   Например, ако ще строиш нещо, не те интересува дали то ще е широко 10m или 10.000000000000004m. За сравнение, един атом е голям от порядъка на 0.0000000001m. Или пък ако измерваш температура между 30C и 30.000000000000004C няма практически никаква разлика. Особено при положение, че термометърът ти сигурно има точност до 1 десета или стотна от градус.

   Има случаи, в които все пак трябва да се грижим за точността. Например, банкови системи - там грешката все още е сравнително малка, но като се умножават/събират много на брой сметки тя се натрупва. Особено, когато сумите са големи - там и грешката е по-голяма, защото грешката се увеличава колкото по-голямо е числото.
   Друг пример е, когато искаме да закръглим число със ceil или floor. Тогава, заради грешката, ако не внимаваме числото може да се закръгли на неправилната стойност.

   По подразбиране използваме floating-point числа и само ако сме сигурни, че ни трябва огромна точност - Decimal или Rational. Decimal и Rational представат числата по различен начин в паметта и може да имат произволно голяма точност.

   Заради тази дребна неточност, която може да се появи - никога float числа не се сравняват с ==. Ако искате да проверите дали две float числа са равни - изваждате ги и гледате дали получавате нещо достатъчно близко до 0 с някаква точност. Това правим и ние в тестовете - разгледайте тестовете на първа задача. Там има проверки от рода на expect(convert_between_temperature_units(0, 'C', 'K')).to be_within(0.0001).of(273.15). Това проверява дали резултатът е равен на 273.15 с точност до четвъртия знак след запетаята. Тоест, може да е 273.1501 и пак ще работи. Това е доста щедро - по-вероятно е да е нещо подобно на 273.150000000000001 или 273.149999999999998, които също ще минат проверката. В тази задача, оригиналната идея беше за цели числа (не сме тествали с такива с плаваща запетая), затова сравнение с == тук е ОК решение.

   Публикувано преди почти 9 години

Трябва да сте влезли в системата, за да може да отговаряте на теми.