Re: Announce: Grace project site operational

["Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org>]

Not only is there the proliferation of operators as an issue, but one of
efficiency as well. Perhaps you can pragma Inline them all or otherwise get
the code minimized & avoid all the function calls, but it seems this is
still "at risk" to not be very efficient or small if a given compiler is not
very good at the optimizations. The point is that even if you want some
separation of the types at the abstract, high-level of your program, what
you want in the way of machine code is a simple
add/subtract/multiply/divide. If you can't make it degenerate to that, then
you've got efficiency concerns.

Besides, it seems to kind of be working at cross purposes. First you create
separate types to avoid the arbitrary mixing of one thing with another, then
you invent a bunch of operators that allow you to mix them up again. Yeah,
you still have protection from some kinds of errors (assigning Volts to
Amps, e.g.)  but we ought to ask if these are the most prevalent of errors
that strong typing protects against and is it worth the bazillion operators,
overhead, & potential obfuscation that results?

It might be sufficient and simpler to do something like define a type
Electrical_Units_Type (or Physics_Units_Type, or whatever others you think
of) out of which you can make Volts and Amps & etc. (or Mass & Acceleration
& etc.) That might fall into the category of Good Enough. That would let you
do Volts * Amps but not Volts * Mass. Is that sufficient type safety?

OTOH, if someone wanted to come up with an all-encompassing set of packages
that provided engineering unit calculations & conversions with generic
versions for Integer, Fixed, Decimal and Floating Point types, I doubt I'd
try to stop them. If it looked good and seemed to be workable on a practical
level, I'd be willing to go along with adding it to Grace. Just because I
can't imagine such a package that wouldn't be a major pain in the posterior
doesn't mean that someone more clever than myself won't come up with one.
:-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Ted Dennison" <dennison@telepath.com> wrote in message
news:4519e058.0205150657.3b695758@posting.google.com...
>
> I'm certianly not an engineering math expert, but I've watched enough
> of them try to go this route and fail that I'm skeptical. The big
> problem was always the geometric explosion of operators required for
> every new unit added. Its no biggie when you just have positions and
> velocities, but at ((n-1)n * p)/2 custom operators requred (where n =
> # of units in your system and p = the average number of operators per
> unit combo), you could potentially have to add 45p operators when the
> 10th unit is added, 105p operators when the 15th unit is added, and
> 190p operators when the 20th unit is added. If p is 2 ("*" and "/"),
> then that's 90, 210, and 380 operator subprograms respectively.
<snip>