Извините, но в аналогиях математики это похоже на «мне непонятен смысл учиться доказывать теоремы: нужна теорема — посмотри доказательство в интернете».
Смысл элементарен: не под всё есть алгоритмы. Да вот элементарнейшая задача: массив линий, из которых состоит произвольный многоугольник, посчитать boundbox многоугольника. Насколько могу судить, это не похоже ни на разновидность поиска, ни сортировки. Возможно, среди алгоритмов компьютерной графики найдётся что-нибудь такое… Но чёрт, зачем? Зачем, если абсолютно очевидно, как это делается?
Очевидно человеку, умеющему разрабатывать алгоритмы. Очевидно, наверное, человеку, глубоко овладевшим классическими — стоит заметить, это элементарная задача для умеющего разрабатывать.
По большому счёту, вся разработка состоит из создания разной сложности и разного рода алгоритмов. А покажите мне алгоритм, например, побуквенного парсинга XML или JSON… А он относится к классическим?
А сможет ли такой алгоритм написать человек, умеющий создавать алгоритмы? А человек, знакомый с классическими алгоритмами?
Правильное мнение — то, которое принесёт наилучший результат. В данном случае.
Не проводил. Но зато (а) я предполагаю, что составители учебной программы в Стенфорде лучше нас с вами знают, как учить людей алгоритмам, и (б) у меня есть педагогическое образование (в другой области), которое с ними соглашается.
Не отрицаю, что вы можете быть правы. Даже не пытаюсь вас убедить. Просто делюсь своим мнением.
То, что конкретно у вас вышло так, не означает ни того, что другим так удобно, ни даже того, что если бы вас учили в другой последовательности, вышло бы хуже.
Ах да, знаком со множеством людей, одни из которых следовали одному варианту, другие — другому. Но тут очень сложно что-то сказать объективно: как правило, люди, освоившие сначала создание своих алгоритмов, а уже потом — классические алгоритмы, разработкой именно увлекаются, и неудивительно, что их уровень на порядок (а то и не на один) выше.
Выучить язык можно на практических задачах. А написание (не важно, самостоятельное, или нет) алгоритмов, во-первых, не связано с языком, а во-вторых, как раз требует добротного владения тем языком, на котором человек пишет. Что хуже, когда человек плохо владеет языком, а его еще и просят придумать, как решить не самую тривиальную задачу, он одновременно путается и в одном, и в другом.
Возможно. Если честно, с этой стороны я не смотрел: мне совершенно непонятен смысл алгоритмов (не общечеловеческих или математических, а именно тех же алгоритмов поиска, сортировки и т.п.) в отрыве от программирования и практики.
Впрочем, сейчас большинство предметов преподаются точно также, математика, например.
Иными словами, обучение конкретному языку программирования — это один курс. Обучение алгоритмам — другой курс. Смешивать их не стоит.
У меня большой соблазн упомянуть Кнута :). Хоть это и не совсем верно.
Этого недостаточно: нужно, чтобы они имели ещё и правильное мнение.
Ну и, вообще говоря, странно выглядит наш спор: я, да и вы, подозреваю, тоже, не проводили каких-либо опытов, чтобы иметь возможность на их основе оценить, какой вариант лучше. Возможно, вы знаете два каких-либо университета, в которых именно это изучают по-разному, при прочих равных (т.к. сравнивать, например, Стэнфорд с вузом из российской глубинки — явно некорректно)? Я не знаю, так что возможностей сравнить у меня нет.
Но, тем не менее, своё мнение у меня сложилось на основе того, как знакомился с этим я. Ну а я научился создавать алгоритмы задолго до того, как познакомился с большинством классических. Я тогда не знал, что такое, например, бинарный поиск, зато спокойно мог создать и написать, скажем, алгоритм поиска подстроки в строке, алгоритм поиска в дереве, алгоритм создания бинарного дерева из массива (если бы мне объяснили, конечно, что такое бинарное дерево, что, впрочем, элементарно). Возможно, не самый быстрый и эффективный, зато свой и сходу.
Возможно, поэтому, когда я знакомился с классическими алгоритмами, каких-то больших трудностей не возникало. Именно поэтому я поддерживаю эту идею. Потому что нужно сначала выучить язык, а не сходу переводить на нём тексты.
Можно спокойно найти 20 авторитетов, мнения которых будут не совпадать. Кто-то из них точно ошибётся.
А весь Стэнфорд придерживается единого мнения? Вплоть до человека?
Поддержу. Начинать стоит с создания собственных алгоритмов. Изучили язык, познакомились с массивами и прочим… Ставим задачу поиска. Как бы вы искали в массиве? А можно ли придумать более быстрый способ? А если данные отсортированы? И т.п.
Кстати, с математикой точно также, только там теоремы, а не алгоритмы.
Помнится, лет 6 назад, ещё во времена IE6, была у меня толстая книжка, взятая в библиотеке — по HTML 4.1 и CSS 2 (с хвостиком, 2.3 что ли, или как там).
Как ни странно, большинство ответов (border-style, селектор, visibility, @ charset, oblique...) — просто вспоминал оттуда.
До некоторых можно просто догадаться: все единицы кроме ems знакомы.
Кстати говоря, понимание 4 измерения как времени, в котором мы можем передвигаться, даёт вполне простое и интуитивное понимание 4-мерного пространства. Точнее, даже не времени, можно просто не пытаться проецировать четырёхмерное пространство на трёхмерное, которое проецируется на двухмерное, а рассматривать трёхмерные проекции четырёхмерного пространства: так вполне можно понять даже какой-нибудь сложный четырёхмерный объект и выше (да хоть двенадцати, если в уме уместить все проекции получится)…
В данном случае у нас кубик Рубика, меняя одну проекцию которого, мы меняем и остальные. Правда, представить алгоритм сборки такого человеку, не знакомому с алгоритмом сборки трёхмерного — очень страшно.
Ну да: достаточно сделать массив элементов в Rat, и в функциях Rat.prototype.path, image, text, пушать элемент в массив. Можно даже и сам Rat от массива унаследовать. Дальше будет обработка событий, и я, возможно, приду к чему-нибудь подобному.
Такой подход я реализовал в, собственно, Graphics2D ( Github ), а Rat — чисто поиграть-поэкспериментировать, что уложится в 100 строк :).
В G2D всё то же самое реализуется таким кодом:
var path = ctx.path([
// можно точно так же указывать функции ( ['lineTo', x, y] )
[10, 10], // но по умолчанию -- 2 аргумента => lineTo
[100, 100], // а в первом -- moveTo
[10, 100],
true // closePath
], 'red', 'green 4px');
var img = ctx.image('image.jpg', x, y);
var circle = new createjs.Shape();
circle.graphics.beginFill("DeepSkyBlue").drawCircle(0, 0, 50);
circle.x = 100;
circle.y = 100;
stage.addChild(circle);
Может быть, это и удобно. Но… моё чувство эстетики (эстетичности? как правильно?) всеми руками протестует против чеининга свойств контекста:
// зачем делать так??
context.fillStyle('red').fillRect(10, 10, 200, 200);
// когда можно вот так?
context.fillRect(10, 10, 200, 200, 'red');
И при этом в каком-то виде возможна реализация ООП, и соблюдается «чистота» — свойства ранее отрисованных объектов не переползают на позднее рисуемые.
Ну да, картинка же рисуется по событию onload, которое случается после основного потока… Поэтому она окажется нарисована позже (и выше, соответственно). Если вы об этом.
var path = rat.path([
['moveTo', 10, 10],
['lineTo', 100, 100],
['lineTo', 10, 100],
['closePath']
], {
fillStyle: 'red',
strokeStyle: 'green',
lineWidth: 4
});
var img = new Image();
img.src = "image.jpg";
img.onload = function(){
img = rat.image(img);
path.draw(); // внимание сюда
}
Да, про данные подумал не сразу. Но, в целом, можно и data-ориентированный код на чистом 2dcontext писать, разница есть, но не сильно заметная. Ну, мне так кажется, очень надеюсь, что я ошибаюсь.
В любом случае, именно на этих объектах будут строиться следующие части статьи.
Про добавление своих функций отрисовки чуть-чуть не понял, имеется в виду что-то подобное?:
var rect = rat.rect([10, 10, 200, 200], {
fillStyle: 'red'
});
В том, что получится пара десятков оттенков, и придётся извращаться как в посте.
Да и не совсем очевидно, что краснее — тыквенно-красный или апельсиново-красный, например. А так сразу видно, что к какому цвету ближе. Знающему человеку, естественно.
Так мы снова пришли к понимать vs запоминать, только уже с другой стороны.
Транспортир гораздо более очевиден :).
Мысленное деление пополам: нижняя точка — 180 градусов, дальше прибавляем четверть: 270, вот у нас и есть примерный цвет. В данном случае: 285 градусов это между красным и синим, причём ближе к синему…
Вот и получили человеческое описание hsl-цвета.
Это не QR-коды вручную расшифровывать, тут и в уме можно.
Просто hsl вовсе не различимы человеком, в частности, hue. Я хотел сказать именно об этом.
А вообще, если сильно хочется, можно представить цветовой круг, красный, синий и зелёный, между ними — смеси, отмерить на нём 285 градусов и примерно предположить. Но это неочевидно.
Смысл элементарен: не под всё есть алгоритмы. Да вот элементарнейшая задача: массив линий, из которых состоит произвольный многоугольник, посчитать boundbox многоугольника. Насколько могу судить, это не похоже ни на разновидность поиска, ни сортировки. Возможно, среди алгоритмов компьютерной графики найдётся что-нибудь такое… Но чёрт, зачем? Зачем, если абсолютно очевидно, как это делается?
Очевидно человеку, умеющему разрабатывать алгоритмы. Очевидно, наверное, человеку, глубоко овладевшим классическими — стоит заметить, это элементарная задача для умеющего разрабатывать.
По большому счёту, вся разработка состоит из создания разной сложности и разного рода алгоритмов. А покажите мне алгоритм, например, побуквенного парсинга XML или JSON… А он относится к классическим?
А сможет ли такой алгоритм написать человек, умеющий создавать алгоритмы? А человек, знакомый с классическими алгоритмами?
Разве я где-то ошибаюсь?
Правильное мнение — то, которое принесёт наилучший результат. В данном случае.
Не отрицаю, что вы можете быть правы. Даже не пытаюсь вас убедить. Просто делюсь своим мнением.
Ах да, знаком со множеством людей, одни из которых следовали одному варианту, другие — другому. Но тут очень сложно что-то сказать объективно: как правило, люди, освоившие сначала создание своих алгоритмов, а уже потом — классические алгоритмы, разработкой именно увлекаются, и неудивительно, что их уровень на порядок (а то и не на один) выше.
Возможно. Если честно, с этой стороны я не смотрел: мне совершенно непонятен смысл алгоритмов (не общечеловеческих или математических, а именно тех же алгоритмов поиска, сортировки и т.п.) в отрыве от программирования и практики.
Впрочем, сейчас большинство предметов преподаются точно также, математика, например.
У меня большой соблазн упомянуть Кнута :). Хоть это и не совсем верно.
Ну и, вообще говоря, странно выглядит наш спор: я, да и вы, подозреваю, тоже, не проводили каких-либо опытов, чтобы иметь возможность на их основе оценить, какой вариант лучше. Возможно, вы знаете два каких-либо университета, в которых именно это изучают по-разному, при прочих равных (т.к. сравнивать, например, Стэнфорд с вузом из российской глубинки — явно некорректно)? Я не знаю, так что возможностей сравнить у меня нет.
Но, тем не менее, своё мнение у меня сложилось на основе того, как знакомился с этим я. Ну а я научился создавать алгоритмы задолго до того, как познакомился с большинством классических. Я тогда не знал, что такое, например, бинарный поиск, зато спокойно мог создать и написать, скажем, алгоритм поиска подстроки в строке, алгоритм поиска в дереве, алгоритм создания бинарного дерева из массива (если бы мне объяснили, конечно, что такое бинарное дерево, что, впрочем, элементарно). Возможно, не самый быстрый и эффективный, зато свой и сходу.
Возможно, поэтому, когда я знакомился с классическими алгоритмами, каких-то больших трудностей не возникало. Именно поэтому я поддерживаю эту идею. Потому что нужно сначала выучить язык, а не сходу переводить на нём тексты.
А весь Стэнфорд придерживается единого мнения? Вплоть до человека?
Поддержу. Начинать стоит с создания собственных алгоритмов. Изучили язык, познакомились с массивами и прочим… Ставим задачу поиска. Как бы вы искали в массиве? А можно ли придумать более быстрый способ? А если данные отсортированы? И т.п.
Кстати, с математикой точно также, только там теоремы, а не алгоритмы.
А это точно от слова «ровный»?
Как ни странно, большинство ответов (border-style, селектор, visibility, @ charset, oblique...) — просто вспоминал оттуда.
До некоторых можно просто догадаться: все единицы кроме ems знакомы.
В данном случае у нас кубик Рубика, меняя одну проекцию которого, мы меняем и остальные. Правда, представить алгоритм сборки такого человеку, не знакомому с алгоритмом сборки трёхмерного — очень страшно.
Такой подход я реализовал в, собственно, Graphics2D ( Github ), а Rat — чисто поиграть-поэкспериментировать, что уложится в 100 строк :).
В G2D всё то же самое реализуется таким кодом:
Всё перерисовывается, обрабатывается и т.п.
Может быть, это и удобно. Но… моё чувство эстетики (эстетичности? как правильно?) всеми руками протестует против чеининга свойств контекста:
И при этом в каком-то виде возможна реализация ООП, и соблюдается «чистота» — свойства ранее отрисованных объектов не переползают на позднее рисуемые.
На первой опечатке ненадолго завис, но в итоге смысл понял, вторая просто незаметна.
В любом случае, именно на этих объектах будут строиться следующие части статьи.
Про добавление своих функций отрисовки чуть-чуть не понял, имеется в виду что-то подобное?:
Вот это как раз про композицию.
Да и не совсем очевидно, что краснее — тыквенно-красный или апельсиново-красный, например. А так сразу видно, что к какому цвету ближе. Знающему человеку, естественно.
Так мы снова пришли к понимать vs запоминать, только уже с другой стороны.
Мысленное деление пополам: нижняя точка — 180 градусов, дальше прибавляем четверть: 270, вот у нас и есть примерный цвет. В данном случае: 285 градусов это между красным и синим, причём ближе к синему…
Вот и получили человеческое описание hsl-цвета.
Это не QR-коды вручную расшифровывать, тут и в уме можно.
А вообще, если сильно хочется, можно представить цветовой круг, красный, синий и зелёный, между ними — смеси, отмерить на нём 285 градусов и примерно предположить. Но это неочевидно.