On Wed, 5 Feb 2003, David LeBlanc wrote: > Hmmm... and what shall the precision of 4.5 + 2.331 be? I see this as being > some sort of output attribute and not an inherent property of the stored > value. Already covered -- read the documentation at http://fixedpoint.sf.net/. I'm starting with what's specified there and proposing adjustments. > Are floats and ints immutable? Yes, and it's essential. > No public methods? No math operators? Is this a fixed point numeric > constant? No need for methods. Other numeric types don't have them. (Well, complex has .conjugate(), but that's very complex-specific.) > > 6. No global mutable state. That means no global settings for > > default precision or rounding mode. Either pick a standard > > precision or always require the second constructor argument. > > Rounding mode is a tougher problem; i see two solutions: > > Disagree. there is a "natural" precision that most people would tend to use > and I think it's 2 places to the right of the decimal point. I didn't contradict your suggestion. A default of 2 places is fine. But there must be a fixed default; no global mutable setting. > Rounding varies > according to need and, again, I think there's a "natural" preference, > although in this case I don't know what it would be. I believe the natural preference is round-half-to-even, also known as "banker's rounding", which is the current default in FixedPoint. > I thend to think that I want rounding to be a display function and not > something that effects the stored value. Otherwise you propegate rounding > loss. There must be some limit to storage precision. If you want to avoid propagating loss, use high precision, then round when you're done. > > This may sound like a harsh requirement, but i am convinced that > > global mutable settings will cause nightmares for people who try > > to make their modules and programs interoperate. > > How? Suppose two modules use different default precisions or rounding modes, and they set this by changing a global flag. If you use both modules, one will break, and it will be practically impossible to fix. > I think the idea should be to get the package into the distro and not start > a rethink/redesign at this stage - otherwise it won't appear until Python > 3000 ;). The adjustments i'm suggesting look pretty small to me: remove mutability, remove global state. When in doubt, simplify or remove features. Features can be always added later; but once a feature is in, dependencies force it to stay. -- ?!ng
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