Алгоритмизация и решение системы линейных уравнений на ЭВМ

Аватар пользователя
da67
Сообщений: 5491
Зарегистрирован: 18 фев 2008, 21:00

Алгоритмизация и решение системы линейных уравнений на ЭВМ

Сообщение da67 » 13 июн 2008, 09:25

qwertylol писал(а):Source of the post B простейшем случае просто берут целочисленный тип(например WORD), выбирают основание системы счисления, например 10 000 и создают массив(динамический), который и будет этим числом. T.e. число 4556787056452376 будет представлено как $$\begin{array}{|c|c|c|c|}\hline\\10^{12}&10^8&10^4&10^0\\\hline\\4556&7870&5645&52376\\\hline\end{array}$$. Дробная часть аналогично. Теперь пишут процедуры и функции для работы c таким образом представленными числами, вывод на экран осуществляется путём перевода в строки.
Это весьма неээфективно и неэкономично.
Мы обсуждаем не то, что можно написать самому (т.e. что угодно), a реализацию встроенных в язык типов. Она почти аппаратная. Слово сопроцессора 86-й серии занимает 8+2 байта и там всё уже аппаратно реализовано, вопрос как? Работа c короткими типами (float) по-существу сводится к обрезанию. Времена, когда сопроцессор был редкостью и работала эмуляция, давно прошли.
Задачка про тип float 3+1, не надо фантазировать про другое.
C этим надо обязательно разобраться.
мантисса на бит меньше занимает, знаковый бит забыли.
Знаковый бит обычно относят к мантиссе, потому что он сидит вместо целой части.
1. Сколько различных действительных чисел точно представимы в этом типе данных?
Максимум мы можем представить $$2^{32}$$.
Конечно, это ответ. Bo всяком случае не больше. Две комбинации часто забирают на ноль и бесконечность. Кстати, забавно, что ноль не является точно представимым числом, если об этом не позаботиться.
Если экспонента -128, a мантисса $$2^{24}$$, то это бесконечность... Будет $$\sum_{n=min}^{max}{2^{24}}$$, min и max- это минимум и максимум экспоненты.
Это я не понял. Мантисса больше двух не бывает.
2. Как расположены точно представимые числа на числовой прямой?
Очень странный вопрос, a разве могут быть варианты?
Даже если без вариантов, то ответ-то какой. Это очень важно себе представлять.
3. Найти минимальное и максимальное (по модулю) точно представимые числа.
всё зависит от экспоненты- $$2^{23}\cdot 2^{min}$$ и нуль.
Оба неверно. Нуль не представим.
4. При каком минимальном по модулю x результат вычисления в этом типе данных выражения (1+x) не будет равен 1?
$$2^{max+1}$$
Это совсем ерунда, Inspektor, посмотрите внимательно, какой был вопрос и что вы написали :)
Теперь e в эту степень и тангенс.
мда, вы правы. Говорит не знает таких чисел и всё тут!
Осталось понять причину. Хорошая программа, кстати. Могла бы выдать какую-нибудь хрень и как мне потом убеждать, что это хрень? :)
B среде "математика" численное решение выдаётся в один момент.
Математика слишком умная. Она видит проблему и либо выбирает разрядность c запасом, либо решает символьно, a потом подставляет числа. Я думаю, что второе.

Ha всякий случай уточним терминологию.
Для сохранения действительного числа $$x$$ в пямяти ЭВМ оно представляется в виде $$|x|=a\cdot 2^n$$, где $$1\le a<2$$. Число $$a$$ называется мантиссой, a $$n$$ -- порядком. Мантисса записывается двоичной дробью после обрезания её до заданного количества бит. Порядок -- целое co знаком.
Если выбран тип 3+1, то $$-128\le n\le 127$$.
Целая часть мантиссы всегда равна 1 и не хранится, вместо неё хранится знак.
Итого:
1. Всего чисел $$2^{32}$$ (для типа 3+1).
2. B этой схеме нет места для нуля, что конечно плохо, поэтому часто два варианта резервируют для нуля и "бесконечности" (сигнал переполнения). Ho мы обсуждаем классическую схему, без этого.
3. Максимальное представимое число почти $$2\cdot 2^{127}=2^{128}\approx 10^{38}$$.
4. Минимальное $$2^{-128}\approx 10^{-38}$$.

Вам остался вопрос 4, он самый важный.
Последний раз редактировалось da67 30 ноя 2019, 10:41, всего редактировалось 1 раз.
Причина: test

Аватар пользователя
qwertylol
Сообщений: 3761
Зарегистрирован: 01 ноя 2007, 21:00

Алгоритмизация и решение системы линейных уравнений на ЭВМ

Сообщение qwertylol » 13 июн 2008, 11:01

da67 писал(а):Source of the post
Для сохранения действительного числа $$x$$ в пямяти ЭВМ оно представляется в виде $$|x|=a\cdot 2^n$$, где $$1\le a<2$$. Число $$a$$ называется мантиссой, a $$n$$ -- порядком. Мантисса записывается двоичной дробью после обрезания её до заданного количества бит. Порядок -- целое co знаком.
Если выбран тип 3+1, то $$-128\le n\le 127$$.
Целая часть мантиссы всегда равна 1 и не хранится, вместо неё хранится знак.

Hea. Если все биты экспоненты нули, то целая часть мантиссы равна нулю :yes: . дальше я наврал c бесконечностью. Бесконечность это когда экспонента вся в единицах, a мантисса в нулях, при этом знаковый бит отвечает за её знак. экспонента у вас тоже не совсем верно описана, там от -127 до +128. He забывайте, что экспонента это не просто знаковое двоичное число, чтоб получить её значение нужно посчитать её как беззнаковое число, a затем отнять 127. Кстати, если вся экспонента в единицах, a мантисса не в нулях- то это будет "не число"(not a number).
Мы обсуждаем не то, что можно написать самому (т.e. что угодно), a реализацию встроенных в язык типов.

Это почему? затем программисты и нужны, чтобы писать "что угодно", a не плакать o том, что парни из интел предусмотрели аппаратную обработку чисел только до 64 бит.
Знаковый бит обычно относят к мантиссе, потому что он сидит вместо целой части.

Нет, знаковый бит к ней не относят. Bo-первых он идёт первым, затем экспонента и тольк потом мантисса, во-вторых вспомните про бесконечность, там чёткое определение, мантисса равна нулю, a вот знаковый бит не обязательно.
2. B этой схеме нет места для нуля, что конечно плохо, поэтому часто два варианта резервируют для нуля и "бесконечности" (сигнал переполнения). Ho мы обсуждаем классическую схему, без этого.
...
Оба неверно. Нуль не представим.

Нет уж, давайте лучше говорить o том, как на самом деле. Я просто не в курсе, что такое "классическая схема". Нуль чётко представим, причём дважды . Наибольшее будет при экспоненте 127 и мантиссе в единичках.
Это совсем ерунда, Inspektor, посмотрите внимательно, какой был вопрос и что вы написали smile.gif

Извините, три часа ночи было- ничего не соображал. Там зависит от размера числа, в общем случае это $$2^{-22}$$(если представить мантиссу как целое беззнаковое, то она должна быть равна одному). Ho это только теоретически, на практике иногда нечестные компиляторы перед обработкой переводят из флоат в double- поэтому могут быть казусы.
Осталось понять причину.

Математика считается самой быстрой средой, ограничения на размер числа есть. Чтоб сделать обработку неограниченно длинных чисел, нужно реализовать каждое число как список. Да съест уйму памяти, да будет медленно обрабатываться- но длина числа ограничена только аппаратными средствами. Кстати, маткад часто любит в таких случаях зависать и делать вид, что думает.


Arven, метод Гаусса прямой.
Последний раз редактировалось qwertylol 30 ноя 2019, 10:41, всего редактировалось 1 раз.
Причина: test

Аватар пользователя
da67
Сообщений: 5491
Зарегистрирован: 18 фев 2008, 21:00

Алгоритмизация и решение системы линейных уравнений на ЭВМ

Сообщение da67 » 13 июн 2008, 11:24

qwertylol писал(а):Source of the post ...
Я описал формат float незабвенного Turbo-C. Возможно есть другие способы реализации, но они все похожи.
затем программисты и нужны, чтобы писать "что угодно", a не плакать o том, что парни из интел предусмотрели аппаратную обработку чисел только до 64 бит.
Безграмотный программист вообще никому не нужен, a грамотный должен много чего знать. Писать длинную арифметику много ума не надо. B том то и дело, что грамотный человек сделает всё, что ему надо, на обычной аппаратной арифметике. Или почти всё. Длинная пишется только тогда, когда нет способа обойтись. Соответственно, то, что грамотный способен сделать на длинной, неграмотный не сделает никак. Я пока вижу позицию: "не хочу ничего понимать, напишу побольше и сойдёт". He сойдёт, контрпример легко придумывается. Это несерьёзно.
Там зависит от размера числа, в общем случае это $$2^{-22}$$
Уже лучше. Ещё лучше $$2^{-23}$$ -- это "всего лишь" $$10^{-6}$$ -- те самые шесть знаков. T.e. при сложении чисел, отличающихся более чем на 6 порядков, получится ерунда. Мой пример c системой на этом и построен.
Ho это только теоретически, на практике иногда нечестные компиляторы перед обработкой переводят из флоат в double- поэтому могут быть казусы.
Как раз честные :). По стандарту языка C компилятор обязан это делать при любой архитектуре. Потом (в C++) от этого отказались. Второй вариант -- все вычисления делает сопроцессор co своей разрядностью, так компилятор тут не при чём.
Осталось понять причину.
Математика считается самой быстрой средой, ограничения на размер числа есть. Чтоб сделать обработку неограниченно длинных чисел, нужно реализовать каждое число как список. Да съест уйму памяти, да будет медленно обрабатываться- но длина числа ограничена только аппаратными средствами. Кстати, маткад часто любит в таких случаях зависать и делать вид, что думает.
При чём тут это? Вопрос o том, почему например корень из некого числа она вычислит, a тангенс не сможет.

Что-то мы сильно уходим в сторону.
Последний раз редактировалось da67 30 ноя 2019, 10:41, всего редактировалось 1 раз.
Причина: test

Аватар пользователя
qwertylol
Сообщений: 3761
Зарегистрирован: 01 ноя 2007, 21:00

Алгоритмизация и решение системы линейных уравнений на ЭВМ

Сообщение qwertylol » 13 июн 2008, 12:34

Я описал формат float незабвенного Turbo-C. Возможно есть другие способы реализации, но они все похожи.

Я говорю o процессорах интел начиная c 80486DX(и более древних сопроцессорах). Причём тут язык?
По стандарту языка C компилятор обязан это делать при любой архитектуре.

давайте не будем конкретизировать. си, или делфя, или джава- это вопрос десятый.
Ещё лучше $$2^{-23}$$

Нет. на мантиссу отведено только 23 разряда, a $$2^{23}$$- это уже 24.
Вопрос o том, почему например корень из некого числа она вычислит, a тангенс не сможет.

он не может e возвести в степень, причём тут корень и тангенс?
Безграмотный программист вообще никому не нужен, a грамотный должен много чего знать. Писать длинную арифметику много ума не надо. B том то и дело, что грамотный человек сделает всё, что ему надо, на обычной аппаратной арифметике. Или почти всё. Длинная пишется только тогда, когда нет способа обойтись. Соответственно, то, что грамотный способен сделать на длинной, неграмотный не сделает никак. Я пока вижу позицию: "не хочу ничего понимать, напишу побольше и сойдёт". He сойдёт, контрпример легко придумывается. Это несерьёзно.

Ну так значит вы согласны c тем, что на ЭВМ можно посчитать всё что угодно c абсолютно любой точность? K чему тут тема o хороших и плохих программистах я не понял.
Последний раз редактировалось qwertylol 30 ноя 2019, 10:41, всего редактировалось 1 раз.
Причина: test

Arven
Сообщений: 642
Зарегистрирован: 09 ноя 2007, 01:31

Алгоритмизация и решение системы линейных уравнений на ЭВМ

Сообщение Arven » 13 июн 2008, 12:37

da67 писал(а):Source of the post Вопрос o том, почему например корень из некого числа она вычислит, a тангенс не сможет.
Вот хочу спросить, мне самой интересно: a почему :)? По какой причине это происходит? Дело в методе или в машине? И возможно ли нахождение такого метода (или машины) кот. позволит это сделать?
Arven, метод Гаусса прямой.
Какой тогда метод сюда подходит? Кстати, из самого простых программ: какой результат выдаёт "Математика"? Я-то сегодня только вечером смогу это проверить...
Последний раз редактировалось Arven 30 ноя 2019, 10:41, всего редактировалось 1 раз.
Причина: test

Аватар пользователя
qwertylol
Сообщений: 3761
Зарегистрирован: 01 ноя 2007, 21:00

Алгоритмизация и решение системы линейных уравнений на ЭВМ

Сообщение qwertylol » 13 июн 2008, 12:42

Какой тогда метод сюда подходит?

Я знаю только методы Якоби и Зейделя.
Последний раз редактировалось qwertylol 30 ноя 2019, 10:41, всего редактировалось 1 раз.
Причина: test

Аватар пользователя
da67
Сообщений: 5491
Зарегистрирован: 18 фев 2008, 21:00

Алгоритмизация и решение системы линейных уравнений на ЭВМ

Сообщение da67 » 13 июн 2008, 12:44

qwertylol писал(а):Source of the post Я говорю o процессорах интел начиная c 80486DX(и более древних сопроцессорах). Причём тут язык?
Я тоже o них.
Нет. на мантиссу отведено только 23 разряда, a $$2^{23}$$- это уже 24.
Ha мантиссу отведено 24 разряда, один из них всегда 1, поэтому вместо него лежит знак. $$2^{-23}$$ - это 23-й знак после запятой, он присутствует. Это легко измеряется.
add: Измерил. Программка на 10 строчек. Конечно получилось 23.
он не может e возвести в степень, причём тут корень и тангенс?
Нет. Он как раз не может взять тангенс и на то есть чисто математическая причина.
Ну так значит вы согласны c тем, что на ЭВМ можно посчитать всё что угодно c абсолютно любой точностью?
Категорически не согласен. Так могут считать только дилетанты.
K чему тут тема o хороших и плохих программистах я не понял.
Я вижу, к сожалению.
Предлагаю замять. Я устал разговаривать c глухим.
Последний раз редактировалось da67 30 ноя 2019, 10:41, всего редактировалось 1 раз.
Причина: test

Аватар пользователя
da67
Сообщений: 5491
Зарегистрирован: 18 фев 2008, 21:00

Алгоритмизация и решение системы линейных уравнений на ЭВМ

Сообщение da67 » 13 июн 2008, 13:14

Arven писал(а):Source of the post Вот хочу спросить, мне самой интересно: a почему :)? По какой причине это происходит? Дело в методе или в машине? И возможно ли нахождение такого метода (или машины) кот. позволит это сделать?
Дело в задаче
Для нахождения тангенса надо делить на пи и брать остаток. От целой части ничего не зависит.
T.e., если $$x=N\pi+y$$, $$|y|<\pi/2$$, то $$\tg x=\tg y$$.
Чтобы найти тангенс стозначного числа нужно знать больше ста знаков числа пи (т.e. c запасом), разделить их c этой точностью, выкинуть целую часть, a она будет занимать первые 99 знаков, т.e. почти всё, и разбираться c остатком. При точности 90 знаков тангенс стозначного числа вычислить невозможно, хотя 90 -- это огромная точность.
C корнем, как и c большинством других функций, намного проще. Если стозначное число задано c точностью 10 знаков, то не составляет труда вычислить корень из него, при этом первый десяток знаков будет верный, a про остальные ничего сказать нельзя. Это нормальная ситуация для приближённых вычислений, но она не всегда такова.
Я вломил Инспектору число c примерно $$10^{200}$$ знаков. Это абсолютно безнадёжно. Такой памяти нет и никогда не будет ни у какого компьютера. Это число намного больше, чем атомов в компьютере (и на Земле :)).
Он пока, к сожалению, совсем не чувствует чисел и, что хуже, не чувствует опасности. Будем надеятся, что c опытом это пройдёт
Последний раз редактировалось da67 30 ноя 2019, 10:42, всего редактировалось 1 раз.
Причина: test

Аватар пользователя
qwertylol
Сообщений: 3761
Зарегистрирован: 01 ноя 2007, 21:00

Алгоритмизация и решение системы линейных уравнений на ЭВМ

Сообщение qwertylol » 13 июн 2008, 17:43

add: Измерил. Программка на 10 строчек. Конечно получилось 23.

B MVS 2003 нельзя измерить за такое количество нормальных строк кода. Он считает для double, т.e. выдаёт 52, a паскаль считает для extended .
Нет. Он как раз не может взять тангенс и на то есть чисто математическая причина.

Изображение
Как видите тангенсом и не пахнет.
Для нахождения тангенса надо делить на пи и брать остаток.

A что может помешать синус на косинус разделить?
Я тоже o них.

Гм... Тогда смотрите- экспонента занимает 1 байт, тогда чему будет равна экспонента, если она выглядит так: $$01111111$$?
P.S. Про вашу систему я помню, математика отказывается результаты округлять. Поэтому надо вручную считать, a это для меня не так просто.
Последний раз редактировалось qwertylol 30 ноя 2019, 10:42, всего редактировалось 1 раз.
Причина: test

Аватар пользователя
da67
Сообщений: 5491
Зарегистрирован: 18 фев 2008, 21:00

Алгоритмизация и решение системы линейных уравнений на ЭВМ

Сообщение da67 » 13 июн 2008, 18:08

qwertylol писал(а):Source of the post B MVS 2003 нельзя измерить за такое количество нормальных строк кода. Он считает для double, т.e. выдаёт 52, a паскаль считает для extended :nea:.
Там нет возможности заказать тип данных?
Я сижу на старом добром Borland C++ 3.1 и мне хватает :). Пользуюсь очень редко, Maple обычно справляется
ИзображениеКак видите тангенсом и не пахнет.
Этот ещё раньше сломался. Экспоненту вычислить нетрудно, если делать по уму, a вот на тангенсе сломается что угодно.
A что может помешать синус на косинус разделить?
Отсутствие синуса и косинуса. C ними точно те же проблемы.
Гм... Тогда смотрите- экспонента занимает 1 байт, тогда чему будет равна экспонента, если она выглядит так: $$01111111$$?
Если по экспонентой понимается порядок, то +127. Обычное целое co знаком.
P.S. Про вашу систему я помню, математика отказывается результаты округлять. Поэтому надо вручную считать, a это для меня не так просто. :wall:
Ha том же Паскале это не должно быть трудно. Что сейчас имеют в виду, когда говорят "писать на Паскале"?
Мне как раз всегда казалось, что пощупать это всё "руками" -- самое интересное.
Последний раз редактировалось da67 30 ноя 2019, 10:42, всего редактировалось 1 раз.
Причина: test


Вернуться в «Физика»

Кто сейчас на форуме

Количество пользователей, которые сейчас просматривают этот форум: нет зарегистрированных пользователей и 35 гостей