29. Странно работают некорректные (и некоторые корректные) арифметические операции.
Ниже пример полностью рабочего кода с непредсказуемыми результатами.

Ох... Сущностей хоть отбавляй. Часть не доделана. Часть уже не нужна. Там еще управление портами есть. Просто теперь отключено. В левом верхнем углу есть две ненужные выезжающие панельки, на одной написано myROBOT, на другой версия. Раньше на верхней были нарисованные светодиодики, показывающие состояние параллельного порта, а на нижней — управление последовательным портом. В языке были специальные команды. Всё это хозяйство позволяло программировать роботов или сделать ёлочку новогоднюю с бегущими огнями из светодиодов. (Из "атавизмов" сейчас осталась сущность "датчик".) Вот на этой странице https://myrobot.ru/stepbystep/r_firstbot1.php есть в конце видеоролик с роботом. Так этот робот ездил на самом деле по программе, работающей из GameLogo.

Это к вопросу, что делает GameLogo на сайте про роботов.

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

И как это я умудрился еще и забыть про массивы в справке?

Огромное Вам спасибо за найденные неточности, ошибки и баги. Я Вам очень признателен за помощь. Постараюсь на днях всё исправить.

Про сущности понятно, не знал, что все так серьезно

30. Странно работает ф-я round (не описано, как точно она должна работать, обычно есть нюансы, но тут точно неверно). Для чисел с 0.5 через имеем неверный результат в половине случаев, например:

round(1.5) = 2

round(2.5) = 2

round(3.5) = 4

round(4.5) = 4

31. Дробные числа могут выводиться иногда с разделителем "," вместо ".". Пример:

Прошу прощения, был занят. Сегодня-завтра всё постараюсь поправить.
Относительно пункта 30.
Это стандартное округление по Гауссу. Используется для того, чтобы избежать серийного накопления погрешности. Так часто работает round, например, в Питоне начиная с 3 версии.

Вот пример суммы ваших чисел: 1.5 + 2.5 + 3.5 +4.5 = 12.
Если round по Гауссу, то round(1.5) + round(2.5) + round(3.5) + round(4.5) будет равен тоже 12.
А если используется обычное математическое округление, то сумма округленных Ваших чисел будет равна 14.
round(1.5) + round(2.5) + round(3.5) + round(4.5) = 14
Округление по Гауссу используют при банковских вычислениях, поэтому его еще называют банковским.

Но если Вы считаете, что должно быть 14 , я поправлю.

Всё поправил. Спасибо Вам огромное за такое внимательное исправление моих ошибок.

30. Придумал как выйти из положения: round сделал как в математике, а для округления по Гауссу добавил функцию roundg.

29. Это фича была такая. Она описана в четвёртом абзаце на странице "Почему GameLogo?"

Изучил проблему с округлением, спасибо за ликбез, но пришлось лезть еще глубже и изучать как это сделано в разных языках Возможно изначальный вариант и был идеологически верным. Поэтому не буду утверждать, как нужно делать по умолчанию. Но все же для "детского" языка наверное обычное математическое округление будет более очевидным (собственно так этот вопрос и возник). Причем я где-то быстро проверил, как должна работать функция округления, уже и не вспомню где проверял, возможно это был LibreOffice, ф-я ROUND(X;0) - округляет по правилам математики. Скорее всего популярные электронные таблицы округляют так (Excel раньше делал так же), а многие языки программирования - кто во что горазд. Как правило в ЯП куча ф-ий округления, но их поведение обычно документируется, чтобы выбрать верную (хотя и не всегда).
Проверил пару вариантов Basic, округляют так же, как и предыдущая версия GameLogo, хотя в справке говорится просто про ближайшее целое (без уточнений).
Лично мне текущий вариант с двумя функциями нравится больше, но как правильно для всех, судить не возьмусь.

* Кстати, для функций в справке возможно стоит описать их синтаксис, типа int(x), т.к. иначе может возникнуть непонимание у начинающих.


31. Есть ошибки с порядком действий и с буквой E в записи чисел (если это вообще предусмотрено):



Выводят:

3,0517578125E25

5E+15

20

Всё поправил. Получилась версия 1.6.10
Снова огромное спасибо за Вашу помощь.



Как-то не очень соображу, как это просто написать, чтобы не было сложно. Может быть, Вы предложите пример строки для функции Int?

Теперь, наверное, стоит вставить логические операции И и ИЛИ в условиях. Возрастной порог освоения множественных критериев, вроде бы, снижается. Как Вы считаете?

Спасибо за 1.6.10

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

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

В списке можно так и написать:

sin(X) - вычисляет синус угла X (тут еще нужно указать единицу измерения, т.к. сейчас в справке это не указано)

Либо можно сделать все проще и описать ф-и так (так сделано в Small Basic):

int(число)

sin(угол)

Так наверное даже проще и понятнее.

Там отдельно описывается сначала имя ф-ии и что она делает (т.е. примерно как сейчас в Game Logo), затем ее вид с параметрами, описание параметра и что ф-я возвращает.

Пример оттуда:


В идеале для функций, где могут быть "неожиданные" результаты, нужно более подробное описание, можно с примерами (например int с отрицательными числами, round с отрицательными и 0.5 итп.)


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

Довольно объемно получится с математикой. Справкой будет неудобно пользоваться (очень много прокручивать). Попробую засунуть в спойлер.

Об И и ИЛИ был разговор, но мне казалось, что освоение вложенных конструкций на первом этапе более важное дело. Поэтому не вставлял возможность использования И и ИЛИ в условный оператор. Теперь время меняется, потребности меняются, взгляды тоже меняются. Буду добавлять.

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

Сейчас в целом и так все понятно, кроме синтаксиса.

Про И/ИЛИ: никто же не заставляет ими пользоваться, кто считает это сложным, можно просто опустить данный момент.

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

И и ИЛИ сел делать.
Спасибо большое, надеюсь, Вы не оставите меня, когда И и ИЛИ будут готовы.
Сделал на сайте описание всех функций.
Во встроенной справке указал синтаксис и единицы измерения.
Каплецвет поправил (я вообще не знаю, откуда он такой кривой взялся). Теперь он нормальный.

Постараюсь помочь в тестировании

Некоторые замечания:
* Может стоит в справке выделить жирным главное во фразе "Чтобы вычислить квадратный корень", чтобы бросалось в глаза.
* В примере "Случайный рисунок.txt" есть код:

* На сайте на странице "Черепашья математика" зеленым цветом неверное утверждение:

* Ошибка в справке на сайте (+ возможно требуется более корректное описание функции):

На самом деле: -4

32. В файлах примеров найдены такие работающие вещи:
32.1. "направо100", "повторить86" - в целом ничего странного, что они работают, может и не стоит трогать, тут ничего не скажу, но в "образцовых примерах" наверное лучше писать через пробел
32.2. Используется и работает "пауза" без аргумента. Наверное очередной архаизм, либо надо задокументировать, что так можно и зачем.

33. Баг в языке. Работает следующий код:

Результат: 2511

34. Еще баг, появился в v.1.6.9: выдается ошибка в команде "пиши", когда после арифметического выражения (или числа) есть строка. Пример:

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

35. Извлекаются корни четной степени из отрицательных чисел в переменных:

Хотя такой вариант работает верно, приводит к сообщению об ошибке:


** Не работают корни нечетной степени их отрицательных чисел, например:

Хотя это мало где работает верно. Наверное не стоит лезть в эти дебри в Лого. Кто до этого дошел, напишет, чтобы было правильно

Всё поправил.
32.2 Добавил в начало справки: "Если аргумент не задан, то он считается равным нулю". В начало учебника добавил: "Число или числовое выражение, которое указывает черепашке сколько шагов пройти или на какой угол повернуть, называется аргументом команды. Если аргумент не задан, то черепашка считает его равным нулю".
35. Попробовал сделать возведение в дробную степень отрицательных чисел (корни нечетной степени), но из-за проблем с точностью для десятичного представления дробей выползают двузначности: считать ли целым, если в десятом знаке не ноль? Пока просто убрал.

И и ИЛИ сделаю в ближайшее время.

Я Вам очень признателен, я бы без Вас столько бы "архаизмов" не выловил. Удивляюсь Вашей способности и радуюсь.

35. Думаю проще просто запретить извлекать любые корни из отрицательных чисел путем возведения в степень, задокументировав данный момент.
Если бы была функция извлечения корня с целочисленным аргументом аргумента степени типа root(-1,3), тогда можно было бы сделать корректно, но оно тут ни к чему.
Я проверил, как работает возведение степени в нескольких языках, в большинстве все плохо, поэтому нет смысла пытаться кого-то переплюнуть. Например, при возведении в степень -1 в степень 1/3 большинство выдало аналог NAN, что неплохо, но кое-кто выдал даже 0.

Учитывая, что большинство языков было интерпретаторами и степень задавалась в виде 1/3 или 1.0/3.0, то у них был шанс сделать верное возведение в степень хотя бы в явно числовых выражениях, где не использовались переменные.

Если есть сильное желание, то можно реализовать возведение отрицательных чисел в нечетную степень именно когда она задана в виде обычной дроби типа 1/3 или 1/5. Но это много мороки и скорее всего никто не оценит. Разве что выдвигать это как огромное преимущество над другими языками


36. Если после команды "пиши" есть 2 апострофа (не обязательно последовательно), выдаются ошибки (разные):



** Неплохо было бы отформатировать вывод сообщений об ошибках и сделать их однообразным. Например на отдельных строках (не обязательно так, просто пример):
Строка в которой произошла ошибка
Описание ошибки
(# ошибки)

Номер ошибки наверное начинающему программисту вообще ни о чем не говорит и практически не нужен. Поэтому возможно стоит перенести его в конец сообщения (или на новую строку после него), чтобы не отвлекало.