Duplicate argument

Програмиране с Go

Курс във Факултета по Математика и Информатика към СУ

Втора задача

  5. 1: Стойността nil е свързана с бъдещо предизвикателство и не е част от задачата. Прост изтрии този аргумент аз ще оправя условието.

    2: В условието се казва, че когато е даден алфа канал другите трябва да се умножът по него за да се нормализират. Ако умножиш 255 по 255 няма да получиш числе [0 - 255] => ако представиш цветовете, като числа между 0 - 1 ще е по лесно.

  7. Отчайващо описание на условието. Подозирам, че разбирането му ще е много по трудно от самата задача. Що за изречение е "Представяйте за данни всеки цвят като число между 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)?

    Моя съвет: влагайте в писането на задачите поне време, колкото толкова накрая да няма грешки и каквито и да е правописни на българския език. Това много ще улесни разбирането им. След това питайте някой външен човек дали ги разбира.

  9. Позволили сме си да не описваме подробно какво значат буквичките, основавайки се на RGB модела и неговото разширение RGBA. Все пак беше добра идея да има линк към тях в условието.

    Иначе самият Format е string, което се вижда от example-а и от примерните тестове.

    Какво да правим, когато данните са непълни ({1}) или неверни ({456732, 231, 234567, -1})?

    Очаквате винаги коректен вход, ако не е указано изрично обратното.

    Задължително ли е когато викаме println върху типа за цвят той да се печата точно както е показано в примера (Red: 0, Green: 12, Blue: 244)?

    Да.

    Иначе point taken за местата, в които сме демонстрирали дислексия. Ако има неяснотии из условието, можеш да мяташ око на примерния тест, ако все още имаш неяснотии - ни храниш :)

    1. Съжалявам за неточности в условието (откъм изразяване) но идеята е то да имитира спецификация(която по принцип не е достатъчно прецизна). Идеята е да започнете да ползвате примерите и примерните тестове за източник на информация (а условието само за насоки).
    2. Приемливи формати са RGB, BGR, RGBA, BGRA

  11. Аз имам два бързи въпроса:

    1. На къде искате да round-ваме числата ? Ceil, Floor, или математическо (в зависимост от десетичната стойност), понеже гледам че кастването взима Floor-а (което е логично да направи). Та какво да правим ние?

    2. В InspectPixel(a,b) a и b са координатите x и y , нали ? Тоест a === x === columns && b === y === rows ?

  16. Да сме напълно точни 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)
    }
}

    или се бъркам?

  19. Последно като гледах темата, имаше пост на Дейвид, в който пишеше, че трябва да приложим научения материал от лекцията за Error Handling в задачата, но сега сякаш не мога да го намеря или е редактиран.

    Искам да питам дали трябва да осъществяваме проверка за грешен вход, например неточен формат, масив с неправилна дължина или колона и ред, извън рамките на изображението, или съм сънувал този пост :smile:

  21. @Александър, действително постът беше такъв преди, но след това го редактираха. Питах на лекции дали трябва да проверяваме за грешен вход и ми отговориха, че не трябва и разчитаме на коректен вход.

  24. Да, проблем в evans е. Причината да гърми проверката е, че не намира main функцията в пакета mainа, вие main функция във вашите домашни не трябва да пишете.

    Тъй като издънката е от наша страна, срокът за предаване ще бъде удължен ;)

  29. Чакайте, чакайте! Защо се реши, че е правилно да се floor-ва? Ни най - малко. До колкото разбирам ние тук се опитваме да правим premultiplied alpha composition. Не е съвсем ясно, но ми се струва, че е по - правилно да се закръглява към по - близкото цяло число. Най - правилно би било да използваме float, но тъй като не го правим следва поне да се опитаме да сме най - близо до истината.

    Ето този човек го е обяснил сравнително добре. Идеята е, че с по - хубаво закръгляване ще губим по - малко информация за оригиналния цвят. С floor най - голямата потенциална грешка ще е от 0.999.., а със закръгляне до най - близкото число: 0.5. След много операции това ще има съществено значение.

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

  30. Радвам се, че си активен и че си изразяваш мнението но изглежда не си разбрал идеята.

    1. Прав си, правите premultiplied alpha composition. И също така, нарочно не съм излял тонове излишна теория а само нужното за решаване на задачата.
    2. Условията се състоят от 3 части (описание, пример, примерни тестове) комбинирано те съдържат достатъчно информация.
    3. Прав си, че закръгляне до най - близкото число е по-коректно но за целта на нашата задача, както вече казах се използва floor (и тестовете разчитат на това).

  31. Съжалявам, че отклоних темата от въпроса на @Мария. Моето разбиране е, че всяка пермутаця на множествата {R,G,B} и {R,G,B,A} е верен формат.

    @Дейвид, ще се опитам да ти обясня какво ме притеснява в случая. За целта ще използвам точките ти в разбъркан ред. Заради особености в markdown реда е още по - разбъркан.

    1. Нека разгледаме трите части.

      • Описание - не се споменава нищо за закръгляне
      • Пример - нищо за закръгляне
      • Примерни тестове - нищо свързано със закръгляне. Т.е. по - правилното закръгляне минава всички примерни тестове.

    2. Стигнал съм до моя извод как трябва да се справя със закръглянето въз основна на нещата изброени в точка 2. плюс малко четене за алфа канали. Изглежда съм прав в извода си.

    3. Ще сменя решението и тестовете ми в 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 е направен прозрачен, то не искаме да губим цялата информация за него, нали?

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