EX09 - Padawan Equipment - Discussion
Отварям тази тема от философски подбуди. Първоначално събмитнах кода така и получих 90/100, като тест 3 гърмеше. Използвах минималистичен подход и сложих най-ниските възможни типове променливи, тъй като по условие НЕ се очакваше надхвърлящо капацитета им число (дискутираме само тези в червено). Промених ги после и 3-те на на double, но тогава гръмна за време само последният. Работещата комбинация се оказа два дабъла и float за priceOfBelts.
Въпросъ е, защо условието лъже за това че винаги ще дойдат валидни типове данни впосочените гранични стойности? :D
using System;
namespace EX09_PadawanEquipment
{
class CostCalculator
{
static void Main()
{
double money = double.Parse(Console.ReadLine());
int students = int.Parse(Console.ReadLine());
float priceOfStabbers = float.Parse(Console.ReadLine());
float priceOfRobes = float.Parse(Console.ReadLine());
float priceOfBelts = float.Parse(Console.ReadLine());
double tenPercent = Math.Ceiling(students * 0.1);
double totalStabbers = (tenPercent + students) * priceOfStabbers;
double totalRobes = students * priceOfRobes;
double totalBelts = (students - (students / 6)) * priceOfBelts;
double costOfEquipment = totalStabbers + totalRobes + totalBelts;
Console.WriteLine(money >= costOfEquipment ? $"The money is enough - it would cost {costOfEquipment:F2}lv." : $"Ivan Cho will need {((money - costOfEquipment) * -1):F2}lv more.");
}
}
}
Filkolev аз още от сега се точа на структурите от бази данни и алгоритми, затова гледам да "остържа боята" използвайки променливите на предела :D
NikolayNeykov92 това с фоутинг поинта е ясно, визирах постановеният в условието рейндж който би следвало идеално да се вмести в float, byte, float, float, float :D А пък отзаде на тестовете се подават по-дълги числа от 7 символа (•Floating point ◦float : 32 bits, range from 1.5 × 10−45 - 3.4 × 1038, 7-digit precision) :D
The input data will always be valid. There is no need to check it explicitly.
В диапазона 0-100 има безкрайно много реални числа. Никъде в условието не е казано, че ще са с не повече от 7 цифри, така че тестът не е грешен. Не са подадени отрицателни числа или по-големи от 100, проверено :).
При алгоритмите примитивните типове са най-малкият проблем. Там проблемите идват от неефикасно изпълнение на операции (обхождания на ненужни данни и т.н.). Освен ако нямаш подадени много, ама много на брой малки числа, не би трябвало да има особена разлика. А и ще разбереш ако това е проблемът - ще имаш прехвърлена памет в тестовете. От гледна точка на скорост, типовете по подразбиране са по-ефикасни доколкото помня, защото се правят преобразувания - но тук трябва да провериш, защото беше отдавна и не съм сигурен, че съм прав.
В диапазона от 0.00 до 100.00 аз лично разбирам, че входът ще е нещо от рода 87.16 но не повече или по-малко от оказаните граници. Сиреч гарантирано ми е, че няма да дойде някво 88.94893и483217488712498428174741442414гигавата8946427429 число. Явно в моят телевизор е грешката.
Иначе системата явно наистина е на слаба машина, защото с дабъл на второ четене съшият код минава. Това беше коментирано за БГ кодер преди, сега като се замисля.
88.94893483217488712498428174741442414 е положително число, по-малко от 100 - демек валиден вход, горната и долната граница са спазени. Нищо не е казано за брой цифри, което предполага да се ползва типа по подразбиране. Т.е. смятайки, че float ще ти е достатъчен, добавяш ограничения към задачата, които не са зададени по условие.