Re: Type-free Circles and Ellipses [T]

> On Sun, 26 Aug 2001 02:51:15 GMT, topmind_at_technologist.com (Topmind)
> wrote:
>
> >A Topmind view of shapes:
> >
> >I defined an ellipse as "a rectangle with a
> >100 percent smoothing factor", and a circle
> >as "a square with a 100 percent smoothing
> >factor". This is a "has-a" viewpoint. A rectangle
> >has-a zero percent smoothing and an ellipse
> >has-a 100 percent.
> >
> >You can get all kinds of nice hybrids
> >("tweeners") that way. Possibilities
> >open up if you move away from is-a
> >thinking.
> >
> >However, I don't think it is practical
> >to define an explicit case for circle
> >when an ellipse can satisfy that.
> >
> >An even more generic approach to shapes
> >is a bunch of "segments" where the segments
> >can be curves or strait lines. In that
> >approach you don't really need even an
> >"ellipse type", because it can be made
> >out of four curved segments.
> >
> >Add the continious smoothing to this
> >mix, and you can get just about any shape.
> >If fact, the smoothing may be able to
> >replace curves by having a "bleed factor".
> >the bleed factor may work better if
> >we define nodes instead of segments.
> >This needs a bit more exploration.
> >
> >Thus, one does not even need "types"
> >for shapes. A shape is just a variable
> >number of segments (or nodes), in which each
> >segment has indepedent attributes.
>
> So all shapes have same type?

In essense, yes. "Type" is not
really applicable. Perhaps "entity"
would be a better description.

>
> [ A mighty tune comes in mind:
>
> ALL IS SHAPE
>
> Chorus:
>
> ALL IS OBJECT
>
> (:-))
> ]
>
> BTW. How would you calculate the perimeter of a shape?

Add the perimeters of the segments. How the actual calculation is done per segment (or node)? I don't know. I forgot all that stuff since my dorm-days.

> How many
> segments should have the shape built from the modified Bessel
> function?

I don't understand this question. Note that I did not specify how the smoothing was acheived. (The smoothing algorithm used could be an attribute. This may get a bit sticky in that some smoothing algorithms can involve many nodes. Thus, I suggest a "bleedPercent" kind of attribute to affect how much nearby nodes/segments are allowed to affect the current one.)

>
> I know that you are aginst OO. It seems that you are against ADT too.
> Right?

I will just say that it is situational. I don't beleive in one-paradigm-fits-all-projects.

The actual approach used may depend on the needs of the system. If there are a lot of "regular shapes", then I might choose a different approach than if there was a lot of "funny shapes". Something optimized for lots of regular shapes is probably not optimized for lots of funny shapes.

>
> Regards,
> Dmitry Kazakov
>

-T- Received on Mon Aug 27 2001 - 22:34:31 CEST