<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 8/28/2010 4:22 PM, Philippe Sigaud wrote:
<blockquote
cite="mid:AANLkTikWoOXxi_GTA0doOfDG5Npi0g_y2n7yUwzYMj_x@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div>line 76: isAssignable would be a good addition to
std.traits.<br>
</div>
</div>
</blockquote>
<br>
Yeah, will do unless anyone has any objections.<br>
<br>
<blockquote
cite="mid:AANLkTikWoOXxi_GTA0doOfDG5Npi0g_y2n7yUwzYMj_x@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div> </div>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">
<div class="im">
<blockquote type="cite">
<div class="gmail_quote">
<div> <br>
Next, 1/0. OK, it's correctly dealt with (Integer
Divide By Zero Error)<br>
But 0/1 botches. In fact, any rational that's zero
creates a DBZ error. r-= r, etc.<br>
I guess it's a pb in simplify (454-455) or gcf
(638), you should test for a zero numerator or
divisor<br>
</div>
</div>
</blockquote>
<br>
</div>
I can't believe I forgot to test this edge case. Fixed by
simply testing for zero as a special case in simplify().</div>
</blockquote>
<div><br>
Put in some very basic unit tests :-) 0+0==0, 1-1==0, that
kind of thing :)<br>
</div>
</div>
</blockquote>
<br>
Did that already. They pass.<br>
<br>
<blockquote
cite="mid:AANLkTikWoOXxi_GTA0doOfDG5Npi0g_y2n7yUwzYMj_x@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">
<div class="im">
<blockquote type="cite">
<div class="gmail_quote">
<div> <br>
Now, for the code itself:<br>
line 35: Maybe you should add %, %=, they are part
of what I consider 'integer like'. You use them in
gcf anyway<br>
</div>
</div>
</blockquote>
<br>
</div>
Good point. Done. Also added comparison.</div>
</blockquote>
<div><br>
Man, integer-like is beginning to be quite big.<br>
<br>
What about adding ++ and -- ?<br>
</div>
</div>
</blockquote>
<br>
I don't need/use them, so there's no real reason to require them.<br>
<br>
<blockquote
cite="mid:AANLkTikWoOXxi_GTA0doOfDG5Npi0g_y2n7yUwzYMj_x@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div><br>
Btw, I'm against putting ++ and -- in Rational, but please do
add opUnary!"+", opUnary!"-".<br>
</div>
</div>
</blockquote>
<br>
Will do, along with ^^. These were left out as oversights, not for
"good" reasons.<br>
<br>
<blockquote
cite="mid:AANLkTikWoOXxi_GTA0doOfDG5Npi0g_y2n7yUwzYMj_x@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">
<div class="im">
<blockquote type="cite">
<div class="gmail_quote">
<div>* a fractional part function (ie 22/7 is ~3.14
-> 0.14) as a FP<br>
</div>
</div>
</blockquote>
<br>
</div>
Ditto.</div>
</blockquote>
<div><br>
Thinking about it some more, maybe the fractional part should
return a typeof(this): 22/7 -> 1/7. Not a float.<br>
</div>
</div>
</blockquote>
<br>
Yea, this makes more sense. If you want a float, you can always
cast it. <br>
<br>
<blockquote
cite="mid:AANLkTikWoOXxi_GTA0doOfDG5Npi0g_y2n7yUwzYMj_x@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">
<div class="im"><br>
<blockquote type="cite">
<div class="gmail_quote">
<div>* Accordingly, floor/ceil functions could be
interesting, unless you think the user should use
std.math.floor(cast(real)rat), which I could
understand.<br>
</div>
</div>
</blockquote>
<br>
</div>
Again, good idea. Using std.math sucks because a major
point of Rational is that it's supposed to work with
arbitrary precision, and reals aren't arbitrary precision. <br>
</div>
</blockquote>
<div><br>
<br>
I could argue that floor or ceil are exactly when you get rid
of this arbitrary precision, but to answer the question in
your next post, I think these should be part of the rational
module and be free functions: it makes the module
self-supported. And having rational support in std math means
it must in turn import the rational module. I'm against this.<br>
<br>
In any case, people will probably import both at the same
time...<br>
<br>
I'm not clear on the subtle nuances between the integer part,
the floor and the ceil for positive and negative Rationals,
though.<br>
<br>
See std.math: ceil, floor, nearbyInt, round, trunc! Awww.<br>
<br>
The next question would be: what other free function? I'll add
abs(), but not much more. Maybe pow or opBinary!"^^" ?<br>
</div>
</div>
</blockquote>
<br>
opBinary!"^^": Yes. pow(): I don't see the point. Probably
everyone writing generic math code nowadays will use ^^ instead of
pow() because it's less typing and more readable. Then again, pow()
would be trivial to implement in terms of opBinary!"^^".<br>
<br>
<blockquote
cite="mid:AANLkTikWoOXxi_GTA0doOfDG5Npi0g_y2n7yUwzYMj_x@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div>I wouldn't add any trigonometric function.</div>
</div>
</blockquote>
<blockquote
cite="mid:AANLkTikWoOXxi_GTA0doOfDG5Npi0g_y2n7yUwzYMj_x@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div>. <br>
sqrt is on the fence for me. Is there an algorithm to
calculate the square root of a rational apart from the
Babylonian method? <br>
</div>
</div>
</blockquote>
<br>
I'm going to leave trig and sqrt out. To me, the point of rationals
is to allow calculations to be exact. Functions where the result
can be irrational don't make sense in this context. You'd be better
off just casting to real and then calling the std.math functions.<br>
<br>
<blockquote
cite="mid:AANLkTikWoOXxi_GTA0doOfDG5Npi0g_y2n7yUwzYMj_x@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">
<div class="im">
<blockquote type="cite">
<div class="gmail_quote">
<div> ***<br>
2. I couldn't figure out how to handle the case of
user-defined fixed-width integer types in the
decimal conversion (opCast) function, so it just
assumes non-builtin integer types are arbitrary
precision. The biggest problem is lack of a way of
introspecting whether the integer is fixed or
arbitrary width and what its fixed width might be if
it is, in fact, fixed. The secondary problem is
that I don't know of a good algorithm (though I'm
sure I could find one if I tried) for converting
fixed-width integers to floating point numbers in
software. Arbitrary precision is much easier.<br>
***<br>
<br>
About converting fixed-width integer-like types,
maybe these should provide .min and .max properties?<br>
That way you know the range of possible values and
maybe it's then possible to convert (I didn't think
this through so I may be completly mistaken)<br>
</div>
</div>
</blockquote>
<br>
</div>
I think what I'm going to do here is just throw an exception
iff the denominator has both the highest and lowest order
bit set. This is enough of a corner case in that it will
only happen close to the limit of the largest denominator
value that can be represented that I don't consider it a
major limitation. It's easily detectable because the
numerator will never become bigger than the denominator by
bit shifting iff either the numerator is zero or the
denominator has its highest order bit set. If the
denominator's lowest order bit isn't set then I can shift
the denominator right to make it not have its highest order
bit set.<br>
</div>
</blockquote>
<div><br>
What's the pb with having a numerator bigger than the
denominator? Sorry, I didn't read the conversion function
carefully.<br>
</div>
</div>
</blockquote>
<br>
The way the function works involves bit shifting the numerator left
until it's bigger than the denominator. If the denominator has its
highest order bit occupied, no amount of shifting will ever make the
numerator bigger.<br>
<blockquote
cite="mid:AANLkTikWoOXxi_GTA0doOfDG5Npi0g_y2n7yUwzYMj_x@mail.gmail.com"
type="cite">
<div class="gmail_quote"><br>
<div bgcolor="#ffffff" text="#000000">This code has been around
in some form for almost a year. It's just that the proposal
for a units library made me remember that I've been meaning to
clean up all the bit rot, improve it and submit it for
inclusion.</div>
<div><br>
Seeing that you have time, talent and energy, I'll order a
BigDecimal module :-)<br>
</div>
</div>
</blockquote>
<br>
I'd love one, but I haven't the slightest clue how to write one and
have several hacking projects that I need to finish/start before
even considering it.<br>
<br>
</body>
</html>