[image]

Твердые ракетные топлива карамельного типа ХII

 
1 145 146 147 148 149 232
RU SashaMaks #23.11.2013 16:45  @Serge77#23.11.2013 16:36
+
-
edit
 

SashaMaks
SashaPro

аксакал

Serge77> Исходные данные в файле PEPCODED.DAF имеют в большинстве своём три значащие цифры, некоторые две или четыре. Значит конечный результат никак не может иметь семь значащих цифр, как ты пишешь 121,7539. Скорее всего значащих цифр всего три, а значит УИ=122.

Может, может и ещё раз может. Это расчётная модель и в этом её прелесть! Для неё исходное число истинно именно 1,5, хотя в действительности оно может быть совсем другим, например 1,521643162364123...
И это никак не отразиться на поведении математических функций (ну или с очень малой долей вероятности). А те погрешности, что ты пытаешься применить будут актуальны только при сравнении её конечного результата расчёта с конечным практическим, но не с её собственным расчётным. Это и даёт такую прекрасную возможность, как проведения матанализа на повышенной точности, чтобы понять, как писал Ксан, как ведёт себя функция в тех или иных условиях. Ну и конечно же, всегда есть вероятность ошибки, правда они очень мала, но для тебя оставляет право писать, что расчёт неправильный))) Но и тут есть целый раздев математики, который занимается вероятностными расчётами.

На ЭВМ, я тебе даже УИ 122+-6 смогу сравнить с 121+-6, только вот хвосты у них подрезать не нужно))), тогда и 121,112+-6 можно сравнить с 121,546+-6.
   25.025.0
RU SashaMaks #23.11.2013 16:58  @Serge77#23.11.2013 16:36
+
-
edit
 

SashaMaks
SashaPro

аксакал

Serge77> Исходные данные в файле PEPCODED.DAF имеют в большинстве своём три значащие цифры, некоторые две или четыре.

Это для экономии счётных ресурсов делалось и только. То был ~1980 год и был ДОС и компы были слабые.

А так почти все исходные данные находятся в опытно-расчётной базе данных продуктов сгорания JANNAF (1570 записей и в каждой по где-то 20 переменных), и в ней использованы 16-битные рациональные числа для записи данных. И там очень много знаков после запятой. Поэтому формат записи этого файла двоичный, так как он самый компактный и быстрый.
   25.025.0
RU SashaMaks #23.11.2013 17:04  @SashaMaks#23.11.2013 16:58
+
-
edit
 

SashaMaks
SashaPro

аксакал

SashaMaks> А так почти все исходные данные находятся в опытно-расчётной базе данных продуктов сгорания JANNAF (1570 записей и в каждой по где-то 20 переменных)...

Вот пример начала этой самой базы данных - аналог нашей русской базе данных ифтантермо.
Перевёл в Эксель, но потом передумал использовать её в таком формате. На современных компах тоже притормаживает, не сильно но напрягает. Поэтому будет двоичный. Простой текстовый формат использовать проблематично будет, структура сложная...
Прикреплённые файлы:
JANNAF.png (скачать) [1331x1019, 178 кБ]
 
 
   25.025.0
UA Serge77 #23.11.2013 17:45  @SashaMaks#23.11.2013 17:04
+
0 (+1/-1)
-
edit
 

Serge77

модератор

Всё-таки сходи к учителям, пусть они тебя доучат. Хватит писать фигню.
   31.0.1650.5731.0.1650.57

RU Бывший генералиссимус #23.11.2013 20:51  @SashaMaks#23.11.2013 16:58
+
-
edit
 
SashaMaks> А так почти все исходные данные находятся в опытно-расчётной базе данных продуктов сгорания JANNAF (1570 записей и в каждой по где-то 20 переменных), и в ней использованы 16-битные рациональные числа для записи данных. И там очень много знаков после запятой.
16-битное двоичное число эквивалентно по точности 4 1/2 десятичным цифрам, т.е. эквивалентной записью может быть, например, 35,254+/-0,002, не точнее.
Или 29999+/-1, или 39999+/-2, не точнее.
Но это всё фигня.
Все нормальные программы выдают обычно 2 результата, один называется frozen, другой - shifting. Сколько между ними разница? в процентах.
Внимание, это два разных теоретических результата с одинаковыми входными данными, просто в одной модели состав продуктов заморожен, а в другой - меняется по длине сопла с мгновенным установлением термодинамического равновесия.
Причём, ни одна теоретическая модель не берётся предсказывать, в отрыве от реальной конструкции двигателя и т.д., в каком именно месте между frozen и shifting будет правильный результат.
Обычно, чем меньше двигатель (короче сопло), тем ближе к frozen, но, вообще-то, с учётом, допустим, аб** сопла, даже нет гарантии, что реальный результат обязательно окажется между этими двумя точками. Точнее, нет, не реальный, а теоретический, посчитанный с учётом конкретной реализации двигателя на суперкомпьютере с 10000000 точек.
   10.010.0
RU SashaMaks #24.11.2013 00:49  @Бывший генералиссимус#23.11.2013 20:51
+
-
edit
 

SashaMaks
SashaPro

аксакал

Б.г.> Все нормальные программы выдают обычно 2 результата, один называется frozen, другой - shifting. Сколько между ними разница? в процентах.

Это понятно. Главный вопрос в том, можно ли сравнивать между собой замороженный и не замороженный УИ в этой программе соответственно с замороженным и не замороженным УИ между отдельно взятыми расчётами? И как для неё посчитать погрешность?

Смотрел методы расчёта погрешностей для численных вычислений, они все какие-то очень сложные и неопределённые, но ничего общего нет с тем, что написал Сергей, хотя можно всё, но что будет корректней?
   25.025.0
RU SashaMaks #24.11.2013 00:55  @Бывший генералиссимус#23.11.2013 20:51
+
-
edit
 

SashaMaks
SashaPro

аксакал

Б.г.> 16-битное двоичное число эквивалентно по точности 4 1/2 десятичным цифрам, т.е. эквивалентной записью может быть, например, 35,254+/-0,002, не точнее.

Тут я запамятовал.
Посмотрел в исходник PropeLant, где дешифровал базу, там запись переменной считывается размером 4 байта, т.е. они 32-битные были в базе изначально.
   25.025.0
RU SashaMaks #24.11.2013 01:18  @Бывший генералиссимус#23.11.2013 20:51
+
-
edit
 

SashaMaks
SashaPro

аксакал

Б.г.> ...даже нет гарантии, что реальный результат обязательно окажется между этими двумя точками. Точнее, нет, не реальный, а теоретический, посчитанный с учётом конкретной реализации двигателя на суперкомпьютере с 10000000 точек.

Вот, на счёт гарантии. Помимо цифры и поля допуска нужно указывать вероятность, так как пределы разброса выходят очень большими и всегда есть вероятность получить неадекватное число (например, как вот в этом расчёте - максимальный скачок на графике).

Вот, а для расчёта вероятности, как я уже писал, необходимо делать выборку в дельтах допусков всех исходных данных и пересчитывать, тогда будет видно чего и в каком количестве выпадет, и будет получена функция нормального распределения и можно будет посчитать вероятность выпадения той или иной цифры в соответствующем интервале допуска. Это вроде называется методом чёрного ящика?
Прикреплённые файлы:
005.png (скачать) [840x600, 71 кБ]
 
 
   25.025.0
RU Бывший генералиссимус #24.11.2013 01:37  @SashaMaks#24.11.2013 00:49
+
+1
-
edit
 
Б.г.>> Все нормальные программы выдают обычно 2 результата, один называется frozen, другой - shifting. Сколько между ними разница? в процентах.
SashaMaks> Это понятно. Главный вопрос в том, можно ли сравнивать между собой замороженный и не замороженный УИ в этой программе соответственно с замороженным и не замороженным УИ между отдельно взятыми расчётами?

Нет, нельзя. Ибо если мы добавляем в топливо компонент, которого раньше не было, атомный вес которого сильно отличается и кинетика тоже отличается, то и реальный результат легко может переместиться между замороженным и равновесным. Ибо одни реакции радикально катастрофически быстрее других. Например, окисление серы молекулярным кислородом медленнее, чем окисление сероводорода молекулярным кислородом, но сера с бертолеткой реагирует с хлопком, а сероводород с бертолеткой - почти и не реагирует. Т.е. в теории можно получить 1% выигрыша, а на практике - 1% проигрыша, и наоборот. Причём, понятно, это будет зависеть от давления, приведённой длины, степени расширения, размера заряда и т.д.

SashaMaks> И как для неё посчитать погрешность?

для кого "неё"? :)

SashaMaks> Смотрел методы расчёта погрешностей для численных вычислений, они все какие-то очень сложные и неопределённые, но ничего общего нет с тем, что написал Сергей, хотя можно всё, но что будет корректней?

Речь идёт не о погрешности самого расчёта. Речь идёт о том, что способ расчёта должен быть устойчив к малым погрешностям. Т.е. там, где расчётная функция недифференцируема в аналитическом представлении, в численном появляется большая "мёртвая зона", в этой зоне результаты вычисления будут недостоверны, даже если брать всякие "даблы" и "лонги". Вот выбросы на твоих графиках - как раз и есть показатель того, что в алгоритме где-то дыра, и к его данным надо относиться с осторожностью. Даже там, где всё выглядит гладким.
   10.010.0
RU Бывший генералиссимус #24.11.2013 01:44  @SashaMaks#24.11.2013 00:55
+
-
edit
 
Б.г.>> 16-битное двоичное число эквивалентно по точности 4 1/2 десятичным цифрам, т.е. эквивалентной записью может быть, например, 35,254+/-0,002, не точнее.
SashaMaks> Тут я запамятовал.
SashaMaks> Посмотрел в исходник PropeLant, где дешифровал базу, там запись переменной считывается размером 4 байта, т.е. они 32-битные были в базе изначально.

А причём тут твой PropeLant, в исходнике-то они какие? Если взять любой хим.справочник, видно, что циферки приводят с точностью в пол-процента, редко лучше. Если молекулярной массы приведено 4 знака, то энтальпии образования - только три.
Причём, если в большом справочнике указывают, что последняя цифра может быть плюс-минус один или плюс-минус три, или плюс-минус пять, то перепечатывальщики часто это написать забывают.
   10.010.0
RU SashaMaks #24.11.2013 01:45  @Бывший генералиссимус#24.11.2013 01:37
+
-
edit
 

SashaMaks
SashaPro

аксакал

Б.г.> Вот выбросы на твоих графиках - как раз и есть показатель того, что в алгоритме где-то дыра, и к его данным надо относиться с осторожностью. Даже там, где всё выглядит гладким.

Так я так сразу и написал, что теоретически. Практически ещё только собираюсь это проверить. Чего сразу неучем-то кидаться.

Так или иначе есть вероятность того, что разница в 1% в пользу серы имеет место быть. Дальше следует опытное подтверждение этого. Программа это показала, да, она может ошибаться, но не всегда, как настаивает Сергей. На практике всё будет видно. По крайней мере будет видно, что на количествах до 10% серы в карамели хуже не будет. Думаю, это удастся отследить.
   25.025.0
RU SashaMaks #24.11.2013 01:50  @Бывший генералиссимус#24.11.2013 01:44
+
-
edit
 

SashaMaks
SashaPro

аксакал

Б.г.> А причём тут твой PropeLant, в исходнике-то они какие?

Мой PropeLant работает с исходным файлом PROPEP, этот файл и есть исходник. В нём хоть в одном месте ошибёшься, хотя бы с чтением одной переменной хотя бы на 1 байт, программа ничего не рассчитает. Так как все последующие числа будут прочитаны с ошибкой смещения.

Б.г.>Если взять любой хим.справочник, видно, что циферки приводят с точностью в пол-процента, редко лучше. Если молекулярной массы приведено 4 знака, то энтальпии образования - только три.

Но вот видешь, тут в исходном файле они приведены с куда большей точностью. Причём большинство из них скорее всего предварительно так же пересчитывались на ЭВМ и в неизменном виде записывались в этот файл без всякого округления.
   25.025.0
RU Бывший генералиссимус #24.11.2013 02:02  @SashaMaks#24.11.2013 01:50
+
-
edit
 
Б.г.>> А причём тут твой PropeLant, в исходнике-то они какие?
SashaMaks> Мой PropeLant работает с исходным файлом PROPEP, этот файл и есть исходник. В нём хоть в одном месте ошибёшься, хотя бы с чтением одной переменной хотя бы на 1 байт, программа ничего не рассчитает. Так как все последующие числа будут прочитаны с ошибкой смещения.
Да при чём здесь смещение, большое количество циферок появляется просто из-за перевода из двоичной в десятичную и обратно :) как ты определяешь, сколько из них значащих?

Б.г.>>Если взять любой хим.справочник, видно, что циферки приводят с точностью в пол-процента, редко лучше. Если молекулярной массы приведено 4 знака, то энтальпии образования - только три.
SashaMaks> Но вот видешь, тут в исходном файле они приведены с куда большей точностью. Причём большинство из них скорее всего предварительно так же пересчитывались на ЭВМ и в неизменном виде записывались в этот файл без всякого округления.

Не всё можно рассчитать, кое-что можно только померять, и для этих величин встаёт вопрос - как меряли, с какой точностью, и чем могут подтвердить эту точность?
У меня есть замечательная книга - диаграммы состояния двойных металлических систем, там для многих пар металлов "не бьются" данные разных исследований, т.е. расхождение превышает заявленную ошибку. Один исследователь пишет - образуется вещество состава XnYm, а другой пишет - нет, не образуется!
   10.010.0
RU SashaMaks #24.11.2013 02:15  @Бывший генералиссимус#24.11.2013 02:02
+
-
edit
 

SashaMaks
SashaPro

аксакал

Б.г.> Да при чём здесь смещение, большое количество циферок появляется просто из-за перевода из двоичной в десятичную и обратно :) как ты определяешь, сколько из них значащих?

Нет от этого перевода не появляется. Двоичная запись числа из файла в оперативную память и вообще куда угодно на ЭВМ делается без переводов - это и повышает скорость записи/чтения. Может быть так, что при переводе из 32-битного числа в 64 битное, число, скажем, 32,1 может измениться 31,09999999999999 или 32,10000000000001. А если число имеет набор всех цифр на всех разрядах - это все значащие числа, такого ни при каком программном преобразовании типов быть не должно, иначе это просто неправильный алгоритм, которым вместо 32,1 выдаст тебе, 45,9, но такого не наблюдал в дельфи никогда.

Б.г.> Не всё можно рассчитать, кое-что можно только померять, и для этих величин встаёт вопрос - как меряли, с какой точностью, и чем могут подтвердить эту точность?

Знаю. Я тебе даже больше скажу, как бы там не было, в мои измерения Сергей никогда не поверит. Но мне это не нужно.

Статистику отклонения расчётного УИ в Пропеп от реально замеренного я уже проводил для своего топлива и двигателей на нём. Результаты были не хуже, чем Накки на обычной карамели, а местами и лучше. Но тут окислители разные. Осталось также для простой натриевой карамели проделать. Главное, что того ужаса от наличия её в карамели точно нет. Есть некоторые другие плюсы, а тогда почему нет. Для достижения рекордных показателей своих ракет не вижу препятствий к её применению.
   25.025.0
+
-
edit
 

SashaMaks
SashaPro

аксакал

LEVSHA> ...получается – «убийство»(непонимание) на почве личного не восприятия точки зрения другого. :D :)

Да, и не преподаватели, не политех, не кто другой не изменит этой ситуации, раз за 6 лет ничего не поменялось.

А вот бесспорные доказательства этой ситуации.
Политика двойных стандартов Serge77:

Из сообщения 2008года:
Serge77 «У меня получается так:
Serge77 10атм
Serge77 NaNO3(59)+C6H14O6(30)+S(11)
Serge77 THE MOLECULAR WEIGHT OF THE MIXTURE IS 35.54 г/моль
Serge77 ISP* 119.2
Serge77 NaNO3(65)+C6H14O6(35)
Serge77 THE MOLECULAR WEIGHT OF THE MIXTURE IS 33.895 г/моль
Serge77 ISP* 124.3»

Никакой погрешности нигде не указано.
И вдруг сейчас, он пишет, когда я считаю на PROPEP:

Serge77 правильно писать
Serge77 "НН-Сорбит (65-35) без серы
Serge77 Удельный импульс топлива, с 122 ±6
Serge77 НН-Сорбит-S (62,4-33,6-4) с серой
Serge77 Удельный импульс топлива, с 122 ±6"
Serge77 Значит, никаких выводов, что чего больше, сделать нельзя.

А потом далеко идущие выводы обо мне:

Serge77> А какое у тебя образование? Кажется высшее техническое? Какое именно? Неужели вам не читали по поводу погрешности инженерных расчётов?
Serge77> Я как раз по самой сути. Ты пишешь 3Д симуляторы всего, а как оценить погрешность своих расчётов понятия не имеешь. Даже не понимаешь, о чём речь.
Serge77> Нет у тебя высшего образования. Даже троечник хотя бы слышал, что есть такой статанализ. А ты даже не слышал.
Serge77> Вот так же странно выглядит "математик", который не понимает вопроса "какая у твоей программы погрешность расчёта?"

По факту он и о себе тоже самое написал.

Моё образование здесь ни при чём, поход в политех тоже ничего не изменить, да и платить там деньги за то, чтобы они представили методичку, как считать погрешность численной модели только ради бесполезного спора, мне не нужно.

Это я сохраню и каждый раз буду печатать везде, где будет снова возникать его следующая претензия к моим расчётам.
   25.025.0
RU SashaMaks #24.11.2013 04:24  @Бывший генералиссимус#24.11.2013 02:02
+
-
edit
 

SashaMaks
SashaPro

аксакал

Б.г.> как ты определяешь, сколько из них значащих?

Да и это правильно, не округлять вычислительные данные на ЭВМ. Так как неизвестно, где будет конец расчёта. Если это делать из раза в раз на каждой стадии расчёта, то будет сильно расти погрешность округления, и тогда конечный результат будет ещё хуже. Поэтому они правильно сделали, что так записали значения в исходную базу данных. А то так можно округлять результат после каждой вычислительной операции на ЭВМ. И будет не расчёт, а сплошная погрешность в итоге.
   25.025.0
RU SashaMaks #24.11.2013 04:41  @Serge77#23.11.2013 16:38
+
-
edit
 

SashaMaks
SashaPro

аксакал

SashaMaks>> Всё нашёл, где "собака зарыта".
Serge77> ))))))))))))))))))))))))))))))))))))))))))))))))))))
Serge77> Это капец, твоя креативность не знает пределов))))))))))))))))))))))))))))

Нет - это не креативность, а метод такой, каким ты пользуешься, с правилом Брадиса-крылова:
Прикреплённые файлы:
Метод.png (скачать) [761x378, 30 кБ]
 
Pogr.pdf (скачать) [218 кБ]
 
 
   25.025.0
RU SashaMaks #24.11.2013 04:49  @Serge77#23.11.2013 17:45
+
-
edit
 

SashaMaks
SashaPro

аксакал

Serge77> Всё-таки сходи к учителям, пусть они тебя доучат. Хватит писать фигню.

Просвещайся:
В.В. Иванов. Методы вычислений на ЭВМ.
Прикреплённые файлы:
Ерунда.png (скачать) [593x452, 199 кБ]
 
Ещё фигня.png (скачать) [575x263, 125 кБ]
 
 
   25.025.0
RU Бывший генералиссимус #24.11.2013 10:34  @SashaMaks#24.11.2013 04:24
+
-
edit
 
Б.г.>> как ты определяешь, сколько из них значащих?
SashaMaks> Да и это правильно, не округлять вычислительные данные на ЭВМ. Так как неизвестно, где будет конец расчёта.

Нет, это ни разу не правильно. И это легко доказывается.

SashaMaks> Если это делать из раза в раз на каждой стадии расчёта, то будет сильно расти погрешность округления, и тогда конечный результат будет ещё хуже.

Нет. Смотри. Для сложения или вычитания имеют значение только абсолютные погрешности.
Например, мы складываем 32586±1 и 4528±10. В результате у нас с очевидностью получается 37114±11. То есть, фактически, любое число от 37103 до 37125. И у нас уже неизвестна последняя цифра, но и предпоследняя может быть ±1. Для того, чтобы ошибка при сложении и вычитании не накапливалась, сколько бы мы ни делали вычислений, достаточно считать ОДНУ дополнительную цифру, но в конечном результате всё равно её отбросить. Если это была последняя операция расчёта, то записи 37114±11 и 37110±15 эквивалентны.
Для умножения и деления имеют значение только относительные погрешности.
Допустим, мы умножаем 1,23±0,02 на 43,13±0,02. В результате получается 53,0499+0,8876/-0,8868. И эта запись эквивалентна 53±1. Разница в величине погрешности между первой и второй записями составляет 10%. Это значит, что, если мы в цепочке делаем 10 вычислений, то даже если мы отбрасываем при каждом шаге все незначащие цифры, то погрешность к 10-му шагу, в худшем случае, удвоится. Если мы оставляем при округлении одну незначащую цифру, то для удвоения погрешности нужно 100 вычислений в цепочке.

SashaMaks> Поэтому они правильно сделали, что так записали значения в исходную базу данных.

как "так", можно цитату из базы? Ты не пробовал сделать обратный перевод в футы, фунты, и градусы фаренгейта?

SashaMaks> А то так можно округлять результат после каждой вычислительной операции на ЭВМ. И будет не расчёт, а сплошная погрешность в итоге.

Ещё раз - если у тебя 100 сомножителей в цепочке, и ты сохраняешь одну "запасную" цифру, то погрешность результата будет всего вдвое больше погрешности худшего из сомножителей. Даже если ты не используешь порядковую сортировку по точности. Если используешь - то погрешность результата в точности равна погрешности худшего из сомножителей.

Всё же ты прогуливал дискретную математику :)
   10.010.0
+
-
edit
 

Mester

втянувшийся

ошибки вычислений :

Ошибки вычислений

Процесс исследования исходного объекта методом математического моделирования и вычислительного эксперимента неизбежно носит приближенный характер, так как на каждом этапе вносятся погрешности. Построение математической модели связано с упрощением исходного явления, недостаточно точным заданием коэффициентов уравнения и других входных данных. По отношению к численному методу, реализующему данную математическую модель, указанные погрешности являются неустранимыми, поскольку они неизбежны в рамках данной модели. // Дальше — www.machinelearning.ru
 
   25.025.0
RU SashaMaks #24.11.2013 13:38  @Бывший генералиссимус#24.11.2013 10:34
+
-
edit
 

SashaMaks
SashaPro

аксакал

Б.г.> Всё же ты прогуливал дискретную математику :)

В расчёте получилось число не 37114±11 (То есть, фактически, любое число от 37103 до 37125), а 11±11 (То есть, фактически, любое число от 0 до 22). Потом округлилось до 0 и пошло на умножение/деление. Нетрудно представить какая дальше будет расчётная погрешность.
Нельзя применять методы работы с приближёнными вычислениями к рациональным числам на ЭВМ.
   25.025.0
+
-
edit
 

SashaMaks
SashaPro

аксакал

Mester> ошибки вычислений :
Mester> Ошибки вычислений

Хорошая фраза: "т.е. все значащие цифры могут оказаться неверными"
Просто напиши, что тебе нравяться вычисления на ЭВМ, что все они ложные. Мне ты этого не докажешь, как и я тебе обратного. Я всё равно буду считать на компьютере.
   25.025.0
+
-
edit
 

Mester

втянувшийся

Mester>> ошибки вычислений :
Mester>> Ошибки вычислений
SashaMaks> Хорошая фраза: "т.е. все значащие цифры могут оказаться неверными"
это твое собственное мнения, я такого не говорил! %)
SashaMaks> Просто напиши, что тебе нравятся вычисления на ЭВМ, что все они ложные. Мне ты этого не докажешь, как и я тебе обратного. Я всё равно буду считать на компьютере.
я тебе ничего не доказываю, мне это не нужно!!!
   25.025.0
+
-
edit
 

SashaMaks
SashaPro

аксакал

Mester> это твое собственное мнения, я такого не говорил! %)

Нет, это по твоей ссылки было написано. Я не читаю только один пример, так необъективно получается...
   25.025.0
AD Реклама Google — средство выживания форумов :)
RU SashaMaks #24.11.2013 14:10  @SashaMaks#24.11.2013 13:38
+
-
edit
 

SashaMaks
SashaPro

аксакал

SashaMaks> В расчёте получилось число не 37114±11 (То есть, фактически, любое число от 37103 до 37125), а 11±11 (То есть, фактически, любое число от 0 до 22).

Путь даже число X = 37114±11 относительно предела 37125 после округления до верхнего значения в формуле Y = 1/(37125 - X), так же отколет сюрприз. Хотя без округления в алгоритме может никогда не получиться числа более 37114.
   25.025.0
1 145 146 147 148 149 232

в начало страницы | новое
 
Поиск
Настройки
Твиттер сайта
Статистика
Рейтинг@Mail.ru