April 21, 2004
"lacs" <lacs_member@pathlink.com> wrote in message news:c66dls$1mt5$1@digitaldaemon.com...
> Add primitive-units-checking to D and a lot of people who work with
numbers will
> fall in love with D.

That would be neat. I wonder how far D's template would go without modifying the language. See http://www2.inf.ethz.ch/~meyer/publications/OTHERS/scott_meyers/dimensions.pdf for an approach in C++. There are probably lots and lots of ways to support "units" depending on what the user wants and dimension checking would be a useful start.


April 21, 2004
"Norbert Nemec" <Norbert.Nemec@gmx.de> wrote in message news:c65fmi$2js$1@digitaldaemon.com...
> From what I have read so far, D really has the potential to close the gap between C++ and Fortran and in this way gain a huge share in the scientific/high-performance area of computing. Anyway, to have any chance to go there, much care has to be taken now.

I agree totally with you, which is why D has several features with a numerics focus. If there are any I missed, I want to know about it.


April 21, 2004
"Norbert Nemec" <Norbert.Nemec@gmx.de> wrote in message news:c65fmi$2js$1@digitaldaemon.com...
> From what I have read so far, D really has the potential to close the gap between C++ and Fortran and in this way gain a huge share in the scientific/high-performance area of computing. Anyway, to have any chance to go there, much care has to be taken now.
>
> People unfamiliar with numeric programming often wonder why Fortran still has such a huge share among scientists. Many scientists still use
Fortran77
> and even those who have moved to Fortran95 only use it for its modern syntax, never touching the advanced concepts of it. And this is not only because they don't know better, but also because it is extremely hard to match the performance of Fortran77! (OK, 99% of the reason might actually be the lazyness to learn a different language and the existing code-base, but still people usual argue based on the superior performance of the language)

What Fortran has over C is the 'noalias' on function parameters which allows for aggressive optimization. What I'm thinking of is writing the spec for D functions so that parameters are always 'noalias' (for extern (C) functions this would not apply).

What do you think?

For reference: http://www.lysator.liu.se/c/restrict.html


April 21, 2004
Walter wrote:
> What Fortran has over C is the 'noalias' on function parameters which allows for aggressive optimization. What I'm thinking of is writing the spec for D functions so that parameters are always 'noalias' (for extern (C) functions this would not apply).
> 
> What do you think?
> 
> For reference: http://www.lysator.liu.se/c/restrict.html

I only have some basic knowledge about the "restrict" problem and would not want to judge any detailed language design decisions.

Anyhow, the problem of both, the Fortran- as well as the C-"restrict"-solution, that I see is, that in both cases, you "demand" that pointers are not aliased, without being able to check it.

Of course, it is not possible to check this in every case at compile time (if it were possible, C compilers would not have a problem), but maybe, we can at least identify a class of situations where it is possible? Or, alternatively enforce nonaliasing parameters via preconditions, so it is checked in debugging mode?

For plain pointers it rather hard to check for illegal aliasing, since you never know how large the are is that is not allowed to overlap, but pointers are rarely used in D anyway.

Object references on the other hand are far easier to check: objects cannot overlap, so two references are either equal or noalias. If you want to allow the compiler to optimize a routine for nonaliased arguments, just put in a precondition prohibiting references to identical objects.

For arrays, the matter gets more tricky, but again, arrays have enough semantics that I believe it should be possible to specify and check whether to arrays or slices overlap in memory. The tricky question here is: are two disjunct slices of the same array aliased? The simple way would be to say, that two slices of the same array are always aliased (simple to check, simple to specify, simple to enforce) The more powerful solution would allow disjunct slices to be used as nonaliased objects. (Allowing stuff like copying internal parts of arrays around with full optimization.)

So my uneducated suggestion would be:

* accept that pointers may always be aliased to anything and don't try to optimize too much there.

* prohibit aliased object references by explicit preconditions/assertions

* check closely what "aliasing" means for arrays and slices and find a way to prohibit this kind of aliasing in contracts as well.

The problem certainly is not trivial to solve, but looking at the time that researchers have spent on working it out in C it certainly is worth some more consideration in D...
April 21, 2004
Is a neat idea, but I'm pretty sure, you can simply implement that in the library with the language as it is now. A good language should not cover everything, but it should be slim and still powerful enough to do everything in the library.

lacs wrote:

> Add primitive-units-checking to D and a lot of people who work with
> numbers will fall in love with D. What is primitive-units-checking? It is
> something we miss in C++ or Java(I have never read a line of Fortran :$ ),
> that is being teach in physic 101 and that could have avoid a Nasa probe
> crash on Mars(not the digital one) few years ago(I dont remember the name
> of the probe sorry. It was a forgoten miles-kilometers convertion factor
> problems). Check the following code written in a fictive language and you
> will understand what was meant by primitive-units-checking
> float<meter>        distance = 100.0;
> float<second>       time     =   3.0;
> float<meter/second> speed1;
> float<second>       speed2;
> float<feet/second>  speed3;
> 
> speed1 = distance/time; // no error
> speed2 = distance/time; // generate compile-time error
> speed3 = distance/time; // ok only if the compiler knows the conversion
> 
> // factor between meters and foot because the
> //compiler can do the conversion for us automatically
> 
> As you migth have guessed, the notation float<meter> has nothing to do with c++ templates and wouldnt interfere with it since it can only be used with primitives. Notice that float<meter> still is a primitive. Of course, a lots of units are way more complex than meter/second in scientific equations. And its what would make primitive units checking a time-saving feature in D for scientific computing.
> 
> 
> newbie11234

April 21, 2004
Norbert Nemec wrote:

> Hi there,
> 
> as you might have gathered from my previous posts, I am quite interested in
> numerical/scientific computing.
> 
> 
> Ciao,
> Nobbi

It would be nice to have classes for really big numbers inside phobos.
April 21, 2004
"Norbert Nemec" <Norbert.Nemec@gmx.de> wrote in message news:c66quv$2fe5$1@digitaldaemon.com...
> Anyhow, the problem of both, the Fortran- as well as the C-"restrict"-solution, that I see is, that in both cases, you "demand"
that
> pointers are not aliased, without being able to check it.

Correct.

> Of course, it is not possible to check this in every case at compile time (if it were possible, C compilers would not have a problem),

Correct.

> but maybe, we
> can at least identify a class of situations where it is possible? Or,
> alternatively enforce nonaliasing parameters via preconditions, so it is
> checked in debugging mode?

This is a possibility.

> For plain pointers it rather hard to check for illegal aliasing, since you never know how large the are is that is not allowed to overlap, but pointers are rarely used in D anyway.

It might be reasonable to constrain the requirement to be just for arrays and objects, not pointers.

> Object references on the other hand are far easier to check: objects
cannot
> overlap, so two references are either equal or noalias.

This is, unfortunately, not true when you get into interfaces. It's also possible for pointers into class objects, as well as arrays referencing into class objects.

> If you want to
> allow the compiler to optimize a routine for nonaliased arguments, just
put
> in a precondition prohibiting references to identical objects.

Historically, adding in special keywords for such optimizations has not worked out well. That's why I was thinking of making it implicit for D function parameters.

> For arrays, the matter gets more tricky, but again, arrays have enough semantics that I believe it should be possible to specify and check
whether
> to arrays or slices overlap in memory. The tricky question here is: are
two
> disjunct slices of the same array aliased? The simple way would be to say, that two slices of the same array are always aliased (simple to check, simple to specify, simple to enforce) The more powerful solution would allow disjunct slices to be used as nonaliased objects. (Allowing stuff like copying internal parts of arrays around with full optimization.)

Yes, it should be possible to have disjoint slices treated as noaliased.

> So my uneducated suggestion would be:
>
> * accept that pointers may always be aliased to anything and don't try to optimize too much there.

This is a good idea, but I'm concerned it may not be sufficient.

> * prohibit aliased object references by explicit preconditions/assertions

Having the compiler insert runtime checks for debug builds is a good idea. Unfortunately, as you pointed out, adding runtime checks for aliased pointers is impossible.

> * check closely what "aliasing" means for arrays and slices and find a way to prohibit this kind of aliasing in contracts as well.
>
> The problem certainly is not trivial to solve, but looking at the time
that
> researchers have spent on working it out in C it certainly is worth some more consideration in D...

Solving it is worthwhile, as it removes a major barrier to the Fortran crowd being interested in upgrading to D. C/C++ failed to supplant Fortran largely for this reason. C99's "restrict" keyword is an ugly kludge (and D users all know how much I hate type modifiers <g>).


April 21, 2004
I agree with that.

Want to write them?

"Stephan Wienczny" <wienczny@web.de> wrote in message news:c66tm4$2k9o$1@digitaldaemon.com...
> Norbert Nemec wrote:
>
> > Hi there,
> >
> > as you might have gathered from my previous posts, I am quite interested in numerical/scientific computing.
> >
> >
> > Ciao,
> > Nobbi
>
> It would be nice to have classes for really big numbers inside phobos.


April 21, 2004
Matthew wrote:

> I agree with that.
> 
> Want to write them?
> 

> 
I actually started to months ago, but then wanted to wait until DTL finishes ;-)
April 21, 2004
Stephan Wienczny wrote:

> Matthew wrote:
>
> I actually started to months ago, but then wanted to wait until DTL finishes ;-)

Your quick. <g>

-- 
-Anderson: http://badmama.com.au/~anderson/