DePauwREU2013 / scales

2 stars 0 forks source link

Smashed Bug #21

Closed mfansler closed 11 years ago

mfansler commented 11 years ago

Run TestSmashed. It's not right.

smashed-wrong

There's actually two things wrong:

I'll try to fix it tonight. Mostly likely something I broke while doing the code clean up.

mfansler commented 11 years ago

Hmm... well maybe I'm wrong about the second point. I was assuming that hSmash was something which removed the horizontal dimension and vSmash removed the vertical dimension. The spec says it's the complete opposite, which although counterintuitive to me, is at least consistent.

Still working on the rows overlapping.

mfansler commented 11 years ago

Over the weekend I had attempted making the Transform.bounds "smarter" by having it use the bounds of the transformed shape of the original graphic, rather than the bounds of the transformed bounds. That would have made it so that two successive 45 degree rotations of a square would result in a bounds matching the original. Unfortunately, java's Area.add doesn't reliably preserve the boundaries if one of the areas is flattened.

Lesson Learned: you can rely on a bounds to give you a shape, but not a shape to give you bounds.

bhoward commented 11 years ago

Yes, the names hSmash and vSmash have seemed at best ambiguous to me, if not actually backwards. I've also worried about what happens when something of zero width or height (or both, like Phantom) is composed. Ideally, Phantom should be an identity for composition, but if the bounding box of the Graphic it is composed with does not include (0, 0), then I believe the current implementation will expand the resulting bounds. Should there be a special case for zero width or height when computing bounding boxes? If there is a use for zero dimensions that still record a position, then perhaps we could use negative dimensions to signal when they shouldn't affect the bounds?

On Mon, Jul 29, 2013 at 12:11 AM, Mervin Fansler notifications@github.comwrote:

Hmm... well maybe I'm wrong about the second point. I was assuming that hSmash was something which removed the horizontal dimension and vSmashremoved the vertical dimension. The spec says it's the complete opposite, which although counterintuitive to me, is at least consistent.

Still working on the rows overlapping.

— Reply to this email directly or view it on GitHubhttps://github.com/DePauwREU2013/scales/issues/21#issuecomment-21698665 .