www.digitalmars.com         C & C++   DMDScript  

D - XR Exact Real Arithmetic

reply Mark Evans <Mark_member pathlink.com> writes:
This is an application of the FC++ library, whose author had a hand in this
work.  The concept of exact real arithmetic also appeals to me as a native
capability for D.

http://more.btexact.com/people/briggsk2/XR.html

"This is an implementation of exact (or constructive) real arithmetic, including
python and C++ versions. It is an alternative to multiple-precision
floating-point codes. An important distinction is that in multiple-precision
floating-point one sets the precision before starting a computation, and then
one cannot be sure of the final result. Interval arithmetic is an improvement on
this, but still not an ideal solution because if the final interval is larger
than desired, there is no simple way to restart the computation at higher
precision. By constrast, in XR no precision level is set in advance, and no
computation takes place until a final request takes place for some output."
Mar 04 2003
parent reply Bill Cox <bill viasic.com> writes:
Mark Evans wrote:
 This is an application of the FC++ library, whose author had a hand in this
 work.  The concept of exact real arithmetic also appeals to me as a native
 capability for D.
 
 http://more.btexact.com/people/briggsk2/XR.html
 
 "This is an implementation of exact (or constructive) real arithmetic,
including
 python and C++ versions. It is an alternative to multiple-precision
 floating-point codes. An important distinction is that in multiple-precision
 floating-point one sets the precision before starting a computation, and then
 one cannot be sure of the final result. Interval arithmetic is an improvement
on
 this, but still not an ideal solution because if the final interval is larger
 than desired, there is no simple way to restart the computation at higher
 precision. By constrast, in XR no precision level is set in advance, and no
 computation takes place until a final request takes place for some output."

Hi, Mark. You might find writing a compiler that includes the features you want enlightning. I wrote a very simple one over Christmas (I had to spend 2 weeks with my in-laws). Three of the four advanced features I've been lobbying for have been tested in that compiler (Sather "includes" or virtual clases, advanced iterators, dynamic inheritance). I also added some simple features, like the extended while loop. I'm just now playing with compiler extensions. I'd be interested in hearing about language features that allow things like exact real arithmetic to be supported in a standard library without any loss in speed. I'm currently trying to see if aplication specific compiler extensions get you there. Bill
Mar 04 2003
parent reply Mark Evans <Mark_member pathlink.com> writes:
You might find writing a compiler that includes the features you want 
enlightning.

Funny you should mention that; I have given it serious thought. XR is not the only factor involved. The capabilities I seek exist in other languages already, and D folks appear consistently opposed to, or ignorant of them. For example in the stack frame tweaking discussions, no one brought out that first-class continuations eliminate such nonsense. From that standpoint, it might be more sensible for me to tack on low-level bit-pushing capabilities to another language -- inline assembly, pointers, optimized compilation based on TAL and/or Cyclone, etc. Something similar to what the Boost Python Library accomplished for Python, but with the freedom to modify and merge the two languages involved. I also never considered 'bootstrapping' a virtue, and think one should author compilers in languages that are specialized, or at least particularly strong, for that purpose. Mark
Mar 04 2003
parent reply "Sean L. Palmer" <seanpalmer directvinternet.com> writes:
Like I said, if you can (easily!) write a compiler in the language, the
language has got to have something good going for it.  If you can't
(easily!) write a compiler in the language, it's not a good general purpose
language yet since quite a bit of day-to-day work involves parsing,
manipulating trees and graphs, recursion, etc.

So bootstrapping does serve a purpose as a kind of litmus test to the
maturity of a (general purpose) language.

A professional-grade compiler should use whatever is the best tool for the
job;  not all D compilers have to be written in D, but at very least one
should be.

Sean

"Mark Evans" <Mark_member pathlink.com> wrote in message
news:b43khc$vn6$1 digitaldaemon.com...
 From that standpoint, it might be more sensible for me to tack on

 bit-pushing capabilities to another language -- inline assembly, pointers,
 optimized compilation based on TAL and/or Cyclone, etc.  Something similar

 what the Boost Python Library accomplished for Python, but with the

 modify and merge the two languages involved.  I also never considered
 'bootstrapping' a virtue, and think one should author compilers in

 that are specialized, or at least particularly strong, for that purpose.

 Mark

Mar 04 2003
next sibling parent reply Garen <garen_nospam_ wsu.edu> writes:
Sean L. Palmer wrote:

 Like I said, if you can (easily!) write a compiler in the language, the
 language has got to have something good going for it.  If you can't
 (easily!) write a compiler in the language, it's not a good general purpose
 language yet since quite a bit of day-to-day work involves parsing,
 manipulating trees and graphs, recursion, etc.

Seems to me that there's no shortage of cool features; many have been explored but producing efficient code for 'em is hard. There's where I thought it was cool that someone with a fair deal of implementation experience (Walter) was designing D. (As opposed to dreaming up a standard with a bunch of untested, unimplemented ideas that blow up once they're tried. C++ exceptions and export anyone?)
Mar 05 2003
parent reply Mark Evans <Mark_member pathlink.com> writes:
Sean L. Palmer says:
 Like I said, if you can (easily!) write a compiler in the language, the
 language has got to have something good going for it.

Bootstrapping might be a litmus test, but there are many conceivable litmus tests. Bootstrapping duplicates work already done. It also creates extra work, because the target language has bugs while under development. You're not just writing the compiler, you're fighting these bugs. And to fix the bugs, you need to write a new version using the version which *has* them! Moreover the general-purpose target language will never be as good at writing its own compiler as the specialized ones designed for such purposes. Boostrapping has a lot of cache, but I see in it no intrinsic value. Garen says...
Seems to me that there's no shortage of cool features; many have been explored
but producing efficient code for 'em is hard.

There have been vague assertions to that effect, but few concrete examples, and even those are disputable. I'd like to offer a counterexample. You admit that C++ is a high-performance language. Fine; take a look at FC++. FC++ almost achieves functional language power in C++. Not quite the whole enchilada, but close. (Read the papers.) D could take that result and, with just a few language enhancements above C++, actually get the whole enchilada. This kind of low-hanging fruit you dismiss by saying it's too high to reach. Mark
Mar 05 2003
parent Garen <garen_nospam_ wsu.edu> writes:
Mark Evans wrote:
 
 There have been vague assertions to that effect, but few concrete examples, and
 even those are disputable.

What is disputable? It seems pretty intuitive that typically more work is involved to translate one representation to another the further they're apart in structure, form, abstraction or whatever.
 
 I'd like to offer a counterexample.  You admit that C++ is a high-performance
 language.  Fine; take a look at FC++.  FC++ almost achieves functional language
 power in C++.  Not quite the whole enchilada, but close.  (Read the papers.)  D
 could take that result and, with just a few language enhancements above C++,
 actually get the whole enchilada.  This kind of low-hanging fruit you dismiss
by
 saying it's too high to reach.

I wasn't aware I dismissed anything.
Mar 05 2003
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Sean L. Palmer" <seanpalmer directvinternet.com> wrote in message
news:b447kf$1an6$1 digitaldaemon.com...
 A professional-grade compiler should use whatever is the best tool for the
 job;  not all D compilers have to be written in D, but at very least one
 should be.

The trouble with writing D in D is hooking it up to existing back ends.
Mar 05 2003
parent reply "Sean L. Palmer" <seanpalmer directvinternet.com> writes:
I will take your word for it.

What about just a front-end?  ;)

Sean

"Walter" <walter digitalmars.com> wrote in message
news:b46mos$2q9f$1 digitaldaemon.com...
 "Sean L. Palmer" <seanpalmer directvinternet.com> wrote in message
 news:b447kf$1an6$1 digitaldaemon.com...
 A professional-grade compiler should use whatever is the best tool for


 job;  not all D compilers have to be written in D, but at very least one
 should be.

The trouble with writing D in D is hooking it up to existing back ends.

Mar 06 2003
parent "Walter" <walter digitalmars.com> writes:
??

"Sean L. Palmer" <seanpalmer directvinternet.com> wrote in message
news:b49i6c$1dks$1 digitaldaemon.com...
 I will take your word for it.

 What about just a front-end?  ;)

 Sean

 "Walter" <walter digitalmars.com> wrote in message
 news:b46mos$2q9f$1 digitaldaemon.com...
 "Sean L. Palmer" <seanpalmer directvinternet.com> wrote in message
 news:b447kf$1an6$1 digitaldaemon.com...
 A professional-grade compiler should use whatever is the best tool for


 job;  not all D compilers have to be written in D, but at very least



 should be.

The trouble with writing D in D is hooking it up to existing back ends.


Mar 07 2003