Здравствуйте, Кодт, Вы писали:

К>К слову сказать, транспонирование неквадратной матрицы, размещённой в непрерывном массиве, — это очень нетривиальная перестановка. Тут swap'ами нахаляву не отделаешься.

Вроде как небольшими квадратиками это делается. Поправте.

Здравствуйте, vadimcher, Вы писали:

К>>Кто-нибудь делал попытку красиво визуализировать это дело? Типа множества Мандельброта или странного аттрактора Лоренца?

V>А как именно? Циклы на матрице рисовать?

Ну я не знаю, ну например, функция количества или длины циклов от размера (N,M) матрицы.
Или длина какого-нибудь "характерного" цикла (например, вовлекающего клетку (1,2) или (1,N)).
Раз она нерегулярна, то могут появляться загадочные узоры.

Здравствуйте, minorlogic, Вы писали:

M>Здравствуйте, Кодт, Вы писали:

К>>К слову сказать, транспонирование неквадратной матрицы, размещённой в непрерывном массиве, — это очень нетривиальная перестановка. Тут swap'ами нахаляву не отделаешься.

M>Вроде как небольшими квадратиками это делается. Поправте.

Это я не знаю. Там идея такая: допустим ты матрицу задаешь линейно, только отмечаешь число элементов в строке. Например, матрицу

0 1 2
3 4 5

можно задать как { 3, { 0 1 2 3 4 5 } }, первое число означает, что в каждой строке по 3 элемента, а дальше идут элементы по строкам.
При транспонировании эта матрица превратится в
{ 2, { 0 3 1 4 2 5 } }

Можно, конечно, выделить память под новую матрицу, и туда легко все по столбцам переписать. Но возникает вопрос, а что если умудриться без дополнительной памяти переписать матрицу на том же месте. Элемент 0 имеет координаты (0,0), он там и останется. Элемент 1 имеет координаты (0,1), перейдет в (1,0), это будет третье место по порядку, т.е. перейдет на место цифры 2. Чтобы 1 туда записать, надо посмотреть, куда перейдет 2 -- на место 4 (из координат (0,2) в (2,0)). 4 -- на место 3, 3 -- на место 1. Т.е. у нас 3 цикла. Два из них длины 1 -- которые есть всегда -- первый и последний остаются на месте, а один переставляет все остальные по циклу. В общем случае, эффективного алгоритма, как все это делать, не найдено.

Здравствуйте, Sergey Chadov, Вы писали:

SC>Даже во времена раннего С++ для работы с матрицами не изобретали велосипед, а использовали BLAS.

Тьфу на Вас еще раз! Какой к богу велосипед ? Создание массива под type**, хоть прямоугольного, хоть треугольного, хоть ступенчатого — один из банальных примеров любого приличного учебника по С (даже не С++)

type** p = new type[n];
for ( i = 0; i < n; i++)
p[i] = new type[m];

На чистом С заменить new на malloc. Ну и type замените на конкретный тип.

Удаление сам напишешь ?

Это намного сложнее, чем описание

type a[M][N]; // естественно, что M и N в данном случае константы

?

>Реализацией которого(сюрприз, сюрприз) и является boost::ublas. Так что, не будь это лабораторной работой, это было бы вполне оправдано хотя бы из-за того, что используется де-факто стандартный интерфейс.

Ай-яй-яй. Уж никак без каких-то стандартных интерфейсов не обойтись, когда можно 3 строки написать! Скоро будем стандартные интерфейсы искать для реализации условного оператора, если так дальше пойдет. Совсем уж разучились простые вещи делать!

Здравствуйте, ilvi, Вы писали:

I>Скоро можно будет на собеседовании у разработчика по с++ с 5 летним и более стажем задавать вопрос на засыпку, определяющий уровень ЗП:
I>как задать матрицу произвольного размера без буста

Скоро у разработчиков со стажем менее 5 лет нельзя будет этот вопрос задавать, потому что никто из них на него не ответит

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Скоро у разработчиков со стажем менее 5 лет нельзя будет этот вопрос задавать, потому что никто из них на него не ответит

Ну ты же ответишь?
Я ответишь и т. д...

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>type** p = new type[n];
PD>for ( i = 0; i < n; i++)
PD> p[i] = new type[m];

PD>Удаление сам напишешь ?

Тему-то топикстратер создал, так что он/она её наверное читает...
Так, что, IMHO, для С++ надо что-то вроде

std::vector< std::vector<type> > arr( n, std::vector<type>( m ) );

советовать...

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>Скоро у разработчиков со стажем менее 5 лет нельзя будет этот вопрос задавать, потому что никто из них на него не ответит

E>Ну ты же ответишь?

А у меня стаж не менее 5 лет, а порядком побольше.

E>Я ответишь и т. д...

И у тебя, я полагаю, тоже

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>type** p = new type[n];
PD>>for ( i = 0; i < n; i++)
PD>> p[i] = new type[m];

PD>>Удаление сам напишешь ?

E>Тему-то топикстратер создал, так что он/она её наверное читает...
E>Так, что, IMHO, для С++ надо что-то вроде

std::vector< std::vector<type> > arr( n, std::vector<type>( m ) );

советовать...

Егор, ты вообще отдаешь себе отчет, о чем речь-то идет ? Некая девушка, скорее всего из начинающих или вообще к программированию отношения не имеющих, задает вопрос о довольно простом действии, которое есть в любом учебнике. А то, что ты предлагаешь, предполагает как минимум знание STL (а чтобы с STL работать, надо все же язык знать не на уровне начинающих — это раз, и саму STL — это два). Она скорее всего не только vector от list не отличает, но и не знает, чем vector отличается от массива

Здравствуйте, Erop, Вы писали:

E>Так, что, IMHO, для С++ надо что-то вроде

std::vector< std::vector<type> > arr( n, std::vector<type>( m ) );

советовать...

Я думаю, что такие советы надо давать людям, которые уже представляют, что такое массив и как его готовить. Т.е. прежде чем учить человека высокоуровневым вещам, надо научить человека низкоуровневым. Чтобы не было пробелов в знаниях. И чтобы при разработке человек делал осознаный выбор в пользу тех или иных инструментов, зная что стоит за ними и как они хотябы примерно устроены, а не просто руководствовался советом с форума, не понимая его сути. Я не против использования boost или stl, я против их использования людьми, которые "не знают массивов".

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Егор, ты вообще отдаешь себе отчет, о чем речь-то идет ? Некая девушка, скорее всего из начинающих или вообще к программированию отношения не имеющих, задает вопрос о довольно простом действии, которое есть в любом учебнике. А то, что ты предлагаешь, предполагает как минимум знание STL (а чтобы с STL работать, надо все же язык знать не на уровне начинающих — это раз, и саму STL — это два). Она скорее всего не только vector от list не отличает, но и не знает, чем vector отличается от массива

Чтобы работать с вектором ничего такого знать не надо...

Здравствуйте, ilvi, Вы писали:

I>Я думаю, что такие советы надо давать людям, которые уже представляют, что такое массив и как его готовить. Т.е. прежде чем учить человека высокоуровневым вещам, надо научить человека низкоуровневым. Чтобы не было пробелов в знаниях. И чтобы при разработке человек делал осознаный выбор в пользу тех или иных инструментов, зная что стоит за ними и как они хотябы примерно устроены, а не просто руководствовался советом с форума, не понимая его сути. Я не против использования boost или stl, я против их использования людьми, которые "не знают массивов".

Это зависит от целей обучения. Вообще-то я думаю, что топикстартер не знает про программирование почти ничего. И чтобы научиться программировать хорошо бы писать программы в каком-то более дружелюбном окружении, чем голый С...

Вот когда матрицу транспонировать научишься и двухпутевое слияние освоишь, вот тогда можно и подробностями реализации заняться...

С другой стороны, не понятно где граница. Почему ты считаешь, что "основы" -- это сишные массивы, а не асм, там, или особенности архитектуры проца или КЭД...

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>А у меня стаж не менее 5 лет, а порядком побольше.
PD>И у тебя, я полагаю, тоже

Эх, не так я как-то тезис распарсил...

Здравствуйте, Erop, Вы писали:

E>Чтобы работать с вектором ничего такого знать не надо...

Чтобы работать с чем угодно, надо понимать, что это такое — если не хочешь работать с ним как обезьяна с компьютером.

Здравствуйте, ilvi, Вы писали:

I>Я думаю, что такие советы надо давать людям, которые уже представляют, что такое массив и как его готовить. Т.е. прежде чем учить человека высокоуровневым вещам, надо научить человека низкоуровневым. Чтобы не было пробелов в знаниях. И чтобы при разработке человек делал осознаный выбор в пользу тех или иных инструментов, зная что стоит за ними и как они хотябы примерно устроены, а не просто руководствовался советом с форума, не понимая его сути. Я не против использования boost или stl, я против их использования людьми, которые "не знают массивов".

Полностью присоединяюсь.

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, ilvi, Вы писали:

I>>которые "не знают массивов".

E>С другой стороны, не понятно где граница. Почему ты считаешь, что "основы" -- это сишные массивы, а не асм, там, или особенности архитектуры проца или КЭД...

А я и не считаю, что они основы, поэтому и взял в кавычки ту фразу. Для меня они входят в основы По моему мнению это та часть, через которую человек пишущий на си должен пройти. Пусть у него не будет получаться, будут утечки памяти, аксес виолейшины и всякий мусор в данных, но хотя бы будет знать зачем нужен этот вектор, каких проблем он помагает избежать. Он будет знать "почему", а не только "как". Для меня это очень важное качество в программисте. Когда я забредаю на неведомую мне територию в програмировании и приходится писать руководствуясь только "как", меня всего коробит, потому что я не знаю сайд эффектов написаного мной.

А асм и особенности архитектуры тоже пригодятся, но это будет наверное уже после boost и stl

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Чтобы работать с чем угодно, надо понимать, что это такое — если не хочешь работать с ним как обезьяна с компьютером.

Как работают с компьютером обезьяны я не знаю, а как работают с кодом люди, которые программировать только учатся -- знаю.
Ты же, когда учишь студентов, наверное cin cout используешь, не вдаваясь в подробности их реализации? Если так, что чем vector хуже?

IMHO, понятие "массив" оно довольно таки простое. И довольно таки высокоуровневое. И если воспринимать std::vector, как реализацию этого понятия, не вдаваясь в подробности, и не пользуясь итераторами и прочими особенностями STL, то им вполне можно пользоваться В УЧЕБНЫХ ЦЕЛЯХ во всяком случае.
IMHO, вообще С++ не самый удачный язык для обучения программированию. Лично мне ближе PASCAL, но мне лень его подробно вспоминать ради тех относительно редких в моей практике случаев, когда приходится кого-то учить программированию с 0...

Здравствуйте, ilvi, Вы писали:

I>А асм и особенности архитектуры тоже пригодятся, но это будет наверное уже после boost и stl
Ну я в целом согласен, со всем тобой написанным, но, IMHO, если человек не умеет транспонировать матрицу, то ему рано учиться программировать на С, надо сначала просто "учиться программировать"...

А потом уже, когда будешь понимать что такое структуры данных, алгоритмы, как пишется программа, как она работает, тогда уже пора переходить к "программировать на С", ну и далее я с тобой согласен уже...

Здравствуйте, Erop, Вы писали:

[scip]
E>Ну я в целом согласен, со всем тобой написанным, но, IMHO, если человек не умеет транспонировать матрицу, то ему рано учиться программировать на С, надо сначала просто "учиться программировать"...
Если человек не понимает, что такое транспонирование матрицы, желательно вначале вспомнить, а что это вообще такое, транспонировать пару матриц на листике, понять, как меняются индексы. И только потом, когда человек будет хорошо понимать, что такое транспонирование (а не просто цитировать по памяти куски конспекта и известных людей), можно переходить к формальному алгоритму, пусть даже записанному на языке "это туда, а это сюда" (для некоторых людей так просто может быть понятее)
E>А потом уже, когда будешь понимать что такое структуры данных, алгоритмы, как пишется программа, как она работает, тогда уже пора переходить к "программировать на С", ну и далее я с тобой согласен уже...
А это можно учить паралельно.
И когда обе части созреют, можно соединять.
Хотя иногда бывает и наоборот. и достаточно успешно...

Здравствуйте, Erop, Вы писали:

E>Ты же, когда учишь студентов, наверное cin cout используешь, не вдаваясь в подробности их реализации? Если так, что чем vector хуже?

Не угадал. Я их Win32 учу. А там нет классов

E>IMHO, понятие "массив" оно довольно таки простое. И довольно таки высокоуровневое. И если воспринимать std::vector, как реализацию этого понятия, не вдаваясь в подробности, и не пользуясь итераторами и прочими особенностями STL, то им вполне можно пользоваться В УЧЕБНЫХ ЦЕЛЯХ во всяком случае.

Можно, но это кончится тем. что они тот код, что я привел, написать не смогут, и char* от char** отличать не будут...

E>IMHO, вообще С++ не самый удачный язык для обучения программированию. Лично мне ближе PASCAL,

+5. Мы и начинаем с Паскаля, на 1 курсе. C/C++ на 2-м.