Re: [perl #128913] [BUG] decimal->float non-monotonic conversion [Request: ET-9576 is created]

2018-04-13 Thread dcu



	
		
			
			

	
		 
	

			
			
		
	





	
		
			
			

	
		
	

			
			
		
	





	
		
			
			
			

	
		
	
	
		
		
			

	
	Thank you for your email request. Your request ID is I-1544030 
	
	
	
  

 



  
  

  
  

  














  












  



  


DCU Home   
Branches   
Branch/ATM Locator   
Contact


  
  

  
  

  
  

  
  

  Our Privacy Policy protects your privacy and we will never sell your name or email address. 
  Federally insured by NCUA. DCU is an Equal Housing Lender. 
  Please do not reply 
  to this email. For questions or additional information, please email d...@dcu.org. 
  
  
  
  220 Donald Lynch Boulevard, PO Box 9130, Marlborough, MA 01752-9130
  508.263.6700 • 800.328.8797
  ABA Routing Number: 211391825NMLS#: 466914
  
  
  ©  Digital Federal Credit Union
  



  

 

   
 

			
		
		
	

			
			
			
		
	




Re: [perl #128913] [BUG] decimal->float non-monotonic conversion [Request: ET-9577 is created]

2018-04-13 Thread dcu



	
		
			
			

	
		 
	

			
			
		
	





	
		
			
			

	
		
	

			
			
		
	





	
		
			
			
			

	
		
	
	
		
		
			

	
	Thank you for your email request. Your request ID is I-1544031 
	
	
	
  

 



  
  

  
  

  














  












  



  


DCU Home   
Branches   
Branch/ATM Locator   
Contact


  
  

  
  

  
  

  
  

  Our Privacy Policy protects your privacy and we will never sell your name or email address. 
  Federally insured by NCUA. DCU is an Equal Housing Lender. 
  Please do not reply 
  to this email. For questions or additional information, please email d...@dcu.org. 
  
  
  
  220 Donald Lynch Boulevard, PO Box 9130, Marlborough, MA 01752-9130
  508.263.6700 • 800.328.8797
  ABA Routing Number: 211391825NMLS#: 466914
  
  
  ©  Digital Federal Credit Union
  



  

 

   
 

			
		
		
	

			
			
			
		
	




[perl #128913] [BUG] decimal->float non-monotonic conversion

2018-04-13 Thread Zoffix Znet via RT
On Fri, 12 Aug 2016 10:00:17 -0700, zef...@fysh.org wrote:
> > "9.9981e0".EVAL < "9.998e0".EVAL
> True
> 
> Observe that the literal with a greater nominal value yields a lower
> Num value.  (The .EVAL circumlocution is required to work around [perl
> #128820].)  This implies that at least one of the literals is getting
> incorrect rounding, which was the subject of [perl #128912].  (In fact
> the greater one is getting correct rounding and the lower one is not.
> The correct roundings of both are the same.)  But this case goes beyond
> the rounding merely being incorrect; with this behaviour the rounding
> isn't even self-consistent.
> 
> -zefram

Thank you for the report. This is now fixed.

Fix:  https://github.com/rakudo/rakudo/commit/a760ac3cfc6426d9bd2fb00db
  https://github.com/MoarVM/MoarVM/commit/b735866ddee9bd719440e5c82
Test: https://github.com/perl6/roast/commit/07830c2042b998128


[perl #128913] [BUG] decimal->float non-monotonic conversion

2018-04-13 Thread Zoffix Znet via RT
On Fri, 12 Aug 2016 10:00:17 -0700, zef...@fysh.org wrote:
> > "9.9981e0".EVAL < "9.998e0".EVAL
> True
> 
> Observe that the literal with a greater nominal value yields a lower
> Num value.  (The .EVAL circumlocution is required to work around [perl
> #128820].)  This implies that at least one of the literals is getting
> incorrect rounding, which was the subject of [perl #128912].  (In fact
> the greater one is getting correct rounding and the lower one is not.
> The correct roundings of both are the same.)  But this case goes beyond
> the rounding merely being incorrect; with this behaviour the rounding
> isn't even self-consistent.
> 
> -zefram

Thank you for the report. This is now fixed.

Fix:  https://github.com/rakudo/rakudo/commit/a760ac3cfc6426d9bd2fb00db
  https://github.com/MoarVM/MoarVM/commit/b735866ddee9bd719440e5c82
Test: https://github.com/perl6/roast/commit/07830c2042b998128



[perl #128913] [BUG] decimal->float non-monotonic conversion

2016-08-12 Thread via RT
# New Ticket Created by  Zefram 
# Please include the string:  [perl #128913]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/Ticket/Display.html?id=128913 >


> "9.9981e0".EVAL < "9.998e0".EVAL
True

Observe that the literal with a greater nominal value yields a lower
Num value.  (The .EVAL circumlocution is required to work around [perl
#128820].)  This implies that at least one of the literals is getting
incorrect rounding, which was the subject of [perl #128912].  (In fact
the greater one is getting correct rounding and the lower one is not.
The correct roundings of both are the same.)  But this case goes beyond
the rounding merely being incorrect; with this behaviour the rounding
isn't even self-consistent.

-zefram