คำถามติดแท็ก floating-point

เป็นที่ทราบกันดีว่า NaNs เผยแพร่เลขคณิต แต่ฉันไม่พบการสาธิตดังนั้นฉันจึงเขียนการทดสอบเล็กน้อย: #include <limits> #include <cstdio> int main(int argc, char* argv[]) { float qNaN = std::numeric_limits<float>::quiet_NaN(); float neg = -qNaN; float sub1 = 6.0f - qNaN; float sub2 = qNaN - 6.0f; float sub3 = qNaN - qNaN; float add1 = 6.0f + qNaN; float add2 = qNaN …

300 c++  c  floating-point  ieee-754  icc 

ฉันมีค่า25.00ในแต่เมื่อฉันพิมพ์บนหน้าจอมันเป็นfloat ฉันจะแสดงค่าด้วยทศนิยมสองตำแหน่งได้อย่างไร25.0000000

296 objective-c  formatting  floating-point 

เหตุใดการเปลี่ยนลำดับผลรวมจึงให้ผลลัพธ์ที่แตกต่าง 23.53 + 5.88 + 17.64 = 47.05 23.53 + 17.64 + 5.88 = 47.050000000000004 ทั้งJavaและJavaScriptให้ผลลัพธ์เหมือนกัน ฉันเข้าใจว่าเนื่องจากวิธีการแสดงจำนวนจุดลอยตัวเป็นเลขฐานสองจำนวนตรรกยะบางส่วน ( เช่น 1/3 - 0.333333 ... ) จึงไม่สามารถแสดงได้อย่างแม่นยำ ทำไมการเปลี่ยนลำดับขององค์ประกอบจึงส่งผลต่อผลลัพธ์

294 java  javascript  floating-point 

เมื่อเปรียบเทียบลอยกับจำนวนเต็มคู่ของค่าบางอย่างใช้เวลานานในการประเมินมากกว่าค่าอื่น ๆ ที่มีขนาดใกล้เคียงกัน ตัวอย่างเช่น: >>> import timeit >>> timeit.timeit("562949953420000.7 < 562949953421000") # run 1 million times 0.5387085462592742 แต่ถ้าจำนวนลอยหรือจำนวนเต็มน้อยกว่าหรือใหญ่กว่าการเปรียบเทียบจะทำงานได้เร็วขึ้น: >>> timeit.timeit("562949953420000.7 < 562949953422000") # integer increased by 1000 0.1481498428446173 >>> timeit.timeit("562949953423001.8 < 562949953421000") # float increased by 3001.1 0.1459577925548956 การเปลี่ยนตัวดำเนินการเปรียบเทียบ (เช่นการใช้==หรือ>แทน) จะไม่ส่งผลกระทบต่อเวลาในลักษณะที่สังเกตเห็นได้ สิ่งนี้ไม่ได้เกี่ยวข้องกับขนาดเพียงอย่างเดียวเพราะการเลือกค่าที่มากขึ้นหรือน้อยลงอาจทำให้การเปรียบเทียบเร็วขึ้นดังนั้นฉันจึงสงสัยว่ามันจะลงไปในทางที่โชคร้ายเล็กน้อยที่บิตเรียงกัน เห็นได้ชัดว่าการเปรียบเทียบค่าเหล่านี้เร็วกว่าเพียงพอสำหรับกรณีใช้งานส่วนใหญ่ ฉันแค่อยากรู้ว่าทำไม Python ดูเหมือนจะต่อสู้กับค่าบางคู่มากกว่ากับคนอื่น

284 python  performance  floating-point  cpython  python-internals 

มีการหลายคำถามที่โพสต์เกี่ยวกับจุดลอยตัวแทน ตัวอย่างเช่นเลขทศนิยม 0.1 ไม่มีการแทนค่าไบนารีที่แน่นอนดังนั้นจึงเป็นอันตรายที่จะใช้ตัวดำเนินการ == เพื่อเปรียบเทียบกับตัวเลขทศนิยมอื่น ฉันเข้าใจหลักการที่อยู่เบื้องหลังการเป็นตัวแทนจุดลอยตัว สิ่งที่ฉันไม่เข้าใจคือทำไมจากมุมมองทางคณิตศาสตร์ตัวเลขทางด้านขวาของจุดทศนิยมคือ "พิเศษ" ที่อยู่ทางซ้ายหรือไม่ ตัวอย่างเช่นหมายเลข 61.0 มีการแทนค่าไบนารี่ที่แน่นอนเนื่องจากส่วนที่สำคัญของจำนวนใด ๆ นั้นแน่นอนเสมอ แต่หมายเลข 6.10 นั้นไม่ถูกต้อง ทั้งหมดที่ฉันทำคือย้ายทศนิยมหนึ่งตำแหน่งและทันใดนั้นฉันก็ไปจาก Exactopia ไปยัง Inexactville ในทางคณิตศาสตร์ไม่ควรมีความแตกต่างที่แท้จริงระหว่างสองตัวเลข - มันเป็นแค่ตัวเลข ในทางตรงกันข้ามถ้าฉันย้ายทศนิยมหนึ่งตำแหน่งในทิศทางอื่นเพื่อสร้างหมายเลข 610 ฉันก็ยังอยู่ใน Exactopia ฉันสามารถไปในทิศทางนั้นได้ (6100, 610000000, 610000000000000) และพวกเขายังคงแน่นอนถูกต้องแน่นอน แต่ทันทีที่ทศนิยมผ่านเกณฑ์บางจำนวนจะไม่แน่นอน เกิดอะไรขึ้น? แก้ไข: เพื่อชี้แจงผมต้องการที่จะอยู่ห่างจากการอภิปรายเกี่ยวกับการแสดงมาตรฐานอุตสาหกรรมเช่น IEEE และติดกับสิ่งที่ผมเชื่อว่าเป็นวิธีทางคณิตศาสตร์ "บริสุทธิ์" ในฐานที่ 10 ค่าตำแหน่ง ได้แก่ : ... 1000 100 10 …

284 math  floating-point 

บางครั้งประเภทข้อมูล Activerecord ทำให้ฉันสับสน เอ่อบ่อย หนึ่งในคำถามที่นิรันดร์ของฉันคือสำหรับกรณีที่กำหนด ฉันควรใช้:decimalหรือ:float? ฉันเคยเจอลิงก์นี้บ่อยครั้งActiveRecord:: ทศนิยม vs: float? แต่คำตอบไม่ชัดเจนพอที่ฉันจะมั่นใจ: ฉันได้เห็นหลายกระทู้ที่ผู้คนแนะนำให้แบนไม่เคยใช้ทศนิยมและใช้ทศนิยมเสมอ ฉันเคยเห็นคำแนะนำจากบางคนเพื่อใช้โฟลตสำหรับการใช้งานทางวิทยาศาสตร์เท่านั้น นี่คือตัวอย่างบางกรณี: Geolocation / ละติจูด / ลองจิจูด: -45.756688, 120.5777777... อัตราส่วน / ร้อยละ: 0.9, 1.25, 1.333, 1.4143... ฉันเคยใช้:decimalในอดีต แต่ฉันพบว่าการจัดการกับBigDecimalวัตถุใน Ruby นั้นไม่สะดวกสบายเมื่อเทียบกับการลอย ฉันรู้ว่าฉันสามารถใช้:integerเพื่อเป็นตัวแทนเงิน / เซ็นต์ได้เช่นกัน แต่มันก็ไม่เหมาะสำหรับกรณีอื่น ๆ เช่นเมื่อปริมาณที่ความแม่นยำอาจเปลี่ยนแปลงไปตามกาลเวลา ข้อดี / ข้อเสียของการใช้แต่ละข้อมีอะไรบ้าง มีกฎอะไรบ้างที่จะรู้ว่าควรใช้แบบไหน

283 ruby-on-rails  types  floating-point  decimal  rails-activerecord 

เห็นได้ชัดว่ารหัสต่อไปนี้ผิด มีปัญหาอะไร? i <- 0.1 i <- i + 0.05 i ## [1] 0.15 if(i==0.15) cat("i equals 0.15") else cat("i does not equal 0.15") ## i does not equal 0.15

273 r  floating-point  floating-accuracy  r-faq 

ฉันจะสร้างการสุ่มลอยตัวใน C ++ ได้อย่างไร ฉันคิดว่าฉันสามารถเอาแรนด์จำนวนเต็มแล้วหารด้วยบางอย่างนั่นจะเพียงพอหรือไม่

271 c++  random  floating-point 

ทำไมการเปรียบเทียบค่า NaN จึงแตกต่างจากค่าอื่น ๆ ทั้งหมด นั่นคือการเปรียบเทียบทั้งหมดกับโอเปอเรเตอร์ ==, <=,> =, <,> โดยที่หนึ่งหรือทั้งสองค่าเป็น NaN จะส่งคืนค่าเท็จซึ่งตรงกันข้ามกับพฤติกรรมของค่าอื่น ๆ ทั้งหมด ฉันคิดว่าสิ่งนี้จะทำให้การคำนวณเชิงตัวเลขง่ายขึ้น แต่ฉันไม่สามารถหาเหตุผลที่ระบุไว้อย่างชัดเจนไม่ได้แม้แต่ในบันทึกการบรรยายเกี่ยวกับสถานะของ IEEE 754โดย Kahan ซึ่งกล่าวถึงการตัดสินใจออกแบบรายละเอียดอื่น ๆ พฤติกรรมเบี่ยงเบนนี้ทำให้เกิดปัญหาเมื่อทำการประมวลผลข้อมูลอย่างง่าย ตัวอย่างเช่นเมื่อเรียงลำดับรายการเรคคอร์ด wrt บางฟิลด์มูลค่าจริงในโปรแกรม C ฉันจำเป็นต้องเขียนรหัสพิเศษเพื่อจัดการ NaN เป็นองค์ประกอบสูงสุดมิฉะนั้นอัลกอริทึมการเรียงลำดับอาจกลายเป็นสับสน แก้ไข: คำตอบจนถึงทุกคนยืนยันว่ามันไม่มีความหมายในการเปรียบเทียบ NaNs ฉันเห็นด้วย แต่นั่นไม่ได้หมายความว่าคำตอบที่ถูกต้องเป็นเท็จ แต่จะเป็น Not-a-Boolean (NaB) ซึ่งโชคดีที่ไม่มีอยู่จริง ดังนั้นทางเลือกของการคืนค่าจริงหรือเท็จสำหรับการเปรียบเทียบอยู่ในมุมมองของฉันโดยพลการและสำหรับการประมวลผลข้อมูลทั่วไปมันจะมีประโยชน์ถ้ามันเป็นไปตามกฎหมายปกติ (reflexivity ของ ==, trichotomy ของ <, ==,>) ซึ่งพึ่งพากฎหมายเหล่านี้จะสับสน ดังนั้นฉันขอความได้เปรียบที่เป็นรูปธรรมของการละเมิดกฎหมายเหล่านี้ไม่ใช่เพียงการให้เหตุผลเชิงปรัชญา แก้ไข …

267 floating-point  comparison  nan  ieee-754  iec10967 

ฉันสามารถตั้งชื่อข้อดีสามข้อให้กับการใช้double(หรือfloat) แทนdecimal: ใช้หน่วยความจำน้อยลง เร็วขึ้นเนื่องจากการดำเนินการทางคณิตศาสตร์ของจุดลอยตัวได้รับการสนับสนุนโดยตัวประมวลผล สามารถแสดงช่วงของตัวเลขที่มากขึ้น แต่ข้อดีเหล่านี้ดูเหมือนจะใช้เฉพาะกับการคำนวณการดำเนินการที่เข้มข้นเช่นที่พบในซอฟต์แวร์การสร้างแบบจำลอง แน่นอนไม่ควรใช้คู่ผสมเมื่อต้องการความแม่นยำเช่นการคำนวณทางการเงิน ดังนั้นมีเหตุผลเชิงปฏิบัติใดที่เคยเลือกdouble(หรือfloat) แทนที่จะdecimalใช้แอปพลิเคชัน "ปกติ" แก้ไขเพื่อเพิ่ม: ขอบคุณสำหรับคำตอบที่ยอดเยี่ยมทั้งหมดฉันเรียนรู้จากพวกเขา คำถามอีกข้อหนึ่ง: มีคนเพียงไม่กี่คนที่ชี้ให้เห็นว่าการเป็นตัวแทนจำนวนจริงนั้นแม่นยำยิ่งขึ้น เมื่อประกาศฉันจะคิดว่าพวกเขามักจะเป็นตัวแทนของพวกเขาอย่างถูกต้องเช่นกัน แต่มันเป็นความจริงหรือไม่ที่ความแม่นยำอาจลดลง (บางครั้งมีนัยสำคัญ) เมื่อดำเนินการกับจุดลอยตัว?

265 c#  types  floating-point  double  decimal 

ฉันได้ค้นหาสิ่งนี้แล้ว แต่ไม่มีใครมีตัวอย่างของเมื่อคุณจะใช้strictfpคำหลักใน Java หรือไม่? มีใครพบการใช้งานนี้จริงหรือ จะมีผลข้างเคียงของการใส่ลงในการดำเนินการจุดลอยตัวของฉันทั้งหมดหรือไม่

258 java  floating-point  strictfp 

ฉันกำลังทำงานกับข้อมูลแผนที่และLatitude/Longitudeขยายไปถึง 8 ตำแหน่งทศนิยม ตัวอย่างเช่น: Latitude 40.71727401 Longitude -74.00898606 ฉันเห็นในเอกสารของ Google ที่ใช้: lat FLOAT( 10, 6 ) NOT NULL, lng FLOAT( 10, 6 ) NOT NULL อย่างไรก็ตามตำแหน่งทศนิยมของพวกเขาไปที่ 6 ฉันควรใช้FLOAT(10, 8)หรือมีวิธีอื่นในการพิจารณาสำหรับการจัดเก็บข้อมูลนี้เพื่อให้แม่นยำ มันจะใช้กับการคำนวณแผนที่ ขอบคุณ!

257 mysql  types  floating-point 

ตัวอย่างเช่น: 9 / 5 #=> 1 1.8แต่ผมคาดว่า ฉันจะรับผลลัพธ์ทศนิยม (ไม่ใช่จำนวนเต็ม) ที่ถูกต้องได้อย่างไร ทำไมมันกลับมา1เลย?

256 ruby  math  floating-point  division  integer-division 

ฉันพยายามแยกค่าสองค่าจากดาตาแกรม ฟิลด์เป็นตัวเลขและเมื่อมีเครื่องหมายจุลภาค (เช่น 554,20) ฉันจะไม่สามารถรับตัวเลขหลังเครื่องหมายจุลภาค ฉันได้พยายามและparseInt parseFloatฉันจะทำสิ่งนี้ได้อย่างไร

255 javascript  parsing  floating-point 

ฉันมีตัวเลขลอยเหมือนและ3.21.6 ฉันต้องการแยกตัวเลขออกเป็นส่วนจำนวนเต็มและทศนิยม ตัวอย่างเช่นค่าของ3.2จะถูกแบ่งออกเป็นสองตัวเลขคือ3และ0.2 การรับส่วนจำนวนเต็มเป็นเรื่องง่าย: n = Math.floor(n); แต่ฉันมีปัญหาในการรับส่วนทศนิยม ฉันได้ลองสิ่งนี้แล้ว: remainer = n % 2; //obtem a parte decimal do rating แต่มันไม่ทำงานอย่างถูกต้องเสมอไป รหัสก่อนหน้ามีผลลัพธ์ต่อไปนี้: n = 3.1 => remainer = 1.1 สิ่งที่ฉันหายไปที่นี่

248 javascript  floating-point  numbers  decimal  rounding