4 ms·
> Is the angle -90 equal to 270? > Is the quotient 1/2 equal to 3/6? I think these are good examples that come up in the real world a lot. The representation
by jstimpfle 10y ago
> Is the angle -90 equal to 270?
> Is the quotient 1/2 equal to 3/6?
I think these are good examples that come up in the real world a lot. The representation structures we use are not sufficient for precise specification. So we have to overspecify (making a superfluous choice in representation, -90, 270, 630?).
My opinion still is that data must be normalized with explicit procedure calls. Doing stuff implicitly is neither beneficient to efficiency nor to comprehensibility. Explicit normalization allows to leverage what the compiler _can_ infer.
The other questions I have to return because it's not even clear to me, "Should they be"?
- mbrock 10y agoWhether they should be depends on your needs, so it's nice to be able to choose the equality semantics for your application's types.
- dllthomas 10y ago> My opinion still is that data must be normalized with explicit procedure calls. Doing stuff implicitly is neither beneficient to efficiency nor to comprehensibility. It can certainly benefit comprehensibility. Needing to explicitly normalize before I can apply standard comparisons leaves more space for things to go wrong. "Having a value of this type means that I have a normalized value" means I have fewer things to keep track of. (I do note that there is significant space between "it can benefit comprehensibility" and "it will always benefit comprehensibility" - that depends on what I need to be readily able to pull out of the implementation from a quick read of surface syntax) Also, some things may have an easy equality check while normalizing may be expensive or impossible - although I sadly can't think of any examples off the top of my head.