`Vector <float> ควรจะสะท้อนกลับหรือควรเป็นไปตามความหมายของ IEEE 754?

เมื่อเปรียบเทียบค่าทศนิยมเพื่อความเท่าเทียมมีสองวิธีที่แตกต่างกัน:

• NaNจะไม่เท่ากับตัวเองซึ่งตรงกับมาตรฐาน IEEE 754สเปค
• NaNมีความเท่าเทียมกับตัวเองซึ่งให้คุณสมบัติทางคณิตศาสตร์ของReflexivityซึ่งเป็นสิ่งจำเป็นต่อความหมายของความสัมพันธ์ที่เท่าเทียมกัน

สร้างขึ้นใน IEEE ลอยชนิดจุดใน C # ( floatและdouble) ปฏิบัติตามมาตรฐาน IEEE ความหมายสำหรับ==และ!=(และผู้ประกอบการเชิงสัมพันธ์เช่น<) แต่ให้มั่นใจ reflexivity สำหรับobject.Equals, IEquatable<T>.Equals(และCompareTo)

ตอนนี้พิจารณาห้องสมุดที่ให้ structs เวกเตอร์ที่ด้านบนของ/float doubleประเภทเวกเตอร์ดังกล่าวจะเกิน==/ !=และแทนที่/object.EqualsIEquatable<T>.Equals

สิ่งที่ทุกคนเห็นพ้องต้องกันคือ==/ !=ควรทำตามความหมายของ IEEE คำถามคือห้องสมุดควรใช้Equalsวิธีการ (ซึ่งแยกจากตัวดำเนินการความเสมอภาค) ในวิธีที่สะท้อนกลับหรือในวิธีที่ตรงกับความหมายของ IEEE

อาร์กิวเมนต์สำหรับการใช้ความหมายของ IEEE สำหรับEquals:

• เป็นไปตาม IEEE 754

• มันเร็วกว่า (อาจมาก) เพราะสามารถใช้ประโยชน์จากคำสั่ง SIMD ได้

  ฉันได้ถามคำถามแยกต่างหากเกี่ยวกับสแต็คโอเวอร์โฟลว์เกี่ยวกับวิธีที่คุณแสดงความเท่าเทียมสะท้อนกลับโดยใช้คำสั่ง SIMD และผลกระทบต่อประสิทธิภาพการทำงานของพวกเขา: คำแนะนำ SIMD สำหรับการเปรียบเทียบความเท่าเทียมกันของจุดลอยตัว

  อัปเดต:ดูเหมือนว่าเป็นไปได้ที่จะใช้ความเท่าเทียมแบบสะท้อนได้อย่างมีประสิทธิภาพโดยใช้คำสั่ง SIMD สามคำ

• เอกสารสำหรับEqualsไม่จำเป็นต้องมีการสะท้อนกลับเมื่อเกี่ยวข้องกับจุดลอยตัว:

  ข้อความต่อไปนี้ต้องเป็นจริงสำหรับการใช้งานทั้งหมดของวิธีการ Equals (Object) ในรายการx, yและzแทนการอ้างอิงวัตถุที่ไม่เป็นโมฆะ

  x.Equals(x)ผลตอบแทนtrueยกเว้นในกรณีที่เกี่ยวข้องกับประเภทจุดลอย ดูที่ ISO / IEC / IEEE 60559: 2011, เทคโนโลยีสารสนเทศ - ระบบไมโครโปรเซสเซอร์ - เลขทศนิยม

• หากคุณกำลังใช้โฟลทเป็นคีย์พจนานุกรมคุณกำลังใช้ชีวิตอยู่ในสภาพบาปและไม่ควรคาดหวังพฤติกรรมที่มีสติ

อาร์กิวเมนต์สำหรับการสะท้อนกลับ:

• มันเป็นเรื่องที่สอดคล้องกับประเภทที่มีอยู่รวมทั้งSingle, Double, และTupleSystem.Numerics.Complex

  ฉันไม่รู้แบบอย่างใด ๆ ใน BCL ที่Equalsติดตาม IEEE แทนที่จะสะท้อนกลับ เคาน์เตอร์ตัวอย่าง ได้แก่Single, Double, และTupleSystem.Numerics.Complex

• Equalsส่วนใหญ่จะใช้โดยคอนเทนเนอร์และอัลกอริทึมการค้นหาซึ่งขึ้นอยู่กับการสะท้อนกลับ สำหรับอัลกอริธึมเหล่านี้ประสิทธิภาพที่เพิ่มขึ้นนั้นไม่เกี่ยวข้องหากป้องกันไม่ให้ทำงานได้ อย่าเสียสละความถูกต้องในการแสดง
• จะแบ่งทุกชุดกัญชาและพจนานุกรมContains, Find, IndexOfคอลเลกชันต่างๆ / LINQ การดำเนินงานชุด LINQ based ( Union, Exceptฯลฯ ) หากข้อมูลที่มีNaNค่า

• โค้ดที่ทำการคำนวณจริงที่ยอมรับได้ในความหมายของ IEEE มักใช้กับรูปแบบที่เป็นรูปธรรมและใช้==/ !=(หรือการเปรียบเทียบ epsilon ที่มีแนวโน้มมากกว่า)

  ขณะนี้คุณไม่สามารถเขียนการคำนวณประสิทธิภาพสูงโดยใช้ generics เนื่องจากคุณต้องการการดำเนินการทางคณิตศาสตร์สำหรับสิ่งนั้น แต่สิ่งเหล่านี้ไม่สามารถใช้ได้ผ่านทางอินเตอร์เฟส / วิธีการเสมือน

  ดังนั้นEqualsวิธีที่ช้ากว่าจะไม่ส่งผลกระทบต่อรหัสประสิทธิภาพสูงที่สุด

• เป็นไปได้ที่จะให้IeeeEqualsวิธีการหรือIeeeEqualityComparer<T>กรณีที่คุณต้องการความหมายของ IEEE หรือคุณต้องการประสิทธิภาพที่เหนือกว่า

ในความคิดของฉันข้อโต้แย้งเหล่านี้สนับสนุนการใช้งานแบบสะท้อนกลับอย่างยิ่ง

ทีม CoreFX ของ Microsoft วางแผนที่จะแนะนำประเภทเวกเตอร์ดังกล่าวใน. NET ซึ่งแตกต่างจากฉันพวกเขาชอบโซลูชัน IEEEส่วนใหญ่เนื่องจากข้อได้เปรียบด้านประสิทธิภาพ เนื่องจากการตัดสินใจดังกล่าวจะไม่เปลี่ยนแปลงหลังจากการเปิดตัวครั้งสุดท้ายฉันต้องการได้รับคำติชมจากชุมชนในสิ่งที่ฉันเชื่อว่าเป็นความผิดพลาดครั้งใหญ่

ฉันจะยืนยันว่าพฤติกรรม IEEE นั้นถูกต้อง NaNไม่เทียบเท่ากันในทางใดทางหนึ่ง พวกเขาสอดคล้องกับเงื่อนไขที่กำหนดไว้ไม่ดีซึ่งคำตอบที่เป็นตัวเลขไม่เหมาะสม

นอกเหนือจากผลประโยชน์ที่มาจากการใช้มาตรฐาน IEEE เลขคณิตที่ประมวลผลส่วนใหญ่สนับสนุนการกำเนิดผมคิดว่ามีปัญหากับความหมายบอกว่าถ้าแล้วisnan(x) && isnan(y) x == yตัวอย่างเช่น

// C++
double inf = std::numeric_limits<double>::infinity();
double x = 0.0 / 0.0;
double y = inf - inf;

ฉันจะยืนยันว่าไม่มีเหตุผลที่มีความหมายว่าทำไมหนึ่งจะพิจารณาเท่ากับx yคุณแทบจะไม่สามารถสรุปได้ว่าพวกเขาเป็นตัวเลขที่เทียบเท่ากัน พวกมันไม่ใช่ตัวเลขเลยดังนั้นมันจึงดูเหมือนว่าเป็นแนวคิดที่ไม่ถูกต้องทั้งหมด

นอกจากนี้จากมุมมองการออกแบบ API หากคุณกำลังทำงานกับไลบรารีวัตถุประสงค์ทั่วไปที่ตั้งใจจะใช้โดยโปรแกรมเมอร์จำนวนมากมันก็สมเหตุสมผลที่จะใช้ซีแมนทิกส์จุดลอยตัวทั่วไปในอุตสาหกรรม เป้าหมายของห้องสมุดที่ดีคือการประหยัดเวลาสำหรับผู้ที่ใช้ห้องสมุดดังนั้นการสร้างพฤติกรรมที่ไม่เป็นมาตรฐานนั้นทำให้เกิดความสับสน

มีปัญหา: IEEE754 กำหนดการดำเนินงานเชิงสัมพันธ์และความเท่าเทียมกันในลักษณะที่เหมาะสมกับแอปพลิเคชั่นตัวเลข มันไม่เหมาะที่จะเรียงลำดับและคร่ำเครียด ดังนั้นหากคุณต้องการเรียงลำดับอาร์เรย์ตามค่าตัวเลขหรือถ้าคุณต้องการเพิ่มค่าตัวเลขให้กับชุดหรือใช้เป็นคีย์ในพจนานุกรมคุณอาจประกาศว่าไม่อนุญาตให้ใช้ค่า NaN หรือไม่ใช้ IEEE754 การดำเนินงานในตัว ตารางแฮชของคุณจะต้องตรวจสอบให้แน่ใจว่า NaNs ทั้งหมดนั้นตรงกับค่าเดียวกันและเปรียบเทียบให้เท่ากัน

หากคุณกำหนด Vector คุณต้องตัดสินใจออกแบบว่าคุณต้องการใช้เพื่อวัตถุประสงค์เชิงตัวเลขเท่านั้นหรือควรเข้ากันได้กับการเรียงลำดับและการแปลงแป้นพิมพ์ โดยส่วนตัวผมคิดว่าจุดประสงค์เชิงตัวเลขควรมีความสำคัญมากกว่า หากจำเป็นต้องมีการเรียงลำดับ / hashing คุณสามารถเขียนคลาสที่มี Vector เป็นสมาชิกและกำหนด hashing และความเท่าเทียมกันในชั้นเรียนตามที่คุณต้องการ