[Ka-Ping Yee] > Methods named "set-whatever" are typically understood to change a > component of something. If this must be done with a method, the method > should be called something like "with_scale(x)" instead of "set_scale(x)".\ I still like set_precision(). You ignore that this module has happy users -- I know that the current names make sense to them. I don't know that abstract arguments will. > But i think the method is unnecessary -- the constructor already > provides a perfectly good way to make a new number with an altered > precision, so why provide a second way to do the same thing? There > should be OOWTDI. It's a dedicated method for a common case. I doubt many (if any) current module users realize that precision can be changed via the constructor, and doing it that way seems strained even to me. Presumably you would be happier then if the constructor lost this ability. > ... > That's not an argument that 'precision' is the right name. That's > just a claim that we can confuse people into believing that 'precision' > is not so bad. I don't care whether it's "right", I only care that it's proven itself to work in practce. > ... > The attribute we're talking about represents something *completely > different*. As I said before, existing users have had no problems with this. >>> (b) Set rounding function as an attribute of the number. >> Bleech. > Can you, er, elaborate? Desired rounding is a function of the operand(s) and the operation they're combined with. The idea that there's a "round to even" 4.1 and a "add a half and chop" 4.1 is simply bizarre. It would make *some* kind of sense to say there are "round to even" and "add a half and chop" flavors of the addition operator, but then that multiplies too. Real apps overwhelmingly want "round to even" on every operation over some stretch, or overwhelmingly want "add a half and chop" rounding on every operation over some stretch. > And, can we reduce the issue to the rounding mode? Can we agree on > no global mutable default precision, at least? FixedPoint never had global mutable default precision, and I don't believe Doug added it. The default precision is 2, period. Cowlishaw's proposal has other kinds of "input state", though. > ... > I'm assuming we both believe that people will want to adjust rounding > modes more often with fixed-point than with floating-point. I don't, at least not in a problematic sense. A commerical app has to adhere to financial rounding rules that, like time zone rules, are often more informed by arbitrary political foolishness than sense. I expect the typical case is for an app to set the rounding mode once at its start, and never change it again. > The question is what happens to people who do mess with such things. > Should such people find interoperability impossible, or merely tedious? Tedious, surprising, and error-prone, but easy and pleasant for most people most of the time. > ... > I feel pretty hard-line about the default precision, but i may be willing > to concede the rounding issue if you have a good story for interoperability. There isn't a "default precision issue" that I can see, unless you object to the current default of 2; if "interoperability" is a real issue I expect that one of the module's users might have mentioned it by now <wink>.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4