PureBasic - форум |
Привет, Гость! Войдите или зарегистрируйтесь.
Вы здесь » PureBasic - форум » Вопросы по PureBasic » вопрос о точности типов данных
При вводе числовых данных с типом .f иногда (т.е не всегда) в 8-10 знаках после запятой появляется мусор (еще значения).
А при вычитании, скажем, от значения угла 180 град (в радианах) #PI угол не 90 град, а 89.9999999и еще. На экран эти числа вывожу MessageRequester. Это так выводит или и считает? Конечно, считаю не траекторию полета, но напрягает. Или смириться?
Спасибо.
Отредактировано теано (17.05.2021 18:47:50)
Числа с плавающей точкой вычисляются с определенной погрешностью. https://habr.com/ru/post/266023/
Нужно использовать тип .d чтобы уменьшить погрешность.
Спасибо. Нервирует, собственно, не столько результат вычислений, сколько результат ввода данных. Пугает, что в некоторых случаях, значения увеличиваются, а в некоторых уменьшаются. Может, где-то не поставил нужный флажок?
PS. Пардон за возможные глупые вопросы, пытаюсь программировать уже "целых" 3 месяца.
PPS. И, чтобы не плодить новые темы. В старых версиях символом, обозначающем, что строка программы продолжается на другой строке было подчеркивание (не проверял -читал, что так). В 4.6 это не работает. Нужен другой символ или я что-то не так делаю? Спасибо.
подчёркивание в AutoIt3, а здесь просто на на новой строке писать, только знать, где. Перечисление параметров функции, после запятой перенос можно делать.
Round() - округлить до целого
Отредактировано AZJIO (19.05.2021 19:58:39)
Извините, а "AutoIt3" - это что? Опять пардон, "а здесь просто на на новой строке писать, только знать, где." Где? "Перечисление параметров функции, после запятой перенос можно делать." Попробовал - синтаксическая ошибка. Елки, что я делаю не так? Но, все равно, спасибо.
И еще, а как округлить до знака?
Отредактировано теано (19.05.2021 20:16:53)
Из справки
Многострочный код (продолжение команды на следующей строке)
Если строка кода содержит большое выражение, его можно разделить на несколько строк. Разделяемая строка в точке переноса должна заканчиваться одним из следующих операторов: Плюс ( + ); Запятая ( , ); Побитовое 'ИЛИ' ( | ); Логическое 'И' ( And ); Логическое 'ИЛИ' ( Or ); Логическое 'исключающее ИЛИ' ( Xor ).
ПримерКод:Text$ = "Very very very very long text" + #LF$ + "another long text" + #LF$ + " and the end of the long text" MessageRequester("Hello this is a very long title", "And a very long message, so we can use the multiline" + #LF$ + Text$, #PB_MessageRequester_Ok)
И еще, а как округлить до знака?
https://www.purebasic.com/documentation … /strf.html
https://www.purebasic.com/documentation … /strd.html
теано
Внутри программы нет смысла округлять, так как при арифметических действиях будут вычисляться значения до указанной ширины числа. При выводе в графический интерфейс (GUI) можно округлить превратив это в текст с нужным округлением, так как элементы GUI отображают информацию в виде текста. При взятии числа с GUI придётся опять превращать текст в число (ValD()) и оно опять будет иметь ширину согласно типу данных. Проблемы как видим не возникает, а округлять внутри программы это заведомо искажать результаты.
Да вопрос не точности при вычислениях. Ввожу данные StringGadget(2, 100, 2, 50, 20, StrF(Koord.f(2,3,0),3)) - 14.77 записываю в файл WriteStringN(1,strf(Koord.f(2,3,0),3)),#PB_Unicode), читаю из файла Koord.f(2,3,0)=valf(ReadString(0,#PB_Unicode). Вывожу MessageRequester("",StrF(Koord.f(2,3,0))) и получаю на экране 14.7700004578. Да, не траектория к Марсу, но странно.
И, видимо, у нас разные версии Basic, у меня 4.60. Разделяю на запятой MessageRequester("Ошибка",
"Файл не создан")
пишет "Синтаксическая ошибка". Может запятая должна быть в QWERTY-раскладке?
Понимаю, что с этим можно смириться, но как-то не фен-шуй.
Отредактировано теано (19.05.2021 23:10:21)
Вывожу MessageRequester("",StrF(Koord.f(2,3,0))) и получаю на экране 14.7700004578.
А если так?
MessageRequester("",StrF(Koord(2,3,0), 2))А если так?
Так выводит 14.77. Расширю вопрос - это неправильный вывод или мусор в числовом представлении? Как проверить, я не знаю. И, видимо забью на это. Всем спасибо.
теано
можешь объяснить почему 10/3 не получается красиво как хотелось бы? Вот тоже самое происходит с некоторыми числами в двоичной системе. Компьютер считает числа в двоичной системе, потом они отображаются в виде десятеричных. Причём 10 и 9.999999999999 фактически одинаковы, человеческое зрение не сможет отличить два шара разного диаметра 10 и 9.999999999999, человеческий слух не сможет различить громкость между 10 и 9.999999999999. Так почему же запись этих чисел так ломает? Это достаточно точные значения чтобы считать 9.999999999999 как 10, тем более вы признались что не вычисляете орбиту Марса. Вам ещё предстоит свыкнутся что вы не сможете считать большие числа, потому что результат может не поместиться в память. Свыкнуться выбирать ширину числа для какого либо вычисления. Например координаты монитора не превышают нескольких тысяч и всегда целое число, или код буквы не превышает 255, из этого нет необходимости выделять память для этого числа шире максимально допустимого. Хотя изначально хотелось бы вообще не заморачиваться и сколько присвоил значение, столько присвоил, но тогда бы компьютер работал нерационально, выделил бы гиг памяти на число, так сказать с запасом, надо было бы быть миллионером, чтобы память была миллион терабайт. Но чтобы комп всё-таки мог сделать вычисления не принуждая своего пользователя быть миллионером и была придумана определение ширины числа для определённого вида операции. А числа неокруглённые пугают только тех кто не понимает как это работает.
Кстати в AutoIt3 автор в описании пишет что для таких случаях у него есть внутренний корректирующий алгоритм чтобы числа типа 9.999999999999 автоматически показывать как 10.
Эта функция делает незначительную коррекцию чисел с плавающей точкой, учитывая неточность таких чисел. Например, выражение с плавающей точкой 0.7 + 0.2 + 0.1 создаёт число с плавающей точкой, но это не совсем 1.0. Функция Int() корректирует это отклонение, однако, в крайне редких случаях Int() возвращает неожиданное значение (шансы получить неожиданное значение меньше, чем если бы Int() не пыталась корректировать совсем).
Вы здесь » PureBasic - форум » Вопросы по PureBasic » вопрос о точности типов данных