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

@Juarez2000 · Регистрация: 06.09.2010

Студворк — интернет-сервис помощи студентам

Люди, кто разбирается в массивах, помогите пожалуйста написать программу на pascale буду благодарен):

В одномерном массиве переставить элементы таким образом, чтобы сначала шли все отрицательные, затем нулевые, затем положительные, но порядок внутри каждой из этих групп сохранился.
Требования к следующим программам: Код программы должен содержать процедуры и функции. Допускается наличие только одних процедур, либо только одних функций, однако студент должен объяснить целесообразность такого выбора.

Массивы не понимаю, я передыдущую программу ели написал)):
Заданы два целых числа М и N. Найти сумму М последних цифр числа N.

Pascal
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
Uses WinCRt;
Var
i,n,s: Integer;
arr: Array[1..10000] of integer;
Begin
 Read(n);
 For i:= 1 to n do
 Begin
 Read(arr[i]);
 End;
  For i:=1 to n do
   Begin
    If arr[i]<0 Then
    Begin
    s:=arr[i];
    End;
    End;
    write('Последний отрицательный элемент: ',s);
    writeln;
  For i:=1 to n do
  Begin
   If (odd(arr[i])) then
    Begin
     arr[i]:=s;
     End;
     write(arr[i]: 3);
     End;
End.

@Puporev · 09.09.2010, 12:46

Pascal
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
uses crt;
const nmax=100;
type mas=array[1..nmax] of integer;
{процедура создания и и вывода на экран исходного массива, такие действия не возможны в функции
 типом ее результата не может быть массив}
procedure Vvod(var a:mas;var n:byte);
var i:byte;
begin
repeat
write('Размер массива до ',nmax,' = ');
readln(n);
until n in [1..nmax];
writeln('Исходный массив:');
for i:=1 to n do
   begin
     a[i]:=random(8)-4;
     write(a[i],' ');
   end;
writeln;
writeln;
end;
{процедура перестановки и вывода результата, причина выбора таже}
procedure Sort(var a:mas;var n:byte);
var i,j,k:byte;
    x:integer;
begin
{отрицательные вперед}
k:=0;
for i:=1 to n do
if a[i]<0 then
  begin
    k:=k+1;
    x:=a[i];
    for j:=i downto k+1 do
    a[j]:=a[j-1];
    a[k]:=x;
  end;
{положительные в конец}
k:=0;
for i:=n downto 1 do
if a[i]>0 then
  begin
    k:=k+1;
    x:=a[i];
    for j:=i to n-k do
    a[j]:=a[j+1];
    a[n-k+1]:=x;
  end;
writeln('Перестановка:');
for i:=1 to n do
write(a[i],' ');
readln
end;
var a:mas;
    n:byte;
begin
clrscr;
randomize;
Vvod(a,n);
Sort(a,n);
end.

@Puporev · 09.09.2010, 12:51

Сообщение от Juarez2000

Заданы два целых числа М и N. Найти сумму М последних цифр числа N.

Juarez2000, вы что лепите? Какое отношение имеет эта задача к вашему коду и к этой теме? Лишь бы что-то ляпнуть, чтоб показать свою ученость?

Добавлено через 1 минуту

Сообщение от Tronix

и крутить его туда сюда как связный список

Да вы даже списки знаете? А что же такой примитив написать не можете сами?

@Juarez2000 · 09.09.2010, 12:51 **[ТС]**

Сообщение от Puporev

Juarez2000, вы что лепите? Какое отношение имеет эта задача к вашему коду и к этой теме? Лишь бы что-то ляпнуть, чтоб показать свою ученость?

Добавлено через 1 минуту

Да вы даже списки знаете? А что же такой примитив написать не можете сами?

Я не собирался ляпнуть свою ученость

@Puporev · 09.09.2010, 13:15

Кстати "свой" код вы скопипастили здесь.
https://www.cyberforum.ru/post947454.html
Нехорошо так начинать, со сплошного вранья.

@Juarez2000 · 09.09.2010, 13:21 **[ТС]**

Я не то скопировал.

Надо было это

Pascal
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Program Zadacha 1;
var
m, n, s, i: integer;
begin
writeln ('Введите число m');
readln (m);
writeln ('Введите число n');
readln (n);
s := 0;
for i := 1 to m do
begin
s := s + n mod 10;
n := n div 10;
end;
writeln ('Сумма = ', s);
end.

@lexus_ilia · 09.09.2010, 15:32

Tronix, ой списки нигде не используются в таком виде в котором их дают? Да Вы что, а откуда такая уверенность, списки (их разновидности), деревья и прочие интересные вещи используются, в большом круге решения задач.
Ну давайте рассмотрим некотрые примеры - вот есть функция написанная разработчиками (например microsoft разрабатывали свою Visual Studi'ю), как можно утверждать, что они нигде не использовали списки/очереди/стеки/деки/деревья? Ведь есть даже библиотека для работы со списками. Просто уже все написано и их остается лишь использовать.
Списки - это очень приятная вещь, рассмотрим например какое-нибудь сетевое приложение. Приходят Вам пакеты в большом количестве, а Вам требуется их обработать по порядку, есть несколько вариантов - использовать массивы, а можно и использовать списки. Теперь посмотрите на преимущество, обработали Вы первые 50 пакетов по очереди, и тут Вам следует вернуться на пакет где были какие-то данные - если бы был массив, то надо бы было идти назад, заводить лишний счетчик и искать требуемый элемент, а т.к. у Вс есть список и один указатель, то Вы спокойно "пробегаете" назад по списку, пока не конец или пока не нашли нужные данные.
А экономия памяти? А что по поводу того, что некоторые системы имеют разное представление о выделении памяти (для массивов), и где-то она резервируется, а потом выделяется, а где-то она ищется и резервируется и выделяется "по кускам", а когда у Вас есть список, Вы выделяете по одному элементу, не заморачиваясь о способе выделения массивов.
А что же по поводу безопасности? Ведь все библиотеки работы с массивами имеют готовые функции/методы по выводу всего массива, никто конечно не запрещает Вам написать свою библиотеку только с нужными вам функциями, но опять же есть готовые библиотек по работе со списками, где описан только основной метод работы (LIFO, FIFO) и там уже надо самому дописывать треубемые функции (если они конечно нужны).
А если рссмотреть деревья, то как они отлично выполняют поиск, они прямо для этого созданы. А что же по поводу нахождения пути между точками? Посмотрю я на Вас как Вы будете используя динамическое программирование и ломание головы искать способ нахождения оптимального пути (одна из разновидностей задач), а так взяли дерево, погуглили по готовым кодам, заюзали, дополнили своим и вот - готовая функция/метод для использования.
Я не сторонник использования списков (и т.д.) везде, нет конечно, большой круг задач решается намного проще используя массивы/файлы. Я не говорю, что знание списков очень важно для программиста, можно быть программистом и не очень понимать в списка и во всем таком, но все равно столкнетесь с ними и изучите, никуда не денетесь.
Так что не надо говорить то, в чем Вы не полностью осведомлены.
И да, готов выслушивать критику, которая имеет подтвержение.
С Уважением, lexus_ilia

Не по теме:

Большая часть сказанного имеет силу для языков программирования C ориетнированных

@Puporev · 09.09.2010, 15:49

Сообщение от lexus_ilia

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

Ну и в чем разница? В заведении счетчика и все.

@Tronix · 09.09.2010, 16:32

Сообщение от lexus_ilia

Tronix, ой списки нигде не используются в таком виде в котором их дают? Да Вы что, а откуда такая уверенность, списки (их разновидности), деревья и прочие интересные вещи используются, в большом круге решения задач.

Ну кто же спорит, что используются деревья и разновидности списков? Обращаю Ваше внимание на слово "разновидности", кстати. Но вот Вы мне скажите, так между нами, вы хоть раз в жизни использовали стек? Не тот, который в ассемблере, а так как его дают на лабах в ПТУ/школе/на курсах кулинарок? Ну там допустим процедура положить элемент в стек, вытащить элемент из стека? Лично я такого случая не помню. Несомненно, что преподаватели все правильно делают. Таким образом человек знакомится с пониманием стека. Но в таком виде он нигде больше никогда не используется. Согласны?

Сообщение от lexus_ilia

Ну давайте рассмотрим некотрые примеры - вот есть функция написанная разработчиками (например microsoft разрабатывали свою Visual Studi'ю), как можно утверждать, что они нигде не использовали списки/очереди/стеки/деки/деревья? Ведь есть даже библиотека для работы со списками. Просто уже все написано и их остается лишь использовать.

И тут я не спорю. Откуда я могу знать чего там индусы накодили в майкрософте? Про индусов шутка конечно, вижуал студиа на удивление хороший продукт. Но библиотеки больше относятся к Си, нежели к паскалю. Паскаль это как-бы сказать так.. Ну почему-то так повелось, что мало кто использовал в паскале чужие библиотеки (модули). И велосипедов было изобретено не мало.

Сообщение от lexus_ilia

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

Пока я буду "пробегать" назад и искать (читай сравнивать) каждый элемент, я все новые пакеты потеряю

В том то и главная беда списков - общая тромознутость. Поиск элемента - цикл+сравнение, удаление элемента и вставка нового элемента - опять бегаем туда сюда и чего-то ищем. Если у нас список (массив) например на 2 гига памяти и требуется тупо молотить в цикле числа из него (ну скажем вычислять какие-нибуть милионны знаков числа Pi) то долго мы будем по списку бегать. Плюс к этому всему я уж не говорю что для каждой функции списка нужна процедура, вызов которой из основной программы опять накладывает дополнительные расходы - передача параметров процедуре, сохранение в стеке основных регистров - по выходу из процедуры все восстановить из стека. Это с одной стороны. Тормознуто. С другой - код в принципе читается и обслуживается легче.

Сообщение от lexus_ilia

А экономия памяти? А что по поводу того, что некоторые системы имеют разное представление о выделении памяти (для массивов), и где-то она резервируется, а потом выделяется, а где-то она ищется и резервируется и выделяется "по кускам", а когда у Вас есть список, Вы выделяете по одному элементу, не заморачиваясь о способе выделения массивов.

Экономия памяти? Спорно, особенно для случая когда мы точно знаем что у нас будет список или массив для такого-то количества элементов. Ну скажем 100. В случае со списком мы будем хранить 100 самих элементов, плюс сто указателей к ним. В случае с массивом мы будем хранить 100 элементов и одну переменную - индексную. Как говорится разница очевидна.
И еще раз напомню что мы говорим о x86 архитектуре и Pascal'е. В данном случае вообще Borland Pascal.

Сообщение от lexus_ilia

Я не сторонник использования списков (и т.д.) везде, нет конечно, большой круг задач решается намного проще используя массивы/файлы. Я не говорю, что знание списков очень важно для программиста, можно быть программистом и не очень понимать в списка и во всем таком, но все равно столкнетесь с ними и изучите, никуда не денетесь.

Ну и я тоже не сторонник их использовать. Видите, нас уже двое, еще чуть-чуть и будет статистика

Если можно обойтись без них - лучше обойтись без них.

Сообщение от lexus_ilia

Так что не надо говорить то, в чем Вы не полностью осведомлены.
И да, готов выслушивать критику, которая имеет подтвержение.

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

С Уважением, Tronix

@Puporev · 09.09.2010, 16:38

Сообщение от Tronix

Ну и я тоже не сторонник их использовать. Видите, нас уже двое

Уже трое.
Но давайте холивар прекратим, или, если это интересно, вынесем в отдельную тему.

Новые блоги и статьи Все статьи Все блоги /
Символьное дифференцирование igorrr37 13.02.2026 / * Логарифм записывается как: (x-2)log(x^2+2) - означает логарифм (x^2+2) по основанию (x-2). Унарный минус обозначается как ! */ #include <iostream> #include <stack> #include <cctype>. . .	Камера Toupcam IUA500KMA Eddy_Em 12.02.2026 Т. к. у всяких "хикроботов" слишком уж мелкий пиксель, для подсмотра в ESPriF они вообще плохо годятся: уже 14 величину можно рассмотреть еле-еле лишь на экспозициях под 3 секунды (а то и больше),. . .	И ясному Солнцу zbw 12.02.2026 И ясному Солнцу, и светлой Луне. В мире покоя нет и люди не могут жить в тишине. А жить им немного лет.	«Знание-Сила» zbw 12.02.2026 «Знание-Сила» «Время-Деньги» «Деньги -Пуля»
SDL3 для Web (WebAssembly): Подключение Box2D v3, физика и отрисовка коллайдеров 8Observer8 12.02.2026 Содержание блога Box2D - это библиотека для 2D физики для анимаций и игр. С её помощью можно определять были ли коллизии между конкретными объектами и вызывать обработчики событий столкновения. . . .	SDL3 для Web (WebAssembly): Загрузка PNG с прозрачным фоном с помощью SDL_LoadPNG (без SDL3_image) 8Observer8 11.02.2026 Содержание блога Библиотека SDL3 содержит встроенные инструменты для базовой работы с изображениями - без использования библиотеки SDL3_image. Пошагово создадим проект для загрузки изображения. . .	SDL3 для Web (WebAssembly): Загрузка PNG с прозрачным фоном с помощью SDL3_image 8Observer8 10.02.2026 Содержание блога Библиотека SDL3_image содержит инструменты для расширенной работы с изображениями. Пошагово создадим проект для загрузки изображения формата PNG с альфа-каналом (с прозрачным. . .	Установка Qt-версии Lazarus IDE в Debian Trixie Xfce volvo 10.02.2026 В общем, достали меня глюки IDE Лазаруса, собранной с использованием набора виджетов Gtk2 (конкретно: если набирать текст в редакторе и вызвать подсказку через Ctrl+Space, то после закрытия окошка. . .

@Puporev Почетный модератор 64314 / 47610 / 32743 Регистрация: 18.05.2008 Сообщений: 115,167
	09.09.2010, 13:15
	Кстати "свой" код вы скопипастили здесь. https://www.cyberforum.ru/post947454.html Нехорошо так начинать, со сплошного вранья. 0

@lexus_ilia 3067 / 727 / 69 Регистрация: 24.09.2008 Сообщений: 1,531
	09.09.2010, 15:32
	Tronix, ой списки нигде не используются в таком виде в котором их дают? Да Вы что, а откуда такая уверенность, списки (их разновидности), деревья и прочие интересные вещи используются, в большом круге решения задач. Ну давайте рассмотрим некотрые примеры - вот есть функция написанная разработчиками (например microsoft разрабатывали свою Visual Studi'ю), как можно утверждать, что они нигде не использовали списки/очереди/стеки/деки/деревья? Ведь есть даже библиотека для работы со списками. Просто уже все написано и их остается лишь использовать. Списки - это очень приятная вещь, рассмотрим например какое-нибудь сетевое приложение. Приходят Вам пакеты в большом количестве, а Вам требуется их обработать по порядку, есть несколько вариантов - использовать массивы, а можно и использовать списки. Теперь посмотрите на преимущество, обработали Вы первые 50 пакетов по очереди, и тут Вам следует вернуться на пакет где были какие-то данные - если бы был массив, то надо бы было идти назад, заводить лишний счетчик и искать требуемый элемент, а т.к. у Вс есть список и один указатель, то Вы спокойно "пробегаете" назад по списку, пока не конец или пока не нашли нужные данные. А экономия памяти? А что по поводу того, что некоторые системы имеют разное представление о выделении памяти (для массивов), и где-то она резервируется, а потом выделяется, а где-то она ищется и резервируется и выделяется "по кускам", а когда у Вас есть список, Вы выделяете по одному элементу, не заморачиваясь о способе выделения массивов. А что же по поводу безопасности? Ведь все библиотеки работы с массивами имеют готовые функции/методы по выводу всего массива, никто конечно не запрещает Вам написать свою библиотеку только с нужными вам функциями, но опять же есть готовые библиотек по работе со списками, где описан только основной метод работы (LIFO, FIFO) и там уже надо самому дописывать треубемые функции (если они конечно нужны). А если рссмотреть деревья, то как они отлично выполняют поиск, они прямо для этого созданы. А что же по поводу нахождения пути между точками? Посмотрю я на Вас как Вы будете используя динамическое программирование и ломание головы искать способ нахождения оптимального пути (одна из разновидностей задач), а так взяли дерево, погуглили по готовым кодам, заюзали, дополнили своим и вот - готовая функция/метод для использования. Я не сторонник использования списков (и т.д.) везде, нет конечно, большой круг задач решается намного проще используя массивы/файлы. Я не говорю, что знание списков очень важно для программиста, можно быть программистом и не очень понимать в списка и во всем таком, но все равно столкнетесь с ними и изучите, никуда не денетесь. Так что не надо говорить то, в чем Вы не полностью осведомлены. И да, готов выслушивать критику, которая имеет подтвержение. С Уважением, lexus_ilia Не по теме: Большая часть сказанного имеет силу для языков программирования C ориетнированных 0