[Issue 3240] std.numeric.findRoot only works with real

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=3240


Don clugd...@yahoo.com.au changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED




--- Comment #5 from Don clugd...@yahoo.com.au  2009-08-11 00:22:18 PDT ---
Fixed in SVN commit 1246.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 3232] std.math.approxEqual should consider maxAbsDiff when rhs==0 lhs!=0

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=3232





--- Comment #1 from Lars T. Kyllingstad bugzi...@kyllingen.net  2009-08-11 
00:36:02 PDT ---
I just realised the two solutions I suggested are exactly equivalent. :)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 2973] std.math.pow(int, int), etc.

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=2973


Don clugd...@yahoo.com.au changed:

   What|Removed |Added

 CC||clugd...@yahoo.com.au




--- Comment #6 from Don clugd...@yahoo.com.au  2009-08-11 04:58:06 PDT ---
 Casting to floating point is not a good solution b/c
 you lose performance and, in some cases, precision.

Are you sure?
Performance: 
Floating point multiplication is typically the same speed or faster than
integer multiplication on most CPUs from the past 15 years. On most Intel CPUs,
integer multiplication is actually done in the floating point unit.

Precision:
You'll only lose precision if the base is greater than the 1/real.epsilon. For
an 80-bit real, this means precision is lost only when the result is exactly
equal to ulong.max. And the only time that can happen is with pow(ulong.max,
1).
(because ulong.max is divisible by 5, but not by 25).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 3245] New: Easy bug fix available for disabled unit test code in std.encoding

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=3245

   Summary: Easy bug fix available for disabled unit test code in
std.encoding
   Product: D
   Version: 2.031
  Platform: All
OS/Version: All
Status: NEW
  Severity: trivial
  Priority: P2
 Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: y0uf00...@gmail.com


Bug: unittest line 55 in std.encoding was disabled by version(none)

Rationale: Re-enabling unittest at line 55 results in failure. 

Fix: At line 1059  inside template EncoderInstance(CharType : char). 

Current version:

dchar decodeReverseViaRead()()

{

auto c = read;



Fixed version:
dchar decodeReverseViaRead()()
{
dchar c = read;


Its obvious after failure point is pinned, even if not knowing the exact specs,
as decodeReverseViaRead must return a dchar, and variable c accumulates left
shifted bits in the loop, same as the nearby safeDecodeViaRead method. In
UTF-8,the auto c = read makes a char type only (thank you zerobugs debugger),
so high bits put in c are thrown away, and function may return character 0.
Re-enabled unittest code ran succesfully after above fix.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---