Тук е мястото да питате, ако има нещо неясно по условието на втора задача. Примерният тест е тук.
Втора задача
казва ми, че нямам достъп до задачата
Упс. Вече имаш :)
- Какво в случая е
nil
тук?header := Header{"RGB", 3, nil}
- "Представяйте за данни всеки цвят (Red, Green, Blue, Alpha) като число между 0 и 1." - Какво точно значи това и защо е по-лесно за манипулации?
- Какво в случая е
1: Стойността nil е свързана с бъдещо предизвикателство и не е част от задачата. Прост изтрии този аргумент аз ще оправя условието.
2: В условието се казва, че когато е даден алфа канал другите трябва да се умножът по него за да се нормализират. Ако умножиш 255 по 255 няма да получиш числе [0 - 255] => ако представиш цветовете, като числа между 0 - 1 ще е по лесно.
Ахаа, значи просто
map
-ваме числата от 0 до 255 към числа от 0 до 1 заради алфа канала. Мерси!Отчайващо описание на условието. Подозирам, че разбирането му ще е много по трудно от самата задача. Що за изречение е "Представяйте за данни всеки цвят като число между 0 и 1." за бога? "Задачата ви е да може вашата функция да приема"? Разбирам какво искате да кажете. Но и изречението "биберонът иска аз зеленият" е разбираемо. Както и да е, да мина към въпросите:
Какво значи полето Format в Header "стуктурата"? Какво може да има в него? Наша интерпретация? Или ще очаквате например вътре да има някоя вариация на буквичките "R", "G", "B" и "A" в един стринг. Като буквичките вероятно значат следното
- R - red
- G - green
- B - blue
- A - alpha
Предполагам, че е очевидно. Но все пак го няма в условието. За мен може да е напълно логично да си означавам червеното с A.
Също така, неща като "B", "AB", "RG", "A" валидни формати ли са? Ако да - какво да ги правим?
Какво да правим когато във формата получим нещо странно ("DOYCHO")? Или когато е празен? Всъщност отново се връщам на въпроса - какво значи верен формат?
Какво да правим, когато данните са непълни ({1}) или неверни ({456732, 231, 234567, -1})?
Задължително ли е когато викаме println върху типа за цвят той да се печата точно както е показано в примера (Red: 0, Green: 12, Blue: 244)?
Моя съвет: влагайте в писането на задачите поне време, колкото толкова накрая да няма грешки и каквито и да е правописни на българския език. Това много ще улесни разбирането им. След това питайте някой външен човек дали ги разбира.
Между другото: съжалявам, че привидно само ви хейтя. Всъщност курса много ми харесва и съм благодарен че си отделяте от времето да ме научите на Go :)
Позволили сме си да не описваме подробно какво значат буквичките, основавайки се на RGB модела и неговото разширение RGBA. Все пак беше добра идея да има линк към тях в условието.
Иначе самият
Format
е string, което се вижда от example-а и от примерните тестове.Какво да правим, когато данните са непълни ({1}) или неверни ({456732, 231, 234567, -1})?
Очаквате винаги коректен вход, ако не е указано изрично обратното.
Задължително ли е когато викаме println върху типа за цвят той да се печата точно както е показано в примера (Red: 0, Green: 12, Blue: 244)?
Да.
Иначе point taken за местата, в които сме демонстрирали дислексия. Ако има неяснотии из условието, можеш да мяташ око на примерния тест, ако все още имаш неяснотии - ни храниш :)
- Съжалявам за неточности в условието (откъм изразяване) но идеята е то да имитира спецификация(която по принцип не е достатъчно прецизна). Идеята е да започнете да ползвате примерите и примерните тестове за източник на информация (а условието само за насоки).
- Приемливи формати са RGB, BGR, RGBA, BGRA
Аз имам два бързи въпроса:
На къде искате да round-ваме числата ? Ceil, Floor, или математическо (в зависимост от десетичната стойност), понеже гледам че кастването взима Floor-а (което е логично да направи). Та какво да правим ние?
В
InspectPixel(a,b)
a и b са координатите x и y , нали ? Тоестa === x === columns && b === y === rows
?
Тестовете би трябвало да ти гръмнат и за двете.
- floor т.е. кастваш
- първото ти е колоната, второто редът
За кастването тестовете не гърмят. За колона и ред принципно да, но само единия тест и питам, за да съм сигурен :)
Ами в моето решение използвам cast който се държи като floor. Относно втория въпрос да InspectPixel(a,b) взема колона и ред(x, y)
Благодаря. Но би трябвало InspectPixel да взима (колона , ред).
Да сме напълно точни InspectPixel взима колона (първи аргумент) и ред (втори аргумент) според този тест:
func TestBasicRGBACall(t *testing.T) { data := []byte{ 0, 12, 244, 128, 14, 26, 52, 127, 31, 33, 41, 255, 36, 133, 241, 255, } header := Header{"RGBA", 4} picture := ParseImage(data, header) first_pixel := picture.InspectPixel(0, 0) if err, value := assertColor(first_pixel, 0, 6, 122); err != nil { t.Error(err, value) } second_pixel := picture.InspectPixel(3, 0) if err, value := assertColor(second_pixel, 36, 133, 241); err != nil { t.Error(err, value) } }
или се бъркам?
Да го поставим така... Адекватни ли са тези тестове спрямо вашето изискване?
п.с. Тестовете са на Димитър Дишев, просто ги преработих, понеже той явно закръгляше математически.
Колона и ред взема. Демек x е колона, y - ред.
@Недялко, тестовете изглеждат адекватни.
Последно като гледах темата, имаше пост на Дейвид, в който пишеше, че трябва да приложим научения материал от лекцията за Error Handling в задачата, но сега сякаш не мога да го намеря или е редактиран.
Искам да питам дали трябва да осъществяваме проверка за грешен вход, например неточен формат, масив с неправилна дължина или колона и ред, извън рамките на изображението, или съм сънувал този пост
Само аз ли имам проблем с формата за предаване на 2-рата задача? Казва ми че имам някаква синтактична грешка, и не ми приема решението, а при мен всичко е ОК.
@Александър, действително постът беше такъв преди, но след това го редактираха. Питах на лекции дали трябва да проверяваме за грешен вход и ми отговориха, че не трябва и разчитаме на коректен вход.
@Мария благодаря много за доуточнението :)
И аз имам същия проблем като @Димитър. gofmt мина, няма какво да поправя, кода минава тестовете, но формата не иска да го качи... Отказва заради "синтактична грешка".
Да, проблем в evans е. Причината да гърми проверката е, че не намира
main
функцията в пакетаmain
а, виеmain
функция във вашите домашни не трябва да пишете.Тъй като издънката е от наша страна, срокът за предаване ще бъде удължен ;)
@Кирил, да напишем по една празна
main
функция ?Не, в никакъв случай. Вече можете да пращате решения и всичко би трябвало да е наред. Удължаваме срока до четвъртък.
GRB и GRBA приемливи формати ли са? Дейвид е казал само RGB, BRG, RGBA и BRGA, но според тестовете на Недялко и GRB и GRBA са приемливи и Киро каза, че са адекватни.
Както обещах, ето и малко тестове от мен. Всъщност не ми хрумна много какво да добавям, освен проверки на закръглянето при изчисляването на цвета след alpha.
Чакайте, чакайте! Защо се реши, че е правилно да се floor-ва? Ни най - малко. До колкото разбирам ние тук се опитваме да правим premultiplied alpha composition. Не е съвсем ясно, но ми се струва, че е по - правилно да се закръглява към по - близкото цяло число. Най - правилно би било да използваме float, но тъй като не го правим следва поне да се опитаме да сме най - близо до истината.
Ето този човек го е обяснил сравнително добре. Идеята е, че с по - хубаво закръгляване ще губим по - малко информация за оригиналния цвят. С floor най - голямата потенциална грешка ще е от 0.999.., а със закръгляне до най - близкото число: 0.5. След много операции това ще има съществено значение.
Тъй като за това не пише нищо в условието ще смятам закръглянето към най - близкото число за единствения правилен начин. Независимо как го е решил Дейвид.
Радвам се, че си активен и че си изразяваш мнението но изглежда не си разбрал идеята.
- Прав си, правите premultiplied alpha composition. И също така, нарочно не съм излял тонове излишна теория а само нужното за решаване на задачата.
- Условията се състоят от 3 части (описание, пример, примерни тестове) комбинирано те съдържат достатъчно информация.
- Прав си, че закръгляне до най - близкото число е по-коректно но за целта на нашата задача, както вече казах се използва floor (и тестовете разчитат на това).
Съжалявам, че отклоних темата от въпроса на @Мария. Моето разбиране е, че всяка пермутаця на множествата {R,G,B} и {R,G,B,A} е верен формат.
@Дейвид, ще се опитам да ти обясня какво ме притеснява в случая. За целта ще използвам точките ти в разбъркан ред. Заради особености в markdown реда е още по - разбъркан.
-
Нека разгледаме трите части.
- Описание - не се споменава нищо за закръгляне
- Пример - нищо за закръгляне
- Примерни тестове - нищо свързано със закръгляне. Т.е. по - правилното закръгляне минава всички примерни тестове.
Стигнал съм до моя извод как трябва да се справя със закръглянето въз основна на нещата изброени в точка 2. плюс малко четене за алфа канали. Изглежда съм прав в извода си.
Ще сменя решението и тестовете ми в github с floor закръгляне, защото в крайна сметка вие определяте правилата. А и коментарите ви във форума могат да се смятат за част от описанието на задачата.
Сега, ето го проблема ми. До колкото разбирам идеята на задачите е с необходимата информация да стигнем до възможно най - хубавото решение. Тук не се оценява само знанието ни по Go, нали? Все пак преподавате неща като "как работи операционната система" и култура на тестове и документация. Изхождайки от това си разбиране отделих малко време за да разбера как най - добре да се справя с единствената интересна част на задачата. Ако не бях минал случайно през тази тема във форума щях да бъда наказан за това отделено време т.к. предадох задачата си много преди тук да се спомене закръгляне. Това ме поставя в позиция, в която ще трябва да питам вас за всяко едно свое решение, независимо колко правилно ми се струва.Тала решаването на задачите става доста скучно. Нека започна тогава.
Трябва ли метода Color() на Pixel да връща тип, който да е специално представляващ цвят? Трябва ли този тип да има точно определено име? Например Colour или Color? Т.к. Pixel не съдържа в себе си нищо друго освен цвят, то за мен Pixel е структурата представляваща цвят. Съответно единственото, което прави метода Color() е да връща собствения си receiver. Това приемливо ли е? Трябва ли да създада още една (излишна) структура, която да е единственото поле на Pixel или може би Pixel да "наследява" този тип и Color() само да cast-ва? Има ли нещо такова в тестовете? Има ли значение за вас как ще го направя?
Има ли значение дали методите ни връщат указатели или обекти? Това има ли го в тестовете?
Какво да правим когато Alpha е 0? Например в RGBA формат за пиксел (12,0,24,0) трябва да връщаме (Red, Green, Blue) -> (12,0,24) или (0,0,0)? Наивен алгоритъм, който само умножава би върнал три нули, но това ми се струва грешно. Така ще загубим информация за пиксела. И двата варианта ще докарат един и същи резултат след налгане върху фон, но единия "помни" повече. Ако например този пиксел е част от layer в многослойна картина и просто за известно време този layer е направен прозрачен, то не искаме да губим цялата информация за него, нали?
-
Трябва да сте влезли в системата, за да може да отговаряте на теми.