powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / C++ [игнор отключен] [закрыт для гостей] / Матрицы, позднее связывание, и другое
22 сообщений из 72, страница 3 из 3
Матрицы, позднее связывание, и другое
    #39113024
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SashaMercuryа как же погрешность описываемая в стандарте, e: 1.0+e=1.0. Или она тоже везде будет одинакова ?
Сравню по времени в таком случае.
Я понимаю то о чём вы говорите, правда. Спасибо :)
Ты когда говоришь о т.н. "стандартах" - то уточняй о каком из них. Мы уже говорим про
стандарт на числа плавающей точности?
...
Рейтинг: 0 / 0
Матрицы, позднее связывание, и другое
    #39113672
Фотография SashaMercury
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maytonSashaMercuryа как же погрешность описываемая в стандарте, e: 1.0+e=1.0. Или она тоже везде будет одинакова ?
Сравню по времени в таком случае.
Я понимаю то о чём вы говорите, правда. Спасибо :)
Ты когда говоришь о т.н. "стандартах" - то уточняй о каком из них. Мы уже говорим про
стандарт на числа плавающей точности?

Нет, я говорю о стандарте Си, например, в котором содержится информации об той самой e:1=1+e, и другая вспомогательная информация по работе с числами двойной точности
...
Рейтинг: 0 / 0
Матрицы, позднее связывание, и другое
    #39113675
Фотография SashaMercury
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SashaMercury Реализую первый вариант, предложенный Дмитрием.


Всё-таки этот вариант не самый хороший. Например, в базовом классе M мы определим операцию умножения матриц, но результатом такой операции может быть как прямоугольная матрица M так и квадратная S_M. Вернулся к тому что было
...
Рейтинг: 0 / 0
Матрицы, позднее связывание, и другое
    #39113680
Фотография SashaMercury
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Фабрика - это ведь использование обычного базового абстрактного класса!
Я про это и думал когда писал топик, но не мог понять как правильно его использовать. А мне все стали про паттерны писать, и я думаю почему никто не говорит про базовый абстрактный класс в основе. Сейчас постараюсь с фабрикой разобраться, вроде-бы оно.
...
Рейтинг: 0 / 0
Матрицы, позднее связывание, и другое
    #39113686
Фотография SashaMercury
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Сделал так, но пока не работает.
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
class M
{
	double* a;
	size_t n, m;
public:
	virtual int get_type() = 0;
};

class Creator
{
public:
	virtual M* factory_method() = 0;
};


class RM :public M //rectangular matrix
{
public:
	RM();
	RM(double* buf, size_t n,size_t m)
	{
		if (n == m){
			CreatorSM cr;
			M* m = cr.factory_method();//inaccessible
		}
	}
	int get_type() { return 0; }
};

class CreatorRM :public Creator
{
	M* factory_method() { return new RM(); }
};

class SM :public M //square matrix
{
	int get_type() { return 1; }
};

class CreatorSM :public Creator
{
	M* factory_method() { return new SM(); }
};



не очень красиво получается
...
Рейтинг: 0 / 0
Матрицы, позднее связывание, и другое
    #39113692
White Owl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SashaMercurymaytonпропущено...

Ты когда говоришь о т.н. "стандартах" - то уточняй о каком из них. Мы уже говорим про
стандарт на числа плавающей точности?

Нет, я говорю о стандарте Си, например, в котором содержится информации об той самой e:1=1+e, и другая вспомогательная информация по работе с числами двойной точностиА для понимания этого момента, надо учить историю.
В далекие и древние времена, очень редкие компьютеры умели считать числа с плавающей запятой самостоятельно. Для таких расчетов использовались специальные программы, которые были оформлены в виде функций для библиотек. И так как эти расчеты были нужны достаточно часто, то эти функции появлялись в составе всех имеющихся компиляторов. И в итоге их решили считать стандартными.
В те времена тип float занимал в памяти столько же байт сколько тип int (какого-бы размера int) ни был на конкретной платформе. А double соответственно вдвое длиннее. Ну вот так Ричи захотелось... И отсюда и возникла "стандартная" точность для float и double.
Как работала вся математика для плавающей точки? Через численные методы и схождение рядов. Ну и чтобы добавить порядка, ввели в стандарт ограничения по точности и создатели компиляторов исходя из этой точности задавали сколько итераций делать при расчете всех операций с float и double переменными (и арифметических и тригонометрических и всех остальных -ических).

А потом настал 1980-ый год и Intel выпустил в свободную продажу специальный процессор i8087 который ставился в пару к i8086 и занимался исключительно числами с плавающей запятой. И все номерные процессоры семейства (i8086, i80186, i80286, i80386 и i80486 со всеми кузенами и модификациями) имели младших братишек с семеркой в конце номера. В результате, в 80-х и 90-х годах все компиляторы Си и С++ имели специальный ключик - отдавать все операции с float и double в сопроцессор или использовать собственную библиотеку...
Причем что интересно, стандарт на компьютерную обработку чисел с плавающей запятой уже писался на основе x87-ого чипа. Сначала Intel выпустил 8087-ой сопроцессор, а стандарт который описывает как эти расчеты надо было проводить вышел на пять лет позже... И только тогда появилась мода на 80-и битное хранение чисел ставшая стандартом и сохраняющаяся и сегодня. Стандарт по формальной математик по существу писался с оглядкой на уже существующее коммерческое решение в железе.

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

Кстати, в GNU C/C++ до сих пор есть опция -msoft-float и -mfpmath которыми можно выключить использование команд процессора для расчетов и заменить их вызовами функций (которая уже не поставляется с компилятором).

А на многих микроконтроллерах соответсвующих операций до сих пор нет и там по прежнему программа типа:
Код: plaintext
1.
2.
float a, b, c ;
c= a+b;

превращается в вызов библиотечной функции. Которая может или следовать древним традициям sizeof(float)=sizeof(int), sizeof(double)=2*sizeof(float). Или жестко задавать 80бит для хранения любого числа с плавающей запятой и все. Но это уже достаточная редкость и надо смотреть на конкретную платформу.
А все потомки Pentium'а занимаются плавающей запятой самостоятельно. И точность расчета зависит от процессора а не собственных библиотек компилятора.
...
Рейтинг: 0 / 0
Матрицы, позднее связывание, и другое
    #39113702
Фотография SashaMercury
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Спасибо за ликбез, этого я не знал.
White Owl И только тогда появилась мода на 80-и битное хранение чисел ставшая стандартом и сохраняющаяся и сегодня.

Размер long double в VS 8 байт вроде-бы, т.е. 64 бита
...
Рейтинг: 0 / 0
Матрицы, позднее связывание, и другое
    #39113721
Фотография SashaMercury
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Поправил, но всё-равно ругается
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
class IM
{
	double* a;
	size_t n, m;
public:
	virtual int get_type() = 0;
};

class Matrix :public IM //rectangular matrix, real base class
{
public:
	Matrix();
	Matrix(double* buf, size_t n, size_t m);
	int get_type() { return 0; }
};

class SM :public IM //square matrix
{
	int get_type() { return 1; }
	int get_determinant();
};



class Creator
{
public:
	virtual IM* factory_method() = 0;
};

class CreatorRM :public Creator
{
	IM* factory_method() { return new Matrix(); }
} cRecM;

class CreatorSM :public Creator
{
	IM* factory_method() { return new SM(); }
} cSqM;

static const size_t count_of_creators = 2;

Creator* c[count_of_creators] = { &cRecM, &cSqM };

Matrix::Matrix(double* buf, size_t n, size_t m)
{
	if (n == m){
		IM* m = c[1]->factory_method();
	}
	else{
		IM* m = c[0]->factory_method();
	}
}


int main()
{
	double* temp;
	Matrix* m = new Matrix(temp, 5, 5);
	Matrix* m1 = new Matrix(temp, 5, 7);
	std::cout << m->get_type();
	std::cout << m1->get_type();
	return 0;
}



Error 2 error LNK2019: unresolved external symbol "public: __thiscall Matrix::Matrix(void)" (??0Matrix@@QAE@XZ) referenced in function "private: virtual class IM * __thiscall CreatorRM::factory_method(void)" (?factory_method@CreatorRM@@EAEPAVIM@@XZ


PS
egorych, вы как-то писали что у вас около 100 классов в одном проекте и это не много. Теперь я понимаю почему вы считаете что это не много, и почему их так много.
...
Рейтинг: 0 / 0
Матрицы, позднее связывание, и другое
    #39113784
egorych
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SashaMercury,

>>Поправил, но всё-равно ругается
Error 2 error LNK2019: unresolved external symbol "public: __thiscall Matrix::Matrix(void)" (??0Matrix@@QAE@XZ) referenced in function "private: virtual class IM * __thiscall CreatorRM::factory_method(void)" (?factory_method@CreatorRM@@EAEPAVIM@@XZ
ну, а дефолтный конструктор у класса Matrix кто будет реализовывать? ))

>>egorych, вы как-то писали что у вас около 100 классов в одном проекте и это не много. Теперь я понимаю почему вы считаете что это не много, и почему их так много.
:)

а зачем создающие функции в конкретных реализациях фабрики ты спрятал в private?
Код: plaintext
1.
2.
3.
4.
struct CreatorRM :public Creator
{
	M* factory_method() { return new RM(); }
};

и проблемы с inaccessible сразу будут решены ))
...
Рейтинг: 0 / 0
Матрицы, позднее связывание, и другое
    #39113848
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SashaMercuryegorych, вы как-то писали что у вас около 100 классов в одном проекте и это не много. Теперь я понимаю почему вы считаете что это не много, и почему их так много.
В моём текущем проекте около 14 тыс классов.
...
Рейтинг: 0 / 0
Матрицы, позднее связывание, и другое
    #39113853
mcureenab
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
egorychSashaMercury,
>>>struct<<< CreatorRM :public Creator
{
M* factory_method() { return new RM(); }
};

[/src]и проблемы с inaccessible сразу будут решены ))

или public: не забывать. В struct по умолчанию все члены public, а в class - private, потому недоступны.
...
Рейтинг: 0 / 0
Матрицы, позднее связывание, и другое
    #39113860
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SashaMercurySashaMercury Реализую первый вариант, предложенный Дмитрием.


Всё-таки этот вариант не самый хороший. Например, в базовом классе M мы определим операцию умножения матриц, но результатом такой операции может быть как прямоугольная матрица M так и квадратная S_M. Вернулся к тому что было
Я-бы исходил из того что говорит математика по поводу определителя для не-квадратной матрицы.
Или что говорит твой юзкейс. Например варианты поведения.

1) Бросить исключение - типа "Are you crazy man!"
2) Дать функцию isDeterminantApplyable(). Проверять возможность. И соотв. делать или не делать расчёт.
3) Обобщить прямоугольную. Например дополнить нулями и единичками (здесь
я не уверен нужно почитать возможно ли это) прямоугольную до квадратной и молча выполнить
расчёт детерминанта. Смысл разумеется возложить на постановщика.

И вот эти кейсы что я перечислил во много раз важнее дизайна классов. Как-бы нам
не хотелось красивенько унаследоваться или сделать композицию. Не стоит выпячивать ООП
фичи. Надо исходить из смыслов.
...
Рейтинг: 0 / 0
Матрицы, позднее связывание, и другое
    #39114213
Фотография Anatoly Moskovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SashaMercuryegorych, вы как-то писали что у вас около 100 классов в одном проекте и это не много. Теперь я понимаю почему вы считаете что это не много, и почему их так много.
В данном случае с матрицами никаких фабрик и интерфейсов не нужно.
Если на голом месте высасывать из пальца пачки классов, то и 100 и 14000 не предел.
...
Рейтинг: 0 / 0
Матрицы, позднее связывание, и другое
    #39115935
Фотография SashaMercury
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
egorychа зачем создающие функции в конкретных реализациях фабрики ты спрятал в private?
Код: plaintext
1.
2.
3.
4.
struct CreatorRM :public Creator
{
	M* factory_method() { return new RM(); }
};

и проблемы с inaccessible сразу будут решены ))

Я поправил как вы посоветовали, но это к сожалению не помогло
...
Рейтинг: 0 / 0
Матрицы, позднее связывание, и другое
    #39115937
Фотография SashaMercury
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maytonSashaMercuryegorych, вы как-то писали что у вас около 100 классов в одном проекте и это не много. Теперь я понимаю почему вы считаете что это не много, и почему их так много.
В моём текущем проекте около 14 тыс классов.

И из них 13 900 реализуют внутренний интерфейс и паттерны ?:)
...
Рейтинг: 0 / 0
Матрицы, позднее связывание, и другое
    #39117373
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SashaMercurymaytonпропущено...

В моём текущем проекте около 14 тыс классов.

И из них 13 900 реализуют внутренний интерфейс и паттерны ?:)
Ммм... это хороший вопрос. Для меня даже приблизительный подсчёт
сопряжён с анализом. Так просто.... через grep code я не смогу
ответить на твой вопрос.

Но они являются частью фреймворков и соотв в обязательном порядке
имеют базовый тип.
...
Рейтинг: 0 / 0
Матрицы, позднее связывание, и другое
    #39117379
Фотография SashaMercury
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А вот если бы аналогичное было бы реализовано на условной Java, какой объём по классам можно ожидать ?
...
Рейтинг: 0 / 0
Матрицы, позднее связывание, и другое
    #39117444
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SashaMercuryА вот если бы аналогичное было бы реализовано на условной Java, какой объём по классам можно ожидать ?
Если ты хочешь спросить - можно-ли уменьшить кол-во сущностей в принципе - то я отвечу ДА.

Но какой ценой? Ценой усложнения процесса разработки? Или введением универсальной
божественной сущности типа GodObject в котором можно добавлять и удалять поля и методы?

Или перенести половину логики в DBMS? ТОже своя цена.

Как то так вобщем.
...
Рейтинг: 0 / 0
Матрицы, позднее связывание, и другое
    #39117464
Владимир2012
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maytonВ моём текущем проекте около 14 тыс классовВ том смысле, что если подсчитать количество видов структур используемых API Microsoft + ... + ваших 5 структур, или как?
...
Рейтинг: 0 / 0
Матрицы, позднее связывание, и другое
    #39117470
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Владимир2012, при чём тут Microsoft? Я не использую сабж.
...
Рейтинг: 0 / 0
Матрицы, позднее связывание, и другое
    #39117481
Владимир2012
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maytonЕсли интересно курить сорцы на Java 5.0.Java?
...
Рейтинг: 0 / 0
Матрицы, позднее связывание, и другое
    #39117517
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Владимир2012, эта тема интересная. Но давай как-нибудь обсудим отдельным топиком.
В рамках "Борьбы за уменьшение количества entities"

Здесь всё таки матрицы и позднее связывание.
...
Рейтинг: 0 / 0
22 сообщений из 72, страница 3 из 3
Форумы / C++ [игнор отключен] [закрыт для гостей] / Матрицы, позднее связывание, и другое
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]