Е каква е разликата между float/double и real?
Ей, заредил съм 2 пакета пуканки а ти ще финализираш шоуто с два поста! 
2Създадено на 17.11.2020, видяно: 1166 пъти. #19016
Разликата е в прецизността. Ти си човека завършил математика, ти ги разбираш. Ти си писал на де що процесорни архитектури съществуват. Аз съм чел презентации. И 2+2 не мога да сметна без ел. си таблица. Ако щеш ми вярвай, но не помня дори как се смятаха интеграли, ония простите от първи ред. В моя живот нищо от това не е застъпено.
=*=
Пърл си го казах ей тъй, щото си го обожавам и направи революция. А, ако не бяха залитнали в Raku, още щях да си го ползвам. Там наистина може(ше) да си най-оригиналния зидаро-мазач на строежа.
Реално в днешно време от към обработка на текст в него няма нищо, което го няма в други езици, хеле пък в природения му син PHP. Даже и за Ц вече има библиотека за регулярни изрази от не помня, колко дълго. Така и за останалите манипулации. При положение, че Лари да се свети името му, го е правил на Ц, а не на някаква извънземна технология, колкото и да има слухове по въпроса, няма как нещо ценно от него да не може да се пренесе (и вече да не е пренесено) навсякъде.
Реба Създадено на 17.11.2020, видяно: 1163 пъти. #19017
тя научната математика се прави с молив на хартия,не ти трябва изобщо компютър. компютъра е за приложна математика, а те приложенията са много, но общото между всички тях е че математическия код като дял от целия код е много малко.но дори и да беше много, това пак няма да промени нещата.
аз не знам какви са причините за употребата на фортран, но това че имал real type едва ли е сред тях. ето например компилаторите бачкат изключително интензивно с текст, като почнеш от парсването на командния ред, и стигнеш до основната им функция - парсването на кода, всичко е яко мазане върху стрингове. и на какво се пишат повечето използвани компилатори днес? ами май на език който изобщо няма тип за стринг в себе си. парадокс
Добре де, те числата с плаваща запетая нали трябва по някакъв начин да се представят и след като имаш ограничен обем памет с който да ги представяш, не би ли следвало изначално да означава че проблемът с прецизността винаги си е налице? То и у фортрана реал-а има точно същия проблем, това не идва от програмния език, а си е следствие от самата постановка.
10 не, но 5. C#, Python, T-SQL/PLSQL, JS, TS...
2Създадено на 17.11.2020, видяно: 1145 пъти. #19029
Да в света на микроуслугите и контейнерите, това стана проблем. Докато не се появиха всякакви като Убер с техните смахнати аджайли, света си свиркаше на монолитни жаби и не го ебеше. Сега вместо да стане по-просто, се усложни неимоверно.
Действителен проблем, виден дори за непрограмисти като мен.
Въпросчето не е за тебе, пък и не случайно писах 10, например ти си изпуснал html-то.
2Създадено на 17.11.2020, видяно: 1144 пъти. #19031
Е тогава е изпуснал и css :)
Единствения език, на който съм писал последните години е VBA и то дори не на Уфсъ, а на АОО. Толкова съм мизерен :P
Самата концепция за стринг е за улеснение на програмиста, като се има предвид че улеснението преебава производителността. С малки обеми това не е проблем, но разбира се става проблем в програми които парсват/изграждат големи обеми текстове или просто работят в много копия - нишки, приложения и т.н.
Мен ми изглеждаше малко тъпо целия спор, но гофи си каза че не е програмист, така че всичко си идва на мястото.
Има вероятност доста да харесаш руби въпреки че популярността която имаше покрай руби он рейлс вече е бледа сянка и цар джаваскрипт и дотнета рулират. За скриптване и протипване е шибан разкош, практично мултипарадигмено, може да се гушва с Ц АБИ-то без Ц екстеншъни с компилация, абе кеф :)
2Създадено на 17.11.2020, видяно: 1122 пъти. #19044
Сигурно би ми харесал Рубина, ако бях програмист, още повече, че моя пророк Стефан Кънев го проповядва от 12 години. Обаче аз съм прост и много глупав ламер. Не мога да работя с толкова сложни структури от данни като обекти. Искам най-много дробен масив и това е.
Пък и нямам за цел да написвам света. Искам просто да си улесня живота.
Относно пакетното изпълнение даже Bash си ми е напълно достатъчен, защото нуждите ми не са големи.
Все пак, благодаря за предложението!
Реба Създадено на 17.11.2020, видяно: 1121 пъти. #19045
впрочем проверих, типа реал на фортрана е "The usual default size for a REAL item with no size specified is 4 bytes" това е положението - най-обикновен флоат като тоя в С. сега, вадете тефтерите и моливите, да го разчепкваме въпроса със прецизните флоати ако гоните висока прецизност, най-най-"доброто" което го има широко достъпно е обикновения флоат но само в 32 битова х86 архитектура АМА! АМА! АМА! КАК ТАКА! - ами ей така. защо има кавички околодоброто - товапо-надолу, но сега да изясним техническите детайли. в 32 битова х86 обикновения 4 байтов флоат се смята върху копроцесора, който е реално 10 байтов, а не 4 байтов. ако имате до 8 локални променливи всичко влиза в копроцесора и сметките се извършват със кристална 80 битова прецизност. това е цели два байта повече от double, направо космос!
"ама това е много яко!" така е, това е от ония яки неща като безплатното образование, безплатните болници, държавните пенсии, абе тия като си младо наивно сукалче изглежда много яко, а като станеш стар белобрад старец виждаш че изобщо не е яко. мен лично тая висока прецизност ме е вкарвала в неприятности много пъти, изобщо имплицитните "добрини" са всъщност зло. самите числа с висока прецизност са пак зло, дори когато са експлицитни. така че имплицитната висока прецизност е двойно зло. как става така? първода почнем с имплицитната висока прецизност. начи, като влязоха масово х64 процесорите, тракера ми се напълни с едни бъг репорти които много си приличаха - специфична сцена прави проблем на 64 битов билд, а на 32 битов бачка пушка. самия проблем изобщо не звучеше еднакво във всеки отделен случай, от краш до странен резултат, но общото беше че винаги е само на 64 битов билд. като почнах да разследвам, излезе че винаги опираме до някакъв ког, който изглежда ето така float acc=0; for(int i=0;i<n;i++)acc+=F(i); acc/=n; тоя код очевидно смята средното на F(i), какво е F няма никакво значение, обикновено е масив с някакви данни. защо на 32 бита е ок, а на 64 не е ? не говорим за приемлива грешка от някви проценти, а за огромна грешка стигаща до пъти. причината е че сумирането на флоат работи прецизно само ако събираемите са от един порядък. при разлика от 7 порядъка на практика изобщо не работи. а тая разлика много лесно се достига кога - ами когато самите събираеми са много, дори и самите те да са близки като стойност. това е лекия случай, който само води до грешка. можем обаче да направим това float m=0,d=0; for(int i=0;i<n;i++){ m+=F(i); d+=F(i)*F(i); } m/=n; d/=n; d=sqrtf(d-m*m); <----------------NaN тука имаме хубавата възможност да получим нан, който е силно заразна стойност, и лесно отива до индекс в масив, който е математически "доказано" че не може да е извън ранга. и така на х64 имаме гърмеж,а на х86 всичко е бонбон така, а защо дабъла е зло дори когато е експлицитен? ами защото ако напиша float s=n1.Cross(n2); float c=sqrtf(1-s2); това с флоат ще гръмне още на тестовете във фирмата, а с дабъл ще гръмне чак при клиента след половин година употреба. затова, ако пишете математика - далеч от дабъл, освен в много неотложни ситуации
Разбира се, че е най-обикновен float. Нямам идея защо му четете каквото и да е на гофи, че и му отговаряте.
Останалото е очевидно за всеки, който е писал алгоритми за числени методи. Което означава, че е добре, че си го написал тук, защото не личи много хора да са го правили това. Проблемите с всичките IEEE 754 са големи, всяка година студентчетата имат разни проекти "как да групираме операциите, че да получим по-голяма точност".
Има един тип, Густафсон, който обикаля по университети и конференции да рекламира неговия формат (unum), който ще "реши" всички проблеми. Даже някои му се хващат на глупостите :)
Еми тук не всички са титуловани свръхексперти, нормално е да има хора дето просто им е интересно, това че имат някакви погрешни визии не е болка за умирачка, Джизъс е казал като имаш два БигМака дай един на ближния си, така и ние даваме знания.
Да, затова казах на Реба, че е добре че го е написал. Numerical stability е важно свойство на алгоритмите за числени методи, и това изобщо не е лесно. Което пък влиза в директно противоречие с твърдението на Реба, че математиката в научните симулации е малко.
Реба Създадено на 17.11.2020, видяно: 1080 пъти. #19077
аз твърдя че математиката в кой да е свързан с математика софтуер е малко (спрямо целия софтуер). например преди време като въвеждах един колега във феникса, ей така докато му обяснявам написах за илюстрация флуиден симулатор от нула, пред очите му. целия продукт обаче е писан години, и продължавада се пише.
