Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: mid-rad, inf-sup, a caution...

Ralph Baker Kearfott wrote:

Nate et al,

Please see my inserted comments.

Baker

On 5/11/2010 09:27, Nate Hayes wrote:

John Pryce wrote:

A.

.
.
.

systems, based on mid-rad formats?


Has anyone in this forum ever worked with a mechanical engineer or
architect, or seen the computer software tools they use? In those
applications and domains, tolerancing of parts is almost always done
in mid-rad, e.g.,
http://www.youtube.com/watch?v=H7f5cjspuAs&feature=related
we should be so lucky that some of the largest and most successful
software companies in the world, such as Autodesk, Dassault Systems,
Parametric Technology, etc. would some day use our P1788 standard.
Having at least an interchange format for mid-rad with standardized
conversion rules I suspect would be a minimal requirement.

I would also point out that at least in this sense, mid-rad as an
"interchange format" is already a global, multi-billion dollar
industry. Something that can't be said for inf-sup.




Following this line so far, I'm wondering whether or not engineers'
use of mid-rad in specifications is the same as use of inf-sup in
actual calculations.  If engineers use mid-rad only to specify the
problem, then wouldn't standardization of a decimal-to-binary
conversion between mid-rad and inf-sup, along with standardization of
a corresponding from binary inf-sup to mid-rad, suffice for us?


I think so.

But I also believe its important not to write the standard in such a way
that vendors couldn't potentially use mid-rad as an internal format, if they
wish. For example, to the best of my knowledge Motion 16 should only require
inclusion isotonicity, not exact representation of endpoints.







In terms of interval hardware, mid-rad has an ability to encode an
interval in much fewer bits than inf-sup. This means more intervals
can be stored in memory, and bandwith to and from the processors
will be better than for inf-sup. So this in my view is a strong
reason to consider that there will someday be a competitive
advantage for vendors who wish to support hardware implementations
of mid-rad over inf-sup.


How crucial is (or will be in the foreseeable future) the storage
issue?


I can only speak for the area I know really well, i.e., computer graphics.
In that area it can be very crucial. However, I think the same concept might
apply to any application of interval computations to parallel processing:

Amdahl's Law is usually the most significant obstacle to harnessing the full
power of modern multi-core CPUs. Reading and writing RAM is not a parallel
activity. However, it is feasible to consider the entire interval rendering
algorithm can run entirely inside the cache of a single CPU, thus
eliminating almost all serial portion of the program and enabling massive
scalability on parallel platforms.

The smaller memory footprint and higher bandwith of mid-rad intervals would
make them an attractive option in this kind of computing environment. Also,
some hypothetical interval processor could likely compute twice as many
mid-rad intervals in a single SIMD operation than inf-sup. These are
potentially very important advantages.

However, I am not an expert in the digital roundings behavior of mid-rad
computations. This is something I need to learn more about.

Nate